Trellis in generic_mod_demod

I want to use convolution code to transmit packet over USRP. So I ended
modifying the generic_mod_demod in digital.

The original flow graph was

packed_to_unpacked(bits_per_symbol) —> gray_encoder —>
differential_encoder —> chunks_to_symbol(constellation)
—> rrc_filter —> USRP

USRP —> fll_band_edge —> pfb_clock_sync —>
0) —> demod_pkts

Now I have modified it to the following.

packed_to_unpacked(bits_per_trellis_input) —> trellis_encoder(fsm)
chunnks_to_symbol(constellatin) —> rrc_filter —> USRP

USRP —> fll_band_edge —> pfb_clock_sync —>
4)(symbol) —> viterbi_combined —> demod_pkts

I find this structure ends up in more errors than before. ( almost all
errors )

  1. Does the packet size at the output of has anything to do with
    block_length in viterbi_combined?

  2. Will it make any difference if I specify the starting and ending

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 sync the blocks with the packets then you could add a
stream tag to the start of each packet, and detect that with the
encoder and decoder.


This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs