Author Topic: syncronise multiple ADCs over an Ethernet network?  (Read 4637 times)

0 Members and 1 Guest are viewing this topic.

Offline max_torqueTopic starter

  • Super Contributor
  • ***
  • Posts: 1327
  • Country: gb
    • bitdynamics
syncronise multiple ADCs over an Ethernet network?
« on: December 08, 2019, 06:12:26 pm »
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)
 

Offline FenTiger

  • Regular Contributor
  • *
  • Posts: 88
  • Country: gb
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #1 on: December 08, 2019, 06:39:44 pm »
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...
 

Online Yansi

  • Super Contributor
  • ***
  • Posts: 3930
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #2 on: December 08, 2019, 06:42:49 pm »
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.
 

Online voltsandjolts

  • Supporter
  • ****
  • Posts: 2549
  • Country: gb
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #3 on: December 08, 2019, 08:27:22 pm »
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
 

Offline pardo-bsso

  • Regular Contributor
  • *
  • Posts: 235
  • Country: ar
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #4 on: December 09, 2019, 12:24:46 am »
There's also White Rabbit.

How much are you willing to spend?
 

Offline OldEE

  • Contributor
  • Posts: 18
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #5 on: December 09, 2019, 02:45:14 am »
You might want to look into Audinate's Dante protocol for audio over Ethernet for ideas.

Dante has become the defacto standard audio over LAN over the last 2 or 3 years.   Dante synchronises audio from multiple devices usually at 48kHz and 24 bit samples and it just works.  One device is elected or designated as the master clock.

Note that Dante is designed to work on one subnet or VLAN.  Routing, while it works, is not supported due to added latency.  Forget WiFi.

An interesting requirement is to disable EEE (Energy Efficient Ethernet) on all switches handling Dante traffic.  Apparently EEE causes some packets to be delayed.

Larry
 

Offline mansaxel

  • Super Contributor
  • ***
  • Posts: 3559
  • Country: se
  • SA0XLR
    • My very static home page
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #6 on: December 09, 2019, 05:58:24 am »
You might want to look into Audinate's Dante protocol for audio over Ethernet for ideas.

Dante has become the defacto standard audio over LAN over the last 2 or 3 years.   Dante synchronises audio from multiple devices usually at 48kHz and 24 bit samples and it just works.  One device is elected or designated as the master clock.

Note that Dante is designed to work on one subnet or VLAN.  Routing, while it works, is not supported due to added latency.  Forget WiFi.

An interesting requirement is to disable EEE (Energy Efficient Ethernet) on all switches handling Dante traffic.  Apparently EEE causes some packets to be delayed.

Larry

Angry broadcast network engineer bolierplate:

Dante is a bad, proprietary protocol that interops badly with grown-up systems. You can't route it, contrary to above.  The AES67 standard, while lacking in stream discovery, is inherently more scalable and flexible.  I work with building Wide Area Networks for media, and Dante is making my day more difficult over and over again.  That shit needs to die.

Then again,  yes, the OP has a requirement that is strikingly similar to the problem of sampling audio and shipping it over a stochastical network, so the obvious technical solutions are similar.  I would, based on doing audio/video networks for a living, recommend this:

  • Decide on latency first. You WILL have latency, and how much latency your application tolerates will dictate a LOT. The more latency you can tolerate, the easier your problem will be.
  • From latency and sample word length you will find how many samples and their timestamps you will want to cram into one Ethernet frame, not overdoing it. Audio streams usually have a "ptime" (interpacket interval) of 1ms in AES67; when latency is less important and you have fewer channels you can go up to perhaps 20ms of packet interval which of course is equal to amount of audio per packet. You will find a similar level. I would stay away from sub-millisecond ptimes, if at all possible.
  • Speaking of Ethernet frames, better make them IP packets that can travel over Ethernet, and make things routable. Not repeating the Dante debacle. Oh, and forget TCP. It's too slow.
  • You need PTP. Aim for default 1588-2008 profile if at all possible.
  • You will need a PTP aware switch. Be prepared to pay instrumentation prices, not broadband prices. 24 ports gigabit Ethernet (and you NEED gigabit even for trickle data rates; serialisation delay and buffering is a precision killer) is going to cost you perhaps US $6000 list, subject to some discount depending on who you are. The cheapest we've found that works tolerably well is the Cisco 3650's, but if possible we're using Cisco Nexus 9300 series, that are around 2 times the money. There of course are other vendors; both Mellanox and Arista make decent hardware.
  • Your measurement and data gathering nodes will need Ethernet adapters that can interact with PTP software in the node, doing hardware time stamping. PTP4L (Linux) is compatible with at least the Intel cards, I believe.
  • The measurement and data gathering nodes will need a good hardware clock, so they have something that can be steered by PTP.
  • You will need a Grand Master clock. It can be the switch, if suitably equipped (10MHz input, for instance), but the most common method is a GPS receiver with a network interface. I have used the Meinbergs, and we just bought a Sonifex that is reasonable in price while offering not only GPS capabilities but also can lock to 10MHz, 2048KHz, legacy media sync like WordClock, video tri-level, etc.

Important clarification:  I wrote timestamps above, and that for a reason. You do not want the Ethernet to be anything than an (in this case regrettably) elastic  bit pipe. Clocking on packet arrival times is not going to work well. Put a timestamp on every sample, and then transport that. That is going to make your "shuffles them about in memory" process like 1000 times simpler.

Ethernet is neither reliable nor predictable, and that needs to be accounted for in higher layers.
« Last Edit: December 09, 2019, 06:45:42 am by mansaxel »
 
The following users thanked this post: Someone, JJalling, MagicSmoker, FenTiger

Offline FenTiger

  • Regular Contributor
  • *
  • Posts: 88
  • Country: gb
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #7 on: December 09, 2019, 08:40:19 am »
Is it really important to timestamp every sample?

I'd have thought it would be OK for each packet to contain the timestamp of its first sample, and then the others can be assumed to follow at regular intervals.
 

Offline mansaxel

  • Super Contributor
  • ***
  • Posts: 3559
  • Country: se
  • SA0XLR
    • My very static home page
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #8 on: December 09, 2019, 09:35:16 am »
It depends on your accuracy requirements. If you for some reason want to vary (or, see below, record the variation of) the sampling frequency, a timestamp on every sample will make things obvious. A failed sampling will stand out and offer you the possibility of interpolation while non-timestamped samples will hide and transport the error to the gap between packets, creating a temporal offset of up to "ptime" (borrowing the RTP syntax here again) in locating the error.

Also, it might be more desirable to describe the system latency of the measurement inside the sampling node by actually recording the time the sample was taken rather than assuming an a priori sample interval. A perfectly clean signal sampled at irregular intervals will have time-domain issues when plotted/played back with a steady clock tick. If, OTOH, the sample time is recorded and sent on with the samples, the signal will come out just right if the interval is observed in the interpretation. 

All of this of course assumes a good enough clock in the sampling node, in lockstep with the interpretating node at that. Clock jitter, measurement resolution requirements, CPU capacity in measurement, gathering, processing or presentation nodes might make all of this moot. YMMV, of course.

Sidenote: I once ran a DNS name server for our CC TLD. The domain registry wanted query statistics every 5 minutes reporting on the number of queries, with some detail on success, fail, error, etc. My name server was running "nsd" which is written with performance in mind, first and foremost. Signalling the daemon to dump statistics was done from "cron" every 5 minutes. However, the daemon deemed answering DNS queries more important, so statistics were dumped ASAP, not immediately.  This was no problem, because the dump was time stamped to the required precision, recording the time it had been taken. 

However, the PHP dude whose "code" was the recipient of the data had, to make things easier for himself, simply assumed 300 second intervals between readings.  As a result of this clusterfuck-in-waiting, the graphs from my server were not as beautiful to behold as the graphs from other name servers where statistics dumps were treated as more important than answering queries.

The proposed solution? Said dude asked if it was possible to force my name server to adhere to the 300 second assumption, ignoring the actual task at hand, answering queries.  :palm: Naturally, we refused, and presented the resultant graphs from Doing The Right Thing. 

Online Yansi

  • Super Contributor
  • ***
  • Posts: 3930
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #9 on: December 09, 2019, 10:16:54 am »
You might want to look into Audinate's Dante protocol for audio over Ethernet for ideas.

Dante has become the defacto standard audio over LAN over the last 2 or 3 years.   Dante synchronises audio from multiple devices usually at 48kHz and 24 bit samples and it just works.  One device is elected or designated as the master clock.

Note that Dante is designed to work on one subnet or VLAN.  Routing, while it works, is not supported due to added latency.  Forget WiFi.

An interesting requirement is to disable EEE (Energy Efficient Ethernet) on all switches handling Dante traffic.  Apparently EEE causes some packets to be delayed.

Larry

How is one supposed to look how Dante works, if that crap is closed-source paywalled  ... ..

Thats why I have suggested RAVENNA protocol, because it has not the above mentioned major problems and shall be compatible after all, as RTP and PPTP is nothing new. Dante just uses a different session initiation, if I remember right.
 

Online Yansi

  • Super Contributor
  • ***
  • Posts: 3930
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #10 on: December 09, 2019, 10:24:42 am »
mansaxel,  do NOT and NEVER timestamp all samples. That is completely impractical nonsense, that will not have any benefit.

Both AES67 and Ravenna (both interoperable, routable) use RTP as the transport.  For 1ms chunks, you send RTP packets containing 48 samples of data, timestamped as a whole, including a packet series number.

See https://tools.ietf.org/html/rfc3550 for details about RTP transport.

FenTiger : Of course time stamp of only the first sample in a packet is sufficient.

And because AES67 is also paywalled, I suggest using the Ravenna audio standard, which is even superior (and interoperable) with AES67. https://www.ravenna-network.com/
« Last Edit: December 09, 2019, 10:28:24 am by Yansi »
 

Offline mansaxel

  • Super Contributor
  • ***
  • Posts: 3559
  • Country: se
  • SA0XLR
    • My very static home page
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #11 on: December 09, 2019, 10:53:32 am »
mansaxel,  do NOT and NEVER timestamp all samples. That is completely impractical nonsense, that will not have any benefit.

I can see what you mean. And yes, in a system where sample frequency is very tightly controlled (like audio), it is sufficient to stamp at intervals of "ptime".
In a more general case, where samples are perhaps taken at more interrupted intervals, the time stamp becomes more crucial.

Both AES67 and Ravenna (both interoperable, routable) use RTP as the transport.  For 1ms chunks, you send RTP packets containing 48 samples of data, timestamped as a whole, including a packet series number.

See https://tools.ietf.org/html/rfc3550 for details about RTP transport.

FenTiger : Of course time stamp of only the first sample in a packet is sufficient.

And because AES67 is also paywalled, I suggest using the Ravenna audio standard, which is even superior (and interoperable) with AES67. https://www.ravenna-network.com/

The service location in Ravenna suffers from several of the problems in Dante too. Plain AES67 is so much a subset of Ravenna specs that one can use Ravenna to build AES67 ;-).  Andreas at ALC Networks was very much involved in both Ravenna (of course) and AES67.


/Måns, working at a SMPTE member who is not an AES member. The paywall pain is obvious.

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9964
  • Country: us
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #12 on: December 09, 2019, 04:00:07 pm »
Is it really important to timestamp every sample?

I'd have thought it would be OK for each packet to contain the timestamp of its first sample, and then the others can be assumed to follow at regular intervals.

At least for TCP, packets can, and will, arrive out of order.  Maybe one of the other protocols avoids this but I don't see how considering the vagaries of ethernet transmission.
 

Offline FenTiger

  • Regular Contributor
  • *
  • Posts: 88
  • Country: gb
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #13 on: December 09, 2019, 04:13:35 pm »
Yes, but the samples within a packet won't be reordered. One timestamp per packet is all that's needed to reorder them.

(Also, a single Ethernet hop won't reorder packets unless you're detecting drops and doing retransmission somehow.)
 

Online Yansi

  • Super Contributor
  • ***
  • Posts: 3930
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #14 on: December 09, 2019, 04:31:03 pm »
Is it really important to timestamp every sample?

I'd have thought it would be OK for each packet to contain the timestamp of its first sample, and then the others can be assumed to follow at regular intervals.

At least for TCP, packets can, and will, arrive out of order.  Maybe one of the other protocols avoids this but I don't see how considering the vagaries of ethernet transmission.

TCP is a high level protocol used to NOT get out of order or missing packets. You probably meant UDP/IP.
 

Online rstofer

  • Super Contributor
  • ***
  • Posts: 9964
  • Country: us
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #15 on: December 09, 2019, 04:46:28 pm »
Is it really important to timestamp every sample?

I'd have thought it would be OK for each packet to contain the timestamp of its first sample, and then the others can be assumed to follow at regular intervals.

At least for TCP, packets can, and will, arrive out of order.  Maybe one of the other protocols avoids this but I don't see how considering the vagaries of ethernet transmission.

TCP is a high level protocol used to NOT get out of order or missing packets. You probably meant UDP/IP.

If you let the protocol sort out the packets, they will be presented in order but there may be a delay while the sender gets notified of and resends missed packets.  In terms of ethernet itself, you can just grab the raw packet and deal with it but you can count on data appearing out of order.  It pays to read the documentation because one stack, uIP, only allows one packet in flight.  This doesn't help throughput.

I wouldn't use UDP for much of anything where I cared about the data.  Oddly, there are a lot of applications where dropping a packet doesn't really matter much.
 

Online Yansi

  • Super Contributor
  • ***
  • Posts: 3930
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #16 on: December 09, 2019, 04:52:44 pm »
Is it really important to timestamp every sample?

I'd have thought it would be OK for each packet to contain the timestamp of its first sample, and then the others can be assumed to follow at regular intervals.

At least for TCP, packets can, and will, arrive out of order.  Maybe one of the other protocols avoids this but I don't see how considering the vagaries of ethernet transmission.

TCP is a high level protocol used to NOT get out of order or missing packets. You probably meant UDP/IP.

If you let the protocol sort out the packets, they will be presented in order but there may be a delay while the sender gets notified of and resends missed packets.  In terms of ethernet itself, you can just grab the raw packet and deal with it but you can count on data appearing out of order.  It pays to read the documentation because one stack, uIP, only allows one packet in flight.  This doesn't help throughput.

I wouldn't use UDP for much of anything where I cared about the data.  Oddly, there are a lot of applications where dropping a packet doesn't really matter much.

No, you seem to get quite confused. TCP stack, or to say the TCP protocol, is what deals with packet loss and reordering for you. If you talk about TCP, these function are assumed. (Or just I don't understand your wording. There is no such "if you let it". TCP does it by itself)

UDP is what IS used for transporting real time media.  As exactly this is where you trade low latency for an occasional dropout.
« Last Edit: December 09, 2019, 05:04:46 pm by Yansi »
 
The following users thanked this post: Siwastaja

Offline mansaxel

  • Super Contributor
  • ***
  • Posts: 3559
  • Country: se
  • SA0XLR
    • My very static home page
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #17 on: December 09, 2019, 08:40:06 pm »

No, you seem to get quite confused. TCP stack, or to say the TCP protocol, is what deals with packet loss and reordering for you. If you talk about TCP, these function are assumed. (Or just I don't understand your wording. There is no such "if you let it". TCP does it by itself)

UDP is what IS used for transporting real time media.  As exactly this is where you trade low latency for an occasional dropout.

There are, and here we're off on a tangent wrt the original subject, but there is something of value in here, so bear with me. If we're going to continue using the RTP model to discuss our sample transmission system, there are bits and pieces in place to handle packet reordering, to an extent.

When packets arrive, they are put in a buffer. You need to buffer ptime as a minumum; you in addition to that also need to buffer  PDVmax, that is the max packet delay variation you have.  When packets have arrived in the buffer, they are examined for time stamp and / or sequence number, depending whether you're doing AES67 or simply EBU Tech 3326, to take two examples. If a sequence of packets can be reassembled without gaps, the samples are played out. If a packet is missing, the time lost is known and skipped, more or less audibly, to keep the pace. A late packet is the most common case, where a packet arrives so late that it can't be played back but must be skipped. Longer reassembly buffers will help, but at the same time of course increase latency.
Quote from: mansaxel
    Today's story from the trenches: We're making a TV show of a little party in the town hall here tomorrow evening, with a bunch of scientists and a king, his family, plus lots of other people. We have two different AES 67 sender boxes for two microphones that are going to be used close together for interviews, and, we've normally run the receiving end in "syntonized" mode, where we trust the sample frequency to be right but not bother with the absolute time stamp, instead playing the sound back as soon as it arrives. That does not work well with several senders transmitting the same sound; there will be time delay comb filters and whatnot.  Adjusting the receive end to "synchronized" mode fixed the problem instantly: Now the receiver looks for the departure time and makes sure to playback the sounds synchronized according to time stamp and not as soon as possible.

And yes, a little bandwidth brag is in order:
Code: [Select]
sto-remhub-ro1>sh inte po49
Port-Channel49 is up, line protocol is up (connected)
  Hardware is Port-Channel, address is 985d.8299.da0e
  Description: REMOTE-CONNECTION
  Ethernet MTU 9214 bytes , BW 200000000 kbit
  Full-duplex, 200Gb/s
  Active members in this channel: 2
  ... Ethernet49/1 , Full-duplex, 100Gb/s
  ... Ethernet50/1 , Full-duplex, 100Gb/s
)
 8)

So, to get back on-topic; we can reconstruct the sample train in several ways, both using UDP and TCP, and as usual, there will be tradeoffs with both approaches, and none will be as straightforward as synchronous serial transmission is. But they have so many other advantages that going back to serial-only is rarely considered.

Offline max_torqueTopic starter

  • Super Contributor
  • ***
  • Posts: 1327
  • Country: gb
    • bitdynamics
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #18 on: December 09, 2019, 09:39:44 pm »
wow, that's a lot ot take in!  Thanks all!  I shall read and "Google" myself silly for a bit   :-DD


It's looking like the phaff from having a seperate hardware clock line to each sample might actually be a lot easier than trying to do something clever over ethernet!  Each slave could easily have a "clock in" and  "clock out" BMC connector and i could just daisy chain the clock down the line (the minor time delays due to different lengths of clock line shouldn't be an issue at just 10 KHz sampling)

 

Offline mansaxel

  • Super Contributor
  • ***
  • Posts: 3559
  • Country: se
  • SA0XLR
    • My very static home page
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #19 on: December 10, 2019, 05:21:36 am »
wow, that's a lot ot take in!  Thanks all!  I shall read and "Google" myself silly for a bit   :-DD

It indeed is! Especially when starting anew from scratch. Once you're in the middle of it, it sort of becomes natural.

It's looking like the phaff from having a separate hardware clock line to each sample might actually be a lot easier than trying to do something clever over ethernet!  Each slave could easily have a "clock in" and  "clock out" BMC connector and i could just daisy chain the clock down the line (the minor time delays due to different lengths of clock line shouldn't be an issue at just 10 KHz sampling)

The 200Gbit link i bragged about above is perhaps 15 kilometers, mostly from not going the straight route across town (there are two dark fibre pairs routed separate paths to keep redundancy against fiber cuts). Stringing along a hardware clock is suddenly less simple, not that we haven't wished we could a few times when PTP wasn't playing along...  :-DD

I'd be very cautious to take the plunge if it is a lab with everything within, say, 100 metres cable radius. Anything above that, separate hardware for sync transmission becomes very messy and expensive, and an integrated approach should be considered.

/Måns, did this trick over 600km WDM last week.

Offline max_torqueTopic starter

  • Super Contributor
  • ***
  • Posts: 1327
  • Country: gb
    • bitdynamics
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #20 on: December 10, 2019, 11:16:57 am »
As it stands, i don't currently actually have any known fixed distance between nodes, because the layout and packaging of the system isn't actually done yet, were still at concept stage.   All i know, roughly, is that each slave node will be in a 19" rack style box, in some, er, 19" racking (no suprise there!) so some nodes may be as little as 10cm from each other, but others may be (up to) 10's of meters away.  Right now, i can't see any situation where the total length of the network would be longer than something like 50m absolute maximum, so "easy" to wire.

As every slave node is going to have to route back to some form of ethernet switch / hub type arrangement, my current thought was to do a 1U 19" rack type module that sits next to a 19" rack ethernet switch, and that module does clock / sync and power distribution to a number of slave modules?

ie. here is a 24 port switch:



I'd do a "24 port" clock distribution and power module that would take in a clock signal and power (probably 24V DC) and have 24 sets of Clock (BMC) and Power (TBC) output terminals on the front, meaning it's an easy wire up job, just point to point with those cables, which can be bundled with the ethernet cable to each slave device.

One of those Clock/Pwr units could i guess also include the master clock that is then daisy chained out to everything else, if that unit is "smart" and also has an ethernet data link, then the sampling rate and sampling window can be software controlled by the master PC as well.  :-+




 

Offline mansaxel

  • Super Contributor
  • ***
  • Posts: 3559
  • Country: se
  • SA0XLR
    • My very static home page
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #21 on: December 10, 2019, 12:39:47 pm »
I'd say you want to do a 10MHz clock distribution, if you decide to go separate. And then instruct the end node over a command channel via Ethernet what to do in terms of sampling frequency. The master clock can then be anything from a simple function generator with a quartz crystal in up to a GPS receiver or even a Cæsium normal.

/Måns, borderline time-nut.

Offline dmills

  • Super Contributor
  • ***
  • Posts: 2093
  • Country: gb
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #22 on: December 10, 2019, 01:52:14 pm »
ALL broadcast engineers are borderline time nuts, comes with the territory.

My boss tells stories of conversations with Cisco when building out the first of the Timeline IP trucks that got 'interesting' on the fact that for this use TCP was right out and they could NOT drop UDP packets because their system wanted to take a port off line for a ms or so to run self tests..... Also on the fact that just adding more buffer to the switch was not a viable fix.

Fun fact, when HFT was just getting going, one of the IT network switch vendors bought a SDI router vendor to find out how to do it in a time sensitive manner, now broadcast buys the switches the HFT guys use.
 

Offline max_torqueTopic starter

  • Super Contributor
  • ***
  • Posts: 1327
  • Country: gb
    • bitdynamics
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #23 on: December 10, 2019, 04:22:14 pm »
I'd say you want to do a 10MHz clock distribution, if you decide to go separate. And then instruct the end node over a command channel via Ethernet what to do in terms of sampling frequency. The master clock can then be anything from a simple function generator with a quartz crystal in up to a GPS receiver or even a Cæsium normal.

/Måns, borderline time-nut.

I don't think there is much margin in going that high, as we will never be sampling at anything approaching that rate.   Perhaps a clock in the low hundreds of kHz would make sense, and would enable simple hardware for the slower sampling slaves (like the ones that read temperature sensors that only need to be sampled at a couple of Hz.  Driving the clock line could be interesting, maybe some from of LVDS could work and be simple / cheap.  If we were really showing off we'd push the clock data over the power lines.......     :-/O
 

Online Yansi

  • Super Contributor
  • ***
  • Posts: 3930
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: syncronise multiple ADCs over an Ethernet network?
« Reply #24 on: December 10, 2019, 05:17:24 pm »
10MHz is what is the de-facto instrumentation standard, that can be interface to almost any existing instruments.

Either word-clock (sampling rate) shall be provided directly or a common 10MHz reference to all, that'd be used to derive sampling frequency.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf