FCC ISM Rules May Shatter Lora Mesh Communities

Although everyone has their own reasons for exploring a new hobby, one of the driving factors behind the popularity of Meshtastic and MeshCore has been the incredible accessibility offered by off-grid LoRa mesh networks. You don’t need any expensive hardware or a license to get on the air — armed with a $20 microcontroller dev board and open source software, you could be on the mesh in minutes. Then came the really exciting part, seeing who else was out there. The low barrier of entry and ad-hoc nature of these projects meant there was a good chance you’d soon find yourself exchanging messages with other like-minded folks in the area.

Or at least, that’s how it used to be. With the recent revelation that their default radio configurations have potentially been in violation of the Federal Communications Commission’s (FCC) regulations governing amateur usage of the 900 MHz industrial, scientific and medical (ISM) band, the users and developers of both Meshtastic and MeshCore have been sent scrambling. Getting in compliance isn’t necessarily a technical challenge. In fact, Meshtastic has already introduced changes aimed to address the issue and anyone running the latest alpha release can be sure that their initial radio configuration will meet FCC standards.

But unfortunately, this introduces a new problem. While it’s easy enough to get new installations of Meshtastic and MeshCore operating in a mode that keeps the FCC happy, doing so breaks compatibility with everything that’s already been deployed. The community will be fractured into distinct strata depending on when they first configured their hardware, with an added dash of confusion from the more rebellious users who will undoubtedly refuse to migrate over to the new settings.

What was once easy and accessible has just gotten a whole lot more complicated.

Continue reading “FCC ISM Rules May Shatter Lora Mesh Communities” →

Heat Domes: Meet The Quiet And Oppressive Take On The Thunderdome

One of the nice things about the weather is that even if it’s bad right now, it’ll definitely be changing soon and maybe even for the better. There is one exception to this rule, however, and that comes in the form of heat domes, which are weather systems whereby a region of air becomes isolated from the surrounding systems. This creates effectively a greenhouse, with hot air remaining trapped and moisture unable to get in.

Although until recently not very common, this weather phenomenon poses a major challenge to any flora and fauna that finds itself trapped in a heat dome. With nights being about as hot and stifling as the days with their blue skies unbroken by any cloud cover and no rain for potentially weeks on end, it poses severe hydration, cardiovascular, and other challenges to any affected lifeforms.

Continue reading “Heat Domes: Meet The Quiet And Oppressive Take On The Thunderdome” →

Rosy Retrocomputing

Most of us are guilty of romanticizing the past. Do you long to be the captain of a tall ship? Just as long as you don’t mind weevils in your food, vitamin deficiencies, and death from an infection when there were no antibiotics. Want to be a medieval knight? Even worse. But surely, retrocomputing is as fun as we remember, right? Turn your computer on, and it comes up with BASIC! Ready for you to write your own programs. None of this GUI foolishness. Of course, this is just another example of rosy retrospection.

Even if you like BASIC or a similar language today, things have changed. You have a nice text editor, a fast computer, debugging tools, along with things like named functions, no line numbers, and modern control structures. None of those things were very common in the 1980s. At least, not on a hobby-grade computer.

Why am I thinking about this? Well, the Hackaday Retrocomputing Challenge is on, and it occurred to me that I wanted to work with some young students in glorious MBASIC on a CP/M machine I built and modified from a Hackaday project. Perfect, right? Many of us started that way, so why shouldn’t they?

But it quickly got old. Even a simple program gets bogged down with GOTOs and GOSUBs to mysterious line numbers. It made me remember the time back in the early 1980s, or maybe even the late 1970s, that I wrote a BASIC preprocessor to scan BASIC with no line numbers and produce proper source, converting labels to line numbers in two passes.

Continue reading “Rosy Retrocomputing” →

Tech In Plain Sight: Meet The Robot That Does CPR

Usually in Tech In Plain Sight, we talk about technology you probably see every day, even if you don’t notice it. But we hope you don’t get to see one of the latest crop of medical robots, such as the LUCAS chest compression system. If you watch the popular TV series “The Pitt”, though, you may have caught a glimpse of one of these medical marvels. They aren’t fiction. They are very real devices.

Calling them robots might be stretching the definition a little. They don’t roam the halls looking for patients. But once attached to someone in cardiac arrest, they can take over one of the most important — and physically demanding — parts of CPR: chest compressions.

Keep The Blood Moving

When someone’s heart stops pumping blood, time is critical. CPR doesn’t normally restart the heart on its own. Instead, chest compressions produce enough blood flow to keep oxygen reaching the brain and heart while rescuers work on the underlying problem and, when appropriate, use a defibrillator.

Doing that well is harder than it looks on television. Current American Heart Association guidelines call for adult chest compressions 100 to 120 times per minute, at least 5 cm deep but generally no deeper than 6 cm, while allowing the chest to recoil fully between compressions. Interruptions should be kept to a minimum.

That’s hard physical work. In fact, studies show compression depth begins to fall after only about 90 to 120 seconds, which is one reason CPR teams normally swap compressors every two minutes. But a robot doesn’t get tired.

Continue reading “Tech In Plain Sight: Meet The Robot That Does CPR” →

Hunting The Wild Vibrotruck

A few weeks ago, my wife was out walking the dog, and she sent me four or five photos of small orange boxes planted all around our neighborhood. (OK, I’ll bite!) They had little cards on them explaining that they were geophones, and a QR code on them that lead to a website with all the details. Munich was getting a large-scale seismic survey to map out our underground water, with the aim of using it for geothermal heat and power in the near future.

How do you map up to five kilometers under the earth? You pound the ground, sending shockwaves downward, and then listen for their reflections. At the boundaries between different layers, the change in the speed of sound in the different media cause reflections. Calculating the time it took for a given reflection to reach you lets you figure out how deep the layer boundary is.

The seismic survey procedure goes like this: geophones are set out at roughly 20 m intervals in lines spaced around 300 m apart that run roughly north-south, while “vibrotrucks” drive a roughly east-west course, creating mini-earthquakes every 20 meters along the way. Covering a surface of 1,000 km^2 with over 120,000 sample locations and exciting them 86,000 times is going to take a while. Lucky for me, they started in my part of town.

Continue reading “Hunting The Wild Vibrotruck” →

Hackaday Europe 2026: Outdoors With Robots

Erin Kennedy has been building robots for over a decade now, with a focus on smaller bots that interact with, or maybe even clean up, the outdoor environment. Still other bots are made to interact with people, and when the people are outside in the park, that’s where your robot needs to go.

Whatever the reason, Erin’s talk at Hackaday Europe 2026 is an invitation to take your projects out into the outdoors. But the great wide world outside of your lab is not necessarily the most friendly place for a little bot, and the other half of this talk is about practical design tips and lessons learned to help it survive. Continue reading “Hackaday Europe 2026: Outdoors With Robots” →

From A Ten-Line Script To A Real Utility With Codex

I’m an experienced programmer, and I’ve worked in many different languages. Sometimes being a programmer is a two-edged sword. You want to accomplish something, and you can do it easily — but it can be a lot of work to do it right. Maybe more work than you want to do.

Normally, I’ll kick out a few lines of script for something I want and be done, accepting that it isn’t production-hardened. This time, however, I decided to try an AI tool to see whether they could do the work I was too lazy to do myself. While I’ve played with chatbots, I wanted to try one of the dedicated coding agents, in this case, Codex. Outside of asking ChatGPT to write a simple function or find the cause of an error message, I haven’t done much coding with AI assistance, so I was interested to see what these agents brought to the table.

A Radio Problem

The problem was simple: I wanted an easy way to put buttons on my Linux desktop that launched Internet radio stations. Sure, I could open a player and paste in a long URL, but I’m far too lazy to remember all those URLs.

I searched for a way to make Shortwave — an Internet radio player — open a URL from the command line. Apparently, you can’t. Google Gemini suggested writing a script that launches cvlc, the command-line VLC player, with the URL as an argument.

That’s easy, so I did it. Of course, then I had to find the stream URLs for all my favorite stations. It turns out that Radio Browser maintains an extensive database of stations. I considered scraping the site or using its API, but honestly, the little script was becoming too much of a project.

Besides, I was already struggling to manage the media player’s lifetime. I didn’t want a new station playing on top of one that was already running, and I wanted a command to stop playback, so the script had already grown larger than I first imagined.

My first version used a temporary file containing the player’s process ID so a future script execution could kill the old player. That usually works, but it isn’t very robust, and I knew it. But how much work did I really want to do here? I decided I had done enough and turned the rest over to Codex, OpenAI’s coding assistant.

Continue reading “From A Ten-Line Script To A Real Utility With Codex” →