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 <[email protected]
> <mailto:[email protected]>>:
>
>     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 <[email protected]
>     <mailto:[email protected]>>:
>
>         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
>         <[email protected] <mailto:[email protected]>> 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
>             <[email protected] <mailto:[email protected]>>:
>
>                 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
>                 <[email protected]
>                 <mailto:[email protected]>> 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
>                     [email protected]
>                     <mailto:[email protected]>
>                     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to