Data acquisition syncronization by using timestamp

No way to tell from the above question. I think giving a bit more information would be helpful here - what resolution or precision do you need, how are your subsystems connected, etc.

--
:wq
^X^Cy^K^X^C^C^C^C

lco, thank you for the reply. It was my bad.

The system architecture is like this: A host computer (pc or workstation) will send command and data and collect data to and from 3 sub systems through EtherNet communication. These three sub systems are:

1. motion controller sub system
2. imaging sensor sub system
3. pattern generation system.

The pattern generation system will generate voltage pattern to drive the device under test. While the imaging sensor that is carried with a motion stage will scan through the device and take snap shots of a "voltage image". The motion encoder data, imaging sensor data and the drive pattern need all be synchronized in some way so that the data from all this three sub system sent back to the host computer are timely correlated. The time resolution needs not to be high but in mini second range. The current thinking is that pattern generation sub system sends out a master clock (less than 100hz) to make sync point once every 10 mini second. Local clock of each sub system will sync with this master clock to generate time stamp. This is more just like a general idea but I need to get into detail on how those synchronization in each sub system be realized and what is the best way to generate time stamp information from each sub system?

Thanks

-yan

I'm working on an oceanographic buoy system where we want to keep good time stamps on the data. We are handling that by having a GPS receiver for time and position. Each buoy syncs the local clock to the GPS time. That should be good enough for our 1Hz sampling even without using the 1 Hz time pulse from the GPS. Whenever we read the GPS time we can resynhronize the local clock. We may turn off the GPS for many minutes at a time to conserve power, but the local crystal-controlled RTC won't drift too much in that time.

Mark Borgerson

Instead of trying to sync the timestamps, perhaps you can make something equivalent to a movie clapper board. Once in a while, use all

3 subsystems on a known reference, and have them send the information with their local timestamp. In the host, you can then calculate the timestamp offsets, and subtract the same offsets from all your other data.

There are two important issues:

a) synchronising all systems at some specific time b) how to handle clock drifts between clock synchronisation events

As strange as it may sound, point b might be the harder part :-), if the time between synchronisation events is significant.

Paul

Mark,

Thank you for your input. Can you make it more detail on how you sync local clock with GPS time when ever you read it? I am kind new to this field, so forgive me if i am asking the ABC questions. Did you use some sort of clock counter to keep counting the local clock pulse and compare with the GPS time when you read it? What does RTC means? And how do you deal with drift as paul mentioned?

Thanks

-yan Mark Borgers> > > Hello all,

Also how does the time stamp generated? is it by reading some clock counter register or what?

Thanks

-yan Mark Borgers> > > Hello all,

Basically, you read the GPS time and convert it to seconds since Jan 1, 1970. How you do that is very dependent on the format of the GPS time. You then set that time into a local seconds counter (incremented by a timer interrupt). Every once in a while you check the incoming GPS time against the local timer an if they are different, reset the local counter to the GPS time.

RTC means Real Time Clock.

Mark Borgerson

Yes. You just read the current seconds count from a memory location or hardware register. A hardware timer is responsible for incrementing the seconds count once per second.

Mark Borgerson

"michael" a écrit dans le message news: snipped-for-privacy@n67g2000cwd.googlegroups.com...

We were able to achieve better than 1 ms synchronisation beetween remote sub systems connected at 1200 bauds over power lines. Each sub system had a timer which generated interrupts at 1 ms intervals, the time was simply the count of interrupts.

We had a master station sending a time request message, the local time T0 was noted when the message was sent. The sub system received the message and noted its local time T1, sent a reply at T2 in a message that carried T2-T1. The master station received the reply at T3 and estimated the transmission delay dt = (T3 - T0 - (T2 - T1)) / 2

The master station was sending time request messages at regular intervals of about 10 mn which contained the master's local time and dt. The sub system compared its local time counter with the received time and adjusted its clock by a slight and temporary modification of the actual frequency of the 10 ms timer interrupt, long enough to compensate for the time drift.

In another configuration we were able to achieve 80 microseconds time synchronisation beetween sub systems connected over an Ethernet-like link and a shared wire that was used to carry and interrupt to each sub system. The master system simply sent a message containing the time at which the interrupt would be generated later on. When the sub systems were interrupted they were able to compare their actual clock with the content of the previous message.

michael:

What are the relationships between the motion and pattern generating systems? How controllable are they?

In computed tomography scanners utilizing continuous motion, the "timing" is usually generated by the motion controller. It sends a (hardware-based, so very little latency) trigger signal based on position. To correct for variations in speed, a timing system grabs the time between triggers. The imager integrates between trigger pulses, and an ADC step and readout occurs either very quickly compared to the integration time, or perhaps simultaneously using a dual integrator approach (lots of variation at this step). Of course, this requires the motion controller to have a fast trigger signal, and for the imaging system to be able to utilize such a trigger (this part doesn't go through ethernet).

--
Charles Allen

There are four protocols for ethernet that assist in time synchronisation for control and instrumentation purposes. There are different degrees of granularity of timing and integrity of the protocols. Which one will suit you depends on a number of factors that you will discover when you read the material.

Look up (with Google) the following:-

LXI NTP PowerNet TTP

One of those should be suitable for you.

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

Charles,

thanks for your reply. can you guide me to some more readings? I don't quite get it. for example, why you do integrate between triggers, and further more why is dual integration better.

the motion controller is provided by the third party. therefore it is easier to implement the timing trigger in the subsystem that is designed by ourself.

btw, the motion is not fast, about 200mm/s.

thanks

-yan Charles Allen wrote:

There is an IEEE standard for time synchronisation. IEEE 1588. AFAICR it gives up to microsecond timing on a ethernet network.

Regards Anton Erasmus