Timestamp value

GNU Radio
1

Hi,
I wonder how the timestamps are being generated for each ethernet-packet
sent from the USRP2 to the host? My initial idea about how it works was
that timestamps are generated at 100MHz (same as the samples) and then
the timestamp associated with the first sample in an ethernet data
packet will be put in the metadata which could then be unpacked in the
host. I then would assume that the next packet after the first one will
have a timestamp value that is proportional to the number of samples per
packet times the decimation rate. However I get timestamp values that
increase much much more for each received packet, so I wonder if my idea
of how timestamps are generated is wrong?

I run the stable 3.2 version of gnuradio on Ubuntu 9.04 and I have an
USRP2 with the RFX2400. (I also was going to try the gnuradio trunk but
I got problems with building, see my other post “Error on make from git
development trunk”). I tried both an old version of the fpga bin-file
and one that I just recently downloaded (but both gave the same result).

I put some printouts in usrp2_impl.cc in the handle_data_packet function
and the output when I run rx_streaming_samples then looks like this:
./rx_streaming_samples -f 2457e6 -d 16 -N 400 -v
…
Daughterboard configuration:
baseband_freq=2456250000.000000
ddc_freq=-750000.000000
residual_freq=-0.016764
inverted=no

USRP2 using decimation rate of 16
Receiving 400 samples

ts_in = 1435221596, ts_last = 0, diff = 1435221596
ts_in = 2560802396, ts_last = 1435221596, diff = 1125580800
ts_in = 3367616092, ts_last = 2560802396, diff = 806813696
ts_in = 4174429788, ts_last = 3367616092, diff = 806813696
ts_in = 686341724, ts_last = 4174429788, diff = 806879232
ts_in = 1493155420, ts_last = 686341724, diff = 806813696
ts_in = 2283192156, ts_last = 1493155420, diff = 790036736
ts_in = 3090005852, ts_last = 2283192156, diff = 806813696
ts_in = 3896819548, ts_last = 3090005852, diff = 806813696
ts_in = 408731484, ts_last = 3896819548, diff = 806879232

Copy handler called 2 times.
Copy handler called with 2968 bytes.

Elapsed time was 0.000 seconds.
Packet rate was 100000 pkts/sec.
Approximate throughput was 148.40 MB/sec.
Total instances of overruns was 0.
Total missing frames was 0.
…

ts_in is the timestamp found in the metadata of the packet just
received, ts_last is the one from previous packet and diff is just the
difference them between. Since there seems to be no missing frames I’m
guessing the big value of diff can’t be related to lost packets?
If I try different decimation rates, I see no obvious relation between
the difference in value between two timestamps…

Do anyone know why the difference in timestamp value between received
packets is so big? What am I missing here?

Thanks,
/Ulrika

2

Oops, the printuts seems to have been mosched together in the mail, here
is that part once again:

ts_in = 1435221596, ts_last = 0, diff = 1435221596
ts_in = 2560802396, ts_last = 1435221596, diff = 1125580800
ts_in = 3367616092, ts_last = 2560802396, diff = 806813696
ts_in = 4174429788, ts_last = 3367616092, diff = 806813696
ts_in = 686341724, ts_last = 4174429788, diff = 806879232
ts_in = 1493155420, ts_last = 686341724, diff = 806813696
ts_in = 2283192156, ts_last = 1493155420, diff = 790036736
ts_in = 3090005852, ts_last = 2283192156, diff = 806813696
ts_in = 3896819548, ts_last = 3090005852, diff = 806813696
ts_in = 408731484, ts_last = 3896819548, diff = 806879232

3

Ulrika U. wrote:

ts_in = 3896819548, ts_last = 3090005852, diff = 806813696

Subject: [Discuss-gnuradio] Timestamp value
the number of samples per packet times the decimation rate.

   inverted=no

2283192156, ts_last = 1493155420, diff = 790036736 ts_in =
Total instances of overruns was 0.
relation between the difference in value between two timestamps…
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Have you tried the vrt branch by jblum ?

BR/
Per

4

Hi,
I have now tried both the git master and the vrt branch and the results
there are similar to those in the 3.2 version.

I was guessing that the timestamps would be generated/handled
differently in the vrt branch but at a first glance I didn’t see any
major differences in the code. What is the difference with regard to
timestamps and timing when using the vrt branch?

Regards,
/Ulrika

5

Sorry I made a mistake, I used the wrong fpga-build and firmware when I
ran the vrt branch. When I discovered my mistake I downloaded the files
from http://www.ettus.com/usrp2_vrt but I cannot get the USRP2 to work
with these files. The leds go on just as normal, but when I try to run
./find_usrps I just get “No USRP2 found”. Does anyone know where to get
the proper image files for the fpga and firmware?

Regards,
/Ulrika

6

Ulrika,

I agree with how you think the timestamps are generated – it seems to
work
for me that way anyway!

I did it with a custom source block that added the counterdecimation
rate
after the first sample, the trap I fell into there is that (particuarly
at
lower decimation rates) rx__handler() can be called multiple times per
instance of it.

Are the timestamps being treated as UINT32’s?

400 samples is quite low, I think the packets are usually bigger than
that
(I might be wrong, its been a while since I looked into that).

Cheers,

Tim

7

Tim,
thanks for your reply.

I thought the packets always had the same size (specified by
U2_MAX_SAMPLES), or am I wrong here? I also do get the very same
timestamp diff when running rx_streaming_samples with N= 400, 4000,
6000, 60000 etc.

I don’t quite follow you on what will happen when calling the handler
multiple times? I print the timestamps in usrp2_impl handle_data_packet
which I thought would be run every time (once) a new ethernet packet
arrives which isn’t a control packet?

(And yes the timestamps are treated as uint32’s.)

Regards,
/Ulrika

From: Tim P. [mailto:[email protected]]
Sent: Thursday, February 18, 2010 9:35 PM
To: Ulrika U.
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] Timestamp value

Ulrika,

I agree with how you think the timestamps are generated – it seems to
work for me that way anyway!

I did it with a custom source block that added the counterdecimation
rate after the first sample, the trap I fell into there is that
(particuarly at lower decimation rates) rx__handler() can be called
multiple times per instance of it.

Are the timestamps being treated as UINT32’s?

400 samples is quite low, I think the packets are usually bigger than
that (I might be wrong, its been a while since I looked into that).

Cheers,

Tim

On Thu, Feb 18, 2010 at 4:10 PM, Ulrika U.
<[email protected]mailto:[email protected]> wrote:
Hi,
I wonder how the timestamps are being generated for each ethernet-packet
sent from the USRP2 to the host? My initial idea about how it works was
that timestamps are generated at 100MHz (same as the samples) and then
the timestamp associated with the first sample in an ethernet data
packet will be put in the metadata which could then be unpacked in the
host. I then would assume that the next packet after the first one will
have a timestamp value that is proportional to the number of samples per
packet times the decimation rate. However I get timestamp values that
increase much much more for each received packet, so I wonder if my idea
of how timestamps are generated is wrong?

I run the stable 3.2 version of gnuradio on Ubuntu 9.04 and I have an
USRP2 with the RFX2400. (I also was going to try the gnuradio trunk but
I got problems with building, see my other post “Error on make from git
development trunk”). I tried both an old version of the fpga bin-file
and one that I just recently downloaded (but both gave the same result).

I put some printouts in usrp2_impl.cc in the handle_data_packet function
and the output when I run rx_streaming_samples then looks like this:
./rx_streaming_samples -f 2457e6 -d 16 -N 400 -v
…
Daughterboard configuration:
baseband_freq=2456250000.000000
ddc_freq=-750000.000000
residual_freq=-0.016764
inverted=no

USRP2 using decimation rate of 16
Receiving 400 samples

ts_in = 1435221596, ts_last = 0, diff = 1435221596
ts_in = 2560802396, ts_last = 1435221596, diff = 1125580800
ts_in = 3367616092, ts_last = 2560802396, diff = 806813696
ts_in = 4174429788, ts_last = 3367616092, diff = 806813696
ts_in = 686341724, ts_last = 4174429788, diff = 806879232
ts_in = 1493155420, ts_last = 686341724, diff = 806813696
ts_in = 2283192156, ts_last = 1493155420, diff = 790036736
ts_in = 3090005852, ts_last = 2283192156, diff = 806813696
ts_in = 3896819548, ts_last = 3090005852, diff = 806813696
ts_in = 408731484, ts_last = 3896819548, diff = 806879232

Copy handler called 2 times.
Copy handler called with 2968 bytes.

Elapsed time was 0.000 seconds.
Packet rate was 100000 pkts/sec.
Approximate throughput was 148.40 MB/sec.
Total instances of overruns was 0.
Total missing frames was 0.
…

ts_in is the timestamp found in the metadata of the packet just
received, ts_last is the one from previous packet and diff is just the
difference them between. Since there seems to be no missing frames I’m
guessing the big value of diff can’t be related to lost packets?
If I try different decimation rates, I see no obvious relation between
the difference in value between two timestamps…

Do anyone know why the difference in timestamp value between received
packets is so big? What am I missing here?

Thanks,
/Ulrika

8

You need to flash the sd card with fpga and firmware images from
http://www.ettus.com/usrp2_vrt

Then you must install the host code from this branch:
http://gnuradio.org/cgit/jblum.git/log/?h=usrp2_vrt

Alternatively, you can also build the firmware and fpga images from that
branch as well.

One way to know that the host code is properly installed is to run
wireshark. When you run the command find_usrps, you should see an
ethernet packet going out with protocol id “0xbef0”. If it shows
protocol id “0xbeef” than you are not running the vrt branch.

-Josh

9

Ulrika,

The rx_handler thing is if its implemented to create a seperate stream
of
timestamps in python (i.e gr-usrp2) rather than C++ - I ran into the
problem
due to not fully understanding the code/checking base classes before I
modified it, it shouldnt be an issue with pure C++ or if you dont bother
incrementing the timestamp for each sample in a packet.

I think they are the same size, but contain x samples. I’d ignore that
bit I
was confusing myself I think :slight_smile:
Its been ages since I double checked stuff with wireshark/print
statements
though so i might be wrong on whether they can vary.

Cheers,

Tim

2010/2/19 Ulrika U. [email protected]

10

Hi, thanks for your reply.
I have flashed the sd-card with the fpga and firmware images but I
didn’t get the git thing properly. After reading
http://lists.gnu.org/archive/html/discuss-gnuradio/2009-12/msg00277.html
I managed to understand how to get the right version of the code, but I
still have some issues with git:

When I run git clone git://gnuradio.org/jblum.git I get connection time
out:
fatal: unable to connect a socket (Connection timed out)

When I cloned the master-branch I used http and also defined my proxy in
gitconfig, and that worked fine. But when I try to run git clone
http://gnuradio.org/jblum.git I get:
Initialized empty Git repository in /my-path/jblum/.git/
fatal: http://gnuradio.org/jblum.git/info/refs not found: did you run
git update-server-info on the server?

Is there any way around this?
Regards,
/Ulrika

11

I now ran the vrt version and when I take the difference in ticks
between the packets and divide by the decimation rate, the result is
always 365. Seems more reasonable than the results by the other
versions, but I would still expect the value to be 371 since
samples_per_frame is set by default to this value in rx_samples.
Where does the value 365 come from?

Maybe the number of samples in VRT packet is 365 ?

BR/
Per

12

I have now finally managed to get the vrt code, the problem was that I
got the wrong address… Sorry :stuck_out_tongue:

So lets get back to the main issue:

I now ran the vrt version and when I take the difference in ticks
between the packets and divide by the decimation rate, the result is
always 365. Seems more reasonable than the results by the other
versions, but I would still expect the value to be 371 since
samples_per_frame is set by default to this value in rx_samples. Where
does the value 365 come from?

This also brings me back to the question on the 3.2 stable release which
is the version of gnuradio that I am currently using. In 3.2 the
timestamps don’t behave like the time ticks (fractional time part) in
the vrt version. (The behavior in version 3.2 is described earlier in
this thread
http://lists.gnu.org/archive/html/discuss-gnuradio/2010-02/msg00343.html
) What is the difference else than the size (32 vs 64 bits)?

What else could I do wrong to get such different behavior?
I use the firmware and fpga image from
http://gnuradio.org/releases/usrp2-bin/trunk/ and
http://www.ettus.com/usrp2_vrt for the two versions, and the code is not
touched except from the printouts.

Thanks for any hints.
Regards,
Ulrika

but I didn’t get the git thing properly. After reading
http://lists.gnu.org/archive/html/discuss-gnuradio/2009-12/msg
00277.html I managed to understand how to get the right version of > the
code, but I still have some issues with git:

13

Hello again,
Just want to clear this out for anyone else who bumps in to this:
The solution is simple. The reason that the timestamps behaved strange
in the 3.2 version is because of the byte reverse order of the timestamp
when they are fetched from the pkt->hdrs.fixed.timestamp (I can’t
believe I didn’t see this sooner :wink: ). Running the timestamp through the
ntohx-function made the values much clearer! If I take the difference
between two received packets and divide by the decimation rate this will
now always result in 371 as expected.

Best regards,
Ulrika

release which is the version of gnuradio that I am currently
using. In 3.2 the timestamps don’t behave like the time ticks
(fractional time part) in the vrt version. (The behavior in
version 3.2 is described earlier in this thread
http://lists.gnu.org/archive/html/discuss-gnuradio/2010-02/msg
00343.html ) What is the difference else than the size (32 vs 64 >
bits)?

14

Hi,

I am a newbie with GNU Radio and USRP.

I am trying to synchronize two USRP 1 using GRC 3.6.5

I have gone through mailing list and the net in search of doing this
task.

I came to know that synchronization between 2 USRP 1 nodes is not
possible as the time stamp cannot be extracted from the USRP 1 fpga.

Can I do some kind of Timed Packet transmission using USRP1 and GNU
Radio Companion where I can know the time when the packet is being
transmitted and the time of packet arrival in the reciever so that I can
know the delay time between the Tx and Rx.

Please help.

Raj
Email: [email protected]

15

It looks like some of the demo apps have a samples per frame that is too
large for a typical 1500 byte MTU. Both rx samples and tx samples seem
to have this issue.

-Josh