Pi 5 And SDR Team Up For A Digital Scanner You Can Actually Afford

February 10, 2024 by 27 Comments

Listening to police and fire calls used to be a pretty simple proposition: buy a scanner, punch in some frequencies — or if you’re old enough, buy the right crystals — and you’re off to the races. It was a pretty cheap and easy hobby, all things considered. But progress marches on, and with it came things like trunking radio and digital modulation, requiring ever more sophisticated scanners, often commanding eye-watering prices.

Having had enough of that, [Top DNG] decided to roll his own digital trunking scanner on the cheap. The first video below is a brief intro to the receiver based on the combination of an RTL-SDR dongle and a Raspberry Pi 5. The Pi is set up in headless mode and runs sdrtrunk, which monitors the control channels and frequency channels of trunking radio systems, as well as decoding the P25 digital modulation — as long as it’s not encrypted; don’t even get us started on that pet peeve. The receiver also sports a small HDMI touchscreen display, and everything can be powered over USB, so it should be pretty portable. The best part? Everything can be had for about $250, considerably cheaper than the $600 or so needed to get into a purpose-built digital trunking scanner — we’re looking at our Bearcat BCD996P2 right now and shedding a few tears.

The second video below has complete details and a walkthrough of a build, from start to finish. [Top DNG] notes that sdrtrunk runs the Pi pretty hard, so a heat sink and fan are a must. We’d probably go with an enclosure too, just to keep the SBC safe. A better antenna is a good idea, too, although it seems like [Top DNG] is in the thick of things in Los Angeles, where LAPD radio towers abound. The setup could probably support multiple SDR dongles, opening up a host of possibilities. It might even be nice to team this up with a Boondock Echo. We’ve had deep dives into trunking before if you want more details.

Continue reading “Pi 5 And SDR Team Up For A Digital Scanner You Can Actually Afford” →

The Usage Of Embedded Linux In Spacecraft

February 10, 2024 by 44 Comments

As the first part of a series, [George Emad] takes us through a few examples of the Linux operating system being used in spacecraft. These range from SpaceX’s Dragon capsule to everyone’s favorite Martian helicopter. An interesting aspect is that the freshest Linux kernel isn’t necessarily onboard, as stability is far more important than having the latest whizzbang features. This is why SpaceX uses Linux kernel 3.2 (with real-time patches) on the primary flight computers of both Dragon and its rockets (Falcon 9 and Starship).

SpaceX’s flight computers use the typical triple redundancy setup, with three independent dual-core processors running the exact same calculations and a different Linux instance on each of its cores, and the result being compared afterwards. If any result doesn’t match that of the others, it is dropped. This approach also allows SpaceX to use fairly off-the-shelf (OTS) x86 computing hardware, with the flight software written in C++.

NASA’s efforts are similar, with Ingenuity in particular heavily using OTS parts, along with NASA’s open source, C++-based F’ (F Prime) framework. The chopper also uses some version of the Linux kernel on a Snapdragon 801 SoC, which as we have seen over the past 72 flights works very well.

Which is not to say using Linux is a no-brainer when it comes to use in avionics and similar critical applications. There is a lot of code in the monolithic Linux kernel that requires you to customize it for a specific task, especially if it’s on a resource-constrained platform. Linux isn’t particularly good at hard real-time applications either, but using it does provide access to a wealth of software and documentation — something that needs to be weighed up against the project’s needs.

One Project At A Time, Or A Dozen?

February 10, 2024 by 34 Comments

We got a bunch of great food for thought in this week’s ask-us-anything on the Hackaday Podcast, and we all chewed happily. Some of my favorite answers came out of the question about how many projects we all take on at once. Without an exception, the answer was “many”. And while not every one of the projects that we currently have started will eventually reach the finish line, that’s entirely different from saying that none of them ever do. On the contrary, Tom Nardi made the case for having a number of irons simultaneously in the fire.

We all get stuck from time to time. That’s just the nature of the beast. The question is whether you knuckle down and try to brute-force power your way through the difficulty, or whether you work around it. A lot of the time, and this was Dan Maloney’s biggest bugaboo, you lack the particular part or component that you had in mind to get the job done. In that situation, sometimes you just have to wait. And what are you going to do while waiting? Work on Project B! (But take good notes of the state of Project A, because that makes it a lot easier to get back into the swing of things when the parts do arrive.)

Al and I both weighed in on the side of necessity, though. Sometimes, no matter how many attractive other projects you’ve got piled up, one just needs to get out the door first. My recent example was our coffee roaster. Before I start a big overhaul, I usually roast a couple days’ worth of the evil bean. And then the clock starts ticking. No roasting equals two unhappy adults in this household, so it’s really not an option. Time pressure like that helps focus the mind on the top-priority project.

But I’m also with Tom. It’s a tremendous luxury to have a handful of projects in process, and be able to hack on one simply because you’re inspired, or in love with the project at that moment. And when the muse calls, the parts arrive, or you finally figure out what was blocking you on Project A, then you can always get back to it.

This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter. Want this type of article to hit your inbox every Friday morning? You should sign up!

Minitel, The 1980s Console Game Platform You Never Had

February 10, 2024 by 14 Comments

We’ve made no secret over the years here at Hackaday of our admiration for the Minitel. The ubiquitous CRT terminals which made 1980s France the most connected country in the world never made it to where we grew up, but OH! how we wanted them to! We’ve seen quite a few Minitels repurposed as serial terminals here, but for the time being we think [Louis H] has won the Minitel Internet with his plugin game console cartridges. These have a DIN plug to fit the Minitel serial port, and present themselves as a serial game.

The cartridge itself is an extremely simple affair, a tube which fits over the DIN plug body, containing a slim PCB with an ATmega328 and its supporting components. The games must be programmed such that their gameplay can work over a serial interface, so as an example the first game is a version of 2048.

We applaud both the simplicity and creativity of this project, and we love it that a new 1980s console we never knew we had has been unearthed, without the need for hardware modification. Meanwhile if you’d like to peer inside an Alcatel Telic 1, we can take you there.

Simple Magnetic Levitator

February 10, 2024 by 9 Comments

[Stoppi] always has exciting projects and, as you can see in the video below, the latest one is a very simple magnetic levitator design. The design is classic and simple: a 5 V regulator IC, a Hall effect sensor, a 741 op amp, and a MOSFET to turn the electromagnet on and off.

Sure, there are a few passive components and a diode, too, but nothing exotic. The sensor normally presents 2.5 V of output. The voltage rises or drops depending on the polarity of the magnetic field. The stronger the field, the more the voltage changes away from the 2.5 V center.

The op amp acts as a comparator with a potentiometer setting the trip point. As the ball moves up towards the coil, the voltage increases, triggering the comparator, which turns off the FET. With no current through the coil, there’s no more electromagnet, and the ball starts to fall.

Of course, as the ball falls, the voltage from the sensor also drops, and this eventually turns on the electromagnet. The ball eventually reaches a relatively stable position.

This is one of those cases where a simple analog circuit might work better than a digital one. Or make it hard on yourself and use an FPGA.

Continue reading “Simple Magnetic Levitator” →

Droplet Watch Keeps Time Via Electrowetting

February 9, 2024 by 7 Comments

Hackers just can’t help but turn their sights on timepieces, and [Armin Bindzus] has designed an electrowetting-based watch.

Electrowetting is a way of changing the contact angle of droplets on a surface using electricity, and can be used to move said droplets. The liquid needs to be polar, so in this case [Bindzus] has used a red ink mixed with mono-ethylene glycol to stand out against the white dielectric back of the device. The 60 individual electrodes of the bottom section were etched via laser out of the ITO-coated glass that makes up the bottom plates of the face.

The top plate houses the small round pillars that keep the ink constrained to its paths. They are made of a photosensitive epoxy that is spin-coated onto the glass and then cured via the laser. The plates are put together at a distance of 0.23 mm with epoxy, but a small hole is left to insert the droplets and a filler liquid. An Attiny1614 microcontroller runs the show along with a DS3231 RTC. A 46V signal drives the droplets around their path.

It seems this project is a bit away from true wearable use, but perhaps [Bindzus] could make a desk clock first? If you’re interested in another ink-based, watch, how about this custom E-Ink Tank watch?

Continue reading “Droplet Watch Keeps Time Via Electrowetting” →

Breaking Through The 1 MB Barrier In DOS With Unreal Mode And More

February 9, 2024 by 17 Comments

The memory map of the original 8086 computer with its base and extended memory made the original PC rather straightforward, but also posed countless issues for DOS-based applications as they tried to make use of memory beyond the legacy 1 MB address space. The initial ways to deal with this like EMS, XMS and UMB were rather cumbersome and often impractical, but with the arrival of the 80286 and 80386 processors more options opened up, including protected mode. More interestingly, this led to unreal mode, DOS extenders and the somewhat more obscure LOADALL instruction, as covered by [Julio Merino] in a new article.

This article builds on the first one which covered the older methods and covered the basics of protected mode. Where protected mode is convenient compared to real mode is that with the former the memory accesses go via the MMU and thus allows for access to 16 MB on the 80286 and 4 GB on the 80386. The segment descriptors and resolving of these that make this possible can be (ab)used on the 80286 and up by realizing that these segment descriptors are also used in real mode. Unreal mode is thus about switching to protected mode, loading arbitrary segment descriptors and switching back to real mode. As this is outside the original processor spec, it is commonly called ‘unreal mode’.

Continue reading “Breaking Through The 1 MB Barrier In DOS With Unreal Mode And More” →