Mysterious Files PH

Packet radio is a particularly fun part of the ham radio hobby. Once upon a time, you might have squirted data about the airwaves using something like the Heathkit HK-21 Pocket Packet. Heathkit stopped being a going concern some time ago, but [btech] has now recreated the device with modern hardware.

[btech] has called the project the Pocket Pico, and like the hardware that inspired it, it acts as a terminal node controller for amateur packet radio. It literally runs the same firmware as the real HK-21. It achieves this by using the Raspberry Pi Pico to run a Z80 processor emulator that can run the same code, while also using the microcontroller to do the work of modulating and demodulating Bell 202 audio tones at 1200 baud to avoid the need for a dedicated modem chip.

Thanks to running the same firmware as the HK-21, you can use the Pocket Pico with lots of old packet radio software. It’s fully capable of doing APRS as well as AX.25 Level 2, and has a built in Personal Bulletin Board System for other stations to leave messages.

If you’re looking to get into packet radio, you might just find this project to be useful. Alternatively, you might like taking a look at some other projects we’ve featured in this space, like the capable OpenModem project. Video after the break.

[Thanks to btech for the tip!]

These days, it’s pretty easy to buy old retail console games just by hunting online auction sites. It’s much rarer to come across a disc holding a beta version that was only ever intended for internal us, and yet, that’s precisely what landed in [MattKC’s] hands—a copy of the Beta 3 release of Burnout 3 for the original Xbox. He thus set about the task of investigating the differences to the retail release and preserving the beta for the future.

The first task involved figuring out how to read the disc. Retail Xbox games show up as a DVD Video disc if you put them into a PC, which can complicate reading them. However, being a burnt beta disc for use in an Xbox devkit, this one was a little different. It was easy enough to read and dump with a regular DVD drive and some common tools for ripping Xbox ISOs.

From there, it was a matter of comparing the dumped disc to the retail PAL release. There wasn’t a lot of differences to find—with [MattKC] noting that the beta was dated just six days before the official retail release. Mostly, this beta had just a few localization differences in non-English languages compared to the final release. Still, [MattKC] nonetheless was able to preserve this curio for the future, and it now lives on the Internet Archive for future generations to enjoy. Perhaps the diehard Burnout 3 fans will one day decide that PAL Beta 3 is the ultimate version of the game.

It’s always interesting to get a look behind the scenes of big-time game development. We’ve taken a look at console devkits before, too—hardware that is never intended for the public to see.

This week, Hackaday Editors Elliot Williams and Al Williams had a lot to talk about. From advice for a young hacker to using a laser to break into a microcontroller, there was plenty to cover from the week in Hackaday.

From the “Point/Counter Point” department, there were dueling posts about how big a deal it is for Raspberry Pi to lock out RAM chip swapping. Ever want to do interactive debugging in MicroPython? For intellectual exercise, there’s the physics of raindrops becoming a radar antenna. If you are a history buff, there was even news about World War I codebreaking.

For the can’t-miss articles, the big news was the issues with LoRa mesh communities possibly clashing with the FCC rules and how to make your computer take dictation.

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

Direct download an MP3 created with ultra premium ones and zeros.

Episode 388 Show Notes:

Mailbag:

• [Curioustopher] had a sound, and a question about high-fidelity audio recording.
• [Stefan], a young hacker, wanted some project advice and is looking to connect with hackers in Romania.
• Mailbag still needs intro/outro music. Anyone want to whip something up? Send it to mailbag@hackaday.com.

Interesting Hacks of the Week:

• Raspberry Pi Locks Down RAM Upgrades
• Raspberry Pi RAM Restrictions No Big Deal, Frankly
• On Chip Debug For (Some) MicroPython
• A Hotspot Becomes A Handheld
  • Hackable $20 Modem Combines LTE And Pi Zero W2 Power
• Laser Your Way Into Debug Mode On The RP2350
• Why Raindrops Make For Pretty Good Antennae
• World War I Coded Message Appears Cracked, Finally
  • Kryptos – Wikipedia

Quick Hacks:

• Elliot’s Picks:
  • The RP2350 Does 1080p
  • Making A Digital Music Player For Cassette Decks
  • The Mazda Suitcase Car Rides Again
  • Trying A New Radial Impeller Design For Quadcopters
• Al’s Picks:
  • Sony’s First Computer
  • Emulating Memory Access: How Hard Can It Be?
  • Reviving TEMPEST Attacks With An Injected Signal

Can’t-Miss Articles:

• FCC ISM Rules May Shatter Lora Mesh Communities
• Linux Fu: Speak Up!

Predictions of the future are often laughable when reviewed in the years for which they are made. For example, here in 2026 we neither live on the Moon, nor have flying cars. But sometimes they come closer to the reality than others, and in that the BBC Archive have an interesting offering. It’s a Newsnight feature from 2006 looking at the future of artificial intelligence, and since its main interviewee is none other than Sir Clive Sinclair, it’s worth a second look.

Watching the video it’s a shock to be reminded that 2006 was twenty years ago, as in so many ways it’s close enough to touch. Back then we had laptops with Windows or Linux, we had the Web, and HDTV, as we do today. But as we sat in our Ford Focus family car it would be on a Nokia that we rang home; while technically a smartphone it was nothing like the Apple and Android devices that would take the world by storm in the following years. Sir Clive is positive about the development of AI as he saw it then, seeing it as providing knowledge based services such as education or healthcare from your computer. The following interviewee from British Telecom perhaps puts his finger on the pulse the most, predicting a path “Over the next few years” that seems pretty familiar to us a couple of decades later.

So for once this is a future prediction that doesn’t seem too outlandish. Aside from Sir Clive’s appearance it’s packed with retro technology goodies, so it’s well worth a watch below.

If you wanted to build a clock with a 7-segment display, there are a wide variety of ways you might go about it. You could grab some 74-series logic chips and create a whole bunch of counters and decoders to drive the display, or you could wire up a microcontroller with an RTC and have it do the hard work. Or, as a Japanese company once did… you could create a “digital” looking clock with no digital electronics whatsoever.

[Mark Furneaux] set about tearing down a Lumitime clock, built by the Japanese company Tamura. From the outside, it appears to be a rather stylish digital clock, with a bold red 7-segment display lit with neons. And in some regards, it is. Only, the secret of this clock is that it doesn’t use digital electronics to do the job. There are no counters inside, no real-time clock module, no transistor-based logic chips doing the counting with the output of a 32.768 KHz crystal. Instead, a motor drives a series of gears that turn metal plates that move under sliding finger contacts. The gear train and the metal plates are designed such that the contacts turn the various segment neons on in the correct sequence to display the current time. It’s like a player piano, only instead of playing a tune, it’s switching the segments of a display on and off to display the right numerals at the right time.

It’s a neat way to do a “digital” clock from an era when proper digital electronics were still very expensive. We’ve seen all kinds of whacky 7-segment clocks before, too, like this amusing water-based build. Video after the break.

These days, it’s possible to cram a whole lot of radio functionality into a very compact device. A great example of that is the LakeShark scanner from [SAMS0N1TE].

The LakeShark is based on the LilyGO T-Display P4—which combines an ESP32-P4 microcontroller with a 4.1 inch AMOLED touchscreen display. It comes with an onboard SX1262 LoRa radio module as well as GPS and a nine-axis Inertial Measurement Unit to boot. [SAMS0N1TE] then set it up to also hook up to an RTL-SDR Blog V3 or V4, providing all kinds of extra software-defined radio functionality.

It can scan everything from P25 Phase 1 trunking transmissions, to ADS-B, POCSAG, and even good old FM broadcast radio. If you want to listen in on what’s on the air, or see a minimap with tracks of the planes flying overhead, you can do it all with this rig. You can even investigate various bands with waterfall displays or try and look for activity from nearby nRF24 devices.

Ultimately, it’s a bit of a Swiss Army knife for radio fun—able to do all kinds of neat things, and it fits right in your pocket. We’ve featured some other great SDR hacks recently, too, like this $50 build with an impressive 20 MHz of bandwidth. If you’re cooking up your own gear for the ham shack and beyond, let us know on the tipsline.

After recently working our way through UDP broadcasting and network subnetting all in the comfort zone of IPv4, it’s time to address the elephant in the room, the one wearing a bright neon ‘IPv6’ sign. Although it’s still very much a rumor at this point, supposedly IPv6 is slated to replace the venerable IPv4 protocol. Rather than just being IPv4-but-with-more-addresses, its designers took the opportunity to basically completely redesign the protocol for the futuristic world of the late 90s and the early 2000s.

Joking aside, IPv6 having been introduced in 1995 and still struggling to meaningfully displace IPv4 does invite some worries about just how easy it is to switch between these two fundamental internet protocols. Say if we wanted to join the future of the 2000s and adapt our software to speak IPv6 instead of IPv4, what would change about the aforementioned aspects of IPv4 UDP broadcasting and IPv4 subnetting?

Speaking as an ignorant developer who mostly knows IPv6 from those weird and hard to remember network addresses, as well as many broken router implementations, I’m not entirely convinced that I’m going to like what I’ll see.

Futuristic Broadcasting

We saw with IPv4 UDP broadcasting that it was mostly a matter of either determining the network interface’s broadcast address based upon its subnet, or playing things easy mode with the local broadcast address. In the case of IPv6 none of these things exist, however. This raises the question of how our lonely UDP packet can still ask everyone on an IPv6 network whether they have seen a particular network service.

The simple answer is that IPv6 has a special link-local multicast group at address ff02::1 that functions pretty much identical to an IP broadcast. This is the equivalent of IPv4 multicasting to address 224.0.0.1, so this isn’t technically a new feature, just that multicasting is optional in IPv4.

Even though IPv4 multicasting would seem to be generally implemented, it’s telling that despite spending a considerable amount of time researching IPv4 broadcasting I have not seen this ‘multicast to all’ feature used anywhere. Perhaps this makes IPv4 and IPv4 multicasting worthy of an article of their own in some fashion, as it seems to be a whole other supermarket of canned worms to peruse.

That aside, if we were to look at this from a slightly philosophical technical angle, then having broadcasting treated as just another type of multicasting does make a lot of sense. Rather than singling out a subset of nodes on the network interface, we just mash the ‘all’ option. Very simple and elegant in a way.

Subnet Things

Whereas IPv4 subnetworks are a delightful topic that can keep any sysadmin entertained for days and will happily explode the software written by an ignorant developer – who was until that moment blissfully unaware of subnets beyond /24 – IPv6’s designers took a look at this veritable source of entertainment and decided that they wanted none of this.

In IPv6 you get one subnet and it’s /64, and you will learn to love all of its 2⁶⁴ possible addresses. Since this makes for about four billion times the address space of IPv4 it does make for a compelling argument that it renders subnets unnecessary.

Of course, while certainly the people who hammered out the RFCs for IPv6 were happy with all these changes, it’s somewhat of a running gag that it’s the worst thing that has happened to sysadmins since IPv4.

A 2017 Standard

The slightly smaller elephant in the room that’s hiding in the shadow of the neon-sign-adorned IPv6 elephant is the one wearing a hand-scribbled RFC 8200 sign slung around its neck with a bit of bailing rope. This was namely when the IPv6 RFCs received the ‘Internet Standard’ level of maturity, leading some to question whether the push to switch to IPv6 during the years prior was at all warranted.

This little factoid is just one of the many problems that networking people have with IPv6. For example this 2020 rant by Teknikal_Domain, with the main focus being that instead of being just an IPv4 with 64-bit addressing space and some of the warts of IPv4 smoothed over, it saw fit to add many details and complexity that nobody asked for and fresh warts that could have been easily prevented.

The annoying thing is of course that IPv4 Internet address allocations have pretty much run out everywhere, meaning that you are either lucky right now to still have an IPv4 address, or you have to pay a hosting provider extra, or your Internet connection finds itself with only an IPv6 connection and the IPv4 side of things dumped behind carrier-grade network address translation (CG-NAT) that kills most IPv4-specific applications.

Transitioning from IPv4 to IPv6 is also a pain, as there’s no direct compatibility between the two protocols, with IPv6 supposed to ‘encapsulate’ IPv4 packets while using a dual network stack on the network equipment side of things. Unfortunately this also means that on the Internet you now have a section that’s IPv4-only, an IPv6-only subset and IPv4/v6-capable nodes that may or may not have a broken dual-stack implementation.

Obviously this doesn’t really help anyone, and there’s a strong argument to be made that for LANs IPv4 is really all you need.

A UDP Discovery Perspective

While the idea of cleaning up IPv4’s messy broadcast address options with a simple multicast option is a good one that I’ll definitely be giving a shot in IPv4’s multicast feature, and the lack of subnets a welcome simplification, the whole concept of service discovery gets a bit weird with IPv6.

The first is that IPv6 doesn’t do NAT and unless you use the non-routable prefix your LAN will not be private in the IPv4 NAT-ed LAN sense. Fortunately IPv6 does do NPT, which is essentially NAT, but with prefixes instead of addresses, so it’s totally different.

Although with routable IPv6 prefixes you could totally do a global address space service discovery, this would obviously be less than desirable. Since service discovery tends to be just about devices on the LAN anyway, this makes the use of IPv6 at the very least a questionable proposition, and a liability in the worst case.

Ultimately as nice as IPv6 seems in some respects, when you look at the whole package it really just makes you wish for it having been basically IPv4 with a larger address space and mandatory features like multicasting. For now this means that when it comes to e.g. my NyanSD service discovery library, I see no reason to use IPv6-style UDP broadcast, even the library already fetches the IPv6 address of any found service.

It’s totally possible that I’m wrong and that within a few years we’ll all be using IPv6-only on our LANs, ideally with globally routable IPs like we’re back on the 1990s internet with people plugging their PCs straight into the modem with zero NAT or other considerations.