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