Color Can Triple QR Code Capacity

Recently [mit41301] wondered about increasing the data capacity of QR codes, and was able to successfully triple the number of bits using color. He chose the new rectangular micro QR code (rMQR) standard which was adopted last year as ISO/IEC 23941:2022. This rectangular-shaped QR code is designed to be used on narrow spaces, with an aspect ratio similar to that of a traditional 1D bar code. There are quite a few variations of rMQR, but the largest can hold 361 bytes. The basic idea is to generate three different rMQR codes, coloring them as red, green, blue, and merging the result. Decoding is performed by separating the color image into its RGB components and then decoding the resulting three images.

To do these experiments, [mit41301] took advantage of readily available tools. Generating rMQR codes can be done with this Python module by [Takahiro Tomita], who also makes the generator available online. Or if you’re more comfortable with Go, check out this repository by [Ichinose Shogo]. As a proof-of-concept, [mit41301] takes the first 449 digits of pi, plus the decimal point, and splits them into three each 150 byte chunks. Then he uses the image manipulation program ImageJ, an open-source Java program developed at the National Institutes of Health, to implement the combination and deconstruction processes.

The first 449 digits of pi expressed as a colorful rMQR code

There might be a few pitfalls if you want to do this outside the laboratory, however. First of all, this standard is reasonably new, and after a brief search this author couldn’t find any decoder that would recognize rMQR codes, nor any software modules or libraries. Research into colorization of QR codes, known as HCC2D (High Capacity Colored 2-Dimensional) codes has been ongoing. One issue is that correcting for arbitrary chromatic abnormalities in a scanner’s lens requires a baseline color palette in the code, which eats up some of the newly-gained data capacity.

Nonetheless, we really do like this concept. Do you have any applications of QR codes in your projects where coloring could be helpful? Is anyone using (monochrome) rMQR codes and if so, how are you scanning them? Check out our overview of barcodes, their history, and their future, in this recent article.

Would We Recognize Extraterrestrial Technology If We Saw It?

There’s a common critique in science fiction series like Star Trek about the extraterrestrial species not looking ‘alien’ enough, as well as about their technology being strangely similar to our own, not to mention compatible to the point where their widgets can be integrated into terrestrial systems by any plucky engineer. Is this critique justified, or perhaps more succinctly put: if we came across real extraterrestrial life with real extraterrestrial technology, would we even notice? Would an alien widget borrowed of an alien spacecraft even work with our own terrestrial spacecraft’s system?

Within the domain of exobiology there are still plenty of discussions on the possible formation and evolutionary paths conceivable within the Universe, but the overarching consensus seems to be that it’s hard to escape the herding effect of fundamental physics. For lifeforms, carbon-based chemistry is the only reasonable option, and when it comes to technology, it’s hard to not end up at technology using the same physical principles which we presume to exist across the Universe, which would practically guarantee some level of interoperability.

What’s notable here is that over the past years, a number of people have claimed to have observed potential alien technology in our Solar System, in particular the ʻOumuamua asteroid in 2017 and a more recent claim by astrophysicist Abraham Loeb regarding an interstellar meteor that impacted Earth in 2019, which he says could be proof of ‘alien technology’. This raises the question of whether we are literally being pummeled by extraterrestrial spacecraft these days.

Continue reading “Would We Recognize Extraterrestrial Technology If We Saw It?”

Hackaday Podcast 229: DIY VR, Gutting Voice Assistants, And ChatGPT Failing Its Summer Internship

This week, Editor-in-Chief Elliot Williams and Kristina Panos braved the slight cold and the high heat respectively to bring you the best hacks of the previous seven days. In the news this week: you’ve got a second and final chance to get your Supercon talk proposals in!  So get on that, because we need YOU to help make Supercon awesome.

We can chalk up a win for Kristina on What’s That Sound this week (finally!). Will you get it right? Will you get it exactly right? Time and Elliot’s fancy dice will tell.

Then it’s on to the hacks, where we check out a cool RFID emulator e-paper badge, discuss whether a certain type of record player is better off as a cyberdeck, and look through the eye of a Gameboy-style camera for the Playdate console.

From there we take a look at gutting and rooting voice assistants, a solenoid keyboard, and a beautifully rebuilt VR headset that now does AR as well. Finally we talk autonomous solar boats, lambast ChatGPT as the worst summer intern ever, and ponder what makes a thing count as Linux or not.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Download and savor at your leisure.

Continue reading “Hackaday Podcast 229: DIY VR, Gutting Voice Assistants, And ChatGPT Failing Its Summer Internship”

Pizza Elevator Is The Most Vital Pandemic Technology Of All

Remember the darkest days of lockdown and the pandemic? We were trying to distance ourselves from strangers wherever possible. [scealux]’s pizza elevator was spawned at this time to make apartment pizza deliveries as contactless as possible, and it’s charmingly branded to boot.

The build was intended to loft a pizza from street level to a third-floor balcony (by the American convention, ground floor is numbered one). Built with CNC-cut wooden parts, the elevator frame snap-fits on to the balcony railing. From there, a single spool runs out wire to four corners of the elevator platform.

As the crank is turned, the platform lowers under its own weight. The pizza can then be placed on the platform, and dinner can be lifted back up to the apartment. It’s a simple design, and one that manages to lift the pizza in a stable and flat fashion. With that said, we’d still like to see some anti-tip railings on a potential revision two.

Mock the branding all you will, it’s actually a smart design choice. The recognizable logo made the device’s purpose super obvious to the pizza delivery person, easing the introduction of the technology to a new user base.

If you want to make your own pizza instead of ordering out, you can automate that too.

Continue reading “Pizza Elevator Is The Most Vital Pandemic Technology Of All”

This Week In Security: Zenbleed, Web Integrity, And More!

Up first is Zenbleed, a particularly worrying speculative execution bug, that unfortunately happens to be really simple to exploit. It leaks data from function like strlen, memcpy, and strcmp. It’s vulnerable from within virtual machines, and potentially from within the browser. The scope is fairly limited, though, as Zenbleed only affects Zen 2 CPUs: that’s the AMD Epyc 7002 series, the Ryzen 3000 series, and some of the Ryzen 4000, 5000, and 7020 series of CPUs, specifically those with the built-in Radeon graphics.

And at the heart of problem is a pointer use-after-free — that happens inside the CPU itself. We normally think of CPU registers as fixed locations on the silicon. But in the case of XMM and YMM registers, there’s actually a shared store of register space, and the individual registers are mapped into that space using a method very reminiscent of pointers.

Continue reading “This Week In Security: Zenbleed, Web Integrity, And More!”

An E-ink display showing Conway's Game of Life, with a solar cell beneath it

Solar Powered Game Of Life Follows The Sun’s Rhythm

Conway’s Game of Life is a beautiful example of how complex behavior can emerge from a few very simple rules. But while it uses biological terminology such as “cells”, “alive” and “generation”, the basic game is too simplistic to be a model for any real-world biological process. It’s easy to add features to make it a bit more life-like, however, as [David Hamp-Gonsalves] has done by giving the Conway’s creation something of a circadian rhythm.

The basic idea is that the speed at which [David]’s Game of Life evolves is governed by the amount of ambient light. The game runs off a solar cell that charges a battery, with the battery’s voltage determining how long it takes to advance the game by one generation. The system is therefore highly active in full sunlight, and grinds almost to a complete halt at night.

An ESP32 runs the simulation and outputs the result to a 400 x 300 pixel e-ink display. The display is extremely power-efficient by its very nature; the ESP’s main processor core, on the other hand, is deliberately placed into deep sleep mode most of the time to save as much power as possible. The Ultra Low Power (ULP) co-processor, meanwhile, keeps an eye on the lithium battery’s voltage as it’s slowly being charged by the solar cell. When the voltage reaches 3.3 V, the main CPU wakes up and computes the Game’s new state. In bright sunlight this happens every few seconds, while on an overcast day it could take minutes or even hours.

[David]’s interesting idea of changing Life‘s activity based on the amount of energy available turns the Game into something resembling a cold-blooded animal. We’ve seen a similar approach in a “solar creature” that runs a Life-life simulation on a seven-segment LCD. If it’s speed you care about however, you’re better off implementing Life in an FPGA.

A Deep Dive On Battery Life

There are all kinds of old wives’ tales surrounding proper battery use floating around in the popular culture. Things like needing to fully discharge a battery every so often, unplugging devices when they’re fully charged, or keeping batteries in the fridge are all examples that have some kernel of truth to them but often are improperly applied. If you really want to know the truth about a specific battery, its behavior, and its features, it helps to dig in and actually take some measurements directly like [Tyler] has done with a vast array of embedded batteries in IoT devices.

[Tyler] is a firmware engineer by trade, so he is deeply familiar with this type of small battery. Battery performance can change dramatically under all kinds of scenarios, most important among them being temperature. But even the same type of battery can behave differently to others that are otherwise identical, which is why it’s important to have metrics for the batteries themselves and be able to measure them to identify behaviors and possible problems. [Tyler] has a system of best practices in place for monitoring battery performance, especially after things like firmware upgrades since small software changes can often have a decent impact on battery performance.

While working with huge fleets of devices, [Tyler] outlines plenty of methods for working with batteries, deploying them, and making sure they’re working well for customers. A lot of it is extremely useful for other engineers looking to develop large-scale products like this but it’s also good knowledge to have for those of us rolling out our own one-off projects that will operate under battery power. After all, not caring for one’s lithium batteries can have disastrous consequences.