Time of Arrival Hooks

GNU Radio
1

Hello everyone,

I’m doing a project with the USRP2 that where I need to know the Time of
Arrival(TOA) of the waveforms. This is for a geolocation application.

My understanding as of now is that the hooks to get TOA are there in the
USRP2, but the firmware does not provide access to them at this point.
Is
this correct?

If the firmware can provide TOA, how can I get that information??

Thanks,
Devin

2

Devin,

The metadata is already passed to GNURadio by the USRP2 firmware. Its
the
gnuradio usrp2 source block that doesn’t do anything with this
information
(metadata has the timestamp for the first sample of each frame)

You can modify the code to provide a second stream, or interleave the
data
with them somehow by modifying the rx**_fc_handler.h files (primarily)
to
get access to this timestamp data in C++ blocks or post processing in
python
(all I’ve done so far).

Look for the “Fixme: Do something with metadata” line!

I’ve posted a couple of questions about getting timestamps to this
mailing
list (I don’t need absolute times in my case though so haven’t thought
about
how to sync these timestamps to real times) which some people (Doug,
Juha I
think) have helped me out on and I’m just summarising their replies
here!

I think I’ve read something about the 3.3 release implementing this but
that
might have been about the ability to do TDMA

Cheers,

Tim

3

devin kelly wrote:

Thanks,
Devin

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

The timestamp on the frame of samples is indeed available - and if you
use the low-level interface to the USRP2 (libusrp2) you can see those
timestamps. However, the gr-usrp2 interface (i.e. the default source
block for working with the USRP2) does not. If you want to see the
timestamps in a GNURadio flowgraph, you’ll need to create a custom block
based on the usrp2_source_[32fc or 16sc] block.
However, that won’t give you the TOA of a received signal directly.
You’ll need some scheme to decide that a signal has arrived, and then
calculate the TOA based on the timestamp corresponding to that sample
(the timestamps you get from libusrp2 are for the first signal in the
frame of samples - so you’d need to either calculate the running
timestamp for each sample, or keep track of the offset within the frame
somehow).
Good luck!
Doug

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

4

Hi Guys,

After experimenting a bit more I think the issue was my test setup.

Previously I was using python to setup a USRP Source (with timestamps)
and
save both the samples (64 bit) and timestamps (32bit) to a file sink to
process by importing with numpy and checking timestamps later.

At 25MHz thats ~ 300MB/sec of data, which is substantially more than
machines disk, which is probably about 20MB/sec max.

I’ve written a quick test block to run the same basic check in memory
(i.e
check if latest timestamp is sooner than the last one – expected to
fail at
roll over!) and have had no problems using a 25MHz bandwidth.

I would have thought the large amount of memory in the machine would
have
let me get over the hard drive bottleneck for a short period (say 30
seconds). The amount of data seems generated seems reasonable but the
file
sink seems to be causing corruption in terms of misordered samples.

I’ve had a quick look at the code and gr.file_sink(…) seems to use
fwrite,
is this thread safe? Thats the only idea I cant think of atm that might
be
causing this, has anyone else got any ideas?

I’m going to have a quick google to see if theres a safer way to
implement I
can test quickly, has anyone looked at this before? (Those expensive PCI
Expressive SSD Cards that can handle 1.4Gbit/sec would be nice if they
werent quite as expensive :slight_smile: )

Cheers,

Tim

On Wed, Nov 11, 2009 at 10:22 PM, Doug G.

5

Oops sorry guys this is in reply to the wrong timestamp question – I
had
meant to reply to this thread:
http://lists.gnu.org/archive/html/discuss-gnuradio/2009-11/msg00069.html

Cheers,

Tim

6

Doug,

Thanks I’ll try this. Googling a bit more I think fwrite has to be
thread
safe, I’ll double check my setup again and have another think if this
doesn’t help.

Cheers,

Tim

7

Tim P. wrote:

Hi Guys,

After experimenting a bit more I think the issue was my test setup.

Previously I was using python to setup a USRP Source (with timestamps)
and save both the samples (64 bit) and timestamps (32bit) to a file
sink to process by importing with numpy and checking timestamps later.

At 25MHz thats ~ 300MB/sec of data, which is substantially more than
machines disk, which is probably about 20MB/sec max.
Don’t have a good answer on the thread-safety question - but one method
I’ve used when I want to collect a bunch of data for a limited period of
time is mount a ram disk/tmpfs. E.g. I’d do something like:
$ mkdir /tmp/shm
$ sudo mount -t tmpfs tmpfs /tmp/shm
$ usrp2_rx_cfile -e -f -N
/tmp/shm/data.dat

Cheers,

Tim
Doug

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

8

Hello Tim,

I was going through the old posts for time stamping the samples that I
stumbled across this. I understand we have access to the metadata in the
rx**_fc_handler.h files. But what time is it that this uses? is it the
“machine time” ? If I want to use a GPS receiver time to time stamp the
samples, how can I make that happen with the metadata?

Please walk me through the process. I greatly appreciate your time and
help.

Thanks,
Mark.
Tim P. wrote:

Devin,

The metadata is already passed to GNURadio by the USRP2 firmware. Its
the
gnuradio usrp2 source block that doesn’t do anything with this
information
(metadata has the timestamp for the first sample of each frame)

You can modify the code to provide a second stream, or interleave the
data
with them somehow by modifying the rx**_fc_handler.h files (primarily)
to
get access to this timestamp data in C++ blocks or post processing in
python
(all I’ve done so far).

Look for the “Fixme: Do something with metadata” line!

I’ve posted a couple of questions about getting timestamps to this
mailing
list (I don’t need absolute times in my case though so haven’t thought
about
how to sync these timestamps to real times) which some people (Doug,
Juha I
think) have helped me out on and I’m just summarising their replies
here!

I think I’ve read something about the 3.3 release implementing this but
that
might have been about the ability to do TDMA

Cheers,

Tim