interpolation of heading

[callumrollo]

Heading of the seaexplorer is recorded at a lower temporal resolution than science sensors, approx. 20 seconds between measurements. Current solution is to interpolate onto the timebase of the science sensors. This could cause some unintended results when glider is heading around north, e.g. interpolation of 180 between two values of 355 and 005.

There must be a smart way to fix this. Maybe using deg2rad and some kind of normalisation?

[richardsc]

Good point. I've handled this kind of thing in the past by searching for large jumps, and then adding (or subtracting) 180 degrees before interpolating. Not sure if that would work here.

Another option is to just hold the measured heading during the 20s period, only updating when a new value is measured.

[callumrollo]

Yeah, I'm thinking some kind of nearest neighbour method, rather than the currrent linear interpolation, might be a better solution to resampling the nav data to science data. This could also make it clearer to the end user that the high apparent sampling rate or pitch, roll, heading is just an artefact of processing

[richardsc]

Yes I agree. Better to keep things closer to what was measured than make up a whole bunch of new data. The nav depths that get recorded in the payload files are similar -- the nav-measured depths are just repeated on the payload timebase until a new measurement is available.

[jklymak]

One way to interpolate headings is to interpolate cos head and sin head. That will interpolate across the jumps correctly