Re: [Discuss-gnuradio] Possible bug in the vrt branch firmware?

[Josh Blum]

If you just re-powered the device, time_spec_t(2, 10000) is always a 
time in the past (by the time you get to run a usrp2 app) because of the 
time it takes for hardware/firmware initialization. If you need to rely 
on a specific time to be in the usrp2, use the set_time_now. If you need 
to use set_time_at_next_pps, give yourself 1 second to be sure that the 
time is latched into the registers before starting to stream.

In the example you posted, there is no sleep time between the 
u2->set_time_at_next_pps(usrp2::time_spec_t(0, 0) and the 
u2->start_rx_streaming(0, usrp2::time_spec_t(2, 10000). Therefore, 
set_time_at_next_pps will not take effect in time for the 
start_rx_streaming. And, start_rx_streaming will see a time in the 
registers that is unknown and very likely to be larger than 
time_spec_t(2, 10000). As I said before, I believe there is a bug 
related to telling it to start streaming in the past.

I could be wrong, but try to add the sleep just to remove the issue of 
telling it to start to stream with a time in the past. In general, you 
will always want to wait at least one second after set_time_at_next_pps 
before streaming so you can guarantee known values in the timestamps.

-Josh

On 03/08/2010 11:58 AM, ValentinG wrote:
> How u2->start_rx_streaming(0, usrp2::time_spec_t(2, 10000)) is start
> streaming in the PAST? Isn't it 2 seconds later than the time we reset to
> which is (0,0)? Also we have tried changing the start streaming time to
> (5,10000) which didn't help, hence I'm not sure if sleep(1) is going to make
> a difference...
>
>
>
> Josh Blum-2 wrote:
> > There have been no recent changes to the images posted at
> > http://www.ettus.com/usrp2_vrt
> >
> > I believe that there is a problem when you tell usrp2 to start streaming
> > at a time in the past. I cannot verify this at the moment.
> >
> > Try putting a sleep(1) after the set time at next pps. By nature, set
> > time at nest pps could take a second (worst case scenario) to latch in
> > new values.
> >
> > -Josh
> >
> > On 03/08/2010 10:12 AM, ValentinG wrote:
> > > Hi All,
> > >
> > > We've tried editing the rx_timed_samples.cc to set the time on the USRPs
> > > on
> > > the next pps and then start streaming data some time after, by inserting
> > > the
> > > following code (instead of the existing one) between rx_handler
> > > my_handler(nsamples) and the while loop:
> > >
> > >
> > >     //create a new usrp2 object, set some properties
> > >     usrp2::usrp2::sptr u2 = usrp2::usrp2::make(interface, mac_addr_str);
> > >     u2->set_rx_decim(16);
> > >
> > >     //set the system time to the usrp2
> > >     u2->set_time_at_next_pps(usrp2::time_spec_t(0, 0));
> > >
> > >     //begin streaming in the future
> > >     u2->start_rx_streaming(0, usrp2::time_spec_t(2, 10000));
> > >
> > > this code used to work in the middle of last week. We had to reflash our
> > > SD
> > > cards on Friday, so we downloaded the firmware from
> > > http://www.ettus.com/usrp2_vrt and flashed our cards with it. After doing
> > > that the above code just stopped working. Was there an update of firmware
> > > some time last week?
> > >
> > > Strangely enough it works if we set the time of the usrps to 200,0
> > > instead
> > > of 0,0 and start streaming at 202, 10000. But this fix only works for one
> > > acquisition, i.e. if we run the code one more time it just freezes and
> > > doesn't do anything, so to run it again we have to reset the usrps.
> > >
> > > We're using 1Hz TTL PPS as required by the USRP2 spec.
> > >
> > > Any ideas?
> > >
> > > Valentin
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio