Theo, K, Bob and Andrew tried the first of tests of Ethernet latency from the FC to the new STM32 development boards.
Summary: 50 - 100 us of unidirectional latency. Yay!
Test 1: ping times
We ping'd the STM32 development boards from the FC. We did 1,000 pings at 100 ms between pings, and we got this:
1000 packets transmitted, 1000 received, 0% packet loss, time 99899ms rtt min/avg/max/mdev = 0.285/0.289/0.351/0.014 ms
So a round trip time of 289 -4/+62 us - that's 144 us one way, which is pretty darn OK with us given that's just ping times and no optimization has really been done on the FC or the stm32 side of things.
Here's the raw data: fc-to-stm32-ping-log.txt
Test 2: FC -> STM32 times
Theo wrote a small C program to fire off a 'U' on the FC's serial port (/dev/ttyS1) and then immediately fire off an Ethernet packet to the STM32 dev board. Then the dev board pulled a GPIO line low. So from the starting edge of the 'U' on the serial port to the falling edge of the GPIO gave us a rough measure of latency. There's all sorts of problems with this, but it's a great first try.
We would have some great hard data here, but unfortunately we're Ethernet n00bs so we could only fire it off roughly once a second or so. What we saw was ~ 50 us min to ~ 100 us max of latency. Picture attached, where blue is the FC serial port, yellow is the stm32 GPIO, and the cursors show the difference between event times. In this measurement, we got 76.6 us between events, which was pretty typical.
- Write a program to interrupt the STM32 on a GPIO, send a packet, receive it on the FC, send a response back, and then toggle a GPIO port. This demonstrates the entire sensor -> FC -> actuator data flow. We should also experiment with RT thread priorities and whatnot here, and use a tool like
cpuburnto demonstrate that we reliably get data with low latencies despite whatever the cores are doing.
- Move the ADIS to a stm32 and start streaming data that way.