I should add that the main problem I face is getting it synchronized fast enough for short bursts.
Adrian On April 2, 2018 11:54:21 AM UTC, Thomas Habets <tho...@habets.se> wrote: >I just seem to recall that being said. > >I've used M&M successfully in the past, but it does require some >massaging >of the data to not be "square wave" before it'll work. Also does it >work >(well) for M-FSK? > >On 2 April 2018 at 11:16, Adrian Musceac <kanto...@gmail.com> wrote: > >> Hi, >> >> Why is the M&M algorithm discouraged? >> I use successfully both in FSK and PSK demodulators. It seems to >perform >> fine. >> >> Regards, >> Adrian >> >> >> On April 2, 2018 8:48:00 AM UTC, Thomas Habets <tho...@habets.se> >wrote: >>> >>> 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. >>> * Is there a "best" clock recovery block nowadays? I seem to recall >>> "Clock Recovery MM" being discouraged in favor of "Polyphase Clock >Sync". >>> * I'm trying to read up on the parameters Polyphase Clock Sync >wants, but >>> any pointers would be helpful. >>> * Would it be a good idea to throw in a costas loop for frequency >tuning? >>> * 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) >>> >>> 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. >>> >>> 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? >>> >>> 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 >>> >>> -- >>> typedef struct me_s { >>> char name[] = { "Thomas Habets" }; >>> char email[] = { "tho...@habets.se <tho...@habets.pp.se>" }; >>> char kernel[] = { "Linux" }; >>> char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt"; }; >>> char pgp[] = { "9907 8698 8A24 F52F 1C2E 87F6 39A4 9EEA 460A 0169" >}; >>> char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" }; >>> } me_t; >>> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > >-- >typedef struct me_s { > char name[] = { "Thomas Habets" }; > char email[] = { "tho...@habets.se <tho...@habets.pp.se>" }; > char kernel[] = { "Linux" }; > char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt"; }; > char pgp[] = { "9907 8698 8A24 F52F 1C2E 87F6 39A4 9EEA 460A 0169" }; > char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" }; >} me_t;
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
