Yes, that's absolutely possible with one caveat: These commands end up in queues. So, you need to send them in correct order, or, for example, if you send the commands for 120, 160 , 140, then the the 160 command will block the queue and the 140 command will be executed directly after the 160 command has been executed.
Best regards, Marcus On Mon, 2018-06-04 at 09:40 +0200, Fabian Schwartau via USRP-users 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.co > > > m > > _______________________________________________ > 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
