| Electronics > Projects, Designs, and Technical Stuff |
| Distributed Data Acquisition Scheme |
| (1/4) > >> |
| Evan.Cornell:
Here's the setup: * Central controller/processor (clock master) * 2-5 sensor boards (connected to central processor board by undetermined cable of up to 10-15m length The central processor would produce clock signal(s) that need to get distributed to each of the sensor boards, and those clock(s) would result in data being transmitted back from each sensor board to the central processor. The idea is to have all sensor data synchronized and simultaneously sampled. I saw some material about Automotive Audio Bus from Analog Devices that may do all this well, but it looks like it's behind an NDA-wall, and availability probably isn't great, since this wouldn't be a high-volume automotive application. That then led me to SerDes, but it seems like I'd have to have two channels to each sensor board, one for outgoing clock(s) and one for incoming data. Another option could be Precision Time Protocol (PTP) via Ethernet links, but I'm leaning towards a more hardware-based solution. Each board may or may not have it's own power source (ultimately battery-powered, but could consider powering the sensor boards over Coax lines). Any other thoughts on a clever solution? |
| ajb:
What's your expected maximum data rate and what is your allowable skew between sensors? I would probably start with RS485, which works nicely over Cat5 cable, so you can have one cable carrying a clock pair, a data pair, and possibly power on the other two pairs. The data link can be half duplex or simplex depending on whether or not the master needs to configure the sensors, and you can daisy chain from sensor to sensor if you want. A single decent size MCU should easily get you up to 8 UARTs, so the master can just sit there sending out clock pulses and absorbing the data from the sensors and then doing whatever you need with it (throw it onto an SD card? Forward it over USB/Ethernet?). |
| sokoloff:
If your measurements are small, I'd consider CANBus for this. You can send a CAN message (received by all devices at once), have each node take a measurement and report its measurement back over CAN using different CAN IDs. CAN will take care of the hardware collision-detection/avoidance and message integrity, though you can help out a bit by randomizing or scheduling the timing offset. Primary downside of CAN is that it's not a particularly high-bandwidth solution and each message packet is small in terms of payload. |
| Evan.Cornell:
So each sensor board would have 8 data lines, 2 clock pairs (bit clock & frame sync). The data lines could be daisy-chained to reduce quantity to 4. Sample rate for individual data line is somewhere between 96 and 192kHz. Assume 32 bit per sample. Measurements could be of long duration (at least several minutes at a time), so think continuous data stream to a recorder (either to local memory or packaged up and sent from processor board over network). RS485 as the physical layer is a good idea, although perhaps with multiple cat5.. cabling is TBD. Any concerns about clock/data synchronicity if the cable lengths are different (say one cable is ~1m, one is 15m)? |
| max_torque:
Without specifying the sampling rate, data bandwidth and maximum allowable jitter, it's tricky to suggest a suitable solution. If your requirements are modest, then each slave module can just sample continuously, and the master can ask from the latest data at the appropriate moment over the serial link. Simultaneous sampling is really pretty pointless unless you have a significant requirement to do so (driven by the thing you are sampling changing very fast) |
| Navigation |
| Message Index |
| Next page |