Hi Jawad, no, at this time you'd have to reimplement the example in python source code, modifying the python program that GRC generates. gr-uhd and UHD are pretty much developed in lockstep; it's just a feature that's not there (yet?). I think there might be some movement with that, but adding features like that is definitely an architectural decision and I can't do that on my own :) I'll discuss this, probably at the Berlin GNU Radio Hackfest.
Best regards, Marcus On 11.01.2016 11:58, Jawad Seddar wrote: > Thank you Marcus for taking the time to respond. > > I'm just trying to figure out if there is a straight forward way of > doing so directly from GRC. > I'm trying not to fiddle with the generated script manually (for > flexibility purposes, It's easier to distribute/update GRC flowgraphs > than generated scripts). > > Maybe gr-uhd needs to be patched to enable this with the newer > versions of UHD??? > > Regards, > Jawad > > 2016-01-11 11:46 GMT+01:00 Marcus Müller <marcus.muel...@ettus.com > <mailto:marcus.muel...@ettus.com>>: > > Hi Jawad, > > look at the query_gpsdo_sensors example; we recently (3.9.2) > overhauled that to show how to portably and reliably set the > device time to GPS time. > > The point is that "set_time_source" is a bit of a misleading name: > it actually sets the timing *pulse* source, i.e. where the USRP > gets its PPS from. The GNU Radio USRP blocks set the device time > to 0, iirc. > > > Best regards, > Marcus > > > On 11.01.2016 11:42, Jawad Seddar wrote: >> Hi Derek, >> >> I set my USRP source block to use the GPSDO as a Time source, >> then set the Sync parameter to "Unknown PPS". >> All it does is reset the USRP tilme to 0 on the PPS front, it >> doesn't set the time to the GPS time. >> >> Is there anything else I can try? >> >> In the meantime, I reverted to UHD 3.8.5 which works for me. >> >> >> Regards, >> Jawad >> >> 2016-01-08 20:10 GMT+01:00 Jawad Seddar <jawad.sed...@gmail.com >> <mailto:jawad.sed...@gmail.com>>: >> >> Thanks Derek, I will try that when I get a chance. >> >> I didn't try setting the "Sync" parameter to "Unknown PPS" >> but was guessing it might have something to do with that. >> I will give it shot on Monday. >> >> Regards, >> Jawad >> >> >> 2016-01-08 20:07 GMT+01:00 Derek Kozel <derek.ko...@ettus.com >> <mailto:derek.ko...@ettus.com>>: >> >> Hi Jawad, >> >> I believe that setting the USRP Sink block's setting to: >> Clock: O\B GPSDO >> Sync: Unknown PPS >> >> is all that's needed but I do not have the hardware in >> front of me to verify this at the moment. I hope someone >> will chime in with confirmation or the correct settings, >> but I will check this when I get a chance, but it may not >> be until Monday. >> >> Regards, >> Derek >> >> On Fri, Jan 8, 2016 at 10:40 AM, Jawad Seddar >> <jawad.sed...@gmail.com <mailto:jawad.sed...@gmail.com>> >> wrote: >> >> Hello Derek, >> >> Thanks for your answer. >> >> Unfortunately, this is the method I was referring to >> when I was talking about setting the time manually in >> a python interpreter (the only difference is that I >> was using the functions from gr-uhd that translate to >> the method you mentioned). >> >> Is there a way of doing this directly from GRC? >> It used to work out of the box when using a >> usrp_source or usrp_sink block from gr-uhd. >> >> >> Regards, >> Jawad >> >> 2016-01-08 19:31 GMT+01:00 Derek Kozel >> <derek.ko...@ettus.com <mailto:derek.ko...@ettus.com>>: >> >> Hello Jawad, >> >> The UHD 3.9 release changed the default GPSDO >> behavior. UHD does not automatically synchronize >> device time to GPS time on initialization because >> it's not reliable during device start-up. I'm not >> 100% sure about GNU Radio's handling of these >> changes so will have to check before commenting >> on the behavior there. >> >> Here is a method of reliably setting the time in >> your own code: >> 1) Poll on usrp->get_mboard_sensor("gps_locked") >> until it returns true >> 2) Poll on usrp->get_time_last_pps() until a >> change is seen. >> 3) Sleep 200ms (allow NMEA string to propagate) >> 4) Use >> >> "usrp->set_time_next_pps(uhd::time_spec_t(usrp->get_mboard_sensor("gps_time").to_int()+1));" >> to set the time >> 5) Poll on usrp->get_time_last_pps() until a >> change is seen. >> 6) Sleep 200ms (allow NMEA string to propagate) >> 7) Verify that usrp->get_time_last_pps() and >> usrp->get_mboard_sensor("gps_time") return the >> same time. >> >> Regards, >> Derek >> >> >> On Fri, Jan 8, 2016 at 4:50 AM, Jawad Seddar >> <jawad.sed...@gmail.com >> <mailto:jawad.sed...@gmail.com>> wrote: >> >> Hi all, >> >> Yesterday, I decided to update from GNU Radio >> 3.7.7.1 + UHD 3.8.4 to GNU Radio 3.7.9 + UHD >> 3.9.1. >> >> I used pybombs and everything went well, my >> OOT modules compile and my blocks run just >> like they used to. >> >> My issue comes from the time that is set on >> the USRP. It seems like the time on the >> device is not set to use the GPSDO. After >> doing some digging, I noticed that this >> commit might be responsible >> : >> https://github.com/EttusResearch/uhd/commit/f4f3ce2550aba933b5f4d310d82a42a41ce3f6a1 >> . >> >> So I tried setting the time source as GPSDO >> on my USRP source block (in GRC) but that >> doesn't seem to be working. I still get >> something (in the tens of thousands) that is >> way below what it should be (I get the time >> on the USRP by looking at the rx_time tag >> available at the beginning of a received >> sample stream). >> >> If I run a python CLI and setup a usrp_source >> then set the time manually to the gps_time, >> then the time is somewhat correct. >> >> Am I missing a step when setting up my >> usrp_source in GRC? >> >> Thanks, >> Jawad >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> <mailto:Discuss-gnuradio@gnu.org> >> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> >> >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
