Electronics > Projects, Designs, and Technical Stuff
Distributed Data Acquisition Scheme
<< < (3/4) > >>
sokoloff:
I can't help but think of the "X Y Problem" when reading this thread.
nctnico:

--- Quote from: Evan.Cornell on November 10, 2018, 02:22:05 pm ---I'm not looking for off-the-shelf solutions, this is to integrate together pieces of a solution that already exist. It seems like multiple RS485 links for the clock and data lines may be the way to go, especially if I can ensure that all connecting cables are of equal length.

Timing tolerance should be within one bit-clock, so all data lines are synchronous. If we have 192kHz sample rate (for instance), and assume that two data paths are TDM'd on one data pin, then that yields bit clock of 12.288MHz (period = 81.38ns). So the allowable jitter/skew is going to depend on setup/hold times of the serial interface on the main processor board. Looks like I need to do some timing analysis to determine if the RS485 scheme would work reliably.

--- End quote ---
This is much harder to achieve than you think. The solution I know about about uses the White Rabbit time & frequency protocol developed by CERN. CERN has developed White Rabbit for exactly the same reason you want to develop something new: synchronising data acquisition in a distributed network of sensors.
David Hess:
So 10 to 15 meters in length, 2 channels of 192kHz (audio) sample rate for a bit rate of 12.288MHz (81.38ns), and simultaneous sampling?  That seems pretty straightforward with one complication.

Each board needs a 12.288MHz outgoing clock from the master, a strobe to control sampling and framing, and any data lines if required; some ADCs only require the strobe/framing signal.  RS-485 would work but so would a number of other digital transmission standards including logic with some care.

The complication is that cables have a delay of roughly 5 nanoseconds/meter which produces a round trip delay of 100 to 150 nanoseconds compromising the relationship between the 12.288MHz (81.38ns) outgoing clock and returning data.  A source synchronous returning clock and framing signal solves this and is probably the easiest way.  There are some transmission schemes which include clock and framing like asynchronous serial saving two returning signals.
Evan.Cornell:
I see the point of round-trip prop. delay complicating a direct usage of bit & frame sync clocks. What is method to create returning clock and frame-sync on all remote boards that will ensure rough synchronization, assuming all cables are same length?

I took a quick look at the White Rabbit solution, which seems to be built on top of AVB / TSN ethernet backbone. As I posted previously, I would prefer a primarily hardware-based solution, mostly for development time purposes.
ajb:
If the only purpose of the clock is to time your samples, then it doesn't matter as much.  Your central controller can simply send out a sample clock pulse, the remote devices take whatever measurement, and then they can send back the result asynchronously.  You could even use a UART, as long as you have enough headroom to frame it somehow (break signal, 32->40 bit encoding or something).  I'm assuming you have an MCU at each node, but you haven't specified whether that's the case or not, so I think others have different assumptions.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod