Goals and initial questions

[tjcrone]

Here are what I see as our initial technical data processing goals. Please feel free to comment and adjust as we dig into this deeper.

High-level Goals:

1. Build a real-world position vector for the Nortek ADV.
2. Build a real-world vertical velocity vector.
3. Project the SBE3 data onto the vertical velocity, or vice versa.
4. Integrate to obtain a time-averaged estimate of vertical heat flux.

Initial Questions:

1. How do we incorporate the GX3-25 data? What are the fields?
2. How do we incorporate the Paros pressure data?
3. How do we best coregister vertical velocity and temperature for the integration?
4. Is there any value to gridding our data?

[dehann]

Got it and agree, sounds like a good plan.

How do we incorporate the GX3-25 data?

I would suggest starting without GX3, and build the vectors from Sentry Nav directly and get the full pipeline working first. We can then recover ADV to Sentry motion using the GX3.

What are the fields?

GX3 values of interest are accelerations and rotation rates. I will have a deeper look at the attitude heading estimate the Gx3-25 produced during the dive, but that solution will be way less accurate than the one already available on Sentry.

How do we incorporate the Paros pressure data?

I did not look at Paros when computing the ADV motion relative to Sentry. There is a short and long answer to this. i.) Long answer is full SLAM (simultaneous localization and mapping), which I would like to do anyway, but want to avoid being side tracked.
ii.) Short answer is to filter the Sentry + ADV navigation solution with Paros on depth. This should help resolve vertical position / velocity.

My suggestion is to branch the solutions. First do Sentry only lever-arm transform to the ADV. Then either filter with GX3, or filter with Paros. Once both work, we can look at doing both.

As a second priority I will start work on the full SLAM approach.

How do we best coregister vertical velocity and temperature for the integration?

Timestamping is the general method. If the clocks differ, then a first order fit towards one common clock is a good method. The processes is rather manual, using human eyes to sanity check the time alignment process. By iterating an existing navigation solution and carefully modifying one slave clock alignment parameter at a time, it is relatively easy to find an "expectation maximization" alignment result. Labour intensive, and best done towards the end of the data processing phase.

There might be some value in understanding the hysteresis of the thermometer and compensating for that too.

Is there any value to gridding our data?

I likely only do this if we have many "outliers", but will keep it in mind during analysis.