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
