A diagram with one Tag and two Base Stations.

Using Ultra-Wideband For 3D Location And Tracking

August 19, 2025 by John Elliot V 13 Comments

Interested in playing with ultra-wideband (UWB)? [Jaryd] recently put together a fairly comprehensive getting started guide featuring the AI Thinker BU03 that looks like a great place to start. These modules can be used to determine distance between two of them to an accuracy in the order of 10 centimeters, and they can do so in any orientation and with obstacles in the line of sight. It is possible to create a network of these UWB modules to get multiple distance measurements at once and enable real-time 3D tracking for your project.

[Jaryd] gathers up nine UWB modules and uses a Raspberry Pi Pico for command and control purposes. He explains how to nominate the “tag” (the device being tracked) and the “base stations” (which help in locating the tag). He reports having success at distances of up to about 10 meters and in favorable circumstances all the way up to as much as 30 meters.

If you don’t know anything about UWB and would like a primer on the technology be sure to check out What Is Ultra Wideband?

2025 One Hertz Challenge: STM32 Blinks In Under 50 Bytes

August 16, 2025 by Lewin Day 9 Comments

Many of us have run a Blink program on a microcontroller before. It’s effectively the “Hello, World!” of the embedded space. However, few of us have ever thought about optimizing our Blink code to be as miniscule as possible. But that’s precisely what [Rudra Lad] did for this entry into the 2025 One Hertz Challenge!

This example of Blink, delay_blinky_13, is built specifically for the STM32F4 Discovery microcontroller development board. [Rudra] notes the code is “highly optimized” and compiles down to a binary size of under 50 bytes. The code doesn’t even use RAM, and it aims to get the blink as close to 1 Hz as possible. Many optimizations were used to crunch it down as small as possible. For example, the standard startup code isn’t used, with the entire program instead written in the Reset_Handler to save space. Bit-band is also used to write to peripheral registers to blink the LED, since this uses less instructions than the typical methods. Meanwhile, with many tweaks to the delay counting routine, [Rudra] was eventually able to get the blink frequency to 1.00019 Hz, as measured on a logic analyzer. That’s pretty darn close!

While it’s rare that you have only 50 bytes of binary space to blink an LED, work like this is a great way to flex your coding muscles. Code is on Github for the curious, and if you’ve worked up your own impressive tiny binaries, don’t hesitate to let us know!

Walter Is A Tiny Cellular Modem For Your Projects

August 16, 2025 by Tyler August 19 Comments

It wasn’t that long ago that projects with cellular connectivity were everywhere, but with 2G no longer universally available, glory days of cheap 2G modules seem to be on their way out. So when [Data Slayer] titled his video “You’ve Never Seen Cellular Like This” about a new GSM radio module, we couldn’t help but think that we have — and that we’re glad to see it back.

The module is the Walter, by DPTechnics out of Belgium. It’s fully open-source and contains a ESP32-S3 for WiFi and BLE plus a Sequans Monarch chip for GSM and GNSS connectivity. It’s not the blazing-fast 5G you’re paying your phone carrier for: this is an IoT modem, with LTE-M and NB-IoT. We’re talking speeds in the kbps, not Mbps– but we’re also talking very, very low power usage. Since it’s LTE-M rather than full LTE, you’re probably not going to be bringing back the golden days of Arduino Cellphones, (since LTE-M doesn’t support VoLTE) but if LoRa isn’t your jam, and you hang out around cell towers, this level of connectivity might interest you.

Walter is actually a drop-in replacement for PyCom’s old GPy module, so if you had a project in mind for that and are frustrated by it being EoL — well, here you are. [Data Slayer] seemed impressed enough with its capabilities as a GPS tracker. We’re impressed with the 9.8 µA consumed in deep sleep mode, and the fact that it has already been certified with the CE, FCC, IC, RCM and UKCA. Those certs mean you could go from prototype to product without getting tangled in red tape, assuming Walter is the only radio onboard.

Our thanks to [Keith Olson] for phoning in the tip. If you have a tip and want to connect, operators are standing by. Continue reading “Walter Is A Tiny Cellular Modem For Your Projects” →

Open-Source, Flexible E-Reader

August 3, 2025 by Bryan Cockfield 30 Comments

Although the most popular e-reader by far is the Kindle, some argue that its primary use isn’t even as an e-reader at all but rather as a storefront for one of the world’s richest companies. For those who want user-focused consumer electronics instead, we’ll often reach for something more untethered, like an off-brand ebook that’s nothing more than an Android tablet with an e-paper display or even a jailbroken Kindle freed from the chains of Amazon. But as our 555 enthusiast community continually points out, even these are overkill for reading books. Enter the ZEReader.

The ZEReader started out as a bachelor’s engineering thesis project by [Anna-Lena Marx], whose goal was an open-source, microcontroller-based e-reader instead of the Linux or Android ones most commonly available. She’s based the firmware around the Zephyr Real-Time Operating System, which is an RTOS geared towards embedded devices. With this as a backbone, it’s trivially easy to implement the e-reader on different microcontrollers as well as use a wide variety of screens. Although the firmware is a work-in-progress, it’s already mature enough to support all of the basics of an e-reader, such as reading .epub files, navigating through the book, and saving progress. It even includes basic HTML parsing.

Continue reading “Open-Source, Flexible E-Reader” →

2025 One Hertz Challenge: Learn Morse Code One Second At A Time

August 2, 2025 by Tyler August 3 Comments

Learning Morse Code is no longer a requirement for HAMs in many jurisdictions, but it’s still a nice skill to have. [I_void(warranties)] wanted to learn, but couldn’t find a trainer that fit his style. What to do but build it yourself? Since we’re in the midst of a challenge, he took up the gauntlet and turned his need to learn Morse into a 1 hertz Morse code game.

In concept it is quite simple: a message beeps out in Morse, with a corresponding LED flash, all in one second. The player then has one second to type think they heard. Get it done fast enough, and a character LCD will tell you if you scored.

The project is based around an Arduino Nano; thanks to easily-available libraries, a PS/2 keyboard can serve as input and a 2×16 LCD as feedback with no real effort expended. For the audible component of the Morse challenge, an 8-ohm speaker is driven right off a pin on the Arduino. We won’t claim this efficient design only took one second to put together, but it probably didn’t take too long.

Of course this trainer, unlike some we’ve seen, only helps you learn to listen to the stream of dots and dashes. None of the others ever tried to fit a One Hertz theme, or [I_void(warranties)]’s particular learning style. For some, decoupling send and receive might be just the ticket to finally learning Morse one second at a time.

Raspberry Pi RP2350 A4 Stepping Addresses E9 Current Leakage Bug

July 31, 2025 by Maya Posch 31 Comments

When Raspberry Pi’s new RP2350 MCU was released in 2024, it had a slight issue in that its GPIO pins would leak a significant amount of current when a pin is configured as input with the input buffer enabled. Known as erratum 9 (E9), it has now been addressed per the July 29 Product Change Note from Raspberry Pi for the A4 stepping along with a host of other hardware and software issues.

Although the PCN is for stepping A4, it covers both steppings A3 and A4, with the hardware fixes in A3 and only software (bootrom) fixes present in A4, as confirmed by the updated RP2350 datasheet. It tells us that A3 was an internal development stepping, ergo we should only be seeing the A4 stepping in the wild alongside the original defective A2 stepping.

When we first reported on the E9 bug it was still quite unclear what this issue was about, but nearly a month later it was officially defined as an input mode current leakage issue due to an internal pull-up that was too weak. This silicon-level issue has now finally been addressed in the A3 and thus new public A4 stepping.

Although we still have to see whether this is the end of the E9 saga, this should at least offer a way forward to those who wish to use the RP2350 MCU, but who were balking at the workarounds required for E9 such as external pull-downs.

2025 One Hertz Challenge: 555 Timer Gets A Signal From Above

July 24, 2025 by Adam Zeloof 7 Comments

One of the categories we chose for the One Hertz Challenge is “Could Have Used a 555.” What about when you couldn’t have, but did anyway? The 555 is famously easy to use, but not exactly the most accurate timer out there — one “ticking” at 1 Hz will pulse just about once per second (probably to within a millisecond, depending on the rest of the circuit), but when you need more precise timing, the 555 just won’t cut it. Not on its own, anyway.

An Allan deviation plot — Allan Deviation can be a bit confusing, but generally — lower is more accurate

This entry by [burble] shows us how the humble 555 can hold its own in more demanding systems with some help from a GPS receiver. He used the One Pulse per Second (1PPS) output from a GPS module to discipline the 1 Hz output from a 555 by modulating the control voltage with a microcontroller.

Okay, this sounds a bit like baking a cake by buying a cake, scraping all the icing off, then icing it yourself, but what better way to learn how to ice a cake? The GPS-disciplined 555 is way more accurate than a free running one — just check out that Allan Deviation plot. While the accuracy of the standard 555 begins to decrease as oscillator drift dominates, the GPS-disciplined version just keeps getting better (up to a point — it would also eventually begin to increase, if the data were recorded for long enough). Compared to other high-end oscillators though, [burble] describes the project’s accuracy in one word: “Badly.”

That’s okay though — it really is a fantastic investigation into how GPS-disciplined oscillators work, and does a fantastic job illustrating the accuracy of different types of clocks, and some possible sources of error. This project is a great addition to some of the other precision timekeeping projects we’ve seen here at Hackaday, and a very fitting entry to the competition. Think you can do better? Or much, much worse? You’ve got a few weeks left to enter!