>
> I labeled my block "ofdm_symbol_cutter", but he is not one out of the standard OFDM blocks. I wrote this block, because I want to isolate the sample loss problem.
> I tested the flow with UHD source and the file source, so it's not only a simulation. There was all the times the same flow behaviour. I think there is a problem with the multi-threading or I understand something absolutely wrong.
In the example you gave earlier, using a file-source, you run the
flow-graph for 13 seconds, then call tb.stop(), then harvest the vector
sink. You then make the observation that there are "missing samples".
Are you actually comparing samples, or simply observing that the number
of samples harvested from the vector sink is different on a run
to run basis?
If so, then this is entirely expected behaviour. Linux (and by
implication, Gnu Radio on top) is *not*, in any way, shape or form, a
"hard real-time" operating system with guaranteed scheduling and
latency. The number of computations completed per unit time
is not entirely deterministic, and furthermore, when you go to sleep
for 13 seconds, you aren't necessarily guaranteed 13 seconds,
it could be off by a significant factor (at least, significant at the
level of granularity implied by 2Msps). What that means is that the
number of samples delivered to you vector sink, when you call
tb.stop() after 13 seconds of sleeping, is going to be variable.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment