Sunday, June 2, 2019

Flight to compare yaw and acceleration; data gremlins

I did another flight in N291DR to compare yaw and acceleration, this time with a sensitive and high quality accelerometer that I was able to borrow from a friend. The data is in this directory in our repo.

The setup was similar to what we've done before, except I also had a nice Jeremy-display installed and showing the data as well, in addition to the data logging PC strapped into the seat with an old bicycle innertube as a bungee cord (note patch where the tube was repaired, likely more than once):




The sad part is -- the data is not usable. It seems there is a pretty significant transmission delay in the data from the probe. (I am doing bench testing of this right now and will report back -- preliminary results are that the pain is real.)

Of course, delays in data transmission are a Big Deal [tm] for an instrument like ours, so now would be, like, not a bad time to figure them out. It's not just about data acquisition!

In the graph below, you can see the angle of yaw (beta) in blue, and the lateral acceleration in green. I'm sure you can agree there is no causal way that the angle of yaw can respond to a sideslip 3 seconds after the airplane has started accelerating sideways.... At least not in the physics I was taught, but then again that was a while ago....

2 comments :

  1. 3 seconds sounds extremely high for an artifact of data transmission. From my experience with audio/SDR I wonder if it might a problem like this: the logger is taking one sample from the probe and one from the accelerometer, pairing them up, and logging them together. But the two data sources have different clocks and therefore different sampling rates even if you configure them identically, so you will see increasing time difference the longer the system is on (until a buffer fills up and you start dropping samples).

    I don't mean to blame specifically the logging apparatus, necessarily: any part of the system that is receiving samples and expecting/requiring them to be available at a specific rate not actually locked to the rate at which they are generated can cause this problem.

    ReplyDelete
    Replies
    1. Thank you for the note! So ... the way we are doing it is, *both* data sources are being received on the PC and timestamped on arrival with the PC's clock. So we are using one clock to determine relative arrival times, and physical events that are supposed to be simultaneous in the data.

      Delete