Hello everyone,
I have been testing
USRP (N200) source retuning via messages. The idea was to see how fast the USRP can retune reliably. Also looked at the
usrp_spectrum_sense but as Marcus pointed out in [1] that example is old and newer solutions should be used and I figured the command messages would be a good choice.
Decided to dig deeper and to see if the issue is directly coupled with the message generation process. Decided to look at the time diff between consecutive function calls and from there the time diff between consecutive work() calls. The outcome was quite surprising for me. It seems that once the messages are delivered to the USRP source (I thought that it would be better to send a number of command messages ahead in time to the usrp), the flow of the samples is halted (work function is not called for a time period that is directly related to the time ahead in the commands). Seems the flowgraph waits till the messages are processed. Is this intended, have I misunderstood the command messages? I thought the command messages to the usrp source can be used as timed commands that have a queue.
In general, even with a single message the retune works with 12.5ms dwell_delay. However, the flowgraph stalls for around 0.15sec nearly every 5sec. Tested also with just analog_sig_source - throttle - measuring_block - null_sink, and the 5sec period is still there. In the measuring block I use a monotonic clock from boost. What causes this? Can it be avoided?
With regards,
Meelis