Before the days of MP3 players and smartphones, and even before portable CD players, those of us of a certain age remember that our cassette players were about the only way to take music on-the-go. If we were lucky, they also had a built-in radio for when the single tape exhausted both of its sides. Compared to then, it’s much easier to build a portable radio even though cassettes are largely forgotten, as [wagiminator] shows us with this radio design based on an ATtiny.

The build is about as compact as possible, with the aforementioned ATtiny 402/412 as its core, it also makes use of an integrated circuit FM tuner,  an integrated audio amplifier with its own single speaker, and a small OLED display. The unit also boasts its own lithium-polymer battery charger and its user interface consists of only three buttons, plenty for browsing radio stations and controlling volume.

The entire build fits easily in the palm of a hand and is quite capable for a mobile radio, plus all of the schematics and code is available on the project page. While it doesn’t include AM capability, just the fact that FM is this accessible nowadays when a few decades ago it was cutting-edge technology is quite remarkable. If you’re looking for an even smaller FM receiver without some of the bells and whistles of this one, take a look at this project too.

We’re suckers for alternative data transmission methods, and [Georgi Gerganov]’s ggwave made us smile. At its core, it’s doing what the phone modems of old used to do – sending data encoded as different audio tones. But GGwave does this with sophistication!

It splits the data into four-bit chunks, and uses 16 different frequency offsets to represent each possible value. But for each chunk, these offsets are added to one of six different base frequencies, which allows the receiving computer to tell which chunk it’s in. It’s like a simple framing concept, and it makes the resulting data sound charmingly like R2-D2. (It also uses begin and end markers to be double-sure of the framing.) The data is also sent with error correction, so small hiccups can get repaired automatically.

What really makes ggwave shine is that it’s ported to every platform you care about: ESP32, Arduino, Linux, Mac, Windows, Android, iOS, and anything that’ll run Python or JavaScript. So it’ll run in a browser. There’s even a GUI for playing around with alternative modulation schemes. Pshwew! This makes it easy for a minimalist microcontroller-based beeper button to control your desktop, or vice-versa. An ESP32 makes for an IoT-style WiFi-to-audio bridge. Write code on your cell phone, and you can broadcast it to any listening microcontroller. Whatever your use case, it’s probably covered.

Now the downside. The data rate is slow, around 64-160 bits per second, and the transmission is necessarily beepy-booopy, unless you pitch it up in to the ultrasound or use the radio-frequency HackRF demo. But maybe you want to hear when your devices are talking to each other? Or maybe you just think it’s cute? We do, but we wouldn’t want to have to transmit megabytes this way. But for a simple notification, a few bytes of data, a URL, or some configuration parameters, we can see this being a great software addition to any device that has a speaker and/or microphone.

Oh my god, check out this link from pre-history: a bootloader for the Arduino that runs on the line-in.

[Jacob Geigle] had a problem. A GPS unit and a Bluetooth-to-serial were tying up all the hardware UARTs on an AVR Arduino project. “Software serial”, I hear you say. But what if I told you [Jacob] already had the board in question sending out data over CAN bus?

[Jacob]’s sweet hack creates an arbitrary number of CAN “devices” inside the Arduino code, and can treat each one of them as its own serial data channel. The “N” in CAN stands for network, after all. The trick is to create a device ID for each desired CANSerial interface, which is done in his library using the usual Arduino setup step. A buffer takes care of storing all the different channels until they can be pushed out over the hardware CAN peripheral. On the big-computer side of things, some software listens for the different “device” enumeration IDs and assigns each a virtual serial port.

While this was a hack born of necessity, we can see it as a clever opportunity to segregate information coming from the microcontroller into different streams. Maybe a debug channel, a command channel, and a data channel? They’re virtual devices, so go nuts!

While we usually see CANbus in its native habitat – inside your car – it’s also cool to think of the uses we could put it to. For instance, controlling a 3D printer. Need a CAN refresher? We’ve got just the ticket.

[Bus photo: Malta Bus; The terminus, Valletta by John Haslam. Can photo: Paint Cans by Daniel R. Blume. Horrible visual pun: I’m afraid that’s on us. You try finding images for CANbus code!]

Drums are an exciting instrument to learn to play, but often prohibitive if there are housemates or close neighbors involved. For that problem there are still electronic drums which can be played much more quietly, but then the problem becomes one of price. To solve at least part of that one, [Jeremy] turned to using an Arduino to build a drum module on his own, but he still had to solve yet a third problem: how to make the Arduino fast enough for the drums to sound natural.

Playing music in real life requires precise timing, so the choice of C++ as a language poses some problems as it’s not typically as fast as lower-level languages. It is much easier to work with though, and [Jeremy] explains this in great detail over a series of blog posts detailing his drum kit’s design. Some of the solutions to the software timing are made up for with the hardware on the specific Arduino he chose to use, including an even system, a speedy EEPROM, hardware timers, and an ADC that can sample at 150k samples per second.

With that being said, the hardware isn’t the only thing standing out on this build. [Jeremy] has released the source code on his GitHub page for those curious about the build, and is planning on releasing several more blog posts about the drum kit build in the near future as well. This isn’t the only path to electronic drums, though, as we’ve seen with this build which converts an analog drumset into a digital one.

Before smartphones exploded on the scene in the late 00s, there was still a reasonable demand for pocket-sized computers that could do relatively simple computing tasks. Palm Pilots and other PDAs (Personal Digital Assistants) were all the rage in the ’90s and early ’00s, although for cutting-edge tech from that era plenty of these devices had astronomical price tags. This Arduino-based PDA hearkens back to that era, albeit with a much more accessible parts list.

The build is based around an Arudino Nano with an OLED screen and has the five necessary functions for a PDA: calculator, stopwatch, games, phonebook, and a calendar. With all of these components on such a small microcontroller, memory quickly became an issue when using the default libraries. [Danko] uses his own custom libraries in order to make the best use of memory which are all available on the project’s GitHub page. The build also includes a custom PCB to keep the entire pocket computer pocket-sized.

There are some other features packed into this tiny build as well, like the breakout game that can be played with a potentiometer. It’s an impressive build that makes as much use of the microcontroller’s capabilities as is possible, and if you enjoy projects where a microcontroller is used as if it is a PC take a look at this Arduino build with its own command-line interface.

The Julia programming language is a horrible fit for a no-frills microcontroller like the ATMega328p that lies within the classic Arduino, but that didn’t stop [Sukera] from trying, and succeeding.

All of the features that make Julia a cool programming language for your big computer make it an awful choice for the Arduino. It’s designed for interactivity, is dynamically typed, and leans heavily on its garbage collection; each of these features alone would tax the Mega to the breaking point. But in its favor, it is a compiled language that is based on LLVM, and LLVM has an AVR backend for C. Should just be a simple matter of stubbing out some of the overhead, recompiling LLVM to add an AVR target for Julia, and then fixing up all the other loose ends, right?

Well, it turns out it almost was. Leaning heavily on the flexibility of LLVM, [Sukera] manages to turn off all the language features that aren’t needed, and after some small hurdles like the usual problems with volatile and atomic variables, manages to blink an LED slowly. Huzzah. We love [Sukera’s] wry “Now THAT is what I call two days well spent!” after it’s all done, but seriously, this is the first time we’ve every seen even super-rudimentary Julia code running on an 8-bit microcontroller, so there are definitely some kudos due here.

By the time that Julia is wedged into the AVR, a lot of what makes it appealing on the big computers is missing on the micro, so we don’t really see people picking it over straight C, which has a much more developed ecosystem. But still, it’s great to see what it takes to get a language designed around a runtime and garbage collection up and running on our favorite mini micro.

Thanks [Joel] for the tip!

If you’ve laid hands on a retro analog TV, have the restoration bug, and you plan to make the final project at least somewhat period-correct, you face a bit of a conundrum: what are you going to watch? Sure, you can serve up just about any content digitally these days, but some programs just don’t feel right on an old TV. And even if you do get suitably retro programming, streaming isn’t quite the same as the experience of tuning your way through the somewhat meager selections as we did back in the analog days.

But don’t worry — this Raspberry Pi TV simulator can make your streaming experience just like the analog TV experience of yore. It comes to us from [Rodrigo], who found a slightly abused 5″ black-and-white portable TV that was just right for the modification. The battery compartment underneath the set made the perfect place to mount a Pi, which takes care of streaming a variety of old movies and shorts. The position of the original tuning potentiometer is read by an Arduino, which tells the Pi which “channel” you’re currently tuned to.

Composite video is fed from the Pi’s output right into the TV’s video input, and the image quality is just about what you’d expect. But for our money, the thing that really sells this is the use of a relay to switch the TV’s tuner back into the circuit for a short bit between channel changes. This gives a realistic burst of static and snow, just like we endured in the old days. Hats off to [Rodrigo] for capturing everything that was awful about TV back in the day — Mesa of Lost Women, indeed! — but still managing to make it look good.

We see a lot of simple pen plotter projects around here, and while we appreciate them one and all, most of them are a little on the slow side. That’s OK — a glacial pace is sometimes all that’s needed, as long as it gets the job done. But there’s nothing wrong with putting the pedal to the metal, so to speak. And that’s exactly what this super-fast Arduino-based plotter is all about.

As the story goes, [IV Projects] felt the need for speed after building an earlier pen plotter project that worked, but failed to excite. With the additional goal of keeping the plotter easy to build with cheap parts, the design centers on a “grit roller drive” for the Y-axis — the one that actually moves the paper back and forth. And move it does, using Dremel tool sanding drums on a lightweight shaft to maximize acceleration. In fact, all the moving parts are kept as lightweight as possible, and the results really show — the three steppers really sing when this plotter is in action.

There are some really clever details in [IV Projects]’ design. We particularly like the way the pen lift mechanism works, and the surprise appearance of a clothespin spring as a belt tensioner was a real treat. Judging by the pile of rejected prototype parts, it took quite a bit of work to get this design right. If you’d like to build your own, STLs are available for the printed parts.

If you’re interested in what the other end of the speed scale looks like, check out this bare-minimum pen plotter.

While low-contrast, blue-on-slightly-less-blue 16-character by 2-line LCDs are extremely popular, they really are made specifically for alphanumeric use. They do an admirable job of displaying a few characters, but they don’t exactly spring to mind as a display for non-character purposes. But displaying video on a 16×2 LCD is possible, as long as you’re willing to stretch the definition of “video” a bit and use some imagination while watching.

Normally, a 16×2 display can only display a single character in each spot, chosen from a fixed character set. But [arduinocelantano] was able to leverage the eight custom character slots the display allows to build up images from arbitrary 5×8 pixel bitmaps. After using ffmpeg to scale the original video to a viewport of eight characters, a Python program was used to turn every frame of the scaled video into code to generate the custom bitmaps for each chunk of the viewport. Even with the low refresh rate of the display and the shrunken frame size, the result is a recognizable video, helped no doubt by the choice of the shadow-puppet Bad Apple!! video. Check it out after the break to see how it looks.

We saw a similar rendering of the same video on LCD a while back; that effort was amazing in that it was an EEPROM-only implementation, along with a somewhat bigger LCD with better contrast. That project served as inspiration for [arduinocelantano]’s build here, which in some ways we think looks a bit better — perhaps it’s the inverted pixels. Either way, hats off to both builders for pushing past the normal constraints and teaching us something interesting.

The HackadayPrize2022 is Sponsored by:

What’s more fun than playing video games? Designing your own video game hardware, of course! If you’ve followed these pages long enough you’ll have seen dozens of great examples of homebrew hardware, and perhaps been inspired to try such a project yourself. This often starts with assembling the basic bits onto a solderless breadboard, which is fine for programming but not so great for testing: squeezing pushbuttons into your breadboard works for basic debugging, but is not very user-friendly or reliable. A better solution can be found in [Dimitar]’s GameBug: a set of breadboard-compatible joypad-like controllers.

The GameBug’s design excels in its simplicity: a miniature analog joystick, four buttons arranged in a diamond pattern, a shoulder button and two sliding switches are sitting on a neat purple PCB. On the bottom are two rows of pin headers to ensure a snug fit on your solderless breadboard. There’s even a little vibrating motor for haptic feedback.

Interfacing with the GameBug is simplified by the integrated readout electronics. A Schmitt trigger-based debounce circuit ensures clean signals from all the pushbuttons, while a motor driver chip provides stable current to the haptic feedback system. An RGB LED can be used as yet another user feedback device, or simply for decorative lighting.

All design files are available on [Dimitar]’s GitHub page, along with an Arduino sketch to help you try out the GameBug’s functionality. Having a proper gamepad might come in handy with breadboard-based game systems like Tiny Duck Hunt or this impressive mess of wires that makes up a Colecovision.