this post was submitted on 21 Jun 2025
6 points (100.0% liked)

Amateur Radio

1672 readers
5 users here now

General amateur radio (ham radio) chat, questions, and news

founded 2 years ago
MODERATORS
 

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

you are viewing a single comment's thread
view the rest of the comments
[–] kristoff 1 points 13 hours ago* (last edited 13 hours ago)

011111001101110001011101001100101010100100100010100001001101000111110101101001010011111100000001101101010001001011110010110001000110011000111000011000001110110000101011001001110011101010111111110110110011110001101011100100001111011101111010000010000001011 0111110011011100010111010011001010101001001000101000010011010001111101011010010100111111000000011011010100010010

Hi Otto,

First of all, it is just me or is the wav-file on your github repo actually empty (just 2 byes)?

Concerning the data you receive. Nice capture finding out it is a repetative pattern.

As said, I am not at all a SIGINT expert, but let's see how far we can go with this/

So, what next? Question 1: OK, we've got a repetative pattern, so it is probably a data packet that is repeated continuesly (or multiple data-frames that happen to be all the same) But where does the packet actually start?

One important thing about digitale communication to keep in mind when dealing with digital communication: synchronisation, synchronisation and even more synchronisation!

Although the transmission has a fixed bitrate (and hence, timing), the receiver will mever have exactly the same frequency as the transmitter, so it must continuously adapt it own timingf to that of the transmitter. It does that by looking for bit-transistions and correct any error of its onw timing to that. So what you really want to avoid is large number of all-zero and all-one patterns, or at least, in actual data of the frame.

If you look at the bitstreaming, you see that '0000000 ... 1101101010' pattern.

The 7 consecutive 0 bits probably are a no-data indication.

The following bits are -I guess- the 'start of frame' pattern that indicates .. well, the start of the frame. Note that there are a lot of 0-1 alternations in that pattern. That helps the receiver synchronise itself to the received bitstream. The slight variation on it (i.e. the additional ´1' in front of it) might be there to avoid 'false positive' start-of-frame detections.

Now, as for the rest of the packet. As you have only one single packet, it is very difficult to determine its exact meaning. For that, you need to have multiple packets with different data in it.

Hope this helps a bit

edit: Hum .. just noticed there is actually a 8 all-1 bit pattern in the fransmission. A 2nd marker pattern ? strange!

Kristoff (ON1ARF)