The Pluto software-defined radio is placed on a desk, connected by three RF cables to an RF bridge circuit board. The RF bridge has a prominent ballon taking up most of its area.

Turning The Pluto SDR Into A Network Analyzer

June 5, 2025 by Aaron Beckendorf 1 Comment

Usually when we see a project using a software-defined radio (SDR), the SDR’s inputs and outputs are connected to antennae, but [FromConceptToCircuit]’s project connected an ADALM-Pluto SDR to an RF bridge and a few passive components to make a surprisingly effective network analyzer (part two of the video).

The network analyzer measures two properties of the circuit to which it is connected: return loss (S11) and insertion gain or loss (S21). To measure S21, the SDR feeds a series of tones to the device under test, and reads the device’s output from one of the SDR’s inputs. By comparing the amplitude of the input to the device’s output, a Python program can calculate S21 over the range of tested frequencies. To find S11, [FromConceptToCircuit] put an RF bridge in line with the device being tested and connected the bridge’s output to the SDR’s second input. This allowed the program to calculate the device’s impedance, and from that S11. Continue reading “Turning The Pluto SDR Into A Network Analyzer” →

A circuit board is shown, with the tip of a soldering iron applied to a piece of solder wick positioned above a pad.

Making Solder Wick Less Painful

June 4, 2025 by Aaron Beckendorf 28 Comments

For some people (e.g. this author) solder wick is a tool of last resort. Unfortunately, solder suckers and vacuum pumps lose most of their utility when you move from through-hole to SMD components, forcing us to use the dreaded wick. For those of us in this mindset, [nanofix]’s recent video which we’ve placed below the break on tips for solder wick could make desoldering a much less annoying experience.
Continue reading “Making Solder Wick Less Painful” →

A weather forecast is shown on a blue monochrome cathode ray tube display. It is displaying current conditions, and displays a “The Weather Channel” graphic in the top left corner.

A CRT Display For Retro Weather Forecasting

May 31, 2025 by Aaron Beckendorf 16 Comments

It would be hard to find any electronics still in production which use CRT displays, but for some inscrutable reason it’s easy to find cheap 4-inch CRTs on AliExpress. Not that we’re complaining, of course. Especially when they get picked up for projects like this Retro CRT Weather Display from [Conrad Farnsworth], which recreates the interface of The Weather Channel’s WeatherStar 4000+ in a suitably 90s-styled format.

The CRT itself takes up most of the space in the enclosure, with the control electronics situated in the base behind the display driver. A Raspberry Pi Zero W provides the necessary processing power, and connects to the CRT through its composite video output.

A custom PCB plugs into the GPIO header on the Raspberry Pi and provides some additional features, such as a rotary encoder for volume and brightness display, a control button, a serial UART interface, and a speaker driver. The design still has one or two caveats: it’s designed to powered by USB, but [Conrad] notes that it draws more current than USB 2.0 can provide, though USB-C should be able to keep up.

On the software side, a Python program displays a cycle of three slides: local weather, regional weather, and a radar display. For the local and regional weather display graphics, [Conrad] created a static background image containing most of the graphics, and the program only generated the dynamic components. For the radar display, the regional map’s outlines come from Natural Earth, and a Python program overlays radar data on them.

We’ve seen other attempts at recreating the unique style of the WeatherStar system, but nothing quite beats the real thing.
Continue reading “A CRT Display For Retro Weather Forecasting” →

A console is shown displaying a system’s startup information, followed by “Booting from Hard Disk …”, “Hello World!” in a green font, and “The keyboard is working!”

A Forth OS In 46 Bytes

May 27, 2025 by Aaron Beckendorf 27 Comments

It’s not often that we can include an operating system in a Hackaday article, but here’s the full 46-byte source of [Philippe Brochard]’s 10biForthOS in 8086 opcodes:

50b8 8e00 31d8 e8ff 0017 003c 0575 00ea
5000 3c00 7401 eb02 e8ee 0005 0588 eb47
b8e6 0200 d231 14cd e480 7580 c3f4

Admittedly, this is quite a minimal operating system. It’s written for the Intel 8086, and consists of a Forth implementation with only two instructions: compile (1) and execute (0). It can receive commands over a serial connection or from a keyboard. This allows a host computer to load more complex software onto it, one byte at a time. In particular, [Philippe] provides instructions for loading more advanced compilers, such as subleq-eForth for a more complete Forth implementation, or SectorC for C programming. He’s also written a 217-byte port of the OS to Linux Intel x64.

[Philippe] doesn’t take a strong stance on whether this should technically qualify as a Forth implementation, given that the base implementation lacks stacks, dictionaries, and the ability to define words. However, it does have an outer and inner interpreter, the ability to compile and execute code, and most importantly, “the simplicity and hacky feeling of Forth.”

[Philippe] writes that this masterpiece of minimalism continues the tradition of the minimal Forth implementations we’ve covered before. We’ve even seen Forth run on an Arduino.

A graph of download speeds is shown, with two triangular spikes and declines. Above the graph, the label “8 MB/s” is shown.

A Quick Introduction To TCP Congestion Control

May 25, 2025 by Aaron Beckendorf 10 Comments

It’s hard to imagine now, but in the mid-1980s, the Internet came close to collapsing due to the number of users congesting its networks. Computers would request packets as quickly as they could, and when a router failed to process a packet in time, the transmitting computer would immediately request it again. This tended to result in an unintentional denial-of-service, and was degrading performance significantly. [Navek]’s recent video goes over TCP congestion control, the solution to this problem which allows our much larger modern internet to work.

In a 1987 paper, Van Jacobson described a method to restrain congestion: in a TCP connection, each side of the exchange estimates how much data it can have in transit (sent, but not yet acknowledged) at any given time. The sender and receiver exchange their estimates, and use the smaller estimate as the congestion window. Every time a packet is successfully delivered across the connection, the size of the window doubles.

Once packets start dropping, the sender and receiver divide the size of the window, then slowly and linearly ramp up the size of the window until it again starts dropping packets. This is called additive increase/multiplicative decrease, and the overall result is that the size of the window hovers somewhere around the limit. Any time congestion starts to occur, the computers back off. One way to visualize this is to look at a graph of download speed: the process of periodically hitting and cutting back from the congestion limit tends to create a sawtooth wave.

[Navek] notes that this algorithm has rather harsh behavior, and that there are new algorithms that both recover faster from hitting the congestion limit and take longer to reach it. The overall concept, though, remains in widespread use.

If you’re interested in reading more, we’ve previously covered network congestion control in more detail. We’ve also covered [Navek]’s previous video on IPV5. Continue reading “A Quick Introduction To TCP Congestion Control” →

A USB dongle is shown connected to a laptop computer. A text box in the lower right corner says "PECKUS is running in DEBUG mode, it is 3x faster in non-DEBUG mode."

A Presence-sensing Drive For Securely Storing Secrets

May 24, 2025 by Aaron Beckendorf 24 Comments

When we hear about flash drives in the context of cybersecurity, we tend to think of them more as threats than as targets. When you’re using flash drives to store encryption keys, however, it makes sense to pay more attention to their security. [Juergen] designed the PECKUS (Presence Enforcing Crypto-Key USB-Storage) with this specifically in mind: a few-kilobyte storage device that only unlocks if the owner’s Bluetooth device is in the vicinity.

[Juergen] needed to store an infrequently-used keyfile on an air-gapped system, and commercial encrypted flash drives were rather expensive and left much to be desired in terms of usability. Instead, he designed a CircuitPython custom firmware for MakerDiary’s nRF52840 micro development kit, which provided a BLE-capable system in the form of a USB dongle.

After flashing the firmware to the board, the user sets it up with a particular Bluetooth device and a file to be stored; after writing the file during setup, it cannot be rewritten. Before reading from the device, the user must pair the previously-set device with the board and press a button on the board, and only then does the device appear to the computer.

The limited amount of storage space means that this device will probably only serve its intended purpose, but in those cases, it’ll be handy to have an open-source and inexpensive protected storage device. [Juergen] notes that attackers could theoretically defeat this system by desoldering the microcontroller from the board and extracting the memory contents from the its storage, but if you have enemies that resourceful, you probably won’t be relying on a $20 board anyways.

We’ve previously seen a few flashdrives cross these pages, including one meant to self-destruct, and one made from a rejected microSD card.

A white control box is shown in the foreground. The box has an LCD display, eight button, and two barbed fittings for flexible tubing.

Using Pitot Tubes For More Than Aircraft

May 19, 2025 by Aaron Beckendorf 8 Comments

When we hear the words “pitot tube,” we tend to think more of airplanes than of air ducts, but [Franci Kopač]’s guide to pitot tubes for makers shows that they can be a remarkably versatile tool for measuring air speed, even in domestic settings.

A pitot tube is a tube which faces into an air flow, with one hole at the front of the tube, and one on the side. It’s then possible to determine the air speed by measuring the pressure difference between the side opening and the end facing into the wind. At speeds, temperatures, and altitudes that a hacker’s likely to encounter (i.e. not on an airplane), the pressure difference is pretty small, and it’s only since the advent of MEMS pressure sensors that pitot tubes became practical for amateurs.

[Franci]’s design is based on a Sensiron SDP differential pressure sensor, a 3D-printed pitot tube structure, some tubing, and the microcontroller of your choice. It’s important to position the tube well, so that it doesn’t experience airflow disturbances from other structures and faces straight into the air flow. Besides good positioning, the airspeed calculation requires you to know the air temperature and absolute pressure.

[Franci] also describes a more exotic averaging pitot tube, a fairly simple variation which measures air speed in cavities more accurately. He notes that this provides a more inexpensive way of measuring air flow in ducts than air conditioning flow sensors, while being more resilient than propeller-based solutions – he himself used pitot tubes to balance air flow in his home’s ventilation. All of the necessary CAD files and Arduino code are available on his GitHub repository.

If you’re looking for a more conventional duct flow meter, we’ve covered one before. We’ve even seen a teardown of a pitot tube sensor system from a military drone.