Synchronizing time between distributed RTC (internal or external)

[Anniyan_x]

if let say i have distributed RTC (real time clock), it can be internal RTC or External RTC chips to be synchronized to a reference a clock (GPS or master CPU) up to miliseconds range........actually the design is to cater for SOE (sequence of event detection & time stamping) within 1ms accuracy for digital input card. let say i have 40 slave cards with events between 1ms range, i must be able to timestamped each event within 1ms accuracy refered to the master cpu time.

it is a master slave (multidrop) architecture using rs485. the slave controllers must synchronized their time with the master controller to achive this. each slave have their own RTC (the slave will a stm32F4 mcu).

In the master CPU controller i have [2 x rs485] ports, where 1 port RS485(1) already used for DATA communication (include reference time command also) and another unused rs485(2), and 2 gpios pins. thats all.
------------------------------------------------------------------------------------
for now i plan to use a synchronizing pulse (1 pulse per-second) generated by the master mcu and distributed the pulse through a rs485(2) to all the slave mcu and upon receiving this pulse, the RTC timer will be reset (only the subseconds/miliseconds will be reset), meaning i plan use the 1pps pulse just to reset the miliseconds counter so that it wont drift away & send the reference TIME (the time to set to slave) using rs485(1) but i worry the propagation delays because the rs485(1) uses a custom communications protocol.

OR

i use a dedicated time system where when every seconds tick in the master controller,i just send the current time to the slave controller using rs485(2) and leave rs485(1) is only for DATA communications. so the rs485(2) just send the time in a very simple frame to reduce the propagation delays,not a full communication protocol as rs485(1).

anyway because i plan use dedicated RTC and not timers modules, i believe much of drift issue,OSC calibrations issue & etc will taken care by RTC hardware system.
so only the propagation delays of sending the time from master to slave using rs485 is the issue now.... how to reduce it??

there are 1 special protocols such as IRIG B, but to implement it i need to write the IRIG decoder and encoder. not sure how difficult it is?? anybody had implement IRIG B?? any idea on implementations method, guides?? or without IRIGB, can implement 1ms timestamps between multiple distributed slave controllers. or can we achieve without encoding the master time in IRIG format to be distributed to the slaves.....

 

[JimB]

As you are using RS485, I assume that all the slaves are multi-dropped from the one communication line, and that all the slaves have a unique address.
In which case why not reserve an address for the time sync signal, say address 0 or address 255.
The slaves will receive and act on messages sent by the master to the time sync address, but they will not transmit back to acknowledge the time sync address otherwise there would be a crash of data packets.

Using this method, all slave clocks will be set simultaneously using the one time sync command.

JimB

 

[misterT]

You could send a timestamped message to a slave, which then sends the same message back with the original timestamp and slaves own timestamp. Then you can figure out the response time and compare time differences between slaves. Then send each slave a correction value (or just keep statistics for each slave and do the time-correction at the master end).
Of course, the response from the slaves need to be very deterministic (constant time).. there can't be any variable software delays etc. But, the nice thing is that you can measure the response time and expect it to be constant (maybe you can even calculate the propagation delay.. theoretically).

But, since you are worried about propagation delay, I wonder what kind of cable distances are we talking about.. and what kind of topology. Are you writing custom firmware for the slaves and the master?

 

[Anniyan_x]

As you are using RS485, I assume that all the slaves are multi-dropped from the one communication line, and that all the slaves have a unique address.
In which case why not reserve an address for the time sync signal, say address 0 or address 255.
The slaves will receive and act on messages sent by the master to the time sync address, but they will not transmit back to acknowledge the time sync address otherwise there would be a crash of data packets.

Using this method, all slave clocks will be set simultaneously using the one time sync command.

JimB

yup it is a multidrop rs485, actually the existing protocol already have time sync command, i just wondered because when i read around, many people using IRIG timecode format to do timesync.u mean a timesync broadcast
message but without acknowlegdements mess from slave sides. first im gona try this method

You could send a timestamped message to a slave, which then sends the same message back with the original timestamp and slaves own timestamp. Then you can figure out the response time and compare time differences between slaves. Then send each slave a correction value (or just keep statistics for each slave and do the time-correction at the master end).
Of course, the response from the slaves need to be very deterministic (constant time).. there can't be any variable software delays etc. But, the nice thing is that you can measure the response time and expect it to be constant (maybe you can even calculate the propagation delay.. theoretically).

But, since you are worried about propagation delay, I wonder what kind of cable distances are we talking about.. and what kind of topology. Are you writing custom firmware for the slaves and the master?

it is rs485 multidrop connections, the slave are connected through backplane by slots. for now the total length can be said approx 2meters(or the last card slotted at the end of 2meters from the cpu). already have a linux based application for the master controller,only i need to write firmware for slaves only which already have a custom rs485 communications protocols between MASTER(CPU) & SLAVE.

so only now need to implement a effective time synchronization method. previously the slaves were running on 8051 mcu, now plan to port the codes to STM32F4 and implement the time synchronizations as well improve the overall performance

anyway, as for now i plan to just generate a precise 1second pulse from the CPU and distribute it to all the slaves using rs485(2), and connect the CPU 1second pulsing signal(1pps) to the slave RTC 1pps input (select an RTC with 1pps input feature,) and reset the milliseconds counter (as i need 1 ms timestamp), meaning make sure that the miliseconds counter is reset to zero at each beginning of a second,the idea is to makesure each slave RTC milliseconds counters is doesnt drifts as time passes . The RTC internal calibration system also can use the pulse signal to recalibrate itself and synchronize (some RTC that have this capabilities), as i read that RTC which have 1PSS input will sychronize its internal clock(drive clock faster or slower) according to the 1PPS clock ,but anyway on a multiple RTC's in a multidrop connections, how much the method can be reliable,i must test and see only. So here the cpu time is sent through the rs485(1) time sync broadcast command for the slave RTC actuall time setting. only here i ignore the propagation delay of the time command braodcasted to all teh slave thru rs485.

as this just theory only, im just seeking a advice or better ideas, or am i goin the correct directions...before start the implementation & testing.

so for e.g, let say cpu time is 8:10:30, CPU send this time to all the slaves (by rs485(1)), and set the slave rtc time,and then the slaves will receive a pulse every 1second from the CPU, and use this pulse to calibrate/synchronize the slave's RTC and makesure it is accurate up to miliseconds, for e.g 8:10:30:000ms, as some RTC will reset the miliseconds counter during rising edge of the 1PPS input, so the miliseconds counting will be synchronize across all the slaves at each beginning of a second. so i plan use RTC with these mentioned capabilities. so when few event happen in steps of miliseconds, a timestamp can be stamped for e.g, at 8.10.36.300, 8.10.36.301 & 8.10.36.302ms...................

To measure the propagation delay and do corrections, is a better idea,but the firmware must do the correction algorithms and etc, maybe firmware will get complex unless implement a simple ones as exactly as u said.​

 

[misterT]

Not sure about the internal details. How the RTC is implemented etc. But if you reset the millisecond counter every second, you can easily create more problems than solving them. Not a good idea to reset a counter that is just about to overflow. Also, one millisecond is relatively long time. I would not worry about (electrical signal) propagation delays.

Do you have any specs about the clocks? If you know the specs, you can roughly calculate how long it would take for two clocks to drift apart 1ms (worst case). Two 20ppm clocks will drift 1 millisecond apart roughly in 25 seconds. That is worst case scenario, when other is +20ppm and the other -20ppm.

Instead of generating 1 second signal, maybe it would be better to generate an event every one minute. And all the slaves would send back a timestamp of that event. Then you can monitor and log each clock and get their characteristics. And calculate correction values for each timestamp. I really would avoid resetting any counters. It just creates (random) jitter.

 

[hardikgohil]

Hello,

I am working on the same thing to achieve the same thing for SOE.

Can you tell give me your test results on 1PPS and which method you have opted for ?

how about IRIG-B if you have tried ?

 

[NorthGuy]

It takes less than 1ms to transmit a message through RS485 (assuming reasonable baud rate). So, there's no point in trying to use sophisticated protocols.

 

[granddad]

I have under development wireless serial PIC mcu's running with RTCC on both ,Remote ( a data logger ) has external DS1338 battery backed and is always running . I don't need 1ms precision so every remote message (on the hour + 2 secs ) has a time stamp, monitor checks hour and minutes , for a match if not it writes hh,mm and ss to its RTCC ( date is checked at the 00:00 hrs message), this means monitor does not need to be on all 24 hrs, I think if you try to sync to mili sec , slaves will be continually updating their clocks. can be problematical with internal RTCC.
https://www.electro-tech-online.com...se-monitor-pic-and-hc-12.149016/#post-1274187