You should use a tune_request_t to manually specify the DSP frequency. The issue is that only the master (LO source) channel knows about the actual frequency error in the LO and will automatically use the DDC to compensate for that error. The other channels must have the same correction applied manually. http://files.ettus.com/manual/page_general.html#general_tuning
The GNU Radio UHD interface automatically does this. It is in Python, but the concept is fairly well illustrated. https://github.com/gnuradio/gnuradio/blob/34f7e66e82079ef25b72ba6d6931fac05cfb968a/gr-uhd/apps/uhd_app.py#L219 Regards, Derek On Mon, Jun 4, 2018 at 1:14 PM, Fabian Schwartau via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Derek, > > I think I got that. Is the DDC frequency + offset aligned automatically if > I use a timed command for usrp->set_rx_freq()? Or is there some other > command I missed? > > Best regards, > Fabian > > Am 04.06.2018 um 13:20 schrieb Derek Kozel: > >> 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 <mailto: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> >> <mailto: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> >> <mailto: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> >> <http://lists.ettus.com/mailma >> n/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> >> <mailto: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> >> <http://lists.ettus.com/mailma >> n/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
