Electronics > Projects, Designs, and Technical Stuff
syncronise multiple ADCs over an Ethernet network?
max_torque:
Assume i had a number of "slave devices" that each have an ADC, sampling various inputs. The sampling can occur at between 1 Hz and perhaps up to 10 kHz.
Each slave device spits out it's data into a ethernet data link, to be hoovered up by some master device.
How in this case do people attempt to syncronise or timestamp the data that comes into that master?
I'm not an ethernet expert, but i guess the slave devices will have to include some buffering to enable the non-syncronous ethernet link to spit that data back up to the master. It will broadly arrive in time order overall, but inidividual data packets may be out of sink i guess?
It seems to me that having some form of master clock line is required, but does that have to be a seperate hardware line, or could someway of "kicking things off" be achived using the ethernet link?
In all cases, the sampling must be continuous (ie cannot sample for a short period and then send the data, the data must be sent "continuously".
With a hardware clock line something could be done as follows:
1) the master holds the clock line (either low or high) and the slaves spot this, reset their sample clocks and wait
2) the master toggles the clock line at 10 Khz, each slave increments an integer rolling counter and samples on the rising edge of this clock line, with the 10Khz slaves sampling on every edge, the 1kHz slaves on every 10th edge etc. Each slave records the sample clock at the moment it samples, and links that to the data it has sampled
3) Each slave buffers it's data until ready to send a network packet containing that data, then sends that data
4) The master receives the ethernet data packets, processes them, and shuffles them about in memory so that each data set from each slave sits in the correct order for a monatmoically increasing sample clock value, ie it effectively reassembles the data into the time aligned order in which it were sampled.
The "roll over" of the sample clock counter would of course have to be correctly handled, but as long as that roll over time is greater than the maximum data latency the master sees, that should be reasonably trivial to do.
Have i missed something that would prevent that sort of scheme from occuring? Is there a better way? Can that be done with some form of ethernet "sync" packet and ech slave clocking its own data? (possibly a bit of a 'mare with clock drifts etc)
FenTiger:
10kHz is one sample every 100us.
NTP might not reach that accuracy, but PTP (IEEE1588) will keep a pair of clocks synchronised much more closely than that over a single Ethernet hop.
You might need a pricey switch, though...
Yansi:
I think that PTP nowdays work almost through any kind of a modern switch. Question is, what and how well defined accuracy is required.
And yup, forget NTP.
Also be prepared that you will probably need a real HW PLL (or equivalent way) to synthesize the sampling clock master.
I'd suggest having a look at how professional real-time audio is synced through ETH, for example the Ravenna standard is open and freely accessible to read.
voltsandjolts:
I think CERN use optical fibre for distribution of the LHC timing signal, there are some papers about it....e.g....
https://cds.cern.ch/record/1972447/files/CERN-BE-2014-001.pdf
https://cds.cern.ch/record/592719/files/p63.pdf
pardo-bsso:
There's also White Rabbit.
How much are you willing to spend?
Navigation
[0] Message Index
[#] Next page
Go to full version