discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Start_rx_streaming_at patch problems


From: Doug Geiger
Subject: Re: [Discuss-gnuradio] Start_rx_streaming_at patch problems
Date: Tue, 12 Jan 2010 09:30:18 -0500
User-agent: Thunderbird 2.0.0.23 (Windows/20090812)

Eric Blossom wrote:

You're probably trying to start "In the past".  That is, your start_at
time has already passed (the clock starts ticking when the USRP2
powers up).  I think we'd need to add a "get_current_time" command to
give you a clue as to when to start.  You'd need to add a suitable
offset to the returned value to account for the time required to
process the previous reponse and start_at command.

Eric


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
To expand on that a little bit, I've found that it works best if I call sync_to_pps, wait a short interval (I've been calling nanosleep with at least 1e6 nanoseconds - but usually just over one second), then call start_rxstreaming_at(0, <desired # of samples, I just use USRP2_MAX_RX_SAMPLES here - setting it to zero should have the same effect>, <desired fpga start clock time>), where the fpga start time is at least something greater than the nanosleep interval. However, the real problem here is that you don't have any idea how far into the future the next 1PPS signal is going to arrive (i.e. it could be just under one second into the future, or it could be essentially zero time in the future), unless you have some way of getting the signal into the host PC as well. So I typically sleep for just over a second, and set my fpga start time to be something fairly large (i.e. greater than one second), but not too large. I have found that if it's too far into the future, the command will 'disappear' from the command queue in the USRP2. Perhaps a better solution will come along WRT synchronizing the host PC and the USRP2, but in the meantime I'm able to get it to work with this fairly hack-ish method. As far as using it in gr-usrp2, I ended up writing my own custom source block, which started out life as a copy of the gr-usrp2/usrp2_source_32fc block.
 Doug

--
Douglas Geiger
Code 5545
U.S. Naval Research Laboratory
Washington, DC 20375
(202) 767-9048
address@hidden





reply via email to

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