This week I did lots more testing and debugging, and gave my final presentation to the group!
Ethernet vs Serial
The supposedly “different” issues I identified last week (Arduino data looks like garbage without the instrumentation amplifier; the Ethernet and Serial data don’t match) ended up being caused by the same problem.
Last week I thought the crappy data was caused by sampling too fast — it turns out that was not the case! I was rather relieved to find that the entire project wasn’t a failure… Phew!
I decided to test various variables to see what was the cause. My first thought was perhaps packets were being dropped, which could explain the blips in the Ethernet data vs Serial. While experimenting, I saw things like this:
I was packing the voltage readings into UDP packets that were 8KB in size, which is permissible. The MTU for Ethernet, though, is around 1500 bytes. My packets were getting fragmented into smaller chunks. Seems reasonable… yet the fragmented packets did not have the correct flags set when examined with Wireshark. It turns out that the W5100 chip does not support IP fragmentation. It’s even listed on the datasheet (page 5) as a feature. Awesome.
I verified this was the problem by instead making UDP packets that were around 1000 bytes in size. This data looked fine!
[ Who wins the bet, then? 🙂 ]
So… given that I had to limit my UDP packets to be < 1500 bytes, how much would the overall sampling rate and throughput suffer? The answer surprised me: not at all. I decreased the UDP packet size to around 1200 bytes, benchmarked, and got the same speed as before.
This means that now I could redo the sine wave test and get data that didn’t look like garbage. It also made me think about the DAQ vs Arduino test I did a few weeks ago — if the same thing was happening then, and I don’t see why it wouldn’t be, redoing this test would also improve the Arduino results. Unfortunately, Shane had already packed up the computer I tested this on, so it was impossible to redo this test. ):
I worked on the slides for my final presentation and presented on Wednesday over Google Hangout.
Sine wave test
The goal of this test was to more thoroughly compare the Arduino data to the DAQ. I would generate a sine wave on the signal generator, match the Arduino and DAQ’s sampling rates as before, and capture with both at once.
I would then strip the DAQ’s data of 6 bits of precision — the DAQ has a 16-bit ADC and the Arduino’s is 10-bit. I would compute an initial alignment and shift one of the traces over so they were aligned. The final step would be to align each 1-second chunk of data and compute the sum of squared differences.
Here is a chart of the results. The units for the third column are 1/35635 of a second.
|Chunk number||SSD||Shifted by|
Here is the last aligned segment, calculated by my code’s reported offset, to verify that my code worked (green = arduino, blue = daq. Unfortunately, it seems that the Arduino sine wave has a slightly larger amplitude):
Some observations about the data:
– The SSD generally decreases for each subsequent chunk, and the offset increases. A possible explanation is that because of the larger amplitude in the Arduino sine wave, they are initially aligned well but become less and less aligned as time goes by, and must be shifted more in order to be aligned again.
– When I shift one of the traces to try aligning it, I use circshift, since there doesn’t seem to be a non-circular shift in Matlab. I must delete the data that “wrapped around” back to the front of the time series. Thus, the larger the shift, the more data is cut off, and the less data there is to compute SSD with. This may explain why the SSD decreases for each chunk.
– What does this really tell us about how similar they are? I’m not sure how to evaluate SSD… The highest SSD I got was around 60. Is that good? I’m not sure. One thing I learned is that for some reason, the Arduino sine wave has a larger amplitude. This is something to investigate further.
Arduino vs DAQ test: redo
I couldn’t completely redo this test, even though I would have liked to, given that I fixed the issue with the Ethernet sending code.
I could, however, strip the DAQ data of 6 bits of precision like I did for the sine wave test, and then re-run the data through Weka. [updated] Here are the results:
There doesn’t seem to be much difference between these two sets of results. This leads me to believe that the differences in performance between the DAQ and the Arduino are rather as a result of 1. the packet fragmentation bug I fixed, 2. noise from the instrumentation amplifier.
I guess this is the end of my summer at SPQR. Thanks to everyone for making this such a memorable experience 🙂 I had a lot of fun!