discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Packet Based Radio


From: Martin Braun
Subject: Re: [Discuss-gnuradio] Packet Based Radio
Date: Fri, 24 Jul 2015 15:24:30 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0

Richard,

thanks for the summary. Much appreciated. Some comments:

On 24.07.2015 15:03, Richard Bell wrote:
> 3) The correlation estimator block will double tag peaks from time to
> time. This is due to block boundaries that are imposed by the GNU Radio
> scheduler. If a peak happens to coincide with the end of a scheduler
> block, it will probably get tagged by the correlation estimator block at
> the end of the current block and at the beginning of the next block. I
> wrote an OOT block to remove the double tag when this happened.

I would consider the double tag a bug in the correlation estimator block
(at least, as far as I understand the problem) and we should probably
fix that rather than removing double tags. I know you've been posting
about this before, but please make sure this kind of issue is documented
on the issue tracker.

> 4) I built up the radio using a loopback simulation block by block,
> simulating and confirming input file matched output file along the way,
> so that I could be sure of which block caused an error to creep in. At
> one point, I noticed a plot-only block causing errors in the data
> stream. This block was not a part of the data stream, but somehow
> interacted with it. Someone on the mailing list pointed out that timing
> sync blocks might be able to cause something like this due to rate
> changes. This was the area that happened to be in. I simply deleted the

The argument was that some blocks probably have different behaviour
based on how many samples they consume. I would also consider this a
bug, albeit fiendishly difficult to debug. Again, thanks for bringing
this up, and if you can, please make sure this is tracked somewhere.

> 5) When I added the PFB Clock Sync block into the loopback simulation,
> it would go from working over night for hours, to failing relatively
> quickly, a few minutes. Inspecting the output file it looked like what I
> had been seeing for a while, packet drops. This tells me the PFB Clock
> Sync block must be consuming my correlators tags, which would then cause
> the packet to drop when it reached the HPD Demux block. I don't have a
> fix for this. It's been mentioned by a few developers that this is a
> known issue through rate change blocks.

Same here.

> I hope this is useful information for people starting up on something
> like this. Though I failed with the packet based approach, I was able to
> make a streaming based approach work. I detect the start of a stream one
> [...]

This kind of feedback is fantastic, and thanks a lot for taking the time
for both being thorough in your setups and the recaps here on the list.

Cheers,
Martin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]