is ad2cp bottomTrack being read correctly?

[dankelley]

This issue is to track the addition of bottomTrack to read.adp.ad2cp(). (See a slew of other ad2cp-related issues if you want more context, #1980 in particular.)

As of 6073ac1ef95c2a259e087f0befe8efd9e7a3ef41 of the "ad2cp" branch, I am storing both pre-vectorization and post-vectorization results in the same part of the (@data$bottomTrack). The post-vectorization items are (at this moment) saved in @data$bottomTrack$NEWbottomTrack. Things mostly agree, and I certainly trust the NEW stuff more than the old stuff, so very soon I'll just trash the old stuff and have things in @data$bottomTrack, which is where they ought to be.

The test file I've been looking at so far is in tests/testthat/local_data/ad2cp/S102791A002_Barrow_v2.ad2cp within this repo. It represents readings taken whilst the instrument was in the case, and this makes interpretation a bit tricky. For example, I read bottomTrack$v values that are of order 10m/s. That seems a bit odd for an instrument in the case, so perhaps I'm reading it incorrectly.

Some further insight might be gained by looking at time dependence, and the code

library(oce)
file<-"~/git/oce/tests/testthat/local_data/ad2cp/S102791A002_Barrow_v2.ad2cp"
d <- read.adp.ad2cp(file, from=1, to=300, by=1)
v <- d@data$bottomTrack$v
par(mfrow=c(2,2), mar=c(3,3,1,1),mgp=c(2,0.7,0))
for (i in 1:4) plot(v[,i], ylab=paste0("v[,",i,"]"),type="l")

[dankelley]

To try to get some context, I looked at the IMOS toolbox (https://github.com/aodn/imos-toolbox/blob/e19c8c604cd062a7212cdedafe11436209336ba5/Parser/readAD2CPBinary.m#L558) for reading ad2cp files.

I think the IMOS code has an error, because it reads 2 bytes for ambiguity-velocity, whereas the Nortek docs (Nortek 2017 page 61, second from bottom of page) say that this is 4 bytes. Unless I'm mistaken, a further complication is that IMOS is erroneous in other things that are read after that spot.

[dankelley]

For fun, I plotted each of the 4 bottom-track velocity values against each other, making as below. I also tried some experiments of offsetting the byte index by -2,-1,+1, and +2, and all yielded very high speeds (tens of km per second). So, I don't know what the heck the numbers mean, but I don't have any reason to think I'm reading the bytes incorrectly.

[dankelley]

I'm going to go ahead and close this. At some point, perhaps a user (not me) will raise a similar issue, but then we will have somebody with knowledge of what to expect, plus likely nortek software to get data we can use to test our code.