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/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>
<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/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
