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 _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
