Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)

[Aditya Dhananjay]

Your solution will work, but you have to admit it's a hack. Who says my
payload is 3 or 4 symbols long? I'm currently working on the HPD, and
I'll figure out a way to get this in.

Absolutely; this is an unclean hack.

I guess not consuming the last symbol would be sufficient in most cases,
and since a payload must have at least one, this would be OK. For OFDM,
this must work since one OFDM symbol is longer than the detection timing
ambiguity.

Assume that the FFT size is 64 and the CP length is 16. As long as the trigger comes within the first 16 time-domain samples, we should be fine.

The following applies probably to my unique problem domain (which is to design a better channel interpolation technique): 

I would like the trigger to come in at exactly at the end of the CP, as this would eliminate spurious channel rotations. If the trigger comes in during the CP, we will see rotations in the frequency domain (the channel changes very quickly across subcarriers). To eliminate this, I would like the trigger to come in exactly at the end of the CP. In this case, a trigger offset of 1-4 can cause the subsequent packet to not be detected by the HPD.

If your channel interpolation method is DFE, then these rotations are irrelevant.

best,

aditya

 

MB

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio