Ethernet Shield Transfer Rate

I have 4 sensors connected to arduino (an accelerometer, a gyro, a magnetometer and a sonar), I would like to receive updates from these at a rate of 100 hz and update 4 ESCs connected at the same rate. No calculation will be done on the arduino all it has to do is pool and send the data back to the pc where motor speeds will be calculated and send back.

Arduino will be directly connected to the pc ( no switch router etc..) and I plan on using a binary protocol over UDP (like firmata) since all data received will be position data packet loss isn't all that important.

There are conflicting posts concerning the speed of the ethernet shield, so my question is can this be achieved using ethernet shield? if not what would be the highest frequency I could achieve?

Arduino will be directly connected to the pc

There are conflicting posts concerning the speed of the ethernet shield, so my question is can this be achieved using ethernet shield?

If you are connecting the Arduino to the PC directly, why do you need an ethernet shield?

I will be using serial pins on the arduino to read from another serial device and pass that to the pc, also I am assuming ethernet will be faster than usb over serial, am I wrong?

Ethernet adds a lib to your sketch (bigger), another level of omplexity, it uses at least 4 pins etc. On the other hand you can connect to "any server" on the internet not only the PC nearby. A wireless shield gives even other degrees of freedom. e.g. running an Arduino sketch on your lawmower.

Serial over USB goes up to 115200 baud (windows PC) or approx 10.000 bytes per second. So how much bytes is generated by one reading of all 4 sensors? Are all sensors read with the same frequency? If that is less than say 80 bytes it should be possible to use Serial.

robtillaart, serial pins are in use, I am using them to read from another serial device, in your point of view do I get faster transfer via ethernet or USB?

You could use the library NewSoftSerial to get second serial port.

About thoughput: Ethernet is faster in theory, the ethernetshield has a 100Mbit connection. BUT (there is always a but) as the Arduino itself is only 16 Mhz the datarate achieveable is much lower. and restricted (ao) by the SPI bus between Arduino and ethershield. http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1287138565 states on a good day ethernet can reach approx 5K/second. I cannot confirm as I never tested it. Ethernet has more overhead than a serial protocol, especially when sending small packets. Furthermore one can use UDP or TCP , the first has a higher throughput, the second has handshakes and is more reliable. Finally the network latency of ethernet packets is in the order of 1 - 10 msec. To get maximum throughput from ethernet use big packets to minimize overhead, but that means less frequent packets.

So in the end I expect serial to be faster.

Rob "In theory there is no difference between theory and practice, but in practice there is"

When sending 100 times per second a bunch of data you might consider a compression scheme:

Example: if you must send a temperature (e.g. -10.12 ) over the line one can send its absolute value again and again. -10.1 -10.1 -10.2 -10.0 -9.5 That means at least 5 bytes per time. You can compress this by sending the absolute value once per minute and only the delta per second. resulting in A-10.1 // added an A to imply absolute value 0 -0.1 0.2 0.5 .. A-8.0 // new reference time

Another way to compress is leaving values out if they are the same. Example four values via a comma separated line: 10.12 , 25 , 14.2, SW 10.12 , 25 , 14.3, SW 10.12 , 26 , 14.3, SW

would become

10.12 , 25 , 14.2, SW ,,14.3, // note spaces are stripped too ,26,,

again much less data to transport, be sure to send a reference line once per 50 (fill in your favo number) lines or so.

And most important form of compression is to send only that amount of data you need (can/will process) on the other side.

Rob

I have read/thought about NewSoftSerial, but the docs says it is limited to 9600 boud I'll be receiving packets at a rate of 57600 boud, thats why I decided not to use it.

Assuming each of my packets will be 4 bytes, is there a way to calculate theoretically how much data I can pass back and forth using both USB/Ethernet(UDP)?

Rule of thumb: To send one byte over a serial one needs 10 bits (startbit - data - stopbit).

So if you have 4 bytes to send you need 40 bits per packet. You want to do this 110 times a second makes 4000 bits per second. 9600 Baud can carry 9600 bits per second in theory so it should be fast enough.

So if I use 115200 boud according to what you said, 10 bits per byte 100 times a second I can get 115200 / 1000 which is equal to 115 bytes per second or 115 chars per second?

I think your dimensional analysis is a bit off...

115200[bit/sec]/10[bits/byte]=11520[bytes/sec]

then using your assumption of 4 bytes/packet 11520[bytes/sec]/4[bytes/packet]=2855 [packets/sec]

However I'm guessing the 4 bytes you are talking about is the payload of your packet, so you will have to add any framing and protocol bytes to the 4 and recalculate.

or to go about this from the other direction, you are looking to send 100 [packets/sec]*4[bytes/packet]=400[bytes/sec]

yielding 400[bytes/sec]*10[bits/byte]=4000[bits/sec]

so, if you are correct about your 4 bytes/packet assumption, you have plenty of throughput, but I suspect you will require more than that...

Rule of thumb: To send one byte over a serial one needs 10 bits (startbit - data - stopbit).

And to send one byte over ethernet takes approximately 500 bits, and has a lot more overhead to set up than sending the byte to a serial port :-) (but you don't actually have to send all those bits from the AVR, because the wiznet will make some of them for you.)

But seriously, ethernet is not a great choice for 4-byte packets. You'll be limited more by the packet rate than the datarate, and on small implementations of TCP/UDP/etc getting a high throughput tends to require a large packet size.

For those interested in the details of Ethernet framing and overhead see http://sd.wareonearth.com/~phil/net/overhead/.