This File Transfer Doesn't Use the Internet At All (decimen)
BBetter Stack
Computing/SoftwareConsumer ElectronicsInternet Technology
Transcript
00:00:00Here's a question. How do you send someone a file without using a network and without using any
00:00:05physical devices like USB sticks? Well, the answer is optical file transfer. A developer named Evan
00:00:13Crawley just built a tool called Deciman, which is capable of sending a file from one device to
00:00:19another just by flashing QR codes and reading them back. It's a super cool file transfer technique
00:00:26and it uses some pretty clever engineering tactics. So in today's video, we'll take a look
00:00:31at Deciman, see how it works and test it out on different scenarios to see how powerful optical
00:00:37file transfer actually is. It's going to be a lot of fun, so let's dive into it.
00:00:46So Deciman works like this. One device displays a stream of QR code-like frames on its screen
00:00:53and another device points a camera at it and decodes them back into a file. So there's no network stack
00:01:00involved at all. So if you ever needed to exchange a file with an air gap device, this is the only way
00:01:06to do it without physically plugging in any external devices like USB drives. And the idea is that you
00:01:12encode your file as a sequence of QR codes, flash them on screen one after the other, and have a camera
00:01:19on the other end capture and decode each frame. Now that might sound simple, but the complication arises
00:01:26from the fact that cameras don't actually capture instantaneously, and screens don't refresh
00:01:32instantaneously. So you're racing two different pieces of hardware against each other, and if they get out of sync,
00:01:38frames get corrupted or missed entirely. But Deciman's answer to this problem is a method called fountain coding.
00:01:46Instead of sending frame one, frame two, frame three, and hoping every single one lands,
00:01:53it generates an effectively unlimited stream of encoded frames where each frame is a mathematical blend
00:02:00of pieces of the original file rather than one specific chunk of it. That means no single frame is irreplaceable.
00:02:07The receiver doesn't need frame number 47 specifically, it just needs enough frames, whichever ones happen to land.
00:02:14And if you miss half of them, that doesn't matter. It just keeps broadcasting until the receiver has collected
00:02:22enough of them. But this approach is no way a silver bullet. With this method, there is a ceiling to how much data
00:02:29we can transfer. By default, Deciman's sender pushes 2953 bytes per frame at 60 frames per second.
00:02:37If you do the math on that, you get a theoretical ceiling of roughly 177 kilobytes per second.
00:02:44Factor in the overhead from fountain coding, since some of those blended frames are essentially redundant by design.
00:02:51And what you're left with is the number that Deciman's readme file actually claims.
00:02:56It peaks at around 128 kilobytes per second when measured phone to phone.
00:03:02And the reason why it uses 2953 byte chunks specifically is because it corresponds to QR code version 40,
00:03:11the largest standard QR size, a 177 by 177 grid of individual modules packed into a single frame.
00:03:20And that's where the real trade-off shows up. If you cram more data into a frame, you need fewer frames
00:03:26overall to send the same file, which means whatever camera is reading it back needs more resolution,
00:03:33a steadier hand, and a sharper focus to tell one module from the next.
00:03:38So the entire system is really a balancing act between three variables.
00:03:42How many frames per second you're sending, how dense each one of those frames is, and how good the receiving
00:03:49camera actually is at resolving that density. And Deciman ships with one specific balance dialed in by default,
00:03:57and it's tuned for one specific scenario, which as I found, is not the scenario I tested it in.
00:04:03So here's my setup: a laptop screen as the sender, sitting at a normal arm's length distance,
00:04:09like you'd actually use this in practice. With this setup, my transfer capped at about three kilobytes per second.
00:04:16Roughly one to two percent of transmitted frames are actually being decoded. The rest are captured and thrown away.
00:04:23Now there are three things that are stacking up against us here. The first and the biggest hurdle is frame rate mismatch.
00:04:30The sender is pushing 60 frames per second, but my phone's camera captures at 30. You cannot sample 60 distinct images
00:04:38with a sensor that's only grabbing 30. And it's worse than just missing half of them, because the exposure window on each
00:04:45captured frame straddles two different QR codes on screen. So the camera doesn't cleanly miss a frame. It blends two of them together into something that decodes to nothing.
00:04:56And in the main.ts file, there's even a note that says that iOS will silently deliver 30 frames per second, even when the app explicitly asks the camera for 60.
00:05:07The camera just doesn't give you what you requested, and the code already addresses that.
00:05:12And a little further down in the same file, there's a comment that basically predicts exactly what happened to me on my first attempt.
00:05:19The defaults, which are the 2953 bytes per frame at 60 frames per second, are tuned specifically for close range phone to phone demo.
00:05:29And that same combination is expected to struggle on an ordinary monitor at arm's length.
00:05:35In other words, the project told me this would happen. I just hadn't scrolled far enough in the code to see it.
00:05:41On the sending side, a 60 hertz laptop panel has the same problem in reverse. And LCD pixels take a lot of time to fully transition color gray to gray.
00:05:51And that setting time means the panel hasn't fully arrived at one code before the next one starts painting over it.
00:05:58So you're getting ghosting artifacts. And the second problem is code density versus camera resolution.
00:06:042953 bytes is QR version 40, but reliable decoding needs roughly three to four camera pixels per module, which works out to 600 plus pixels across in sharp focus just for the code itself.
00:06:20And the laptop screen held at arm's length rarely fills that much of a phone's camera frame, but phone to phone at close range fills the entire viewfinder easily.
00:06:30And the third problem is brightness and contrast. It's a secondary issue, but it helps if the receiver's binarizer threshold the image cleanly, but it still can't fix a frame rate mismatch or an undersized code.
00:06:44So now let's try to do the same transfer, but this time from one phone to another phone.
00:06:50So the only thing that changes is the sender. It's a small bright OLED screen held close, filling the receiving phone's entire frame.
00:06:58Now the camera can actually hit closer to its real frame rate.
00:07:02The code fills the frame at high resolution and there's no LCD ghosting to fight with.
00:07:07This is the scenario that the 128 kilobyte per second number in the readme file was actually measured under.
00:07:14There's also a small but genuinely useful detail in the receiver's code.
00:07:18It reports capture FPS and decode FPS separately. Capture tells us what the camera is physically seeing.
00:07:26Decode tells you how much of that is actually usable.
00:07:30When those two numbers pull apart from each other, so capture staying healthy while decode craters,
00:07:35you're looking at a mismatch between how dense the frames are and what the camera can actually resolve at that range.
00:07:42So if laptop to phone is your actual use case, the fix is to rebalance those three variables on the sender's side.
00:07:50You should drop bytes per frame down to 1465, which corresponds to a coarser QR version with bigger, more forgiving modules.
00:07:59And then drop the transmit FPS to 24 deliberately below the camera's 30 FPS ceiling.
00:08:07So frames get sampled cleanly one at a time instead of blending into each other.
00:08:12And as you can see, lowering these numbers yield a much bigger throughput.
00:08:16So this just shows you that optical file transfer is not a one size fits all solution.
00:08:21You have to manually tweak it for every use case depending on the hardware you're using.
00:08:26So there you have it, folks.
00:08:27That is Deciman in a nutshell.
00:08:29Overall, this was a genuinely fun project to dig into.
00:08:32Optical file transfer is a pretty cool technique.
00:08:36And seeing the fountain coding concept being applied in a real case scenario here was really interesting to see.
00:08:44And while I was exploring this project, I was also thinking, where would you actually use this kind of tool?
00:08:49I guess the obvious answer would be for air gapped transfers where you deliberately don't want any network connection at all.
00:08:57Or maybe devices that don't even have Bluetooth or Wi-Fi like old hardware or embedded systems.
00:09:04I mean, anywhere where a screen and a camera are the only two things you can count on.
00:09:10But what do you think about this tool?
00:09:11Have you used optical transfer tools before?
00:09:14Do you see any real life application for this?
00:09:17Let us know in the comments section down below.
00:09:19And folks, if you like these types of technical breakdowns, please let me know by smashing that like button underneath the video.
00:09:25And also don't forget to subscribe to our channel.
00:09:28This has been Andrus from BetterStack and I will see you in the next videos.
00:09:34I'll see you in the next video.