Re: [Discuss-gnuradio] gr-fec Viterbi example

[Jean-Michel FRIEDT]

> I tried building this program on Windows and failed. Since it's
> missing in viterbi/CmakeLists.txt, I fail to see it's built by
> default. How did you compile it? Are you sure it wasn't written
> on a big-endian machine?

under GNU/Linux
g++ -c encode.cc
gcc -c viterbi.c
gcc -c tab.c
gcc -c metrics.c
gcc -o encode encode.o viterbi.o tab.o metrics.o -lm
g++ -c decode.cc
gcc -o decode decode.o viterbi.o tab.o metrics.o -lm
compiles flawlessly.
I then
$ echo "123400" | ./encode  > t
$ cat t | ./decode

that used to work nicely with the original code (it did not comply with
my understanding of Viterbi encoding, which has since improved a bit since I
can decode full sentences of Meteor M2 so I must not be completely wrong) but
after swapping POLYA and POLYB the above demonstration (encoding followed
by decoding) no longer works. I am afraid I broke the assumption given in
the comments

 * The code polynomials are assumed to have 1's on both ends. Given a
 * function encode_state() that returns the two symbols for a given
 * encoder state in the low two bits, such a code will have the following
 * identities for even 'n' < 64:

Thanks, JM

> On Windows at least, the viterbi.h + decode.cc + encode.cc are
> not up-to-date. Missing proper dllexport, setmode(fd,O_BINARY)
> etc. etc.
>
> Anyway, with some patching I was able to link and run them.
> But I have no data to test the Viterbi encoder/decoder with.
> Could you please ship some files to me?
>
> > I am unable to encode the sync word 0x1ACFFC1D to the expected result
> > 0xfc 0xa2 0xb6 0x3d 0xb0 0x0d 0x97 0x94 as explained at
> > https://www.teske.net.br/lucas/2016/11/goes-satellite-hunt-part-3-frame-decoder/
> > I know this encoded sync word is correct because cross-correlating the
> > METEOR stream (after proper constellation rotation) with this word gives
> > a correlation peak every 16384 samples (=1024 byte sentence * 8  
> > bits/byte * 2
> > bits/Viterbi encoder).
> >
> > I am doing (word.bin was generated with Octave's fwrite function)
> > $ xxd word.bin
> > 00000000: 1acf fc1d 0000 0000 0000                 ..........
> > and then
> > $ cat word.bin | ./viterbi/encode > t.bin
> > but
> > $ xxd t.bin
> > 00000000: 0000 0000 0000 0101 0001 0001 0101 0001  ................
> > 00000010: 0001 0000 0100 0001 0101 0000 0000 0100  ................
> > 00000020: 0001 0000 0101 0101 0101 0101 0000 0100  ................
> > 00000030: 0001 0100 0100 0000 0001 0100 0100 0101  ................
> > 00000040: 0000 0001 0001 0101 0001 0101 0000 0000  ................
> > does not match the expected bit sequence which should be
> > word=[1 1 1 1 1 1 0 0 ... %  fc
> >       1 0 1 0 0 0 1 0 ... %  a2
> >       1 0 1 1 0 1 1 0 ... %  b6
> >       0 0 1 1 1 1 0 1 ... %  3d
> >       1 0 1 1 0 0 0 0 ... %  b0
> >       0 0 0 0 1 1 0 1 ... %  0d
> >       1 0 0 1 0 1 1 1 ... %  97
> >       1 0 0 1 0 1 0 0 ... %  94
>
> I had no lock with 'xxd -revert' to check your results here
> I used the attached hex2bin.c instead.
>
> And BTW, my patches also attached.
>
> --
> --gv



--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,  
25000 Besancon, France

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.