Daniel's been doing that thing again where he says he's not going to do something and then asks for the full technical specification anyway.
The man has a server and an empty USB port. That's a dangerous combination.
Here's what he wrote in. He caught the episode on HF transmissions from diplomatic missions, the ones that keep working when everything else is assumed to be down. And he got interested in the receiver side of it. His point is that the cost of entry is modest, much like the people who run AIS receivers for ship tracking. He's imagining a setup where you buy an affordable receiver, plug it into a computer, hook it up to a server running Linux, and then run automated frequency scanning and capture. His question is what's actually involved in that monitoring stack. What packages exist for frequency scanning and monitoring on Linux? And then the bigger question. He's noticed that with AIS, the best results come when capture and analysis are decoupled. Local volunteers run receivers, upload raw data, and the analysis happens upstream through crowdsourcing. He wants to know if there are equivalent networks for shortwave radio monitoring. Are there communities where people maintain local receiving equipment and automatically upload findings to a common cloud, and then the community does the analysis?
This is one of those questions where the answer is yes, and the infrastructure has been running for longer than most people think. But before we get to the networks, let's talk about the physical layer, because that's where Daniel's instinct is right and also a little bit wrong in an interesting way.
Wrong how?
The affordable receiver he's thinking of. That's almost certainly an RTL-SDR dongle. Originally built for digital TV reception, someone figured out the chipset could dump raw radio samples to a computer instead of decoding television. They cost about thirty dollars. Plug one into a Linux box and you've got a software-defined radio receiver covering roughly twenty-four megahertz up to one point seven gigahertz.
Which is not shortwave.
Right. The RTL-SDR dongles start at twenty-four megahertz. Shortwave is three to thirty megahertz. So the cheap dongle everyone starts with doesn't actually cover the HF bands where diplomatic traffic lives. You need an upconverter, which is a small board that shifts shortwave frequencies up into the dongle's range. Or you buy a purpose-built SDR that does HF natively, like the SDRplay or Airspy HF Plus. Those run somewhere between one hundred and two hundred dollars. Still cheap by radio standards, but not thirty dollars cheap.
So the entry point is modest but there's a fork in the road immediately. Thirty dollars plus a forty dollar upconverter, or just buy the hundred and fifty dollar thing that works out of the box.
And the antenna. That's the part people always underestimate. The receiver matters less than what you hang in the air. For shortwave you want a long wire antenna, ideally outside, ideally away from buildings. Forty feet of wire and a balun will outperform a two hundred dollar receiver plugged into a terrible indoor antenna every single time. Daniel lives in an apartment in Jerusalem. That's the real constraint, not the software.
He's got a balcony.
A balcony helps. A wire antenna strung from a balcony to a tree, or even just draped along the railing, will pick up plenty. But he's also in a dense urban environment with enormous amounts of electrical noise. Switch mode power supplies, LED lighting, every charger in the building. The noise floor in a city can be twenty decibels higher than in a rural area. That's the difference between hearing a weak station and hearing nothing.
So the stack starts with a wire and a quiet place to put it. Then what? He asked specifically about Linux packages.
The core of any automated monitoring setup is GQRX or SDR++. Those are the interactive receivers, the things you use when you want to spin the dial and listen. But for automation, the workhorse is rtl_fm, which comes with the RTL-SDR driver package. rtl_fm is a command line tool that tunes to a frequency, demodulates the signal, and streams audio to standard output. You can pipe that directly into a file, or into another program.
Give me the actual pipeline.
Sure. You run rtl_fm with flags for the frequency, the mode, and the sample rate. Pipe the output to sox for audio processing, then to a file. Or pipe it into direwolf if you're doing digital modes, or into multimon for decoding things like POCSAG pager traffic. For scheduled scanning, there's a package called rtl_airband. Originally built for monitoring aircraft frequencies, but it scans a list of frequencies, squelches silence, and records only when there's actual signal. That's the key piece for automation. You don't want to record twenty-four hours of static. You want the receiver to sit there quietly and only capture when something breaks the squelch.
So the dumbest possible version of this is a cron job that fires rtl_fm at a list of frequencies, records for thirty seconds each, and saves the files.
That works. It's crude but it works. A smarter version uses rtl_power, which sweeps a frequency range and produces a spectrogram over time. You end up with a waterfall image showing what was active at what frequency and when. That's actually how a lot of people find new signals in the first place. They run a wideband sweep overnight, look at the waterfall in the morning, and see what popped up.
And then there's the decoupling layer Daniel was asking about. The part where you upload to a common cloud and other people do the analysis.
This is where shortwave has something AIS doesn't, and it's been around since before the internet. The granddaddy of all of this is the KiwiSDR network.
Explain that.
A KiwiSDR is a small dedicated receiver, about three hundred dollars, that plugs into an ethernet port and a shortwave antenna. It's a complete HF receiver on a board with a web interface. The owner sets it up and registers it on a public directory. Then anyone in the world with a browser can connect to that receiver and tune it remotely. Right now there are over seven hundred KiwiSDRs online worldwide. You want to hear what shortwave sounds like in Finland at three in the morning? Click on a receiver in Helsinki. You want to check if a transmission is audible in Japan? There's a KiwiSDR in Tokyo.
So the capture layer is distributed by definition. Each owner runs their own receiver, and the analysis layer is whoever happens to be listening.
And the upload is automatic in the sense that the receiver is always online and always accessible. The owner doesn't have to do anything after setup. The community aggregates through directories like receiverbook dot de, which lists KiwiSDRs and other web-accessible receivers with their locations and frequency coverage.
That's the crowdsourcing part. But what about actually recording and uploading data, not just providing a receiver?
That's where the WebSDR and OpenWebRX projects come in. OpenWebRX is software that runs on a Linux server with an SDR attached. It provides the same kind of web interface, but it's more flexible about hardware. You can run it on a Raspberry Pi with an RTL-SDR dongle. And it has a feature that lets multiple users tune the same receiver simultaneously, each getting their own audio stream. The server does the capture, the users do the tuning and listening. Analysis is inherently distributed.
But that's still real-time listening. Daniel asked about automatic uploads, the AIS model where your receiver just dumps data into a common pool and other people's software figures out what it means.
The closest equivalent in the shortwave world is probably the Reverse Beacon Network. That's for amateur radio, but the architecture is exactly what Daniel's describing. Operators run receivers with software that listens for Morse code callsigns. When the software decodes a callsign, it automatically uploads it to a central server with a timestamp and frequency. The server aggregates reports from hundreds of receivers worldwide. So if you're a ham and you want to know how far your signal is reaching, you check the Reverse Beacon Network and see which stations heard you in the last five minutes.
That's capture and analysis fully decoupled. The receiver operator doesn't even know what they heard. The software decoded it and shipped it upstream.
And the analysis layer is a database query. You look up your callsign and get a map of propagation. That's the model Daniel's imagining, and it exists, it's just optimized for a specific mode and a specific community.
Is there something like that for utility stations? The diplomatic traffic he's actually interested in?
Not in the same automated way, no. And that's worth being precise about. There are communities that catalogue utility stations. The UDXF, the Utility DXers Forum, has been doing this for decades. People log what they hear, post frequencies and callsigns, and maintain shared logs. But the logging is manual. A person listens, identifies a station, and writes it down. There's no software that automatically decodes a diplomatic transmission and uploads it, because diplomatic traffic is often encrypted or uses modes that aren't publicly documented.
So the automated layer stops at detection. You can automatically record that something transmitted on eight point nine megahertz at three in the morning. You can't automatically know what it was.
The automation gets you the waterfall, the timestamp, the frequency, the signal strength. Everything after that is ears and experience. That's why the KiwiSDR network is so powerful for this. You don't need your own receiver in the right place at the right time. You need access to someone else's receiver in the right place at the right time. The community has already solved the capture layer. You just tune in.
Let me push on the AIS comparison, because I think there's a structural difference Daniel's intuition is brushing against.
Go ahead.
AIS is digital from end to end. A ship broadcasts a structured data packet with its position, speed, heading, and identifier. Your receiver decodes the packet and uploads it. The analysis layer is trivial because the data is already structured. Shortwave is analog. The signal is a voice or a digital mode that may or may not be documented. The capture layer is easy to automate, but the decoding layer is not. You can't crowdsource decoding the way you can crowdsource position reports, because decoding requires human ears and judgment.
That's right. And there's a second difference. AIS is line of sight. Your receiver hears ships within about fifty nautical miles. So you need thousands of receivers to cover the world's coastlines, and the redundancy is the point. Shortwave propagates over thousands of miles. One receiver in Cyprus can hear stations all over Europe, the Middle East, and North Africa. You don't need thousands of receivers. You need maybe fifty well-placed ones to cover the entire planet.
Which is exactly what the KiwiSDR network has. Seven hundred receivers is already overkill for global coverage.
And the redundancy is still useful, because propagation changes hour to hour. A frequency that's audible in Cyprus at noon might only be audible in Finland at midnight. Having receivers spread across latitudes and longitudes means someone somewhere can always hear it.
So if Daniel actually built this, what would his stack look like?
Let's say he wants to do it properly on a Linux server. He buys an SDRplay RSPdx, which is about two hundred dollars and covers shortwave natively. He runs a long wire antenna out to the balcony. On the server he installs the SDRplay driver and SoapySDR, which is the abstraction layer that lets different software talk to different hardware. Then he installs OpenWebRX on top of that. Now he's got a web-accessible receiver he can tune from anywhere, and if he registers it on receiverbook, so can everyone else.
That's the community contribution layer.
Then for the automated scanning, he writes a script that uses rtl_power or the SDRplay equivalent to sweep the HF bands overnight and save the waterfall images. In the morning he looks at them, finds interesting signals, and tunes in live to investigate. If he wants to record specific frequencies on a schedule, he sets up rtl_airband or a simple cron job with rtl_fm to capture audio when the squelch breaks.
And the total cost?
Two hundred dollars for the receiver, maybe fifty for wire and connectors, and a Raspberry Pi he probably already owns. The software is all free and open source. The real cost is time and patience. Shortwave monitoring is a hobby where you spend hours hearing nothing and then one night you catch something extraordinary.
The leaf medicine of radio hobbies.
I'm going to ignore that. But there's one more piece of infrastructure worth mentioning, because it's the most technically impressive thing the community has built.
What's that?
The KiwiSDR TDoA network. TDoA is time difference of arrival. The idea is that a signal arrives at different receivers at slightly different times, and if you know the exact positions of the receivers and the exact arrival times, you can triangulate the transmitter's location. The KiwiSDR community built this into the platform. You can select a signal, and the system will use up to twenty or thirty KiwiSDRs that are all hearing it, measure the arrival time differences, and plot a likely location on a map.
That's not crowdsourced analysis. That's crowdsourced capture with automated geolocation.
And it works. The accuracy depends on how many receivers hear the signal and how well synchronized their clocks are, but people have used it to locate pirate broadcasters, numbers stations, and interference sources. It's the single most impressive feature of the whole ecosystem, and it's built entirely by volunteers running three hundred dollar receivers.
So the answer to Daniel's question about decoupling is that the shortwave community decoupled capture and analysis years ago, but in a different direction than AIS. AIS uploads data to a central server for automated analysis. Shortwave uploads access to the receiver itself, and the analysis is done by humans tuning in from anywhere.
And the automated piece, the thing he asked about with packages for frequency scanning, that's the bottom layer. It finds signals. It doesn't identify them. The identification layer is still human, and that's not a limitation of the software. It's the nature of the signals.
What about the legal side? He's in Israel. Is it legal to listen to diplomatic transmissions?
The legal situation varies by country. In most places, listening to shortwave is legal because the signals are broadcast into public space. You can't help but receive them. The restrictions usually kick in when you try to decrypt encrypted communications, or when you act on what you hear. In Israel specifically, the rules around radio monitoring are... I'm not certain about the current statute. I know amateur radio is regulated, and I know there are restrictions on intercepting certain categories of communications. Daniel would want to check that before he starts recording diplomatic traffic and uploading it to a public server.
That's the sensible caveat. Though I suspect the diplomatic services themselves are well aware that anyone with a thirty dollar dongle can hear them. That's why the interesting stuff is encrypted.
Right. The HF diplomatic traffic that's in the clear is things like weather broadcasts, aviation notices, and routine administrative chatter. The sensitive material is encrypted, and no amount of crowdsourcing is going to break that.
So the realistic outcome of Daniel building this stack is that he'd spend a weekend setting it up, record a few nights of static, catch one numbers station, and then spend the next six months trying to identify a weak signal on eight point nine megahertz that turned out to be a fishing boat.
And he'd love every minute of it.
He said he's not going to do this.
He said that about the AIS receiver too. Hannah mentioned he's got three of them now.
That's true. The man has a problem.
It's a very specific problem. The problem of having a server with spare USB ports and a natural curiosity about radio.
Let me ask you something. If you were setting this up, what would you actually monitor? What frequencies would you start with?
For diplomatic and utility traffic, I'd start with the standard HF aeronautical bands, because those are active and in the clear. Then the maritime bands. Then I'd look at the known utility frequencies. There are published lists of frequencies used by various government and military services. The UDXF maintains logs. The shortwave broadcast bands are also useful for propagation testing, because you know exactly when and where those stations are transmitting, so you can calibrate your receiver against them.
So you'd use the broadcast bands as a known reference signal.
If Radio Romania International is coming in clearly on seven point three megahertz, you know your antenna is working and the band is open. Then you sweep the utility frequencies and see what else is there.
And the automated scanning would just log everything, so you build up a picture over time of what's active when.
That's the real value of the automated layer. Not catching a specific transmission, but building a database of what's normally on the air, so that when something unusual appears, you notice it immediately.
Anomaly detection.
It's exactly anomaly detection. The same thing security people do with network traffic. You baseline the spectrum, then alert on deviations.
That's a very Daniel way to think about it. He'd probably build a dashboard.
He would absolutely build a dashboard. Grafana with a waterfall feed and a list of active frequencies and a map of KiwiSDRs he's connected to.
And then Hannah would ask why the balcony is covered in wire.
She'd ask once, and then she'd accept it. That's how it goes.
I want to go back to something you said earlier, about the KiwiSDR TDoA network. Because that's the piece that feels new. The idea that you can geolocate a transmitter using nothing but volunteer receivers and time difference measurements. That's a capability that used to belong exclusively to militaries and intelligence agencies.
And now it's a feature on a three hundred dollar receiver. The accuracy isn't as good as what a government can do with dedicated direction-finding stations, but it's good enough to narrow a signal down to a region or sometimes a city. For a hobbyist, that's extraordinary.
It also changes the threat model for anyone transmitting on shortwave. If you're a pirate broadcaster or a numbers station operator, the hobbyist community can now find you.
The numbers stations know this. That's one reason they use multiple transmitter sites and change frequencies constantly. They're not trying to hide from the hobbyists specifically, but they know the hobbyists are listening and logging.
The whole ecosystem is this odd mix of hobbyists, intelligence agencies, and commercial operators all sharing the same spectrum and watching each other.
And the hobbyists have better tools than they've ever had. A thirty dollar dongle and free software gives you capabilities that would have cost a government agency serious money thirty years ago.
That's the democratization of signals intelligence.
It is. And the network effects are real. Every new KiwiSDR that comes online makes the TDoA network more accurate. Every person who logs a utility station adds to the collective knowledge. It's a collaborative infrastructure project, and it's been running for years without anyone really noticing.
Which is probably how the people who run it like it.
I think so.
Hilbert: You keep saying dongle.
We do.
Hilbert: It's a stick. A little USB stick. I had one of the first ones, back when they were still sold as TV tuners. Twenty dollars from a shop in Shenzhen, shipped in a padded envelope with no return address. Worked fine for two years, then the capacitor blew. I still have it in a drawer.
The early ones were notoriously fragile. The newer ones have better shielding and a proper SMA connector.
Hilbert: The antenna connector on mine was a little plastic thing meant for a portable TV aerial. I had to file down the case to fit a proper adapter. Then I bolted the adapter to a piece of wood so it wouldn't rip the connector off the board. Ran it for a year like that, listening to aircraft.
What were you doing with aircraft?
Hilbert: I lived under the approach path to an airport. Wanted to know if the planes were keeping to the published routes. They mostly were. One night I picked up a medical helicopter that wasn't on any of the published frequencies. Turned out they'd changed their ops channel and forgot to update the database.
That's the thing about monitoring. The interesting catches are almost always administrative errors.
Hilbert: The automated scanning is overrated. You'll record three hundred hours of static and the one thing you actually want, you'll miss because the squelch was set wrong. Better to listen live when you know something's happening. I used to sit with a cup of tea and just tune around. That's how you find things.
So you're saying the software stack is less important than the human in the loop.
Hilbert: I'm saying the software's fine, but it's a tool, not a replacement. The people who rely on automated scanning end up with hard drives full of noise and no idea what any of it is. The people who listen, they know.
That matches what the UDXF people say. The logs are built by people who tune in and identify stations by ear. The automation helps you find activity, but the identification is all experience.
Hilbert: I had a friend who could identify a transmitter by the sound of its carrier. Before the transmission even started, just the hum of it. He worked for a broadcast engineering firm in the seventies. Spent his life around transmitters. He'd say, that's the BBC site at Skelton, and he'd be right. You can't automate that.
That's a very specific skill.
Hilbert: It's a lost one. Most of the old broadcast engineers are gone now. The new ones know digital, not the feel of a tube transmitter warming up.
The shortwave broadcast landscape has changed enormously. Most of the big international broadcasters have moved to internet streaming and shut down their shortwave sites.
Hilbert: I know. I used to listen to the BBC World Service on shortwave every night. Now it's online, and the frequencies are quiet. But the utility traffic is still there. The diplomatic stuff, the military, the maritime. That never went away.
Because there's no internet alternative for a ship in the middle of the ocean or a diplomatic mission in a country where the network is down.
Hilbert: The boring stuff survives. That's what I learned from all those jobs. The boring stuff survives because it has to.
Hilbert: Anyway. If Daniel's going to build one of these, tell him to buy the dedicated receiver, not the dongle. The dongle's fine for VHF and aircraft, but shortwave needs a proper front end. And tell him to put the antenna outside. That's the whole thing. The antenna is the whole thing.
That's what Herman said.
Hilbert: Then Herman's right.
The misconception I keep running into with this topic, and I think Daniel was dancing around it, is that the receiver matters. It doesn't. The antenna and the location matter. You can spend three hundred dollars on a KiwiSDR and hear nothing if your antenna is a piece of wire draped over a radiator. You can spend thirty dollars on a dongle and hear the world if you've got forty feet of wire outside and a quiet noise floor.
The second part of that misconception is that the software will do the work for you. It won't. It'll find signals. It'll record them. It'll even geolocate them if you're using the TDoA network. But it won't tell you what you're hearing. That's still a human skill, and it's one that takes years to develop.
The stack is cheap, the community is generous, and the real investment is time and attention.
Which is true of every worthwhile hobby.
I wonder how long it takes Daniel to order the receiver.
I give it two weeks.
I'll take the under.
One forward-looking thing. The TDoA network is the piece that's going to keep improving. Every new receiver makes it more accurate, and the software is under active development. In a few years, geolocating a shortwave transmitter might be as routine as looking up a ship on AIS. That's a genuine shift in what hobbyists can do.
It's worth keeping an eye on what happens when that capability becomes widely known.
Thanks to Hilbert Flumingtop for producing.
This has been My Weird Prompts.
If you want to reach us, email us at show at my weird prompts dot com.
We'll be back soon.
