Fabian, Timed commands, carefully and correctly used along with common 10 MHz and 1PPS, can give you time aligned reception with an accuracy of one sample clock period. They are used by many projects for this. To have repeatable phase relationships between channels you must also use timed commands to set the DDC frequency offset and decimation. This ensures that you have exactly matching frequency on all channels and exactly the number of samples produced on each stream so they stay inline. With the TwinRX you must use LO sharing between all channels to have repeatable phase offsets.
The LOs take approximately 5mS to settle on the TwinRX, so for your application you can issue a tune command for time X, then a stream command for X + 5mS. https://github.com/EttusResearch/uhd/blob/maint/host/examples/twinrx_freq_hopping.cpp Regards, Derek On Mon, Jun 4, 2018 at 11:47 AM, Fabian Schwartau via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello Derek, > thank you very much. > So is it correct, that the timing using the set_comman_time() function is > so precise that I can do MIMO with it? That would be great :) > > Best regards, > Fabian > > Am 04.06.2018 um 10:52 schrieb Derek Kozel: > >> 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 <mailto: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 <mailto:USRP-users@lists.ettus.com >> > >> http://lists.ettus.com/mailman/listinfo/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 <mailto:USRP-users@lists.ettus.com> >> http://lists.ettus.com/mailman/listinfo/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
