Ambiguity Velocity Calculation

Up to Velocimeters - single point

Ambiguity Velocity Calculation

Posted by Christopher Esposito at June 02. 2010

Hello All,

 

I have some Vector data that was taken in conditions with higher velocity than I had anticipated, and so I am now trying to unwrap my velocities in order to get usable data.  To do this I need to calculate my ambiguity velocity.  The Pulse Coherent Primer gives the equation Vamb = c/(2(36*lag)), but I do not know what my lag is.  I can get my c from the .sen file, but as far as I can tell, the  lag is nowhere to be found.

I am also concerned that my data is currently in ENU coordinates.  The Vector was stationary while taking measurements, but was sometimes horizontal and sometimes vertical.  Will the inverse of the transformation matrix given in the .hdr file take me back to beam coordinates so that I can unwrap the velocities from there?

 

Any help is appreciated.  My .hdr file is attached for reference.

 

-Christopher Esposito

University Of New Orleans

Attachments

Re: Ambiguity Velocity Calculation

Posted by P.J. Rusello at June 03. 2010

Hi Chris,

First to the transforms. You'll need to transform from ENU to beam coordinates which requires accounting for pitch, roll and heading. I don't think I gave all the details for this in the Pulse Coherent Primer, but you can find the basic calculations in this m-file: 

http://www.nortek-as.com/lib/forum-attachments/coordinate-transformation/view

You can also find a very good explanation of how the transformation matrix is formed and modified by pitch, roll, and heading in the following paper if you want to understand where all the math is coming from (note that it is for a 4 beam system):

http://journals.ametsoc.org/doi/abs/10.1175/1520-0426%281990%29007%3C0019%3AHRMOTV%3E2.0.CO%3B2

Finally, there are quite a few topics on the forum regarding coordinate transforms and various issues that may come up if you run into problems. Watch out for the orientation of the instrument (up or down) since it's changing from horizontal to vertical as this will affect the signs of rows 2&3 in the transformation matrix. You'll also potentially run into an issue (depending on how the tilt sensor was installed) of your pitch, roll and heading not being reliable when the pressure case is either horizontal or vertical since the tilt sensor is installed expecting the pressure case mounted in only one of those positions.

 

As for ambiguity velocity, the vertical velocity range reported in the deployment configuration dialogue can be used to correct the velocities once you've handled the above transformation.

 

P.J.

Re: Ambiguity Velocity Calculation

Posted by Christopher Esposito at June 04. 2010

Thanks Peter.

 

Just to make sure:  I asked the instrument to give me ENU coordinates.  Are these the only ones that were recorded, or were beam coordinates written somewhere too? 

 

I knew that the data from the horizontal configuration would not be oriented, but I did not think that I would lose the beam velocities entirely.  This is important because I was sampling at 32Hz, but the tilt and roll sensors sample at 1Hz.  I hate to think that I could lose information so easily, especially since that lost information could invalidate some of my data, because all I have is ENU coordinates, which won't be valid when the instrument was horizontal. 

 

And I'm still a little confused about what to use as the ambiguity velocity.  You said that I should use only the vertical velocity range from the deployment configuration dialogue.  There is a number for horizontal velocity range as well.  Does that number not matter? 

 

 

-Chris

Re: Ambiguity Velocity Calculation

Posted by P.J. Rusello at June 05. 2010

>Just to make sure:  I asked the instrument to give me ENU coordinates.  Are these the only ones that were recorded, or were beam coordinates written >somewhere too? 

 Yes, only ENU velocities were recorded.

 

>I knew that the data from the horizontal configuration would not be oriented, but I did not think that I would lose the beam velocities entirely.  This is >important because I was sampling at 32Hz, but the tilt and roll sensors sample at 1Hz.  I hate to think that I could lose information so easily, especially >since that lost information could invalidate some of my data, because all I have is ENU coordinates, which won't be valid when the instrument was >horizontal. 

 You haven't lost any data as the various transforms are all still perfectly valid (that's just some math). What I wanted you to be aware of (and you seem to be) was that your ENU velocities when the instrument was horizontal won't be valid ENU velocities because the instrument's heading, pitch and roll would not be accurately measured.

The Vector uses the 1 Hz attitude data to transform a group of 32 velocity samples in your setup, so when you do the transform just match your attitude measurements to the appropriate 32 sample section of velocity data.

>And I'm still a little confused about what to use as the ambiguity velocity.  You said that I should use only the vertical velocity range from the deployment >configuration dialogue.  There is a number for horizontal velocity range as well.  Does that number not matter? 

The horizontal velocity range is the projection of the beam ambiguity velocity onto the horizontal coordinate plane. If I remember correctly, the math is a little more complicated than just doing a dot product to obtain this, but that's the basic idea. It is reported because most of us don't think in terms of beam velocities for a flow.
 
I recommend only dealing with phase unwrapping in beam velocities because that is where the phase wrapping actually occurs. You could try to correct XYZ or ENU velocities, but it gives me a headache to even think about how to go about this. So, deal with phase wrapping/ambiguity issues in beam coordinates, and estimate your ambiguity velocity from the vertical velocity range reported in the deployment configuration.
 
P.J.

Powered by Ploneboard
Document Actions
Log in


Forgot your password?
New user?