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
