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
