syncronise multiple ADCs over an Ethernet network? - Page 1
Forum section: electronics / projects

author: max_torque
author_rank: Super Contributor
timestamp: December 08, 2019, 06:12:26 pm
content: 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 wait2) 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 sampled3) Each slave buffers it's data until ready to send a network packet containing that data, then sends that data4) 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)

author: FenTiger
author_rank: Regular Contributor
timestamp: December 08, 2019, 06:39:44 pm
content: 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...

author: Yansi
author_rank: Super Contributor
timestamp: December 08, 2019, 06:42:49 pm
content: 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.

author: voltsandjolts
author_rank: Unknown
timestamp: December 08, 2019, 08:27:22 pm
content: 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.pdfhttps://cds.cern.ch/record/592719/files/p63.pdf

author: pardo-bsso
author_rank: Frequent Contributor
timestamp: December 09, 2019, 12:24:46 am
content: There's also White Rabbit.How much are you willing to spend?

author: OldEE
author_rank: Contributor
timestamp: December 09, 2019, 02:45:14 am
content: 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

author: mansaxel
author_rank: Super Contributor
timestamp: December 09, 2019, 05:58:24 am
content: Quote from: OldEE on December 09, 2019, 02:45:14 amAngry broadcast network engineer bolierplate:Dante is a bad, proprietary protocol that interops badly with grown-up systems. Youcan'troute 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. YouWILLhave 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 packetsthat can travel over Ethernet, and make things routable. Not repeating the Dante debacle. Oh, andforget TCP. It's too slow.Youneed PTP. Aim for default 1588-2008 profile if at all possible.You will need aPTP 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, doinghardware time stamping. PTP4L (Linux) is compatible with at least the Intel cards, I believe.The measurement and data gathering nodes will need agood hardware clock, so they have something that can be steered by PTP.You will need aGrand 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 wrotetimestampsabove, 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.

author: FenTiger
author_rank: Regular Contributor
timestamp: December 09, 2019, 08:40:19 am
content: 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.

author: mansaxel
author_rank: Super Contributor
timestamp: December 09, 2019, 09:35:16 am
content: 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 ana priorisample 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.Naturally, we refused, and presented the resultant graphs from Doing The Right Thing.

author: Yansi
author_rank: Super Contributor
timestamp: December 09, 2019, 10:16:54 am
content: Quote from: OldEE on December 09, 2019, 02:45:14 amHow 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.

author: Yansi
author_rank: Super Contributor
timestamp: December 09, 2019, 10:24:42 am
content: 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.Seehttps://tools.ietf.org/html/rfc3550for 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/

author: mansaxel
author_rank: Super Contributor
timestamp: December 09, 2019, 10:53:32 am
content: Quote from: Yansi on December 09, 2019, 10:24:42 amI 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.Quote from: Yansi on December 09, 2019, 10:24:42 amThe 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.

author: rstofer
author_rank: Super Contributor
timestamp: December 09, 2019, 04:00:07 pm
content: Quote from: FenTiger on December 09, 2019, 08:40:19 amAt 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.

author: FenTiger
author_rank: Regular Contributor
timestamp: December 09, 2019, 04:13:35 pm
content: 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.)

author: Yansi
author_rank: Super Contributor
timestamp: December 09, 2019, 04:31:03 pm
content: Quote from: rstofer on December 09, 2019, 04:00:07 pmTCP is a high level protocol used to NOT get out of order or missing packets. You probably meant UDP/IP.

author: rstofer
author_rank: Super Contributor
timestamp: December 09, 2019, 04:46:28 pm
content: Quote from: Yansi on December 09, 2019, 04:31:03 pmIf 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.

author: Yansi
author_rank: Super Contributor
timestamp: December 09, 2019, 04:52:44 pm
content: Quote from: rstofer on December 09, 2019, 04:46:28 pmNo, 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.

author: mansaxel
author_rank: Super Contributor
timestamp: December 09, 2019, 08:40:06 pm
content: Quote from: Yansi on December 09, 2019, 04:52:44 pmThere 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 bufferptimeas a minumum; you in addition to that also need to bufferPDVmax, 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: mansaxelSo, 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.

author: max_torque
author_rank: Super Contributor
timestamp: December 09, 2019, 09:39:44 pm
content: wow, that's a lot ot take in! Thanks all! I shall read and "Google" myself silly for a bitIt'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)

author: mansaxel
author_rank: Super Contributor
timestamp: December 10, 2019, 05:21:36 am
content: Quote from: max_torque on December 09, 2019, 09:39:44 pmIt indeed is! Especially when starting anew from scratch. Once you're in the middle of it, it sort of becomes natural.Quote from: max_torque on December 09, 2019, 09:39:44 pmThe 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...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.

author: max_torque
author_rank: Super Contributor
timestamp: December 10, 2019, 11:16:57 am
content: 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.

author: mansaxel
author_rank: Super Contributor
timestamp: December 10, 2019, 12:39:47 pm
content: 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.

author: dmills
author_rank: Super Contributor
timestamp: December 10, 2019, 01:52:14 pm
content: 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.

author: max_torque
author_rank: Super Contributor
timestamp: December 10, 2019, 04:22:14 pm
content: Quote from: mansaxel on December 10, 2019, 12:39:47 pmI 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.......

author: Yansi
author_rank: Super Contributor
timestamp: December 10, 2019, 05:17:24 pm
content: 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.

author: mansaxel
author_rank: Super Contributor
timestamp: December 10, 2019, 09:06:47 pm
content: Quote from: Yansi on December 10, 2019, 05:17:24 pmExactly, 10MHz can be had from so many sources, and there is distribution hardware that satisfies very tight phase relationship requirements, many measurement devices can consume 10MHz, et c.

author: jbb
author_rank: Super Contributor
timestamp: December 11, 2019, 02:38:08 am
content: Do you need every sample delivered? Or is missing the occasional sample OK?To open up a completely new front, EtherCAT might be a contender. It’s an industrial Ethernet thing, where the slaves each have 2 ports and daisy-chain off each other. No fancy switch required. If using hardware space drivers (highly recommended), it’s got highly deterministic latency and each additional slave adds only 1.2us latency to the chain.Pretty good (< 300ns if using a hardware timing master and hardware slaves) clock distribution is built in and can do regular timing.We ran an EtherCAT system for the backbone of a megawatt class power conveyer with 100us command cycle timing.

author: Yansi
author_rank: Super Contributor
timestamp: December 11, 2019, 10:23:59 am
content: QuoteHaha... Either very specialized EtherCAT driver IC, or an FPGA with lot of work to make it work.Bute sure, this could work too.You have just moved the fanciness from a simple PTP aware switch to a completely new level

author: jbb
author_rank: Super Contributor
timestamp: December 11, 2019, 10:30:42 am
content: Oi. I said no fancyswitchrequired.The slaves (especially the timing master which objects timing information) are a bit fancy. We used an FPGA with licensed core from Beckhoff. The license was eye-wateringlh expensive. But I think TI offers ARM chips now with EtherCAT hardware.Actually, I’m being a bit thick. I think Analog Devices have a new series of “A2B” chips for distributing audio over twister pair in a car. Maybe some of that stuff could be repurposed?

author: max_torque
author_rank: Super Contributor
timestamp: December 11, 2019, 08:42:41 pm
content: Ethercat is (probably) out because of the cost / complexity.We have looked at just buying a suitable DAQ system off-the-shelf, and one of the options was a Beckhoff based Ethercat system, and the costs skyrocket (compared to basic home grown ethernet connected slaves) and the hardware becomes non optimum in terms of it's physical layout (ie mostly din rail mounted I/O without suitable environmental sealing, as our system needs to work in a reasonably harsh environment)We are going to have to do a trade-off analysis between the various options, currently the least understood part is the master software that is going to bring all this data together under one roof so to speak, option shere range from DIY home grown software, up to National Instruments based Labview/Veristand etc.Although the home grown option is by far the most work, it offers the most flexibility, but realsitically we will probably plump for something of a halfway house, buying the component parts we can buy, and developing the rest

author: nctnico
author_rank: Super Contributor
timestamp: December 11, 2019, 08:59:40 pm
content: Quote from: FenTiger on December 08, 2019, 06:39:44 pmFor PtP for work well you need to use fiber ethernet connections and you'll need special add-on hardware which can synchronise to PtP to get a reasonable accuracy. Also PtP will lose accuracy if you pump a lot of data over the network.The most simple way is to distribute TOD (over RS485), 1PPS and 10MHz over seperate wiring (using a distribution amplifier) and timestamp the data using that. Once the data is timestamped it doesn't matter how long it takes to travel over ethernet. If more accuracy and/or longer distances are required then using White Rabbit switches is the only option to stay below 1us of jitter (typically White Rabbit can transfer time with <1ns jitter over hundreds of kilometers when calibrated). For example CERN uses White Rabbit to synchronise test equipment used for the LHC.

author: dmills
author_rank: Super Contributor
timestamp: December 11, 2019, 10:35:19 pm
content: Not been my experience with PTP at all, 1Gb/s with PTP aware switches and correctly configured traffic prioritisation and EEE turned off and I see a few hundred ns over multiple nodes even over copper and with several hundred Mb/s of other data running, go to 10 or 100Gb/s fabric and things get better again.Sure you need to configure the gear correctly and having switches with PTP clock capability helps a lot, but sub microsecond is EASY!Regards, Dan.

author: nctnico
author_rank: Super Contributor
timestamp: December 11, 2019, 10:46:27 pm
content: But did you do long term (days, weeks) testing with PtP using continuous monitoring? I have access to such data and have seen PtP misbehave. PtP can get upset quite easely so you need to have a good (expensive) local oscillator which is tracking the PtP slowly to average the excesses (and perhaps throw away large time jumps). Putting switches in between and using copper connections doesn't help to improve PtP synchronisation because in the end PtP still relies on packet delays. For example: copper PHYs also have internal packet buffering and re-synchronisation. This can easely add 100ns or more of time assymetry.All in all a system will be much more stable if you can distribute the time over wires directly.

author: Yansi
author_rank: Super Contributor
timestamp: December 12, 2019, 12:08:04 am
content: Quote from: nctnico on December 11, 2019, 08:59:40 pmNo, unless you try to sync for timenut nonsense precision. .. which more then likely is not required here, neither for generic audio applications.

author: OldEE
author_rank: Contributor
timestamp: December 12, 2019, 03:12:24 am
content: Hi gang.Thank you for the follow up to my mention of Dante. I learned a lot from all you fine folks.Also I misspoke about routing Dante. What we actually did was to extend the Dante VLAN to another switch.That was a glitch in the brain to keyboard link.Larry

author: nctnico
author_rank: Super Contributor
timestamp: December 12, 2019, 08:59:30 am
content: Quote from: Yansi on December 12, 2019, 12:08:04 amThe point is that PtP can be accurate but the achieved accuracy will depend on many IFs. If the system the OP wants to build is intended for a local installation then distributing time directly is a much more cost effective and reliable solution.

author: mansaxel
author_rank: Super Contributor
timestamp: December 12, 2019, 01:34:24 pm
content: Quote from: nctnico on December 11, 2019, 08:59:40 pmThe medium is irrelevant, as long as it is a cable. I have lots of end nodes connected via copper, and they behave just nicely.The special hardware, yes. The switch needs to be talking PTP, anything else is an invitation to headache. Network cards in end nodes also need to support PTP.If you have PTP support in the switch and end nodes, you can go near flatline full on the link without much problems. If you do not prioritize or otherwise handle the PTP traffic as important (and having a switch that is boundary clock is, in my experience, by orders of magnitude the best way to do it.), you will have problems at everything above say 40% load.

author: Evan.Cornell
author_rank: Regular Contributor
timestamp: December 12, 2019, 09:38:52 pm
content: Quote from: jbb on December 11, 2019, 10:30:42 amUn-obtainium for small guys.. they've got all the good info behind NDA-walls. I was looking at this for a multi-drop data acquisition system (several nodes to one main board via 10m cables), but ended up going with individual point-to-point SerDes links instead (DS90UA101-Q1 & DS90UA102-Q1 from TI).

author: Yansi
author_rank: Super Contributor
timestamp: December 12, 2019, 09:46:14 pm
content: Audio over twisted pair, like what? AES3? (AES/EBU aka professional SPDIF) - that's long known, no need for special chips for that.DIT4192 and DIR9001 to the rescue.(or any generic FPGA or even MCU these days)...For multi-channel, there is the long known MADI over coax or SFP. Not a twisted pair, but certainly could be pushed throuch any kind of physical medium, including twisted pair. Note, that Soundcraft, those freaking bastards, use a RJ45 ports in between their mixing desks and stage boxes and call it "MADI". How the hell can one call that MADI? Especially, when there runs also some RS485/422 withing the same cable to control the stage box. Why, Soundcraft, why calling that MADI?!

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: December 12, 2019, 09:59:03 pm
content: If this is a dedicated network whose sole purpose is to control/communicate with these devices and not to download torrents and video streams from Netflix and youtube at the same time, I don't think he needs anymore than broadcast packets to synchronize/trigger the ADC conversions and a single UDP packet to transmit the samples back to the controller. IOW the clock signal are the broadcast packets. The smallest enet packet payload is fifty something bytes more than plenty enough to send a sample with a timestamp and more, back to the controller. Any switch can do that, even the cheapest ones are fast enough nowadays, and there won't be any dropped packets nor much jitter in a switched network that's being used well below the ports traffic limits.

author: mansaxel
author_rank: Super Contributor
timestamp: December 12, 2019, 10:57:16 pm
content: One question, that I certainly missed to ask, is:We understand that sampling needs to be precise in frequency and phase (ie wall clock, relative). That is one thing. Another important part is: Is there a requirement to transmit the samples back to data storage/treatment immediately or can it be buffered? Because, with a lot of the discussed solutions, that is two different problems, and they might deserve different treatment. They can be related, but must not be so. If you can wait a little bit for the data to arrive, (you will have to anyway, to some extent, but if there is some additional leeway here) the system becomes a lot easier to build. And, clocking it is perhaps better done, then, as a separate system, leaving the Ethernet to be a very simple bulk transfer system.Just a reality check, here.