Get time including milliseconds?

Hi,

Looking at the ‘Time’ function - there appears to be nothing smaller than 1 second :-((.

I want to be able to print a time including fractions of a second - is this possible on a Photon ??. I assume that the clock is driven by ‘milliseconds’ (or a similar resolution clock source ??)

In C# this format would be “HH:mm:ss;fff”;

I ‘could’ use millis() but is this actually synchronised to the clock time, ie is HH:MM:SS:000 seconds actually represented by millis() %1000 ?? returning 0.

Many Thanks…

BR
Graham

The Time object provided by the Particle framework is based on the STM32F RTC which only sports 1sec resolution and even that will go astray over time, hence the need to regularly call Particle.syncTime().

So even if you got millisecondd back from it they would not me comparable to atomic clock timestamps (never mind the network latency).

The presence of sub-second numbers in C# should also not fool you into believing that your PCs RTC provides atomic clock accuracy.

The millis() and micros() functions on the Particles are running independent of the RTC and are based on the sys tick counter of the MCU that starts counting up in sub µs as soon the MCU starts running.
But given the fact that there always will be some uncertainty about the actual current time, that initial offset between millis() and Time (max ±0.5 sec) should be a calculable risk.

The possibly best high precission time base you could get is via GPS (at least this is what we use at my company for process control network).

If you could give some more background what you need that precission for, we might be able to suggest solutions.
Usually time periodes (or relations between timestamps) need to be measured with higher precission than timestamps (calendric date/time), so seperating that might be one way.

@ScruffR - thanks for this response. I am certainly NOT looking for ultimate precision, and I DO fully understand the limitation of timing in c# ;-)). All I want is a relative millisecond tick, and thats precisely what c# .fff provides.

If I wanted really accurate time - I would as you suggest use GPS or even an old atomic clock receiver would do the job ;-)).

I am simply trying to indicate lapsed time between a command going out, and the response coming back. Its WAY easier to use time and include milliseconds, but if that’s not possible on this CPU then so be it :-((. I DO use this on PIC’s however with much success…but then I have full control over ALL the code.

I am currently using (int)(millis() % 1000l) after displaying the time but the ‘offset’ from zero is ‘annoying’ - thats all ;-)). HH:MM:SS (fff) in my logging.

I fully understand that the clock will ‘drift’, but over a few seconds its pretty damn accurate ;-)).

NB It ‘could’ easily be done with a clock interrupt - which simply resets a (local) millisec counter ‘on the second’ (or even minute/hour), thus ‘syncing’ the two sources - then Time could indeed easily include an fff feature.

Thanks for clarifying though…

BR
Graham

Any anecdotal evidence how big that clock drift might be over time? Is that something in the order of what a quartz crystal will do (i.e. a typical digital watch) or much worse?

It’s comparable to the drift of a free running (unsynced) PC clock (roughly a couple of seconds per day).

1 Like