discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Time of Arrival Hooks


From: Tim Pearce
Subject: Re: [Discuss-gnuradio] Time of Arrival Hooks
Date: Thu, 19 Nov 2009 19:02:06 +0000

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 :) )

Cheers,

Tim


On Wed, Nov 11, 2009 at 10:22 PM, Doug Geiger <address@hidden> wrote:
devin kelly wrote:
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
------------------------------------------------------------------------


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
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 Geiger
Code 5545
U.S. Naval Research Laboratory
Washington, DC 20375
(202) 767-9048
address@hidden




_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


reply via email to

[Prev in Thread] Current Thread [Next in Thread]