> 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.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment