Manu,
At the moment when you feed into your viterbi decoder you still have
phase ambiguity i.e. you don't know if the constellation is orientated
correctly. I imagine this would place a constraint on the code you
could use.
If you go with Achilleas' suggestion then the differential decoding
woul
Incidentally this brings forward a drawback (in my opinion) in the
design of the physical
layers in gnuradio, ie, that the physical layer is designed
essentially with continuous transmission in mind.
For instance, the
fll_band_edge ---> pfb_clock_sync ---> (constellation_receiver,0) --->
chain has
Manu,
Start with a simpler version of your design, ie
1) At the Tx the convolutional code is BEFORE the gray_encoder
2) At the Rx the Viterbi decoder operates with hard decisions (there
is an option for that in the viterbi combined) and is AFTER the block
that synchronizes with the encoded demodum
There is no logic at the moment to make the trellis encoder and
decoder sync their blocks with the packets. I would have thought that
if you don't specify the starting and ending states, and the blocks
are reasonably long, then it would still work adequately but I could
be wrong.
If you want to s
I want to use convolution code to transmit packet over USRP. So I ended up
modifying the generic_mod_demod in digital.
The original flow graph was
Tx
packed_to_unpacked(bits_per_symbol) ---> gray_encoder --->
differential_encoder ---> chunks_to_symbol(constellation)
---> rrc_filter ---> USRP
Rx
