On 01/21/2014 05:55 PM, Aditya Dhananjay wrote: > Hello David, > > I was facing the exact same issue, and the fix I use is identical to > yours. I consume 4 symbols less than I need to, so the subsequent packet > is not lost. > > Best, > Aditya > > On Tue, Jan 21, 2014 at 11:14 AM, David Halls > <david.ha...@toshiba-trel.com <mailto:david.ha...@toshiba-trel.com>> wrote: > > Hi Martin, > > Making good progress with the relay but on another topic, I find if > I use a random data source (rather than the 1...range in the > original example) the trigger signal arrives occasionally one or two > samples earlier than expected.
Yes, I have seen this happen. To recap (please correct me if this is in fact not exactly your problem): Say the input signal looks like this: 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 <- items ^ ^ <- triggers ...everything is fine. Now, the trigger might be early (because of noise etc.): 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 <- items ^ ^ <- triggers In this case, the trigger is consumed with the first packet, and the second one can't be won't be detected. 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. 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. MB _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
