Re: [Discuss-gnuradio] Possible bug in the vrt branch firmware?
If our library is providing a standard call to set the timestamps of returned samples, shouldn't the standard or default way to do it result in those timestamps being accurate wallclock UTC realtime, rather than counting up from zero or from a random number? If by default our streams of samples came back with accurate nanosecond timestamps, that would be a big plus in the long run. You could later sync up signals from receivers all around the world; recordings would contain the time when the signal was received; etc. Any computer on the Internet can easily sync using NTP to within about 10 ms or so, to set the high order bits. And anyone with a PPS clock hooked to their USRP would get real cesium-linked timestamps. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Possible bug in the vrt branch firmware?
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, 1) 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, 1). 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, 1). 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, 1)) 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,1) 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, 1)); 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, 1. 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 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 -- 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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Possible bug in the vrt branch firmware?
On 03/09/2010 04:58 AM, John Gilmore wrote: If our library is providing a standard call to set the timestamps of returned samples, shouldn't the standard or default way to do it result in those timestamps being accurate wallclock UTC realtime, rather than counting up from zero or from a random number? If by default our streams of samples came back with accurate nanosecond timestamps, that would be a big plus in the long run. You could later sync up signals from receivers all around the world; recordings would contain the time when the signal was received; etc. Any computer on the Internet can easily sync using NTP to within about 10 ms or so, to set the high order bits. And anyone with a PPS clock hooked to their USRP would get real cesium-linked timestamps. John I'm working on a paper tiger design for a specialized direct-conversion receiver for radio astronomy that would include a GPS receiver, and a 64-bit nanosecond counter in it, the idea being that each sample block would include an accurate timestamp. My plan is to make the wire format compatible with the USRP2--which I haven't actually looked at yet. GPS modules can be purchased very cheaply these days, and integrated into various hardware platforms, including receivers and digitizers, for use as a phase reference. My receiver will use 1PPS to phase-lock both LO frequency, and the sample clocks, and also to provide head of block nano-second timestamps. I've been working with GPS clocks quite a bit in my real(tm) job. Phase agreement between GPS units, even connected to the same antenna, isn't as spectacular as you'd like. Most of them can get to within 40nsec phase-agreement on the 1PPS outputs. So that means that for doing things like VLBI, you'll still need to futz with the data to get fringes to come out, but your futzing window will be smaller :-) Cheers -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Possible bug in the vrt branch firmware?
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, 1)); 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, 1. 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. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Possible bug in the vrt branch firmware?
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, 1)); 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, 1. 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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Possible bug in the vrt branch firmware?
How u2-start_rx_streaming(0, usrp2::time_spec_t(2, 1)) 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,1) 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, 1)); 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, 1. 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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/Possible-bug-in-the-vrt-branch-firmware--tp27825201p27826670.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Possible bug in the vrt branch firmware?
If you just re-powered the device, time_spec_t(2, 1) 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, 1). 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, 1). 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, 1)) 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,1) 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, 1)); 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, 1. 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 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
