Hello Fabien, Yes, it is possible to queue commands, however there are two important things to keep in mind. The commands will block any other commands in the same queue from executing until the current one's time is reached. So commands must be sent in order (100, then 120, 140 ...). Second, the queue has finite length and if too many commands are sent it will backup into the host.
The TwinRX frequency hopping example will be a good reference for you to look at. It implements a different strategy where only one channel is used to receive and the second channel is used as a secondary LO source, but its inner loop shows how to use burst receiving and timed commands to have sample accurate timing and do a precise sweep across a list of frequencies. Regards, Derek On Mon, Jun 4, 2018 at 8:40 AM, Fabian Schwartau via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, > > thanks for the great answer. > One more question: Is it possible to send multiple commands for different > times right after each other? So for example if the current time is 100, I > execute the code you provided for 120, 140 and 160 at once without waiting > for the command at 120 to be executed. > > Best regards, > Fabian > > > Am 03.06.2018 um 12:44 schrieb Marcus Müller: > >> Hello Fabian, >> >> the issue can be overcome using what we call timed commands – simply >> tell your USRP to tune that LO at time X, and it'll do exactly that! >> >> A bit of example code: >> >> //we will tune the frontends in 500ms from now >> uhd::time_spec_t cmd_time = usrp->get_time_now() + >> uhd::time_spec_t(0.5); >> >> //sets command time on all devices >> //the next commands are all timed >> usrp->set_command_time(cmd_time); >> >> //tune channel 0 and channel 1 >> usrp->set_rx_freq(1.03e9, 0); // Channel 0 >> usrp->set_rx_freq(1.03e9, 1); // Channel 1 >> >> //end timed commands >> usrp->clear_command_time(); >> >> You can also instruct the RX streamer to start streaming at a specific >> time, so that you either know beforehand, at which sample count the >> tuning happened. >> Alternatively, the rx_metadata coming from the USRP contains timestamps >> of the first sample in the sample packet, so you can use that to >> calculate at which sample the tuning happens. >> >> Best regards, >> Marcus >> >> On Sun, 2018-06-03 at 11:35 +0200, Fabian Schwartau via USRP-users >> wrote: >> >>> Hello everyone, >>> >>> I have a question about frequency hopping in a synchronized scenario. >>> I >>> have two USRP X310, each equipped with two TwinRX. The LOs are >>> generated >>> by one of the TwinRX and are distributed to all the others (even >>> across >>> the two motherboards). 10 MHz and 1PPS are also coming from a single >>> source. Then I use the "unknown PPS" method to sync the ADCs. This >>> works >>> perfectly. >>> Now I listen to a single frequency on all channels and change this >>> frequency frequently. I would like to hop the frequency every 20ms or >>> faster. In order not to loose the ADC synchronization, I start a >>> continuous stream and switch the frequency while receiving. This >>> works >>> in principle, but I am not able to identify at which frequency the >>> data >>> that currently comes in was recorded. I tried using a constant time >>> from >>> setting the new frequency to when I assume the new data to be at the >>> new >>> frequency. But even with a timeout of ~50ms the results in data >>> indicate >>> the the delay was not enough in a very few cases. >>> I know there is the locked_lo sensor, but this also does not help. I >>> guess this is caused by buffers which cause a more or less random >>> delay >>> between setting the frequency and receiving the data. This depends on >>> CPU load and other things, so it is quite random. >>> Is there a way to solve this issue? E.g. by embedding information >>> about >>> the LO state in the data. Or defining an exact time when to execute >>> the >>> frequency switch, so that I can use the metadata timestamp in the >>> receive stream to identify the exact point when the frequency was >>> switched (I know that the locking can take a few ms - so I would >>> discard >>> the data between the switch and the signalling+locking offset). Or is >>> it >>> possible to perform multiple time limited captures without having to >>> sync the ADCs again? >>> In an ideal situation I would like the FPGA to switch frequency, wait >>> for LOs to lock, take a single shot synchronized measurement (~1ms of >>> data), transmit the data to the PC (I am using 10G link) and continue >>> with the next frequency. Is that possible without touching the FPGA >>> code? >>> >>> Best regards, >>> Fabian >>> >>> _______________________________________________ >>> USRP-users mailing list >>> USRP-users@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >> > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
