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>:

> 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>:
>
>> 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>
>> 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>:
>>>
>>>> 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>
>>>> 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
>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>>>>>
>>>>
>>>
>>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to