discuss-gnuradio
[Top][All Lists]
Advanced

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

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


From: ValentinG
Subject: [Discuss-gnuradio] Possible bug in the vrt branch firmware?
Date: Mon, 8 Mar 2010 10:12:57 -0800 (PST)

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


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





reply via email to

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