Re: [Discuss-gnuradio] Best in-tree blocks for clock recovery of 8FSK

[Andy Walls]

> Date: Mon, 2 Apr 2018 09:48:00 +0100
> From: Thomas Habets
> Hi.
> 
> As an experiment I'm trying to decode an FT8 signal I've captured.
> I've
> gotten far enough that I can clearly see the packet (
> https://blog.habets.se/tmp/ft8_packet.png), but now I want to
> actually turn
> that into bits.
> 
> I know it's 8FSK (the above screenshot is quad demod of that), but I
> have a
> few questions on clock recovery:
> 
> * Is the GFSK block only for BFSK? If so then that's out.

Generally yes, it is for recovery of 2 level signals.

> * Is there a "best" clock recovery block nowadays? I seem to recall
> "Clock
> Recovery MM" being discouraged in favor of "Polyphase Clock Sync".

Use the new Symbol Synchronizer blocks that are on the master branch
and hopefully in the latest release by now.  That block is a superset
of of all the other PLL-based clock sync blocks currently in tree.

If you haven't seen my brief on this subject already, please
read/watch:

https://www.gnuradio.org/wp-content/uploads/2017/12/Andy-Walls-Samples-to-Digital-Symbols.pdf

https://www.youtube.com/watch?v=uMEfx_l5Oxk



> * I'm trying to read up on the parameters Polyphase Clock Sync wants,
> but
> any pointers would be helpful.

The small signal ML approximation TED that the polyphase clock sync
block uses was derived with only 2 level signals in mind.  It might not
work so well.

The M&M TED was derived with multi-level signals in mind.  But you must
provide a proper constellation (M points on the real axis), and you
must scale the input signal to match the constellation points the M&M
TED is expecting.  Note that is GNURadio, this is complicated by the
Constellation object automatically and silently scaling a user
specified constellation.


> * Would it be a good idea to throw in a costas loop for frequency
> tuning?

Um, no.

You'll need frequency correction, both coarse and fine, but how best to
accomplish that is another lengthy discussion.


> * Does Polyphase Clock Sync have the same dislike of "staircase"
> inputs?
> That is, I should try to make the center of the bits more "pointy"?
> (e.g.
> lowpass filter them)

All PLL based symbol clock recovery blocks/methods in GNURadio require
symbol centers to be peaked.

So yes, the input signals must be put through a pulse matched filter
first to peak the symbols.  With the new symbol sync blocks you can
either have the matched filter external to the block, or let the block
do it.  (As long as you use a TED that doesn't need a derivative of a
square pulse shape.)


> I've done some custom OOT decoders before, so I'm not shy about that.
> Maybe
> the best thing is some whole-packet clock recovery[1]. But if I just
> write
> a block that takes the quad demod (see above screenshot) and finds
> the
> "platforms", outputting a message that is a list of floats, and then
> another block that takes a list of floats and the number 8 and
> decodes it
> as 8FSK, well it seems like I may be reimplementing things where I'm
> guessing someone might say "oh just use this block".
> 
> Also for experimentation and my own understanding I'd like to turn it
> into
> bits using in-tree blocks, if possible.

For frequency correction, you will be forced to use out of tree blocks
or write your own.  There's nothing in tree that will do what you need
aside from maybe the PLL blocks; and they likely won't do the job well
for 8FSK bursts.


> Maybe a correct Polyphase Clock Sync of the quad demod followed by a
> Constellation decoder? I could use the float as the phase, with
> magnitude
> 1. Does that make sense? Is it a good idea?

The simplest thing to do is something like:

signal -> channel filter -> coarse freq correction -> correlators/burst
tagger -> quad demod -> offset correction -> matched filter ->
amplitude correction (agc) -> symbol synch -> m-level slicer -> .... 

And of that proposed DSP chain, there is a lot missing, if you only use
in-tree blocks.  My gr-nwr OOT module has some of those missing blocks,
but they were geared for relatively high SNR SAME 2-FSK bursts.

Regards,
Andy

> What I have so far is:
> Data:
>   https://blog.habets.se/tmp/ft8-burst-10k.raw (10k samp_rate)
> 
> GRC:
>   https://blog.habets.se/tmp/ft8_decode.grc
> 
> Screenshot:
>   https://blog.habets.se/tmp/ft8_decode_grc.png
> (everything off-screen to the right is failed clock recovery
> experiments)
> 
> Quad demod
>   https://blog.habets.se/tmp/ft8_packet.png
> 
> 
> [1] Like https://www.youtube.com/watch?v=rQkBDMeODHc which I turned
> into
> https://github.com/ThomasHabets/radiostuff/blob/master/
> gr-habets/python/magic_decoder.py
>