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 On Thu, Nov 19, 2009 at 7:02 PM, Tim Pearce <[email protected]>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. > > 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 <[email protected] > > 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 >>> [email protected] >>> 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 >> [email protected] >> >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
