set system time in microsecond

[RebootExpert]

using nano, and 3.3.8. Is it possible to set the system time in microsecond?
It's a requirement from my customer that need to do a time sync every second. There's a 1PPS signal interrupt to the module that trigger to update the time. Also the module will receive a UDP datagram contain the time info that need to sync with. That time info is in JSON text contains two variable. 1: number of weeks since some date, 2: microsecond into the week.
The reason of the requirement is that there's time sensitive cmd need to be process. The module will receive commands and the specific time(in microsecond resolution) of the command need to be executed.

[zealott]

I would use a <stopwatch.h> that resets at every PPS pulse and add that to the system time (GPS or NTP?) to get the microsecond component.
Would that work?

Cheers,
J

[pbreed]

Exactly which hardware are you running?
stopwatch.h
will make better than uSec measurements, alas any thing depending on I/O ethernet/serial etc...
the interrupt latency will vary more than a few uSec depending on network and serial port traffic.

If you really need uSec resolution you aren't going to get that in software....
You could probably set up the hardware timers to do that from the PPS....
A lot will depend Will depend on what action you want to make happen and what hardware platform you are running on.

More details are needed...

What EXACTLY are the timing and synchronization requirements you are trying to meet?
Be as specific as possible...

[RebootExpert]

the goal is try to execute a command at some future specific time, like turn on an LED at [01/01/2023 11:22:33.123456]
you're right. I will need a hardware timer for it.

[pbreed]

Which hardware platform?

[RebootExpert]

using NANO module

[pbreed]

With the NANO you have a really nice hardware timer.
Manual calls it DMA timer....(4 of them)
You can clock the timer from the system CPU clock.
Then capture the PPS with the input compare.
You can use output compare to trigger an interrupt at the exact correct time.
If the output compare is set as a level 7 ISR and you use Rapid GPIO signals one could
make this better than 1/2 usec.

If you wanted to mess with DMA triggering a transfer to the Rapidgpio register one could probably
get this to better than 250nsec. Would take some frustrating fiddly code and would not be trivial to make it all come together.

I've done a lot of time pps sync stuff, real easy to be off whole seconds if the UDP identifying the Seconds is delayed or not processed with the PPS.
Got to notice the arrival time over a period of seconds and then ignore "your UDP Secs" that don't match what you expect it to be until you've built up enough UDP secs to see what the new value of Seconds is.

Also most PPS have some dither because they are driven by a clock that is divided down from a non-synchronized clock.
Most super accurate GPS PPS systems have a time sawtooth value that you can have reported tell you haw many nSec early/late the PPS was.
Some GPS system would PLL phase lock the Root timer to make PPS perfect. Different time sources have different rules/accuracies.
You also need to adjust for the cable lengths.... again some super accurate GPS sources have antenna cable length adjustments.

When trying to do super accurate end to end time of arrival stuff at my very first Job at JPL (1984)
we had a system that accurately measured the temperature dependent phase delay of the whole system.
(Mostly the coax or hardline running to the prime focus.) Was even talk about the gravity sag of the large dishes changing the arrival phase.
We also calibrated the phase delay through the atmosphere using a microwave water radiometer that looked back through the atmosphere and
measured the water content of the atmosphere and could reduce the atmospheric phase uncertainty from 50cm to 2 or 3 cm.
How accurate do you really want to be?