In the community of radio amateurs scattered around the planet we have a habit of getting together with others to have fun in whatever shape that takes. The obvious ones are HAMfests, car boot sales, raffles and other amateur adjacent pursuits, but we also do things like licence training, weekly on-air nets, contesting, portable activations, climbing mountains, or hills, setting-up in parks, or lighthouses, we set-up on a field day, just for fun, and find excuses, sorry, reasons, for any number of other activities.

Some of these are solitary affairs, but many are best enjoyed shared with multiple friends, both old and new ones. Having been a member of this community since 2010 I've come to observe an aspect of this community that is odd, to say the least.

We organise all these events, but rarely promote it beyond a single email to three people, if that. It's almost as-if the average organiser thinks that their event permeates the community by magic osmosis.

Even if there is any form of promotion, there's sometimes a date and time, but hardly ever does it show that time in UTC, even if it's a radio event, it's like we've forgotten that radio waves pass through time zones, or there is a misconception that everyone on the planet knows what your local timezone is, let alone if it's summer or winter time at the time of the event.

So, what does promoting your event look like if you actually want people to know about it?

For starters, you should consider who you want to have as a participant. A local HAMfest is unlikely to attract people from around the globe, but Friedrichshafen and Dayton are examples that contradict that notion. A VHF-only event might be intended for local amateurs, but what if it allows for satellite or digital contacts, like say via Allstar, IRLP or Echolink? Similarly, you might run a weekly on-air net, but have visitors from around the planet.

The point being, that your audience might not be exactly what you initially think. In other words, there might be people playing from further afield. Consider that when you announce what time the event starts, and finishes. Speaking of finishing, adding an expected closing time is helpful for participants where only one member of the family lives and breathes amateur radio and the rest just want to get on with their respective lives, so consideration is welcome.

Aside from telling your audience when and for how long the event goes, adding a location is not optional. You'd be surprised how many events say things like: "it's again in the usual location", or "we're at the community hall" without ever publishing an address. I can tell you, it's fun discovering that the name of the hall isn't unique.

Now, for the big one. After putting the information together about the event itself, where and how do you announce it?

For starters, on your own website, in whatever form that takes. It serves two purposes, announcing to the world what is happening, but it's also the definitive place where the right information is published. This is important because things change, get cancelled, moved, updated, whatever. Life isn't static, so you need to define a place where the official announcement lives.

At this point I'd like to mention that this is often where promotion stops. It's easy to think that in your universe everyone you know is aware of your website, but that's just not true. A single place to publish is not the end of the process, it's the start.

Then you need to use things like the local news broadcast, the national news broadcast, the international news broadcasts, contesting websites and calendars, social media, fediverse and whatever else you can get your hands on. You need to include it in your own club news, in club newsletters from other clubs, on the local amateur notice board, you need to talk about the event on-air, share it during on-air nets and if it's recurring, tell the world that it's going to happen again next year.

Nothing here is revolutionary, it's not like launching a rocket into space, this is basic common sense and you too can do this. If you need help, ask.

So, if you have an event that you want to have participants for, you need to make noise. Publishing the announcement at the local planning department in Alpha Centauri 50 years before the event is going to cause issues, as will defining the date for an annual event as: When the June solstice is on a weekday (Monday through Friday), the weekend following shall be the weekend of the event. When the June solstice falls on a Saturday or Sunday, that weekend shall be the weekend of the event, but only for the Winter field day, the Summer one requires you to count back four weekends, or forward, depending on if you're talking about the Spring or Summer event, and add one if it falls on the weekend.

In case you're wondering. No, I didn't make that up. It's real. I'll leave you to ponder how you'd add such an event to your family calendar.

I'm Onno VK6FLAB

Recently I was given some radio data captured on the 40m band. Using a piece of software called "Universal Radio Hacker", I attempted to decode it. At the time I thought that this might be Morse code, since then I've been told by someone who has been using Morse longer than I've been alive, that it isn't.

I shared the data on my VK6FLAB GitHub repository where you can download it and see what you learn, and perhaps repeat what I did, or better still, improve on it.

Over the years I've talked a little about how Software Defined Radio or SDR works, essentially it's a glorified Analogue to Digital converter, much like the sound card in your computer, which does the same, albeit at a much lower frequency. As it happens, you can represent the signal that comes into your radio antenna as a series of values. Essentially, the stronger the signal, the bigger the number, the weaker the signal, the lower the number.

Let's talk about the characteristics of this signal. It consists of two parallel signals, in opposition to each other. The first signal jumps intermittently between 7 kHz and 40 kHz, where the second jumps between -7 kHz and -40 kHz. The recording is marked 7.06 MHz, so if we think of that as the central frequency, the whole signal sits between 7.02 and 7.1 MHz. This 80 kHz wide signal is not something you'd typically be able to hear using a standard amateur radio receiver which tops out at about 3 kHz bandwidth. It's so wide that you couldn't even hear more than one of the four tones at the same time.

Randall VK6WR, who supplied the recording, spotted it on a waterfall display showing a chunk of radio spectrum, in fact, a $25 RTL-SDR dongle could receive this signal.

Aside from the fact that this is a really wide signal, well at least in traditional amateur radio terms, it was interesting in that it was heard on the 40m band. As it happens, just after I shared my initial exploration, I was told by several other amateurs that they had heard the signal. I even saw it on a WebSDR in India and attempted to record it, but failed.

As it happens, a few weeks ago, I was playing with something called "CAN Bus", or Controller Area Network, a technology that was designed in 1983 and is used all over cars for things like sensors for speed, engine temperature, oxygen level, detonation timing and anything else that's happening inside a car. You might know the end-user view of this called OBD2 or On Board Diagnostics, second generation. I was looking into it because my car has been acting up and I've been trying to track down the root cause.

Anyway, I learned that CAN Bus is implemented using something neat, "differential signalling", where two wires each carry the same, but opposite signal, so they can be combined to ensure that in an electrically noisy environment like a car, the information still gets where it needs to go.

Seeing the radio signal Randall shared, reminded me of this.

Noise immunity is a useful attribute in digital HF communication, so I can understand why it was done like this, but it also means that either signal was sufficient to start to decode the information. We can use Universal Radio Hacker to show us only half the signal using a band pass filter.

I then decided that the 40 kHz frequency was "on" and represented by a "one" and the 7 kHz frequency was "off", represented by a "zero". Of course that's entirely arbitrary, there's no reason that it cannot be the other way around, but for our purposes it doesn't matter at this time.

That said, we don't yet have enough to decode the actual signal. We need to figure out how long each switch, or bit, lasts, because two zero's side-by-side or two ones side-by-side would look like a long "off" or a long "on". Using that logic, you could also say that the shortest possible duration for a 40 kHz or a 7 kHz tone would represent a single "one" or a single "zero".

Of course, this is a simplified view of the world. For example, the data file contains more than thirteen and a half million bytes. Half of those are for the I in I/Q, the other for the Q. I'm purposefully glossing over a bunch of stuff here, specifically the notion of so-called I/Q signals, that's for another time.

In computing a single byte can represent 256 different values. It means that if the signal is represented by a single byte, a voltage from the antenna at maximum amplitude can be represented as 255 and the minimum amplitude as 0. As it happens, voltages go up and down around zero, so, now we're only using half a byte, 127 for maximum, -128 for minimum. If we use two bytes, we get significantly more resolution, -32,768 as the minimum and 32,767 as the max.

A little trial and error using another tool, "inspectrum", told me that the data was organised as two bytes per sample. Which brings the next point. How many samples per signal?

Said differently, we're measuring the antenna voltage several times per second, let's say twice per second. If a tone of 7 kHz lasts a second, then we get two samples showing 7 kHz. If it lasts half a second, we only get one. As it happens, we're measuring over 22,000 times per second and using the cursor feature on Universal Radio Hacker, we can determine that each signal lasts 2,500 samples. It's roughly a rate of 100 bits per second. The "inspectrum" tool puts it at 91.81 Baud. It's not a standard Baud rate, sitting between 75 and 110 Baud.

Using Universal Radio Hacker, I was able to decode 1,416 bits. You'll find them on my GitHub page next to the signal.

Now for the fun. What does it mean?

I started with looking for structure, by looking for zeroes. In short order I discovered several sequences of zero, then I noticed that there appeared to be a repeating pattern. After some trial and error, using the "grep" and "fold" commands on my Linux terminal, I discovered that the pattern repeats, more or less, every 255 bits. I say more or less, because there are a few bits that are not the same. I suspect that this is a decoding error which could potentially have been eliminated by using the noise immunity features associated with the differential signalling, but I don't yet know how to do that.

Here's what I think I'm looking at.

It appears to be a signal that's a unique identifier, specifically so that it can be used to synchronise two things together. In this case, I suspect that it's an over the horizon radar and the sequence is used to synchronise the transmitter and the receiver. I think that the signal strength variations are what allows reflections to be measured and I suspect that the actual transmitter and receiver are using more than two bytes to represent each sample, but I'm speculating.

If you have an alternative explanation, I'm all ears.

I'm Onno VK6FLAB

What's the corporate phrase again?

"We're sorry for any inconvenience this has caused our valued customers."

Recently I was helping a friend erect their newly refurbished multi-band antenna and during the process we discussed the notion of tuning an antenna that's high in the air. They made a curious response, in that they'd tuned the antenna on the ground before we started.

I asked how this would work, since as I understand the process, this changes things once it gets in the air. They assured me that while the actual SWR might change, the frequencies at which it was resonant would not.

This was news to me because I've been putting off erecting my own multi-band 6BTV antenna mainly because I didn't really want to face having to erect it, tune it, lower it, modify the elements, erect it, tune it, etc., all whilst standing on the steel roof of my patio. Would this phenomenon be true for my antenna?

It occurred to me that I could test this idea, not only for my antenna, but for other antennas as well. In my minds-eye, I saw a video displaying the pertinent attributes of an antenna, SWR, gain, radiation pattern, and whatever else I could think of, animated with the modifications of things like height and ground radials.

If this sounds familiar in some way, it's because I've been here before. This time the outcome was slightly different, since I found a tool that can optimise antennas using a genetic algorithm. What I mean by that is an automated process where you can test variations of a thing, in this case antennas. Rather than design each antenna and test it, you essentially generate antenna designs and tweak them to determine the best one. Then you use that to generate the next series of designs. Rinse and repeat until you have what you're looking for. There's a whole field of computer science dedicated to this and unsurprisingly the rabbit hole goes deep.

The tool is called "xnec2c-gao" and it's written by Maurizio DC1MDP. The name of the tool hints at its nature, working in combination with "xnec2c", written by Neoklis 5B4AZ and maintained by Eric KJ7LNW, you'll find links to both tools on the xnec2c.org website.

How the two tools work together is a beautiful dance. The antenna modelling tool, xnec2c, can read an antenna definition file and detect if it changes, at which point it can redo the simulation, which it can output to another file. The genetic algorithm optimisation tool, xnec2c-gao, can detect the changed output and update the antenna definition file, and the process repeats. Which brings me to a pro-tip, for this to work, you need to configure xnec2c to do two things, detect the changed definition file, and write the output to CSV, both of these options can be found in the "Optimization Settings" menu, just so you don't spend an hour banging your head against the desk.

Between the two tools, the antenna definition evolves and you end up with a design optimised for your purpose. The default does this for SWR and gain. Mind you, I tested a multi-band dipole which managed to find some interesting designs, but didn't pick them because a low SWR combined with a high gain, for reason't I don't yet understand, wasn't considered better than a high SWR with a high gain, so there's some work to be done. As a software developer I have a sneaking suspicion that it's adding the two, rather than picking the highest gain combined with the lowest SWR, but I haven't confirmed that. As I said, deep rabbit hole.

While we're not yet at the video display stage, for the first time I can get a sense that this might come to pass. There's plenty of work to be done. For example, the antenna display on xnec2c during the process seems broken, there's no way to output gnuplot files during the process, and capturing the various charts in real-time will require work, but all that seems if not easy, at least possible.

Meanwhile, I'm attempting to locate an antenna definition file, preferably in .NEC format for my 6BTV antenna, so I can use this combination of tools to discover if tuning it on the ground will work and while I'm at it, discover if the installation I'm working on will give me something worthwhile.

I realise that this is well beyond "try it and see", but my body isn't up to climbing up and down ladders 17 times in a day and I think that getting a feel for what might occur is a good way to learn.

When was the last time you climbed on a roof and what did you do to avoid it?

I'm Onno VK6FLAB

Just over a year ago, the ARRL, the American Radio Relay League, the peak body for amateur radio in the United States and one of the oldest of such organisations, experienced an incident.

During the weeks following, the ARRL was tight-lipped about the extent of the incident and most amateurs only really noticed that services were off-line or slow to respond. After months of delay and disinformation, the ARRL finally revealed that it was the subject of a ransomware attack and that it had paid a million dollar ransom. It went on to blame the authorities for its silence.

Mind you, it didn't tell me personally, it made public statements on its website. Similarly when I specifically contacted the ARRL to discover what information of mine it held, and what the status of that information was, the ARRL responded that I should refer to its public statements. It continued to state that my information was not compromised, since it only lived in LoTW, the Logbook of The World, the system it uses to coordinate the verification of amateur radio contacts, which are used to distribute awards like the DXCC and Worked All whatever.

Imagine my surprise when I received an email this week, sent from "[email protected]" to my non-amateur radio email address. I confirmed with several amateurs that they too received this email. Informative, to a point, but likely well beyond anything intended by its author, it stated that LoTW was being updated with associated down time, incidentally, inexplicably, coinciding with the 2025 ARRL Field day, and it "will be fully migrated to the cloud". It went on to solicit donations. It made no reference whatsoever to the ransomware attack.

There's a lot hidden in that email.

Although the attack last year was linked to the outage associated with LoTW, the ARRL has continued to claim that the LoTW data was not impacted by the ransomware attack, but the email reveals that the system is being migrated to the cloud, in other words, right now, it's not in the cloud. Which begs the question, where is the server infrastructure for LoTW today, and more importantly, where was it a year ago when its systems were compromised?

From a public post by Dave AA6YQ, dated the 2nd of February 2021, in response to a message about a January LoTW committee meeting, we know that the LoTW server "now employs the current version of an SAP database engine". A month before that, Dave wrote another informative email that indicated that 105 thousand callsigns submitted logs to LoTW in the last 1,826 days or the five years between 2016 and 2021. There were logs from 21 thousand callsigns in the week prior to that January post. In all, according to Dave, there were 153,246 callsigns who submitted contacts to LoTW.

The LoTW committee meeting minutes are no longer available from the ARRL website, but I have a copy. The document states that there were 1.2 billion contacts entered into LoTW, big number right? The next line tells us that this resulted in 262 million QSO records. I wonder what happened to the other billion records? This activity was generated by 139 thousand users using 200 thousand certificates. For context, every VK callsign automatically comes with an AX callsign, but LoTW requires that you separately register each with its own certificate.

As someone who has been playing with databases since the 1980's I can tell you that LoTW is a tiny database. For comparison, the WSPR database is an order of magnitude larger, not to mention, more active. I have no insight into the business rules within the LoTW database, but the fact that updates are being processed in batches and that it regularly has delays indicates a level of complexity that I cannot account for.

As an aside, the LoTW committee document lists 10 members. Dave is not one of those listed. It makes me wonder who else has access to this database. Note that I have no reason to believe that Dave's information is questionable, nor that he has access that he shouldn't, he was after all a member of the LoTW committee from 2013 until 2017 when the ARRL removed all development resources from the LoTW. I'm asking who else has access and why? While we're here, who has been doing maintenance and updates on this system over the past seven years?

Moving on. The database for LoTW contains information from amateurs all over the planet, including those in Europe where the GDPR, the General Data Protection Regulation, enacted in 2016, is extremely strict on the security and disclosure of personal data with very heavy penalties for breaches. The GDPR requires notifications be sent within 72 hours of a breach, and that an organisation must designate a data protection officer. I wonder who has that role at the ARRL and I wonder if they told anyone? Did any European amateurs receive personal notification from the ARRL about their data, I know I didn't.

My first activation of LoTW was in 2013, now twelve years ago. I received certificate expiry messages in 2016 and 2019. Since then there have been no such messages. That's unsurprising, since I stopped using LoTW once I discovered just how broken it was. Don't get me started on portable and QRP variants of my callsign. My care factor is low as to when I last actually used it, since attempting to dig up that information would take considerable effort, but I can guarantee that it was before 28 October 2019, when the last certificate expired.

You might come to this point and ask yourself why am I digging into this at all?

Let me ask you some questions in addition to those I've already mentioned.

SAP, the database system which apparently runs LoTW, had 254 CVEs, or Common Vulnerabilities and Exposures listed, in 2020 alone. It continues to have exploits. When was SAP updated and is it up to date today?

Is it credible that LoTW wasn't compromised during the ransomware attack? Does the ARRL know this for sure, or did it just not detect the compromise?

We know that LoTW was down during the incident and according to the UptimeRobot service showed outages on the 14th of May 2024 but we still don't know exactly when this attack started.

As you might know, the ARRL is also the headquarters for the IARU International Secretariat, the administration body for the global representation of our hobby. It presumably shares infrastructure with the ARRL, but at no point in the past year have we been advised of the impact of this breach to the IARU.

What information is stored in LoTW and why has the ARRL continued to ignore requests for disclosing the specific information it holds on the users of that system? I know for sure that it knows my callsigns and my email address. I also know for sure that it required identity documents to prove my identity and right to use those callsigns. I have been told in writing that LoTW never deletes anything, so what does it store and can I delete all my records and if-so, how?

Why did I receive an update about the upgrade for LoTW when I'm clearly not an active user of the system?

The [email protected] is used for all manner of services, including the propagation updates, and the three other ARRL bulletins. In other words, this address is used for a myriad of messaging. Is this information stored in a database and if so, where is this database? Was it compromised? What information is stored in that database? Are my details in that database, are yours?

While discussing this LoTW update email with other amateurs, I was informed by one amateur that even after they stopped being a member of the ARRL, as a direct result of the ransomware attack and the discontinuation of the delivery of QST magazine they paid for, the ARRL continued to send regular email updates as-if they were still a current member. Where is that data stored and how are the ARRL not considered a source of SPAM?

While we're exploring the blurred lines between being a member of the ARRL and not, why did it send the update about the incident via email to its members on 21 August 2024 and update the website a day later, and why did it not send that same email to me and every other amateur directly? Why does the ARRL continue to ignore its obligations in relation to the personal information it clearly and demonstrably holds?

The GDPR has been a fact of life since 2016. It's not optional if you store data for European citizens, but the ARRL doesn't even mention it on their privacy policy page. Did European users receive specific notification about the breach, now a year ago, which clearly the ARRL had both the capacity and obligation to? Has the GDPR been invoked by European amateurs? Should it?

You could attempt to explain all this as incompetence or mismanagement. That's a response, but it doesn't pass the sniff test. For example, implementing SAP is a non-trivial process. I have over 40 years professional experience in the ICT field and I'm not sure I would stick up my hand to have a go at doing this. Mind you, if I did, there's no way I'd choose SAP, I'd find an open source solution, but that's just me, not to mention that SAP license costs are significant, this in an organisation asking users for donations.

The thing is, we're talking about a system that's now at least 22 years old, running in an organisation that's been around for over a century, an organisation that deals in regulation and legalese at the very foundation of its existence.

In other words, there's a massive amount of legal and technical skill and history available within the organisation, but we're still seeing this level of at best questionable, at worst illegal behaviour.

I'm not a member of the ARRL and nothing I've seen to date makes me want to give them any of my money. If you are, perhaps you should be asking some questions. If you're a citizen of Europe, perhaps you should start asking some questions about your data. If you pay money to your own peak body, then you should ask it to find out what happend at the IARU International Secretariat during the attack.

I'm Onno VK6FLAB

cross-posted from: https://piefed.social/post/963962

Foundations of Amateur Radio

The other day Randall, VK6WR, encouraged me to get on-air. He described it like this:

"There is a mystery signal on 40m that you can try your new Universal Radio Hacker skills on. It appears to be a FSK signal separated by 7kHz with the two signals at 7.0615 and 7.0685 MHz. Each of them on their own sounds a bit like a Morse signal, but my CW decoder decodes junk. But if you can see it on a spectrum scope, it is clearly FSK because either one of them is on at any time."

He went on to say: "You'll need an SDR to receive the signal given the separation, but could be a fun investigation!"

Having just discovered "Universal Radio Hacker", a tool that can help you decode radio signals, that sounded like something I'd love to have a go at. Unfortunately, after the demise of my main workstation last year, my current set-up doesn't allow me to do such recordings, but Randall, ever the gentleman, provided a recording of the signal.

He writes: "This was captured with gqrx demodulating the signal as SSB audio with the VFO tuned to 7.060, so both "signals" are there, one very low freq and one very high freq."

If you're curious, I've uploaded the file as it was shared with me to my VK6FLAB GitHub repository under "signals".

Over the next two days I spent my time attempting to decode this signal. I opened up Universal Radio Hacker and spent delightful hours getting precisely .. nowhere. Some of that is absolutely my unfamiliarity with the tool, but this is a great exercise in learning on the fly, where truth be told, I tend to live most of my life.

It wasn't until several hours later that I decided I should at least listen to the audio. To my ear it sounded like 25 WPM Morse Code, but being still in the learning phases, while my brain was triggering on the sequences, decoding wasn't happening. Of course I could cheat and forward the audio to one of my fellow amateurs, but the actual message wasn't really the point of the exercise, at least not at this stage.

Instead I fired up "multimon-ng" which has an in-built Morse decoder. I spent some hours doing more Yak Shaving than I was expecting, but even then, I still didn't get more than gobbledegook out of the process. I used "Audacity" to shift one of the signals by one wavelength and mixed them together. This allowed me to reduce the noise significantly, but still none of my tools did anything useful. In case you're wondering why, if you have a tone and noise and shift one signal by the wavelength of the tone, then mix them, the tone adds to itself, but the noise, random in nature, is just as likely to add as it is to subtract, so in effect, you're increased the signal to noise ratio.

After multimon-ng failed, I tried an online Morse decoder, which gave me all manner of text, but none of it made sense to me. Of course it's possible that this is someone rag chewing in a different language, but I couldn't make any sense of the thing.

I did come up with some issues that prompted me to create the signal repository. I realised that I didn't have any known "good" signals. Previously I'd tried decoding a sample FT4 signal, but that went nowhere, mainly because the signal was noisy.

So, what I'm going to do over the next couple of weeks is create some clean, as-in, computer generated, known signals, and add them to the repository. The aim is to have a known good starting point to learn from. In software development this technique is often used to limit the number of unconstrained variables. In our case, if I generate a known good Morse Code signal, then I can learn how to use Universal Radio Hacker to decode it, so when I come across an unknown signal, I can use the techniques I learnt to attempt to decode it.

Feel free to make pull requests with known good signals yourself. RTTY, PSK31, WSPR, FT8, etc. Feel free to include non-amateur modes.

One thing, I'm not looking for off-air recordings of signals, yet, that can come later, right now I need signals that are pure, as-in, as I said, computer generated. Of course at some point, perhaps sooner rather than later, I'll discover that generated signals are no easier to decode than off-air recordings, but that's for another day.

Meanwhile, you too can play. Download one or more sample files and decode them. Let me know what you learn.

I'm Onno VK6FLAB

The other day I was discussing with a fellow amateur the increased frustration my mobile phone provider was inflicting. We hit on the idea of figuring out if other providers would fit the bill and how we could determine if their coverage would suit our needs. Aside from using an old mobile phone, I suggested that using a $25 RTL-SDR dongle would provide a way to record mobile phone cell site beacons from the various mobile networks to map what signal levels we might find.

To that end, I discovered a tool called LTE-Cell-Scanner by Xianjun BH1RXH. Forked from the original project by James Peroulas, it allows you to use simple hardware to scan for LTE Cells used by mobile phone networks. James points out on his site that this tool can also be used to calibrate an RTL-SDR receiver's oscillator, since an LTE downlink centre frequency is stable to within 50 Parts Per Billion, that's 10 times more stable than my Yaesu FT-857d using a TCXO.

If this doesn't mean much, think of it as a local frequency reference standard that you can use in your shack with minimal effort and cost.

The story gets better.

I started building LTE-Cell-Scanner from source and in doing so discovered a directory on my computer named "uhrr". I didn't remember what it was for, so I looked online. The first search result, when I looked for "uhrr radio" was a repository by Oliver F4HTB, more on that in a bit.

The second search result was something called "Universal Radio Hacker". I clicked on the link and discovered a mind boggling tool. There are times in your life when something flips, this was one of those times. It happened when I discovered "csdr" by Andras HA7ILM and again when I discovered "GNU Radio".

Diving into "Universal Radio Hacker", by Dr. Johannes Pohl and Dr. Andreas Noack I was introduced to the art of decoding and generating digital radio signals. In 2018 it was presented for the first time during the USENIX Workshop on Offensive Technologies, or WOOT, as a tool to discover, decode and identify exploits of proprietary IoT devices scattered all over the planet. As an aside, USENIX, Users Of Unix, since 1975.

Back to radio. Universal Radio Hacker allows you to dissect recorded radio signals using all manner of interactive processes. When you go looking for it, and you should, I recommend that you start by watching some videos. You'll find an introductory play list on my YouTube channel. By the time you've seen those, you'll likely share my excitement.

To encourage you further, the Universal Radio Hacker is open source, written in Python, and runs on Linux, MacOS and Windows. So far there have been 94 releases of the software, so it's seen significant development in the years since it was released into the wild.

When installing it I was surprised to discover that its acronym was "uhr", not "uhrr". This was a relief since I still didn't remember what "uhrr" was all about and I couldn't imagine having forgotten Universal Radio Hacker. It turns out that the last time I looked at "uhrr" was apparently in 2021 when I shared my experience in an article titled "The remote edge..."; "uhrr" or "Universal Ham Radio Remote" is a tool that allows you to use a web browser to access a radio remotely.

My little journey into unexpected diversions, distractions and discovery has led me into a path where several puzzle pieces have come together. For example, Universal Radio Hacker and GNU Radio can talk to each other, they're both written in Python, they're both open source, have a history of development and have a community of users. The LTE-Cell-Scanner, also open source, will allow me to calibrate most if not all of my radio gear and I'm once again inspired to keep digging into yet another aspect of this wonderful hobby. I'm sure that there are more than a thousand different hobbies under this roof.

Go forth, explore, discover, be amazed, and stay curious!

I'm Onno VK6FLAB

The physicist and mathematician who demonstrated that electric and magnetic fields travel through space as waves moving at the speed of light. He proposed that light is an undulation in the same medium that is the cause of electric and magnetic phenomena. The unification of light and electrical phenomena led to his prediction of the existence of radio waves.

We wouldn't be here without his curiosity.

The other day a fellow amateur asked me to help them with lowering their radio mast so they could do some maintenance on the antennas attached to it. This is not the first time I've been a participant in such an activity, but it was the first time I felt explicitly safe.

Don't get me wrong, on previous occasions nothing bad happened, but there was always an undertone of "what-if" and an associated anxiety. This time was different. Before we did anything, we sat down, had a cup of coffee, talked and discussed what was going to happen. After coffee we looked at specifics and discussed the process in detail. Then we prepared. Clipping cable ties, winding up loose ends, disconnecting coax, and securing a pulley to a tree. We ran a winch line, discussed distances, looked at potential snags and coax lengths and angles, considered what would happen if something unexpected might happen and discussed various safety considerations, like never walking below the mast whilst it was in its most stressed position, half-way lowered and out of reach.

Then we slowly went about doing what we talked about.

All that sounds pretty reasonable, and it should. It was the first time I'd ever discussed in detail what the plan was, what could happen if something broke, if something got caught and any number of contingencies. We even discussed handling steel winch lines, something which I was unfamiliar with.

Of course it's entirely possible that something bad could happen, something neither of us had considered, but we put ourselves in a position where we both felt safe after mitigating known risks and allowing leeway for unknown risks.

Another word for this type of preparation is "Professionalism". It's a fraught word. You might recall me telling a story where I contacted the regulator to discuss wideband interference caused by a train-line, specifically blocking out a range of AM broadcast frequencies, including the emergency broadcast station. I revealed during that conversation that I was an amateur and had some experience with radio. The person I was speaking to shared that they were a "Professional", using a capital "P" to condescend that my amateur credentials were nothing in comparison to theirs. The conversation ended, the wideband interference is still there, years later.

It's not the only time I've come across this weird relationship with this word "Professionalism". At one time I worked at a community broadcaster where I was one of the producers and presenters. If you're unfamiliar, it's essentially a special interest broadcaster, in this case radio, run by mostly volunteers. We were having a meeting to discuss plans and during that I raised the notion of "Professionalism" in relation to conduct, things like turning up on time for your shift, documenting labels correctly on tapes, keeping logs, broadcasting advertisements at the allocated time, etc. Unfortunately some in the group equated "Professionalism" with "Commercialism" and expressed their discontent with the notion vocally. I stopped volunteering there shortly after.

This to say that I can understand that "Professionalism" has different meanings for different people. In a community like Amateur Radio it might mean that it's considered a taboo word, but I'd like to encourage you to think of it as a way of getting things done .. safely .. and to the betterment of the community.

So, next time you have a working bee, an antenna party, a contest, or a ham-fest, think about how you conduct yourself, how you might improve the experience for yourself and for those around you.

I call that "Professionalism".

I'm Onno VK6FLAB