does IMOS read AD2CP bottom-track incorrectly?

Introduction

I have been working to add support for AD2CP data to the "oce" package in the R language. I am not sure I am reading bottom-track data correctly (see e.g. dankelley/oce#1982), and a websearch turned up the IMOS package. Although I am not a matlab user anymore, I think I can understand your code, and I think there may be an error in it.

Possible IMOS Error

At

imos-toolbox/Parser/readAD2CPBinary.m

Line 558 in e19c8c6

    
           sect.Data.AmbiguityVel      = bytecast(data(idx+52:idx+53), 'L', 'uint16', cpuEndianness); % 10^(Velocity scaling) m/s ; corrected for sound velocity

I see that ambiguity velocity is being read as a two-byte (unint16) value. However, my understanding is that it ought to be 4 bytes for bottom-track data (in contrast to other data types, which are 2 bytes). If I am correct in my interpretation, then velocity, etc. may be inferred incorrectly by IMOS (see e.g.

imos-toolbox/Parser/readAD2CPBinary.m

Line 569 in e19c8c6

off = 75;

for the offset used for velocity), and that is why I am writing today. Hopefully, I am wrong, or at least if I'm right, perhaps this can lead to an adjustment to the IMOS code.

My sources for the 4-byte nature of ambiguity-velocity (for bottom-track, not other types) are as follows.

Page 61 of Nortek (2017), as shown in the first snapshot below.
Page 94 of Nortek (2022), as shown in the second snapshot below.

References

Nortek AS. “Signature Integration 55|250|500|1000kHz (2017).” Nortek AS,
2017.
https://www.nortekgroup.com/assets/software/N3015-007-Integrators-Guide-AD2CP_1018.pdf.
Nortek AS. “Signature Integration 55|250|500|1000kHz (2022).” Nortek AS,
March 31, 2022.

Snapshot 1 (2017 manual)

Snapshot 2 (2022 manual)

Hi @dankelley thank you for lodging your issue, and please note it has been forwarded on to the appropriate staff to investigate. once they have had a chance to look at it we will get back to you. Warm regards, Kate

@dankelley Thanks a lot for your feedback, I've been taking over the maintenance of the toolbox, unfortunately I don't have access to a signature file with bottom tracking to do some testing. Any chance you could upload one? cheers

@lbesnard sorry, I don't have one I can share.

Almost all the datasets I use in oce development come from users, who wish that they remain private until publication is complete. In lots of cases, the data are being used in thesis work, which makes the timescale long. I imagine IMOS is similar in this respect.

In an ideal world, instrument manufacturers would provide sample datasets (and even perhaps plots of their data) but I guess that's not our world, for most manufactureres.

Actually @dankelley, I think that we do have a file with bottom track. Note, that this was a bench test, so the data are completely meaningless, but the data structures should be in there.

S102791A002_Barrow_v2.ad2cp.zip

I feel like I have had an example file from Nortek that used bottom track ... at least, an example of using the bottom track to do ice tracking. I'll see if I can find that, or alternatively I might ping Nortek support to send it along again.

thanks @richardsc for the test file. I just put a PR to fix this
https://github.com/aodn/imos-toolbox/pull/794/files

from my understanding, we've never had bottom tracking files within IMOS, so the parser was probably a work in progress and actually never got used.

@richardsc Do you mind if I include your test file in our unittest?

Not at all! It's just a bench test so the data is completely meaningless, but at least the data structures are there.

closing, fix is here: #794