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
