It seems like only yesterday we covered a project using QR codes to archive data on paper (OK, it was last Thursday), so here’s another way to do it, this time with a dedicated codec using the full page. Optar or OPTical ARchiver is a project capable of squeezing a whopping 200 Kb of data onto a single A4 sheet of paper, with writing and reading achieved with a standard laser printer and a scanner. It’s a bit harder than you might think to get that much data on the page, given that even a 600 DPI printer can’t reliably place every dot each time. Additionally, paper is rarely uniform at the microscopic scale, so Optar utilizes a forward error-correcting coding scheme to cater for a little irregularity in both printing and scanning.

The error-correcting scheme selected was an Extended Golay code (24, 12, 8),  which, interestingly, was also used for image transmission by the NASA Voyager 1 and 2 missions. In information theory terms, this scheme has a minimum Hamming Distance of 8, giving detection of up to seven bit errors. This Golay code implementation is capable of correcting three-bit errors in each 24-bit block, with 12 bits available for payload. That’s what the numbers in those brackets mean.

Another interesting problem is paper stretch during printing. A laser printer works by feeding the paper around rollers, some of which are heated. As a printer wears or gets dirty, the friction coefficient along the rollers can vary, leading to twisting and stretching of the paper during the printing process. Water absorbed by the paper can also lead to distortion. To compensate for these effects, Optar regularly inserts calibration targets throughout the bit image, which are used to locally resynchronize the decoding process as the image is processed. This is roughly similar to how the alignment patterns work within larger QR codes. Finally, similar to the position detection targets (those square bits) in QR codes, Optar uses a two-pixel-wide border around the bit image. The border is used to align to the corners well enough to locate the rows of bits to be decoded.

In the distant past of last week, we covered a similar project that uses QR codes. This got us thinking about how QR codes work, and even if encoding capacity can be increased using more colors than just black and white?

Thanks to [Petr] for the tip!

QR codes are used just about everywhere now, for checking into venues, ordering food, or just plain old advertising. But what about data storage? It’s hardly efficient, but if you want to store your files in a ridiculous paper format—there’s a way to do that, too!

QR-Backup was developed by [za3k], and is currently available as a command-line Linux tool only. It takes a file or files, and turns them into a “paper backup”—a black-and white PDF file full of QR codes that’s ready to print. That’s legitimately the whole deal—you run the code, generate the PDF, then print the file. That piece of paper is now your backup. Naturally, qr-backup works in reverse, too. You can use a scanner or webcam to recover your files from the printed page.

Currently, it achieves a storage density of 3KB/page, and [za3k] says backups of text in the single-digit megabyte range are “practical.” You can alternatively print smaller, denser codes for up to 130 KB/page.

Is it something you’ll ever likely need? No. Is it super neat and kind of funny? Yes, very much so.

We’ve seen some other neat uses for QR codes before, too—like this printer that turns digital menus into paper ones. If you’ve got your own nifty uses for these attractive squares, let us know!

If you’ve been reading Hackaday for awhile, you’ll know we’re big fans of OpenSCAD around these parts. There’s a number of reasons it’s a tool we often reach for, but certainly one of the most important ones is its parametric nature. Since you’re already describing the object you want to generate with code and variables, it’s easy to do things like generate an arbitrary number of cloned objects by using a for loop.

There are a number of fantastic OpenSCAD libraries that explore this blurred line between code and physical objects, and one that recently caught our eye is scadqr from [xypwn]. The description says it lets you “Effortlessly generate QR codes directly in OpenSCAD”, and after playing around with it for a bit, we have to agree.

How effortlessly are we talking about? Take a look:

Yeah, that’s pretty damn easy. Even better, there’s no alphabet soup of libraries or APIs going on behind the scenes here. It’s just a single file you include in your OpenSCAD script. In fact, you don’t even need to go that far. As [xypwn] explains, the source for the library itself is just the one file, so you could just copy its code right into your project if you didn’t want to have to pull it in as an include. That could be especially handy if you’re deploying this code somewhere that doesn’t let you pull in external files, like Thingiverse’s Customizer.

Now, there’s all sorts of reasons you might want to create a QR code from within OpenSCAD. But one of first ones that popped into our heads is for the purposes of part identification. Forget simple version numbers, this library would let you physically embed all sorts of ancillary data into your printed components, like who rendered them and at what time. Or perhaps each printed part in an assembly could have a unique QR code that pointed to its respective page in your online documentation.

Got any interesting ideas? Let us know in the comments.