Mysterious Files PH

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.

There are plenty of ways to DJ with a laptop and various controller setups. However, if you find hauling around an entire computer can be a bit much, you might like this lighter system from [Daniel Vučinović].

It’s called Pajoniiir, and it’s intended to replace a laptop in the DJ booth. In its place stands an ESP32-P4 microcontroller, hooked up to a 4.3-inch touchscreen display in an off-the-shelf combo from Guition. The ESP32’s twin USB interfaces are hooked up in turn to a Pioneer DDJ-FLX4 controller, and a USB stick carrying a Rekordbox music library. The microcontroller is then also hooked up to a PCM5102A DAC module for audio output.

The ESP32 reads and plays tracks in MP3, WAV, and FLAC formats, responds to commands from the DJ controller, and displays the waveforms and other controls on the touchscreen. It’s doing most of what a laptop would do in this case, only it costs $50 and won’t get stuck in a bootloop for a Windows update 10 minutes before you’re due to go on.

We’ve featured a few good DJ controller hacks over the years, like this Hercules rig that was modded for better scratching.

Sometimes along comes a hack with a personal angle, and in a video showing Irish bog ore smelting, we find an appropriate follow up to a Hackaday expedition back in 2019. [Alec Steele] joined Irish Bloomery Iron, for a weekend with a medieval blast furnace.

Our brush with bog ore came in a trip to Hack42 in Arnhem, the Netherlands, where a team of Dutch hackers built a furnace from firebricks in an attempt to do the same thing. The Dutch attempt ended with a lot of mixed slag and very little iron, and looking at how the Irish furnace was constructed we see some clues to their success. Their air injection using a perforated sheet of clay and the air blast injected to form a venturi is particularly interesting,as is the shape of the furnace.

The iron bloom is lifted out through the top of the furnace rather than being tapped as molten iron, and we’re treated to it being worked into a usable bar of iron. Having spent a day with our Dutch friends doing the same work only to have scraps of iron, we’re mightily impressed with the results from the Irish smelters. You can visit their website at www.irishbloomeryiron.com.

Although [Arkandas] disclaims any interest in being a ‘car guy’, this is somewhat ironic in light of the sheer amount of modding he has performed on a range of cars over the years, a recent misadventure involving a BMW Mini F56’s infotainment system replacement and some light ECU reprogramming included. What happened exactly is covered in a detailed breakdown in a blog post.

One of the aspects that [Arkandas] disliked about this car was its iDrive infotainment system, itself a stripped-down version of the full-fat infotainment system in ‘real’ BMW cars, with a small screen and awkward UX. The idea was to replace this with a more full-featured modern system.

Since the infotainment system does hook into the car’s CAN buses and other systems it has to be compatible, of course. This took some research before ultimately a fancy €700 aftermarket replacement was ordered from a Chinese seller.

Long story short, the device was mostly compatible aside from a connector wired wrongly and creating a short. This was fixed, but then the loosely fitted display toppled off during a test drive and broke, so a replacement screen was ordered. This screen arrived without requisite factory programming, so [Arkandas] embarked on a long reverse-engineering session.

Before he was able to extract firmware from the broken display and flash it onto the new display he was offered a brand-new replacement for the whole device, which he accepted in return for sending the old unit back. Although this still left him with a range of questions, at least the new infotainment looks pretty spiffy.

The worst part about the whole experience was just how much waiting and agonizing over poor after-sale support was involved, along with all the things that can go wrong and turn a fun afternoon of fitting shiny new parts into a months-long ordeal. Since modern cars are basically just a stack of computers on wheels, this ensures that even ‘not car guys’ will be doing a lot more of such fun car modding.

Perhaps one of the most contentious issues in 3D printing is that of supports, both because they’re an uncomfortable reminder of how gravity affects our prints and because the very idea of there being ‘one right way’ is bound to get you into some spirited discussions. That said, [Matthew Trahan] figured that neither regular grid supports nor organic tree supports are the answer here, and that the better answer is found in fins.

The problem with existing support approaches especially with FDM prints is that they can be fairly wasteful in terms of material, and they can leave serious marks on the printed object’s surface that require post-processing. These fins on the other hand are designed to require as little material as possible and snap off as cleanly as possible. The tool, developed with the assistance of Claude, can either run locally or be accessed via printfins.com.

Currently the idea is that these fins are baked directly into the STL model so that it’s a one-time thing, but it may eventually become available as a slicer plugin. The basic concept was pitched by [Slant3D], who gets credited in the video below, although in their approach they used CAD software to add the fin supports manually.

The fins are there to provide the support base, while small tines can be added to reinforce the connection to the model. These do make it it less easy to snap off with minimal scarring, of course. Conceivably these fins could be made even more light-weight by adding gaps, but that probably would add to the print time.