Re: Synchronization: PPS and Tx signal in a USRP N200

[isaac mario tupac davila]

Hello

Thanks for the information !!!

I have a question regarding the parameter unknown pps. I'm focusing wrong, I think so ...

1. If I read the concept This method is used to sync when the edge of PPS is UNKNOWN. But when I use a N200, a trimble(GPS) and GRC (uhd:usrp source) with this configuration (unknown pps), my N200 gets synchronized using a trimble (known pps)... So , when should I use unknown PPS? 

2. Also says It waits for the last pps and later set time next pps. In another website there is a method 1 to poll the USRP time registers.. Is unknown pps using the same method?...  I think the Method 1 is used for known PPS (trimble and USRP)

Regards

Isaac T.

https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a413014bf3aea4a8ea2d268b4a3b390e9

https://files.ettus.com/manual/page_sync.html

El sáb, 11 dic 2021 a las 9:10, Glen Langston (<glen.i.langston@gmail.com>) escribió:

Thanks for your very well described study
of SDRs processing GPS signals and resulting timing accuracy.

Best regards

Glen

> On Dec 11, 2021, at 3:28 AM, jmfriedt <jean-michel.friedt@femto-st.fr> wrote:
>
> If it can be of any help, we discussed generating a GPS-aligned 1-PPS
> in http://jmfriedt.free.fr/ifcs2021.pdf and the oral presentation at
> http://jmfriedt.free.fr/ifcs2021_presentation_jmfriedt.mp4 prepared
> for the International Frequency Control Symposium (IFCS).
>
> What we realized when working on this topic is that the only place
> where time is known in an SDR processing sequence is at the ADC sample
> acquisition step, since all subsequent processing and data transfer
> afterwards are asynchronous, including the multitasking non-real time
> operating system GNU Radio is running on. Hence, the control on the
> 1-PPS alignement can only be achieved at the FPGA level clocking the
> ADC: the host clock is irrelevant since we do not know how much time
> was needed to transfer and process data. Luckily, GNU Radio provides a
> timestamp on each sample, assuming no data was lost since streaming
> started, so the control signal can be fed back to the SDR clock if the
> delay between reference and generated 1-PPS is measured using the same
> time reference of the ADC clock.
>
> Best, JM
>
>>> On 2021-12-10 17:25, isaac mario tupac davila wrote: 
>>>> Hello everyone!
>>>>
>>>> My name is Isaac. I have a curious situation here... I've
>>>> generated a pulsed signal per second. I've saved one second
>>>> period in a .h5 file, so that I'm sure I'm having a fixed signal
>>>> per second, and then repeat it in my GRC flowgraph. .
>>>>
>>>> To use this signal as Tx I'm trying to synchronize a USRP N200 and
>>>> a trimble in GRC. After run my flowgraph, this is what I see:
>>>>
>>>> imagen.png
>>>>
>>>> imagen.png
>>>>
>>>> The yellow signals are the PPS of my trimble and my purple signals
>>>> are my tx signal per second. They are periodic in time but when
>>>> you see it deeper, the difference between the timble PPS and my Tx
>>>> signal is approx 97 ms. I think this difference should be close to
>>>> cero, as my USRP and trimble are synchronized. ¿What is happening
>>>> here? ¿Is this a normal behavior? I'm using unknown PPS to
>>>> configure my UHD:USRP sink in GRC....
>>>>
>>>> I'll appreciate any help to clarify this behavior
>>>>
>>>> Regards
>>>> Isaac T.
>>>>
>>> Your flow-graph made very little sense to me.  If you want to
>>> synchronize your TX, you have to take explicit measures to ASK the
>>> USRP to schedule your transmits at specific times.
>>>   The 1PPS signal only synchronizes an internal time-stamp clock in
>>> the unit.  It has NO WAY of knowing what the *meaning* of your
>>> samples are, so it can't possibly
>>>   synchronize some arbitrary event in your continuous sample stream
>>> to 1PPS without you explicitly asking for when your bursts need to
>>> be sent.
>>>
>>> https://kb.ettus.com/Synchronizing_USRP_Events_Using_Timed_Commands_in_UHD
>>>
>>
>>
>>
>
>
>
> --
> JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000
> Besancon, France