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 <douglas.gei...@nrl.navy.mil>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 >> Discuss-gnuradio@gnu.org >> 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 > douglas.gei...@nrl.navy.mil > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
