PPS delay

[Eduardo-F]

Hello,

I did some "time" testing.

The test consists of compare the PPS (pulse per second) generate by a receiver with real Sats signal vs a PPS generated by a receiver with signal generated by gps-sdr-sim.

I measured the time between both PPS signals and the result is that PPS generated by simulator is delayed about 1 microsec every second. I try to explain me: t0: both PPS pulses are at same time t1 (1 second later from t0): Pluto PPS is delayed 1 microsec from real PPS t2 (1 second later from t1): Pluto PPS is delayed 2 microsec from real PPS t3 (1 second later from t2): Pluto PPS is delayed 3 microsec from real PPS ... So, at 100 seconds from t0, simulated PPS is delayed 100 microsec from real PPS.

I also did the test for Pluto-gps-sim (which is my goal) and the delay is 10 times, it is 10 microsec every sec.

Do you know what could be the delay cause? frames length? time between messages? How can fix it?

Thank you

[IvanKor]

this is the accuracy of setting the frequency of the crystal oscillator

[ferorted]

Thank you, It is possible but weird, because this delay is 1 microsec in gps-sdr-sim and 10 microsec in pluto-gps-sim. Of course, in both cases I used the same Pluto-SDR device.

[IvanKor]

this delay is 1 microsec in gps-sdr-sim and 10 microsec in pluto-gps-sim. Of course, in both cases I used the same Pluto-SDR device.

Pluto-SDR heats more and the frequency of the crystal oscillator shifts more

[Eduardo-F]

Hi IvanKor, I measured the Pluto-gps-sim code timing adding the system time as following:

// Update receiver time current_timestamp(); // print current timestamp in microseconds grx = incGpsTime(grx, 0.1);

As you can see in the image the time does't take 100 milliseconds between every timestamp call. The fist time is 1593452394:191124 and 4 sec later the time is 1593452398:191157, it is 33 microseconds more. In concordance with 10 microseconds per second delay measured in PPS receiver signal.

so I think it can be the main cause of PPS delay, don't you? Any suggestion to fix it?

[Eduardo-F]

I think the following lines are involved in that you told me and they control the data stream to PlutoSDR, but i don't understand how they work: pthread_cond_signal(&plutotx.data_cond); pthread_cond_wait(&plutotx.data_cond, &plutotx.data_mutex); pthread_mutex_unlock(&plutotx.data_mutex);

Maybe modifing the data stream speed can compensate or improve the final 10 microseconds PPS delay?

Any idea about how the data stream speed can be modify?

Thank you

---

De: IvanKor notifications@github.com Enviado: martes, 30 de junio de 2020 7:24 Para: osqzss/gps-sdr-sim gps-sdr-sim@noreply.github.com Cc: Eduardo-F efernandezortiz@hotmail.com; Author author@noreply.github.com Asunto: Re: [osqzss/gps-sdr-sim] PPS delay (#252)

incGpsTime not real time real time stream in Pluto-SDR

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/osqzss/gps-sdr-sim/issues/252#issuecomment-651546066, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIQVWMLV2KUWVDNYMY5LCNTRZFZKVANCNFSM4OITL5FQ.

[Mictronics]

@Eduardo-F Coming back to this issue: From what I understand, you measure a PPS time pulse against a timestamp generated by your host PC. Keep in mind the simulated GPS clock is an artificial clock. The incremented is hard coded to 0.1s here grx = incGpsTime(grx, 0.1);. However, this 0.1s increment has no relation to realtime, for example measured by you host PC's CPU clock. The real time delay between two 0.1s increments depends on code execution time, SDR processing time etc.

These are simulated clock parameters measured with a ublox M8T and HackRF as transmitter. GPS clock drift and accuracy are comparable to real GPS.

[ferorted]

Hi, thanks for your response.

I understand the 0.1sec increment.

About "drift time" I did tests consist in measuring with an oscilloscope the time between two PPS signals, one from a GPS receiving real Sats signal and the other one from another GPS receiving a signal generated by pluto-gps-sim.

My measurements show a accumulative drift about 10 microsec per second.

Where can it be mainly produced? In pluto-gps-sim host or Pluto Sdr device

El vie., 12 feb. 2021 11:16, Mictronics notifications@github.com escribió:

@Eduardo-F https://github.com/Eduardo-F Coming back to this issue: From what I understand, you measure a PPS time pulse against a timestamp generated by your host PC. Keep in mind the simulated GPS clock is an artificial clock. The incremented is hard coded to 0.1s here grx = incGpsTime(grx, 0.1);. However, this 0.1s increment has no relation to realtime, for example measured by you host PC's CPU clock. The real time delay between two 0.1s increments depends on code execution time, SDR processing time etc.

[image: gps_clock_sim] https://user-images.githubusercontent.com/11965780/107755586-50188800-6d23-11eb-8291-ebf3002fe385.png

These are simulated clock parameters measured with a ublox M8T and HackRF as transmitter. GPS clock drift and accuracy are comparable to real GPS.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/osqzss/gps-sdr-sim/issues/252#issuecomment-778105882, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOBCA57W4QURYAJGUR5WML3S6T5WBANCNFSM4OITL5FQ .

[Mictronics]

What is drifting and accumulating? The simulated PPS signal accumulates 10us/s and getting longer? Or both PPS signals drifting off each other?

I can confirm jitter in PPS when simulating, < 1us, usually around 500ns. I neither see the PPS drifting away nor accumulating (getting longer) when simulating with HackRF or Pluto. However, both SDR's are equipped with OCXO's for precision and in my general experience is the HackRF the better choice.

[ferorted]

Hi, Now, I have replaced the factory xtal for an VTCXO (TYKACCSANF-40.000000).

I mean measured time between a PPS from a receiver with real GPS signal vs a PPS from a receiver with pluto-gps-sim signal.

As you can see in the following images, Real PPS is on channel 1 (yellow) and it is taken as "reference" to measure the time vs Simulated PPS (channel 2, blue).

First image shows a dt=82us between them. Second image was taken about 60sec later and shows a dt=298us. Third image 60sec later (from second image) shows a dt=498us. It is about 3.3us per sec. So, 60min later both PPS will be 11.8msec drifting off each other.

[Mictronics]

I mean measured time between a PPS from a receiver with real GPS signal vs a PPS from a receiver with pluto-gps-sim signal.

What I expected. The simulated GPS clock is: "simulated". It has no synchronization with real world clocks, especially not with the atomic clocks inside the GPS satellites, which are the reference of the real PPS signal.

Take a look at the code: grx = incGpsTime(grx, 0.1); this will increment the "simulated" GPS clock by exactly 0.1s, but nowhere in the code is a synchronization to an external clock, neither to your host system RTC nor any other external clock source.

The time between calls to incGpsTime depends of course on code execution time. However, as long as the simulation code can generate IQ samples in time and feeds the SDR everything is fine. The simulated GPS always gets a perfect 0.1s increment but of course is drifting away over time from a real time clock outside the simulation, that is measuring a metric inside the simulation.

[ferorted]

I´m realize that simulated GPS clock is not sync with other clocks.

So, you say "The simulated GPS always gets a perfect 0.1s increment". Assuming host is able to do this, it is clear that simulated GPS clock and real GPS clock are not sync, but I don't understand why drift increases along the time.

Also, any idea about how can modify the drift? It is possible call grx = incGpsTime(grx, n )? where n is not 0.1 (for example 0.999, 1.001 ...

[Mictronics]

Can you explain the use case? For what purpose you need a synchronized real and simulated PPS signal?

About changing the time increment: just think about how GPS works and what influence a modified time will have.

[ferorted]

I have GPS based "time counters" devices, they move in open sky environments (were real GPS signal is available) and also in indoor environment with no (or weak) GPS signal. In order those counter devices can operate in the indoor place I want provide GPS simulated signal. Then to maintenance a data coherence, both GPS signals have to be synchronized.

If drift exists, data are not valid, for example devices in indoor show not same time than outdoor devices. Also when a device travel from outdoor-indoor-outdoor the showed time has "jumps" , then data are not reliable. And it gets worse along the time.

[Mictronics]

Usually for indoor environments a GPS repeater comes in mind. At least we use them at work to have GPS inside hangars.

Anyway, I still believe you cannot sync the simulation clock to real time because of precision issues. But I can try what happens when delta_t in time increments is modified.

[ferorted]

About the drift, I discovered when xo_correction parameter is modified the speed of drift is affected, even drift speed can be stopped. Obviously it is not valid for drift control because others parameters (Tx_LO frequency, etc.) also are changed. What is the relation between drift and xo_correction?