Re: Transformation matrix issues.

Hi there,

I've come across something curious when processing some data recently and I'm not really sure where I've gone wrong.  We have two HR Aquadopps (with  the sideways 90 degree head) mounted next to each other on a moving profiler with one instrument pointing upwards and one pointing downwards.    They are both operating in burst mode and recording in beam coordinates.  The upwards one has a shorter pulse distance and hence larger wrapping velocity so I've been trying to compare velocities from the two to unwrap the downwards looking one (and I've got some code which should work well except for the issue here).  

Firstly I've been transforming the velocities into instrument (xyz) coordinates.  Now if I were to use the same transformation matrix for each - this would presumably just reverse the directions of the y and z axes of the downwards looking instrument - hence the need to switch the sign on the bottom two rows of the transformation matrix (just taken from the header file).  This also follows the transformation code that is posted on this forum.   This should then give me two lots of velocities in the same coordinate system for comparison.  The x and y-velocities look good -- they track pretty well with larger velocities near the surface as expected but the z-velocities are oppositely signed?  If I don't change the sign of the rows in the transformation matrix - I get what I'd expect in the y (velocities are flipped) but then the z-velocities match well.

Here's some psuedo code showing what I've done...

 Tmat_up=[6461 -3232 -3232; 0 -5596 5596;1506 1506 1506]/4096;

xyz_upwards=Tmat_up*beamvels_up   % Rotate upwards looking AD to xyz coords

Tmat_down=Tmat_up;

Tmat_down(2, = -Tmat_down(2,;        % Instrument flipped so change sign of y and z vels.

Tmat_down(3, = -Tmat_down(3,;

xyz_downwards=Tmat_down*beamvels_down   % Rotate downwards looking AD to same coordinate system

I've attached some plots showing the velocities from the two instruments from the rangebins nearest each other (just ignore the outliers/wrapped velocites)...  Any ideas what I'm missing?!

Cheers,

Julia

Here's another plot showing what happens if I don't flip the rows in the transformation matrix.. y-velocities are oppositely signed as expected but the z-velocities appear to line up.  I mostly include this as the data is very noisy and this makes it easier to tell the z-velocities seems to line up...

p.s.  in the above actually  is    :   )  It's a good thing matlab doesn't have emoticons!

p.p.s  100kb is a very small limit for attachments!

Dear Julia, I am struggling to see what is happening with vertical oscillations.  Can you blow up a section of the fig11.jpg?

Best regards, Atle Lohrmann

Hi Atle,

We've finally finished our fieldwork so I've had time to return to looking at this issue.  Anyway I have resolved a few things:

1.  It is not a transformation matrix issue (which came as somewhat of a relief as I was pretty sure my code was right in this case).

2.  It's a timing issue - which brings up a whole lot of different questions so here goes:

I can't actually find the exact same example I sent above so here's another one.  As above, in this case we had an upward and downward looking aquadopp next to each other mounted on a frame on a small boat.  I've rotated the velocities into ENU coordinates and fig 1 shows a section of the vertical velocities  (the horizontal red band shows the gap between the upper and lower profiles).  As you can see we have waves but they appear oppositely signed in the top and the bottom (hence me thinking it might have been an up-down transformation mistake). I added the black vertical lines as a guide for the eye.  However, if you look at fig 2 which shows the pressures (I've played around a bit with the vertical offsets) you can see there's a timing offset.  I've shifted the downward looking aquadopp along by 5 points and then they match well (see fig 3).  (8Hz sampling rate, 5 points=0.625s which is identical to what I get as a shift from the pressure cross-spectra as well as by eye.  Putting this timing offset into the vertical velocities fixes the alignment there also.

The pressure sensors on the instruments were no more than 10-15 cm apart so it can't be a real timeshift we were measuring.

So my question is therefore - how can we get such a large (0.5s) time error?  When I set up the instruments - I followed the procedure:

1.  Connect upward looking Aquadopp, load dep file, set to start at some time. I click 'yes' for setting the clock to computer time. Disconnect

2.  Repeat for downwards looking instrument. Set to start at the same time and sync the clock.

I always used the same computer and the instruments would have been set up no more than minute or two apart.  The only thing I can think of is that the errors were somehow introduced by the syncing, but I can't believe a computer clock would drift that much that quickly.

More to come on another related question to these timing issues below...

Regards,

Julia

Here's the second figure

... and the third.

Hi,

In another experiment - we are comparing Aquadopp and Vector data with data obtained from a video.  For our analyses, it's important that we can correct for any time differences between data from the different sources and we had no way of syncing the internal video clock directly from a computer.  Before and after the experiment -- we used the online data collection (for both instruments) and took a video recording of the status screen.  The idea being we can compare the time stamp from the video recording (which is imprinted onto the tape) and the timestamp from the instruments online data screen.  In this case we didn't ever reset the instruments to the computer clock.  So my question is - is the time stamp on the screen the same as the instrument, i.e. does the second on the display tick over exactly when the instrument thinks it does or is there a small offset?  Preliminary analysis has indicated that the second changes every 30th frame on the video (which is expected - given it was recording at 30 frames/s).

Regards,

Julia

Dear Julia

The Real Time Clock (RTC) in our instrument has a resolution of 1 second.  When setting the RTC, the software sets it to the nearest second when you set it to the PC clock.  Hence, the clock may be up to 0.5 second off.  This is an offset though, so it is possible to correct for it -as you have done. To find the offset value you need to use the stop deployment command. Before the actual deployment, start a deployment that you stop directly after. The software will then report the offset between the Aquadopp RTC and the PC clock in milliseconds.

When you retrieve the instrument, the software will report the time difference again. If you make sure the PC clock to GPS time, you will then see how much the Aquadopp clock has drifted (typical value is less than 1 second/week). A first order correction of the drift in the Aquadopp would be to distribute the drift evenly throughout the measurement period. Provided that the temperature of the Aquadopp does not change too much during the measurement, the final time scale of you measurement will probably be quite good. 

Best regards, Atle Lohrmann