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

[ValentinG]

There was a gap in our understanding what those commands exactly do, and the
problem was caused by telling the USRPs to start streaming in the past...
Inserting sleep (1) did work. Thanks for the explanations!

Valentin


Josh Blum-2 wrote:
> 
> 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
>>>
>>>
>>
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Possible-bug-in-the-vrt-branch-firmware--tp27825201p27833980.html
Sent from the GnuRadio mailing list archive at Nabble.com.