Foundations of Amateur Radio
Previously I've talked about using radio spectrum monitoring to detect lightning to potentially protect your equipment. This triggered an email from Nick VA3NNW, who pointed out that AM demodulation of "one point twenty-one jiggawatts", is really a red-herring, and indeed it is. Nick went on to point at another approach, which nudged things along.
So, let's start with the herring, not sure about red, I prefer mine fresh, raw, and covered in finely cut raw onion. If you know, you know. If you don't, think sweet fairy-floss. For extra culinary points, pair it with fresh crusty white bread, preferably still warm from the bakery, and slather it in butter. Yum! Beats bacon any day.
Oh, before I forget, pickled herring, lovely, fish aside, in terms of flavour and texture, not in anyway related to fresh herring, just so you know.
Where were we, ah, uh radio.
Before jumping back in, "squelch" is a radio term, it translates to "subdue forcibly", in our case, we're using it to describe a process where radio signals below a certain level, or volume if you like, are suppressed, so you'll hear nothing until the level reaches above the specified level.
This is useful in all manner of scenarios where there's background noise. In amateur radio, squelch is used on VHF and UHF repeaters, but on HF it often means that weak signals don't get heard, keep that in mind next time you start diagnosing a silent radio, ask me how I know.
Anyway, my initial choice of "rtl-airband" as the tool of choice for lightning detection was based on the idea that I could use it to receive a chunk of bandwidth, then automatically apply the in-built squelch to make everything silent when there was nothing but local noise, then when lightning was afoot, noise would suddenly increase above the threshold imposed by the squelch, and I could detect that.
Nick pointed out that there's a better tool for this, "rtl_power", written by Kyle Keen in 2013, which can continuously monitor a whole lot more frequencies, collect them over a set period and intermittently output the power values, which can then be processed.
The tool allows you to specify which frequencies to monitor, how long for and at what resolution. This is extremely useful for exploring activity on a new band. You can use the data to create images of band activity and see what's going on.
I have previously used it to find intermittent interference. Note that it doesn't decode anything as such. It reports relative power levels for the spectrum you're exploring.
As an aside, in the process of building a Docker container for rtl_power, because of course I did, it occurs to me that I often point at Docker as a solution, but I don't think I've ever detailed why.
For starters, it allows you to install and test software without disrupting your local machine, so if you want to remove your experimental installation, you can, and nothing on your computer will be affected.
It also helps with security and permissions, allowing you to define what is allowed and what isn't, helpful if you don't trust the software you're testing.
It allows you to run multiple versions of the same software side-by-side, something which otherwise would create a lot of hard work and head scratching.
If the software you're exploring doesn't exist on your version of operating system, there's a good chance that someone has it packaged elsewhere, Docker will allow you to use that package on your system, or you can build it from source inside the Docker container and not have all the libraries and dependencies clutter your system.
There's a thing called a "Dockerfile" .. essentially a list of commands that document how something is installed. This means that you have a record on how it's done. It means that when it breaks, you have a starting point for debugging, and because it's a text file, you can version control it.
Then there's the ability to automatically start a Docker container on reboot, so you don't have to futz around with "cron" or "scheduled tasks" if you're running that other operating system.
If that's not enough, there's thousands of Docker images just waiting for you to try. I will mention that I tend to build my own images, but you don't need to start there.
So, that's why I use Docker almost everywhere. I'd love for someone to figure out how to run Wayland applications over ssh, but I digress.
Back to rtl_power.
I realised that I don't yet have any data on what lightning looks like specifically. What power levels does an RTL-SDR dongle report when lighting happens, what frequencies should I monitor for the best result, how often should I check, how much data should I collate in each sample .. although we can check every second if we really want to, it seems to me that every minute or ten might be sufficient.
If you have opinions, or better yet, data, to share, feel free to get in touch.
I will end with a disclaimer.
I have only tasted North Sea herring fresh, so you're on your own if you go fishing in a different ocean.
I'm Onno VK6FLAB
