Bald Yak 16: How do you decode FM?

Foundations of amateur radio How do you make a hole?

That's a pretty straightforward kind of question, and by the time the sentence is finished,

there's going to be at least as many answers as people who considered it.

I didn't supply any parameters to this hole, so answers could include shovels, claps

in space, fire, a drill, or any number of other interesting approaches.

If I narrowed it down to say, a hole in wood, there'd still be plenty of options.

Specifying the type of wood, the diameter, and other parameters would further narrow down

the selection of methods.

What if I asked you, how do you decode FM?

You might wonder if there's more than one way, and I can assure you, just like with making

a hole, there's plenty of ways to go about achieving this.

And if I limit this to software implementations only.

I must confess, when I recently set out to test my SOPE SDR library notions using a

GNU radio flow graph to listen to FM radio, I searched the documentation, found a beginner's

tutorial, and used the information there to make my first proof of concept FM receiver.

I put it on GitHub and went about my business.

So finally managing to hear the decode effort and being less than impressed, I started

trying to understand the tutorial flow graph.

When I started looking at what would be needed to decode stereo FM broadcast radio, I discovered

that there were several tutorials, examples, and videos with slightly or significantly

different solutions to the problem.

It's on top of the over a dozen standard FM related blocks supplied within GNU radio.

I then set about trying to discover the canonical implementation of an FM receiver, and came

up short.

Instead I discovered even more implementations of FM receivers, each subtly different.

You should know that there's a difference between how your local hit radio station does

FM, and how an amateur radio repeater does FM, let alone the local CB radio channels,

satellite telemetry, wireless microphones, or even hearing aids.

So within the implementation of an FM receiver, there's additional complexity, which explains

to some extent the variety of FM related blocks within GNU radio.

I think ultimately it's safe to say that there's an unlimited supply of implementations

of an FM receiver within GNU radio.

It let me to ask, what is the, for one of a better word, right way, and what does that

actually mean?

In GNU radio, you string together blocks that process a signal.

If you're familiar with flow charts, the process is very similar.

Unlike flow charts on a piece of paper, in GNU radio, or should I say GNU radio companion,

so until you use to actually design flow graphs, the little blocks represent underlying software,

and their connections represent how data flows between these bits of software.

In other words, each block represents a series of programming instructions that process data

and pass it on.

It means that the more blocks you have in your flow graph, the more instructions are

running to process data.

The more instructions, the more computing resources required.

This is significant because in a complex system like this, we're likely to be doing more

than one thing at a time, so preserving resources is important if only to ensure that there's

time available to process the next sample.

As a result, there's a difference between implementing an FM receiver with two blocks

or with ten blocks.

You might conclude that two blocks is more efficient, but that might not be true.

For example, two blocks processing 2,000 samples per second each are processing 4,000 samples

per second in total.

A block that converts the 2,000 samples into 200 samples, followed by nine blocks processing

200 samples per second each, is processing 3,800 samples in total.

All things being equal, the ten blocks together are handling less data per second, so overall

it's potentially using less resources.

I say potentially because it might be that one of those blocks is using a massive calculation,

consuming more resources than all the other blocks put together.

Ultimately, each block is software, so whatever it's doing is using resources.

So, how would you go about choosing between two implementations or algorithms, which

was the better one and how is better defined?

My first pass at this is to use standard testing files and use the algorithms under consideration

to process them.

Run the tests multiple times, keep a record of how long they take and then attempt to measure

how much the original input signal differs from the processed output signal.

At the moment I have no idea how you might compare signals, other than to invert one and

combine them to see if they cancel each other out, which means that they're the same,

or not, which means that they're different.

For my sins, in trying to think of a way to do this, I realised that the way I implement

this radio contraption needs to be able to deal with test files, and potentially multiple

different implementations of a decoder.

It also means that I have some more thinking to do.

Ideally, there needs to be a concept of meta information, like the radio source, the

tuned frequency, the bandwidth, gain and likely more, so I can set the parameters once and

reuse these across whatever else is part of the flow graph.

It should be possible to use a test file just as simply as a SOPE STR compatible radio.

It should also be possible to hear the audio, or save it to a file, or decode an embedded

signal, or all at the same time.

In other words, it needs to be flexible.

Luckily, GNU radio is really a collection of libraries built specifically for this task.

I'd love to hear your thoughts on the matter.

I'm ono Victor Kilo 6, Foxtrotly Mar Alphabravo.