FSK demodulation with GNU Radio

Question

I'm trying to demodulate a signal using GNU Radio Companion. The signal is FSK (Frequency-shift keying), with mark and space frequencies at 1200 and 2200 Hz, respectively.
The data in the signal text data generated by a device called GeoStamp Audio. The device generates audio of GPS data fed into it in real time, and it can also decode that audio. I have the decoded text version of the audio for reference.

I have set up a flow graph in GNU Radio (see below), and it runs without error, but with all the variations I've tried, I still can't get the data.

1. The output of the flow graph should be binary (1s and 0s) that I can later convert to normal text, right?
2. Is it correct to feed in a wav audio file the way I am?
3. How can I recover the data from the demodulated signal -- am I missing something in my flow graph?

This is a FFT plot of the wav audio file before demodulation:

This is the result of the scope sink after demodulation (maybe looks promising?):

UPDATE (August 2, 2016): I'm still working on this problem (occasionally), and unfortunately still cannot retrieve the data. The result is a promising-looking string of 1's and 0's, but nothing intelligible.

If anyone has suggestions for figuring out the settings on the Polyphase Clock Sync or Clock Recovery MM blocks, or the gain on the Quad Demod block, I would greatly appreciate it.

Here is one version of an updated flow graph based on Marcus's answer (also trying other versions with polyphase clock recovery):

However, I'm still unable to recover data that makes any sense. The result is a long string of 1's and 0's, but not the right ones. I've tried tweaking nearly all the settings in all the blocks. I thought maybe the clock recovery was off, but I've tried a wide range of values with no improvement.

Amoreta

you shouldn't connect the fft sink to the output of your quadrature demod, but to the input; this will only show the symbol rate as periodicity. The scope plot of the quadrature demod output, however, would be much more interesting. – Sinuation

Oh yeah, I was just experimenting with that to see what the result of demodulation looked like. The scope plot after demodulation actually looked interesting, I will edit my post to add it. – Amoreta

Interesting! Yes, I'd say, that's pretty promising. When developing things, I'd compare the output of a scope sink after the demodulator with a waterfall sink of the audio input. – Sinuation

By the way, just leave the imaginary part input of the float to complex unconnected. Shouldn't make much of a difference, though, for your analysis case. – Sinuation

Answer 1

So, at first sight, my approach here would look something like:

What happens here is that we take the input, shift it in frequency domain so that mark and space are at +-500 Hz, and then use quadrature demod. "Logically", we can then just make a "sign decision". I'll share the configuration of the Xlating FIR here:

Notice that the signal is first shifted so that the center frequency (middle between 2200 and 1200 Hz) ends up at 0Hz, and then filtered by a low pass (gain = 1.0, Stopband starts at 1 kHz, Passband ends at 1 kHz - 400 Hz = 600 Hz). At this point, the actual bandwidth that's still present in the signal is much lower than the sample rate, so you might also just downsample without losses (set decimation to something higher, e.g. 16), but for the sake of analysis, we won't do that.

The time sink should now show better values. Have a look at the edges; they are probably not extremely steep. For clock sync I'd hence recommend to just go and try the polyphase clock recovery instead of Müller & Mueller; chosing about any "somewhat round" pulse shape could work.

---

For fun and giggles, I clicked together a quick demo demod (GRC here):

which shows:

Sabbatical

Wow! Thank you so much for all that detail, that resolved a few confusing points I had. For some reason when I use the Polyphase clock sync GRC says "Python quit unexpectedly" every time, so I'm trying the MM recovery clock. The time sink is looking really promising now. Trying to figure out how to read the file sink based on this site. – Amoreta

For some reason I still can't recover the actual data. My result seems like it's on the right path, but binary values are nonsense. I can't tell if it's my processing or the signal. – Amoreta

Problem might just be that you don't know where your byte boundaries are, right? Or maybe they are using some Manchester encoding or something similar? Channel code? – Sinuation

Must be having some kind of problem like that. There's no mention of encoding in any of the device's documentation. Not quite sure what to do now except keep adjusting settings until the output contains the characters it should, I guess. Thanks for the help. – Amoreta

Usually, raw data isn't used for PSK or FSK modulation, since raw data often has long sequences of zeros or ones, which are undesirable. There's usually some kind of encoding, such as Manchester encoding, differential, XORing with a whitening pseudo-random sequence, bit stuffing, etc. – Ornithine

yep, true; whitening is desirable on many levels. First of all, in a real "More than just a few commands" transceiver system, you'd expect data to be source coded (i.e. compressed), so that the input is somewhat white; then, you typically use a whitener whenever you can, because no matter what you do, having correlations within your data stream at least means inefficient spectrum usage, and/or problems with clock recovery and/or problems with frequency selectivity... – Sinuation