Software Hacks

We can tell that [Jon Howell] is our kind of guy. After updating his vintage 1985 Hewlett-Packard plotter with WiFi and the ability to load SVG files, he obviously needed to find a bunch of stuff to run off with it. Gotta justify those hacks somehow. So he doubled down and decided support a hack with another hack by writing a maze generator to keep his plotter well fed. He was kind enough to unleash his creation on an unsuspecting Internet as an open source project, and now we all can benefit from a couple of reams worth of mazes.

The generator itself is written in Java, and should work on whatever operating system your box happens to be running thanks to the *nix and Windows wrapper scripts [Jon] provides. To create a basic maze, one simply needs to provide the script with the desired dimensions and the paper size. You can define the type of paper with either standard sizes (such as --paper a4) or in the case of a plotter with explicit dimensions (--paper 36x48in).

If you aren’t a big fan of right angles, there’s support for changing the internal geometry of the maze to use a hexagonal or triangle grid. You can even pass the program a black and white PNG “mask” which it will use as the boundaries for the maze itself, allowing for personalized puzzles of whatever shape catches your fancy. [Jon] even ran the Wrencher though his software, leading to the creation of a maze which we can neither confirm nor deny will be making an appearance on our Christmas cards this year.

You have a clean MSDOS system, and you need to write some software for it. What do you do? You could use debug, of course. But there are no labels so while you can get machine code from mnemonics, you’ll still need to figure out the addresses on your own. That wasn’t good enough for [mniip], who created an assembler using mostly batch files. There are a few .COM files and it looks as if the first time you use debug to create those, but there’s also source you can assemble on subsequent builds with the assembler.

Why? We aren’t entirely sure. But it is definitely a hack. The technique sort of reminded us of our own universal cross assembler — sort of.

Jennifer Wang likes to dress up for cosplay and she’s a Harry Potter fan. Her wizarding skills are technological rather than magical but to the casual observer she’s managed to blur those lines. Having a lot of experience with different sensors, she decided to fuse all of this together to make a magic wand. The wand contains an inertial measurement unit (IMU) so it can detect gestures. Instead of hardcoding everything [Jennifer] used machine learning and presented her results at the Hackaday Superconference. Didn’t make it to Supercon? No worries, you can watch her talk on building IMU-based gesture recognition below, and grab the code from GitHub.

Naturally, we enjoyed seeing the technology parts of her project, and this is a great primer on applying machine learning to sensor data. But what we thought was really insightful was the discussions about the entire design lifecycle. Asking questions to scope the design space such as how much money can you spend, who will use the device, and where you will use it are often things we subconsciously answer but don’t make explicit. Failing to answer these questions at all increases the risk your project will fail or, at least, not be as successful as it could have been.

Mankind’s fascination with airplanes is unbroken. Whether you’re outside with your camera, getting an actual glimpse of the aircraft, or sitting at home with your RTL-SDR dongle and have a look at them from a distance, tracking them is a fun pastime activity. Provided, of course, that you are living close by an airport or in an area with high enough air traffic. If not, well there’s always real-time tracking online to fall back to, and as [geomatics] will show you, you can build your own live flight tracking system with a few lines of Python.

As it’s usually the case with Python, a lot of functionality is implemented and readily available from external modules, which lets you focus on the actual application without having to worry too much about the details. Similarly, plenty of data can be requested from all sorts of publicly accessible APIs nowadays. If you are looking for a simple-enough example to get into both subjects with a real-world application, [geomatics]’ flight tracker uses cartopy to create a map using Open Street Map data, and retrieves the flight information from ADS-B Exchange‘s public API.

While desktop computers have tons of computing power and storage, some small CPUs don’t have a lot of space to store things. What’s more is some CPUs don’t do multiplication and division very well. Same can be said for FPGAs. So suppose we are going to grab a bunch of three-digit decimal numbers from, say, a serial port. We want to store as many as we can, and we don’t want to do a lot of math because we can’t, it is slow, or perhaps it keeps our processor awake longer and we want to sleep to conserve power. We want a way to pack the numbers as close to the theoretical maximum as we can but with little or no math.

The simple approach is to store the numbers as ASCII. Great for processing since they are probably in ASCII already. If they aren’t, you just add 30 hex to each digit and you are done. That’s awful for storage space, though, since we can store 999 in 10 bits if it were binary and now we are using 24 bits! Storing in binary isn’t a good option, if you play by our rules, by the way. You need to multiply by 10 and 100 (or 10 twice) to get the encoding. Granted, you can change that to two shifts and an add (8x+2x=10x) but there’s no easy way to do the division you’ll have to do for the decode.

Of course, there’s no reason we can’t just store decimal digits. That’s call binary coded decimal or BCD and that has some advantages, too. It is pretty easy to do math on BCD numbers and you don’t get rounding problems. Some CPUs even have specific instructions for BCD manipulation. However, three digits will require 12 bits. That’s better than 24, we agree. But it isn’t as good as that theoretical maximum. After all, if you think about it, you could store 16 distinct codes in 4 bits, and we are storing only 10, so that 6 positions lost. Multiply that by 3 and you are wasting 18 codes.

But there is a way to hit that ten-bit target without doing any math. Its called DPD or densely packed decimal. You can convert three decimal digits into ten bits and then back again with no real math at all. You could implement it with a small lookup table or just do some very simple multiplexer-style logic which means it is cheap and easy to implement in software or onboard an FPGA.

Throughout human history, people try to make the biggest, the fastest, and — sometimes — the smallest. [Hellmood] falls into the latter category and proves it with a 64 byte interactive 3D raycasting application for MSDOS.

Why MSDOS? We suppose why not? The .COM file format is lean, and you can take over everything without a lot of work. If the program were huge, it wouldn’t be very impressive. There are 64 shades of gray which is odd looking these days, however there are versions that use various color palettes and each one fits in 64 bytes or less. There’s even mouse control and you can see the results in the video below.

In systems where there are multiple participants who need to interact with a shared resource some sort of concurrency protection is usually appropriate. The obvious technique is to use locking (and fun words like “mutex”) but this adds a constant performance hit as every participant needs to spend time interacting with the lock regardless of the number of other participants. It turns out this is actually a Big Problem that garners original research, but there are techniques that can yield great effect without a PhD. Years ago [Marc] posted a great walkthrough of one such method, exponential backoff with jitter, to Amazon’s AWS blog which is a great introduction to one such solution.

The blog post was written specifically to deal systems using a specific technique called optimistic concurrency control (OCC) but that doesn’t mean the advice isn’t generally applicable. OCC refers to a method where each writer checks for a write collision only after performing the write (but before committing it), which works well in scenarios where writes are relatively uncommon. [Marc] observed that even in systems where this is a safe assumption things bog down significantly when there are too many writers clamoring for attention all at once.

The traditional solution to such a problem is for each writer to pause for an exponentially increasing amount of time before trying again, but as writers come back in big groups the same problem can recur. He provides a discussion of simple modifications to that strategy which result in significantly reduced wait times for writers.

Problems like this are not especially relevant for single Arduino sensor networks, but even small groups of systems can have concurrency trouble and it’s nice to see such an accessible write up with solutions which are viable even for simple systems. Bonus points to [Marc] for posting source to his test tool online. It doesn’t require anything outside of your computer to run (no AWS required) so if you have any brainwaves about speeding up multi-writer environments it might make a nice test environment! Maybe don’t mention the blog post in your PhD applications though.