Bench testing transmission delay

I set up a simple experiment: I taped the USB accelerometer to the probe, and recorded data for a long time. Every once in a while, I whapped one of the holes of the probe, thus creating a shock that should be simultaneous in pressure and acceleration. I plotted the results. Here is a typical result:

Clearly there is some sort of delay. It is not the 3 second delay we saw in the flight data, but it's definitely something suspicious. My next steps are to try different combinations of serial connections to the probe to see if that will change things.

I am tempted to just jack up the baud rate on the XBee, and indeed that should be the first thing I try, but at the moment I'm just trying to get a sense of the problem.

In both cases -- the accelerometer and the probe -- I am using the Boost asio::serial_port library to open the serial port on the Linux host.

As an aside, here is the sensor zero drift over a period of about 30 hours. The zero reading went from -132 Pa to about -92 Pa, a change of about 40 Pa. This is a +/- 30 in. H2O sensor, in other words, +/- 7473 Pa. The change of 40 Pa is 0.27% of sensor full scale. The total zero offset at the start, -123 Pa,  is about 0.88% of sensor full scale. This sensor is sensor ID 5 from the data in our Git repo.

We are sending approximately 50 bytes at 20 Hz, which comes to about 8000 bits per second. This is on link configured for 9600 baud. Clearly we are near the limit of our 9600 baud link. But the delay of 0.8 seconds implies there's a buffer of approximately (0.8 seconds * 50 bytes/msg * 20 msgs/second) = 800 bytes somewhere, and honestly nowhere in the transmitting side (ATMega chip or XBee) does there exist such a large buffer.

We need to do more testing, under more controlled conditions. Stay tuned.