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] <https://lists.gnu.org/archive/html/discuss-gnuradio/2015-08/msg00035.html> that example is old and newer solutions should be used and I figured the command messages would be a good choice.
As I have a marine VHF radio available then I chose to operate around 156.025MHz, 1kHz steps till 156.055MHz (30 steps, then loop), samp_rate=1MHz. To confirm the SDR recorded output is reasonable, I transmit a constant carrier and check the signal in Octave. Overall I think I got it working, but every now and then the retuning gets stuck (from the output I can see that the USRP does not retune and after a certain time rapidly starts to process the expired commands until catches up). 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 [1] https://lists.gnu.org/archive/html/discuss-gnuradio/2015-08/msg00035.html
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
