All three things are taking measurements and each one has it's own idea of local time which makes it difficult to correlate the readings. They are linked via a MQTT network but latency varies between 0.1 and 1 second depending on the congestion level so having one device broadcast a master clock will cause the others to jump forwards and backwards in time which will mess up the measurement timestamps.
take a WWW search engine and ask for Lamport Clock.
Alternative: don't use the transmitted timestamp from the device, but the local timestamp from your MQTT Server on receive.
Do you need a full time stamp (say DDMMYY HHMMSSsss) or is relative time (say milliseconds since start) good enough ?
Sounds complicated. I shall do some more reading.
you have a complicated task, too.
Messages will have a variable amount of time jitter (network latency) making it impossible to determine exactly when they occurred.
Relative to an absolute point in time, for example midnight, so that a full DDMMYY HHMMSSsss timestamp can be constructed when saving the data to disk.
I will give you the advice to do some own studies about system time sychronization
if the client captures the timestamp at the time it makes a request as well as the timestamp of the response, can't it estimate the the latency by dividing the difference (response - request) to determine the latency which is added to the timestamp from the server. (if the client returns a timestamp when it receives the request, all the better) (see network time synchronization)
this same approach can be done periodically to maintain the time
Have you tried setting up your own NTP server? One example: How to sync time with a server on Raspberry Pi? – RaspberryTips
From reading that link it looks like conventional NTP takes many minutes to synchronize the clocks and doesn't attempt to do better than 128ms. Unfortunately the Arduino doesn't have a battery backed RTC to remember the time between reboots so I need a system that gets going within a few seconds of startup.
i helped implement i believe PTP when i worked on a 4G femtocell. that needed very precise time and was adjusted by speeding up or slowing down the TCXO.
an earlier version used a modified version of NTP. but in general, i believe NTP is just getting the time and i don't believe accounts for delay (but there appear to be some enhanced versions)
Probably having all three systems being ruled by each a radio-controlled clock would eliminate the jitter.
Alternatively having 3 RTC modules that synchronize once a day with a single given UTC packet (at best at nighttime) between them would not prevent some remaining latency, but prevent the nasty jitter.
Unfortunately the Arduino doesn't have a battery backed RTC to remember the time between reboots
That's easy and extremely cheap to add.
You have been asking for a detail "How to sync three devices in time.
if you describe the real thing
- what do you measure? temperature?, pressure?
- what measuring-intervals?
- what are the distancies between the three devices?
- what obstacles like walls or whatever are between the devices?
-Are you in the receiving area of the wireless signal of an atomic clock?
After describing that a lot more possible solutions can be suggested.
best regards Stefan