What time is it?

GNU Radio
1

I was exited to see the vrt progress. I have compiled Josh’s usrp2_vrt-
branch, installed the required firmware/fpga- image in the sd- card, and
can find the usrp2. Everything working so far.

But now comes the question, is there a way to read the current usrp2-
time, so that I can do something like “start_rx_streaming(0,
&future_time)”.
I basically try to figure out what the time in the usrp2 is, and then
add a number of seconds/ticks/whatever to that, in order to start
receiving at some future instant.

To do this, I have tried two ways
First I tried to use two instances of a 16sc handler, one which just
read one sample (writing it to /dev/null), from which I extracted the
time, and then stopped the streaming.
Then I add a number of seconds/ticks to the time I got from the usrp2,
and start streaming again with that incremented time as the second
parameter to “start_rx_streaming(…,…)”, and try to receive samples
using the second handler (which was actually writing to a file).

This results in two things,

  1. During reception with the first handler, a message about bad VRT-
    header is displayed, which I tracked back to usrp2_impl.cc, but not
    further than that, since I can’t really figure out under which
    conditions the message is displayed.
  2. During reception with the second handler, no samples are received.
    I thought that it might have something to do with seconds being to long,
    or a tick being to short, so I tried adding different values but that
    didn’t seem to change much, since the out- file was still 0 bytes.

In the second approach:
I noticed that there is a #define OP_READ_TIME 3, but after some
grepping I only found it in usrp2_eth_packet.h (where it was defined)
and in “usrp2_impl.cc, std::string opcode_to_string(int opcode)”. What
are the plans of this op- code, a “what time is it on my usrp2 right
now”- function?

If that is the case, and it has not been written yet, I did some
rewriting of usrp2.cc, usrp2_impl.cc, usrp2.h and usrp2_impl.h for that
functionality (give me current time on the usrp2), using the already
existing struct op_read_time_reply_t. But this raises another question,
namely: What is “op_read_time_reply_t.time” actually describing? It is a
uint32_t, but the vrt_header seems to use a uint32_t for integer
seconds, and a uint64_t for fractional seconds, while the time_spec_t
structure seems to use two uint32_t for ticks and seconds, and another
structure for something I’m not sure about… I guess the question is,
do I parse the 32 bit integer to a time_spec_t? And if so how?

I think I lost my self somewhere. However would I be very happy if
someone could straighten my questions out.

Best regards
Mattias K.

2

Glad you are trying out the branch. A few notes here:

  1. There is a bug where after power-up, everytime (but the first) you
    restart streaming and get samples there is junk data, and it will read
    “bad vrt header”. Its harmless, but should be fixed

  2. FYI The second parameter to start_rx_streaming, if left out, means
    stream asap.

  3. The time registers are write only. There is no control packet to
    read-back time registers. That should be removed from the code.

  4. There needs to be a way to set the time on the next pps. This must be
    added, I am working on this now… When done, you should be able to get
    the timestamp off of the serial port of a gps device and sync up the
    usrp2 to the correct seconds. Or use your own free-running seconds…

  5. When you didnt get any samples back after setting time time: I cant
    tell if this is a bug or just a bad time. I will test this out

-Josh

3

Josh B. wrote:

read-back time registers. That should be removed from the code.
-Josh

Does this imply that timestamps are completely useless without a pps
signal ?

  1. This sounds brilliant!

BR/
Per

4

On 01/18/2010 01:02 PM, Per Z. wrote:

  1. The time registers are write only. There is no control packet to

-Josh

Does this imply that timestamps are completely useless without a pps
signal ?

  1. This sounds brilliant!

Sync on pps only makes sense if you actually have a PPS signal coming
in. If not, you’ll need to use the free-running seconds count.

Matt

5

Glad you are trying out the branch. A few notes here:

  1. There is a bug where after power-up, everytime (but the first) you
    restart streaming and get samples there is junk data, and it will read
    “bad vrt header”. Its harmless, but should be fixed

When you mention it, I do believe there was a discussion regarding the
junk data when the usrp2 was first released. I have a vague memory of
someone writing code to “get rid of this”. But thats as far as my memory
goes, and I actually don’t know if there were any progress. Maybe it was
more of a -“Yeah sure, I’ll try to do that when I have some time to
spare…”

  1. The time registers are write only. There is no control packet to
    read-back time registers. That should be removed from the code.

Okay, I see, but in that case what am I getting back from the USRP2
then? I send a op_generic_t with op_code = 3, and get something that can
be interpreted as a op_time_reply_t, with op_code = 83.

  1. There needs to be a way to set the time on the next pps. This must
    be added, I am working on this now… When done, you should be able
    to get the timestamp off of the serial port of a gps device and sync
    up the usrp2 to the correct seconds. Or use your own free-running
    seconds…

I concur with the former writer, “Brilliant” =;oD

  1. When you didnt get any samples back after setting time time: I cant
    tell if this is a bug or just a bad time. I will test this out

I can send you the code I wrote if you would like to take a look at it.
But if the first few (hundred) samples are junk, maybe the time- filed
of those were corrupt as well. I could try to receive say 10k samples,
take the time of the last one and then do something like:

time_spec_t future_time
future_time.integer_seconds = last_time_stamp.iteger_seconds+10;
start_rx_streaming(0, &future_time);

Is this the current (and possible future way) of starting rx at a future
time instant?

6

There are new updates to the usrp2_vrt branch.

  1. The sync at pps calls have been removed. They no longer apply and
    have been replaced with the set time calls (see below).

  2. The mimo config call has been replaced with a clock config call that
    handles setting the pps source, pps polarity, ref source, (and other
    options).

  3. Two calls were added to set the time: set_time and
    set_time_at_next_pps. A host pc hooked up to the serial port of a GPSDO
    could use set_time_at_next_pps to set the usrp2 with absolute time.
    Example mentioned in usrp2.h

  4. That bug with the junk data i believe to be fixed. There was an
    improper way to stop the streaming.

  5. There is an example app usrp2/apps/rx_timed_samples
    This app will set the usrp2 time to the host system time with subsecond
    precision. Then it will call start streaming with a time in the future.
    The timestamps on the received packets are printed to verity working.

These changes require burning new fw and fpga images. I will post these
if there is an interest. Otherwise, I will refrain from posting them as
there are other kinks to work out in the codes.

-Josh

7

Josh B. wrote:

set_time_at_next_pps. A host pc hooked up to the serial port of a
verity working.

These changes require burning new fw and fpga images. I will post
these if there is an interest. Otherwise, I will refrain from posting
them as there are other kinks to work out in the codes.

-Josh

Exciting! I’ll take a look. Out of curiosity, do you have any sense of
what sort of sub-second precision you’re getting on setting the usrp2
time according to the host? It looks like the sample is fairly simple,
(i.e. just getting the current system time, then turning around and
setting the USRP2 time ASAP to that time, taking into account the fpga
clock rate). I wonder if the sync between host and USRP2 wouldn’t be
better improved by measuring the (rough) RTT, and taking that into
account (e.g. measuring current system time, sending a control message
to the USRP2 and getting a response, measuring the system time again,
and using the difference as the RTT).
Doug

–
Douglas G.
Code 5545
U.S. Naval Research Laboratory
Washington, DC 20375
(202) 767-9048
[email protected]

8

I dont know what kind of delay exists been calling set_time and usrp2
actually latching in the new times. The only way to get it exactly right
is to use a GPS. However, for syncing the host system time to the usrp2,
the demo could be improved with a estimate_rtt routine that times the
operation of set_time a few times, averages the result, and uses the RTT
to make the final call to set_time with curr_time + RTT/2.

That should get it closer, but I should note that the computer clock
will drift and so will the usrp2 without a 10mhz reference. You may have
to make periodic calls to set_time to keep the sub-second precision as
accurate as possible.

-josh