Ethernet Acquisition Device - 'Standard' Ethernet Interface?

[David]

Hello all,

I am starting to outline a new project comprising of an AD7768 (8 channel, 24-bit ADC - assuming max sample rate for now) with an Ethernet interface (ideally though a microcontroller using DMA to internally buffer samples, or could be through an FPGA if the data rates get a little tricky).

Software is not really my forte! What I am looking for is a 'standard' in which data can be streamed over ethernet to a host PC (windows/linux) without me having to re-invent the wheel. Does such a thing exist? I would perhaps liken it to USB classes (HID, serial etc). I want to do anything I can to reduce the amount of software overhead on the project. I assume samples will be buffered in a ping-pong style (2 buffers) and then read over ethernet when data is available but as I say I'd rather not re-invent the wheel if I don't have to.

EDIT: Another option I've not ruled out is using something like a Xilinx Zynq running Linux as this may give me more flexibility for future features...

[guenthert]

   There are ways to connect Ethernet to a MCU (WIZnet comes to mind).  Unless it's a mass produced device where bean counters do count pennies (BOM and hence better are willing to spend more on development), I would stay away from such and rather connect the sensor(s) either directly (I2C/SPI/1-Wire) or via MCU (connected via USB or UART/proprietary protocol) to a single board (imho better called "open frame") computer like Raspberry Pi or Beagle Bone (Blue, Green, Black, whatever) as that *greatly* simplifies the software side (a secure, reliable TCP/IP stack is no small feat and its development costs shouldn't be underestimated).  A MCU connected to the Internet using an ad-hoc TCP/IP stack is IMHO a liability.

[fchk]

You may have a look at RTP:
https://en.wikipedia.org/wiki/Real-time_Transport_Protocol

RTP is a protocol for transmitting streaming data in a realtime fashion. It is the foundation of almost every audio/video transmission.
RTP and RTCP use UDP, and UDP is fairly easy to implement even without a full-blown stack. You need UDP, IP, parts of ICMP and ARP. That's it.

[GeorgeCh]

Hi,
   Take a look at https://en.wikipedia.org/wiki/XCP_(protocol)

   If you are using a SOC/FPGA running  Linux, Vector offers a free implementation: https://github.com/vectorgrp/XCPlite  . I've used it with rPi, works great.
   And to measure the data: https://github.com/danielhrisca/asammdf albeit with some modifications.

Hope this helps,
   George

[ajb]

AD7768 (8 channel, 24-bit ADC - assuming max sample rate for now)

So 256Ksps * 24b = 6.1Mbps, that isn't too crazy.

Is the host PC on the same local network?

As far as protocol, if you have control over both ends of the connection, then the simplest solution would be to just pack sample data into a UDP datagram and send it off.  Maybe add a small header with a sequence number (so receiver can identify lost/reordered packets), and some sort of identifying tag.  Anything else is going to be more complicated and involve some amount of overhead that you may not need if this is just a one-to-one system, even if it's a prepackaged library someone else already wrote for you.  If this will be part of a larger ecosystem, then a standardized protocol becomes more attractive.  Of course the device needs to know where to send those datagrams to, simplest solution would be a hardcoded destination IP, which could be a broadcast/multicast address. 

(ideally though a microcontroller using DMA to internally buffer samples, or could be through an FPGA if the data rates get a little tricky)

Generally the Ethernet MAC built into an MCU is already going to use DMA for handling transmit/receive.  Once an ethernet frame is assembled in a buffer somewhere, you pass the address and size of the buffer to the MAC and off it goes.  Depending on the data format, you may be able to use DMA to transfer the sample data directly from the ADC into that buffer, then you only need to write in the appropriate header data before sending it off, which would be very efficient.  How easy it is to arrange that also depends on the software stack used.  I know LWIP supports zero-copy drivers with the correct pbuf configuration, but I don't know if the various MCU libraries and vendor frameworks are designed to support that.  That being said, it won't be hard to find an MCU that can handle a 6Mbps stream without a zero-copy eth driver or DMA for the ADC. 

[Nominal Animal]

project comprising of an AD7768 (8 channel, 24-bit ADC - assuming max sample rate for now)

Per the datasheet (PDF), that would be 24 bits × 8 channels × 256,000 samples per second = 49,152,000 bits per second, or 6,144,000 bytes per second (for the AD7768BSTZ for example).  This is about half the theoretical 100 Base-T Ethernet bandwidth, so both standard 100 Base-T (100 Mbits/s theoretical) and USB 2.0 High Speed (480 Mbits/s theoretical) will work.

The SPI interface uses 32 bits per sample, typically a 32.768 MHz clock, with either each ADC having their own data line (octal data), four ADCs sharing a data line (dual data); with a single data line you cannot reach 256 kS/s on all eight channels because 32×8×256000=65,536,000 > 32,768,000.

(Without converting the incoming 32-bit data to 24-bit, the data rate is 65,536,000 bits per second = 8,192,000 bytes per second.)

I'm only a hobbyist, but I'd definitely first try a Teensy 4.1 (with Ethernet kit and 8MB PSRAM), if not for anything else then for quick prototyping and verification (at quite low cost).  The Teensyduino add-on to Arduino makes for very rapid development; I like it even if I don't much like Arduino in general.  Teensy 4.x has an NXP i.MX RT1062 Cortex-M7 core, which runs at 600 MHz (without overclocking), and my tests indicate I can easily sustain 200,000,000+ bits per second (three times the bandwidth needed here) from a Teensy 4.x to a Linux computer using only simple USB 2.0 serial (standard USB CDC-ACM, no drivers needed in Linux/Android/MacOS).  I'd use three SPI buses, two slave for the data (sharing the clock line, DCLK), and one SPI master for the control, so that data is received via DMA.  The 8 MB PSRAM can be used as a cache, in case you use a standard UDP protocol with resend/acknowledge responses (to groups of 1.5k data packets), which would make the receive side on the host computer a standard network application that requires no special privileges.

I personally prefer the High-Speed USB, perhaps isolated from the host using Analog Devices' ADuM3165/3166/4165/4165 or TI ISOUSB211 isolator (with a separate isolated power source for the acquisition side), because I really don't like the existing IP stacks – NativeEthernet or QNEthernet – and the standard USB Serial would well suffice here.  In that case, Teensy 4.0 would suffice.  SPI1(3) (CS=0, SCK=27, DI=1 or 26) and SPI2(1) (CS=36, SCK=37, DI=34 or 35; these are pads on the bottom side) would be used for the data, and SPI(4) (CS=10, SCK=13, MOSI/DO=11, MISO/DI=12) would be used for control.  Note that if you isolate the AD7768 instead, you can use TI ISO7740 and ISO7741 for the isolation; the 32.768MHz rate is no problem at all.

(Apologies to those who are fed up with Teensy being brought up.  In my defence, only the separate bootloader chip and board files are proprietary, and PJRC will even sell preprogrammed bootloader chips if one wants to make their own variants that can be programmed using Teensyduino+Arduino; and other than the SWD/JTAG pins being taken by that chip, one has full control over the i.MX RT1062 chip, so even bare metal programming is easily done – since the bootloader is on a separate chip, you don't need a bootloader in your own code.  Other members here have used the same boards for testing the i.MX RT106x MCUs before making proper designs of their own.)