Re: Problems with Viterbi decoding
There may be some additional things to consider when using gr-trellis: The fsm class does not understand bits. It understands input symbols and output symbols. Your fsm has binary input symbols and quaternary output symbols. So the encoder gets L input bits and produces L quaternary symbols (if you are wondering why, please read the gr-trellis documentation to see the design philosophy). For the VA to work you have to provide L (noisy) quaternary symbols at the input. I attach a modified version of the tcm.grc example (in the gr.trellis/examples/grc/tcm.grc) that shows that the VA works perfectly (0 BER) with your encoder. test_tcm1.grc Description: Binary data
Re: Problems with Viterbi decoding
My understanding is that the constructor takes first k=1 and then n=2 as a parameter for an (n,k) code, so it should be: trellis.fsm(1,2,[0b11001,0b10111]) Achilleas //## //# Automatically generate the FSM from the generator matrix //# of a (n,k) binary convolutional code //## fsm::fsm(int k, int n, const std::vector& G)
Problems with Viterbi decoding
Greetings all, I'm trying to implement a decoder for NXDN in GRC and the Viterbi decoding is not cooperating with me. I'm wondering if one of you could please take a few minutes to look this over and see if you could point out where I have gone wrong, because I am thoroughly puzzled by this. Any insight would be highly, highly appreciated. I've pulled all the parameters and the input testing data straight from the NXDN technical specs so I'm really at a loss here. ECC parameters: K=5, R=1/2, G1= 1 + x^3 + x^4, G2= 1 + x + x^2 + x^4 Trellis permutation: size 252, (0,21,42,63,84,105,126,147,168,189,210,231,1,...) FSM constructor: trellis.fsm(2,1,[0b11001,0b10111]) Block size 252, initial state 0, final state 0 Input data: 1410 0024 0154 0404 a120 6088 0224 0004 8280 4d14 0340 0019 4101 9240 1ec2 40b Correct decoding: 0101 0020 0001 0001 00 My decoding: 0606 00c0 0006 0006 00 Many thanks in advance!
