Unrealistic vertical velocities with 2MHz ADCP
Dear all,
We have an ADCP Aquadopp Nortek 2MHz. We had it for more than 2 years installed on the bottom of a shallow bay (6m depth) pointing upwards.
We have some questions related to unrealistic vertical velocities. We are not especially interested in the up velocity (actually we would expect up velocity to be under the detection limit of the ADCP) but instead we get extremely high values, mostly at the surface, although they can appear down at 3 m depth also. Also we only get ONLY negative values of the up velocity. Since the other EN components are calculated the same way we were wondering if they are trustable. All data looks pretty noisy.
We have different configurations but we get the same problem in all of them. The plot i send you has a profile interval of 3600s but we get the same problem with intervals of 300s. We also thought about the cell size (0.1m) that could be too small and increase the error but even when we used 0.25m we had the same problem. Below I attach header file of the data we plot so you could check the configuration we used.
Also below i print the BEAM2ENU transformation we used, for if you think the problem could lay here, I copied them from somewhere of the Nortek forum and updated the transformation matrix to our instrument.
Has anybody
found a similar problem??
Is the vertical velocity wrong or all of them are wrong??
%Transformation matrix from Aquadorpp Nortek
T = [6461 -3232 -3232 ; 0 -5596 5596 ; 1506 1506 1506];
T = T/4096;
hh = pi * (heading-90)/180;
%%%%%%% E N U Cordinates
H = [cos(hh) sin(hh) 0 ; -sin(hh) cos(hh) 0 ; 0 0 1];
R = H*T;
u_east = R(1,1)*ADCP.v1 + R(1,2)*ADCP.v2 +R(1,3)*ADCP.v3;
u_north = R(2,1)*ADCP.v1 + R(2,2)*ADCP.v2 +R(2,3)*ADCP.v3;
u_up = R(3,1)*ADCP.v1 + R(3,2)*ADCP.v2 +R(3,3)*ADCP.v3;
Information on the header file:
User setup
---------------------------------------------------------------------
Profile interval 3600 sec
Number of cells 55
Cell size 10 cm
Average interval 3600 sec
Measurement load 9 %
Transmit pulse length 0.11 m
Blanking distance 0.10 m
Compass update rate 3600 sec
Distance measurements DISABLED
Wave measurements DISABLED
Wave - Powerlevel LOW
Wave - Interval 21600 sec
Wave - Number of samples 1024
Wave - Sampling rate 1 Hz
Wave - Cell size 1.00 m
Analog input 1 NONE
Analog input 2 NONE
Powerlevel HIGH-
Coordinate system BEAM
Sound speed MEASURED
Salinity 35.0 ppt
Distance between pings 10.36 m
Number of beams 3
Number of pings per burst 2
Software version 1.27
Deployment name Juliol
Wrap mode OFF
Deployment time 08/07/29 11:00:00
Comments N/A
Hardware configuration
---------------------------------------------------------------------
Serial number AQD 2433
Internal code version 13
Revision number 60
Recorder size 161 MByte
Firmware version 1.15
Velocity range HIGH
Head configuration
---------------------------------------------------------------------
Pressure sensor YES
Compass YES
Tilt sensor YES
System 1 1
System 1 0
Head frequency 2000 kHz
Serial number AQP 2223
Transformation matrix 6461 -3232 -3232
0 -5596 5596
1506 1506 1506
Pressure sensor calibration 0 0 3882 23911
Number of beams 3
System5 25 25 25 0
System7 -17617 -1718 11159 279
-17760 1595 11169 -106
System8 0 0 -1
0 1 0
1 0 0
System9 0 0 -1
0 -1 0
-1 0 0
System10 0 -1 1 0
System11 0 -1 -1 0
System13 11847 18809 19217 26822
System14 -18449 842 11606 -50
-18364 684 11709 -68
System15 32755 0 -166 0
32767 -413 0 0
32767 -30 38 0
0 0 0 0
System16 0 0 0 0
System17 5461
System18 3600
System19 3600
System20 10000
Dear Mireia Lara
There are a few different ways you can generate vertical velocities with an Aquadopp profiler:
a) If one or more of the beams is covered (fully or partially). In this case you will also have errors in the horizontal components. Normally you can detect interference in one or more beams by looking at the amplitude data. If the amplitude is smoothly decaying from the transducer toward the surface/bottom, you can normally rule out interference. if you measure the same vertical velocity in all beams you can also rule out interference
b) Errors in the tilt/roll/compass. If, for some reason, the tilt sensors are not working correctly or the tilt/roll has been switched, you will generate an apparent vertical velocity that varies with the absolute magnitude of the flow (and possibly the flow direction). In your case, I can see that the vertical velocity varies quite a bit over time so this is a candidate explanation
c) We have also seen cases a few cases where there is a small but fixed offset in the Doppler estimate of the order 1-2 cm/s. This is especially true for very small cells (and you are using 10 cm cells). The offset is the same for all beams so it will not affect the horizontal velocity estimate, only the vertical velocity.
Best regards, Atle Lohrmann
Hi Alte,
From what you said i think we are in case B since for all the datasets our vertical velocities do vary with the magnitude of the flow specially when this magnitude is big. But i didn't quite understood the explanation.
Since we have the Aquadop moored we are not using tilt transformation for beam data although we do have the peach and roll data from the sensors. I already tried to apply this transformation, and as expected it doesn't change the result, only really slight changes in velocity components.
- If there is a problem with the tilt sensors, how could we solve it...i mean, can they be turned off?
- And again if this is the problem we would only have it in the vertical, not in the horizontal components, right?
Also what you say in C could be happening, but our offset would be more than one order of magnitude higher than 2 cm/s, so maybe it's not the case. Regarding this point we just realised that our problem disappears when we use 50 cm cells, then vertical velocities look much more relaistic. Could it be a cell size effect?
I discarded A because it's a consistent thing we had it for more than 3 years and we always have this problem,and also amplitude data seems ok.
Thanks for the answer!
Mireia Lara
Hi again
Maybe you have both b) and c).
My understanding is that you have collected data in beam coordinates and that you are doing the coordinate transform in the post processing? As you may have seen from the forum, the definition of the Y-axis changes sign depending on whether the instrument points up or down. The reason for this change is to maintain a right-handed XYZ coordinate system and thereby be able to use only one transform from XYZ to ENU. Is it possible that this is an issue in your case?
Best regards, Atle Lohrmann
Hi,
Yes you are right, we collected the data in BEAM coordinates and we used the transformation that you passed me, I printed the lines on the first post.
Since our Aquadopp is mounted on a support and installed on the bottom of the bay pointing upwards, I understand it is on the UP direction, then statusbit=0 and thus we don't need to change the sign of the Yaxis. Is that right?
Since we are pointing up we are NOT using this sign change in the script.
-----Lines from the code--------------------------------------------
% If instrument is pointing down (bit 0 in status equal to 1)
% rows 2 and 3 must change sign
% NOTE: For the Vector the instrument is defined to be in
% the UP orientation when the communication cable
% end of the canister is on the top of the canister, ie when
% the probe is pointing down.
% For the other instruments that are used vertically, the UP
% orientation is defined to be when the head is on the upper
% side of the canister.
if statusbit0 == 1,
T(2,
= -T(2,
;
T(3,
= -T(3,
;
end
---------------------------------------------------------------------------------
Regards,
Mireia Lara
It all looks to be quite correct. Is there any chance you could send me the data file? I may not be able to do much but at least you can have an independent eye look at the transforms. The place to put the data is here : ftp://ftp.nortek-as.com/Incoming/
Regards, Atle
Dear Alte,
Thanks for taking the time, we would really appreciate to know if we are doing the conversion good.
I put on the ftp a file, (juliol09.prf), it's not the same I atached on the first post but it has exactly the same configuration and the same problem.
The reason i'm sending you this one is because in the same file there is a period with "low" amplitude and a period in the middle with really high amplitude values.
I realised looking at the complete time series that the unrealistic high up velocities are more apparent when LOWER, although not low, amplitude velocities are detected throughout the water column. In extrem cases, with really low amplitude we can also see an effect on the horizontal components but the vertical component seems more sensible.
Could this be the reason?
If it is, which would be the minimum amplitude to obtain good quality horizontal components?
I'm ataching the plot of this file so you would be able to check the transforms.
thank you for everything.
Best regards,
Mireia
Dear Mireia,
Sorry about the delay.
I think your diagnose is a good one. This instrument has got a noise floor of 25 counts. A rule of thumb threshold for returned signal strength for a 2MHz profiler is 6 counts above the noise floor, in this example 31 counts.
From the file sent, I see that the next highest power level is chosen. You will most likely get the full range if you increase this.
Best regards
Jonas Røstad
_____________________________________________________________________________________________________________________________
6 counts = 3dB * 0.5 dB/counts
3dB is a rule of thumb SNR threshold
0.5 dB/counts is the relation between the units for a 2MHz Aquadopp Profiler
If i understood correctly what you said, we should start having problems with velocities whenever amplitude is smaller than 31 counts or 15.5dB.
But according to the attached plot it looks like the treshold is higher in our data.
To show you that i atacch a plot that corresponds to the period with the highest amplitude detected on our data series, so the errors in the vertical velocity are small. Nevertheless if we go to detail for example for cell 44 (arround 1m depth). We get that always when under 50 counts we have up velocity problems. I say up velocity but i think its equal to the horizontal velocities, but since they fluctuate at a different scale we cannot see the effect on the plot. So I think our problems start under 50 counts which would correspond to 25dB.
1) 1) Is this possible or is there something wrong with our instrument that it needs such a high signal to produce good data?
2) Anyway given this threshold,should we just erase velocity estimates whenever the amplitude drops under this value?And we should do that for all components, I mean both horizontal and vertical components, right?
I remark for the future that we should always use HIGH power in that site.
I just wanted to note that we run our data through the Nortek software, (CMtool v1.0) which does a quality control based on the backscatter amplitude and SNR, and the data passed pretty good, specially the files with power level set to high- and high+. For example, for the file i send you and corresponding to the plots of the previous post (juliol09.jpg), the cell 44 only had errors in 2%of the data, although our problms are in almost 40% of the data. So it didn’t help much.
And the last question, we have technical note from Nortek that details the sensitivity of the instrument regarding the size of the particles. It indicates that the optimal sensitivity of 3MHz and 1MHz instruments is, respectively, for 160μm and 320 µm size particles so i deduce for our 2MHz Aquadopp the sensitivity will be between this values arround 200um. ( Nortek Tehcnical Note No.: 003, Title: Monitoring Sediment Concentration with acoustic backscattering instruments , Last Edited: October 15, 2001, Author: Atle Lohrmann, Nortek AS ,No. of Pages: 5)
3) Where can we find more detailed information of which sensitivity the 2MHz Aquadopp has? since its such an important parameter for our velocity estimations we would like to be able to predict when and where we can have enough backscatter to use the Aquadopp.
Many thanks for all the clues!
Mireia
NOTE: by Mean Amplitude in the figure, I used the mean of the amplitude of the 3 beams which are pretty similar in trend.
Dear Mireia,
The 3dB above noise floor (31 counts for your instrument) threshold is a rule of thumb. In some conditions this is conservative, others liberal.
Remember that you need to look at the signal strength of all three beams and do the limitation based upon the beam with lowest amplitude.
Up velocity in your data series is the vertical velocity.
1) I don't think there is anything wrong with this instrument.
2) When the signal strength is too low all velocity estimates should be ignored (at least evaluated very closely).
3) I think the paper you mention is the best source available. There are some discussions in this forum as well worth looking at.
CMtool is a free, but unsupported software. To be honest I do not know to much about it. What I do know is that making a QC software purely based upon signal strength isn't too easy. Parameters like vertical velocity and deviation between profiles and between cells should be taken in account.
In addition to raising to power level, I would recommend you to speak with your local sales representative about using HR firmware for this application.
Please tell me if there are uncertainties.
Best regards
Jonas

