velocity shift

PJ,

Prashanth and I have been working together with the V II. I've been collecting data and he has been plotting it. I think I found why the profiles do not match up as closely as we expected. I found abrupt shifts in the velocities while collecting data. I've attached a short portion of one of the files I collected. For about the first two minutes the velocity is bouncing between 16 to 19 cm/s. At about the 2 minute mark the velocity shifts to 6cm/s and remains there for the next two minutes. At the four minute mark the velocity just as abruptly shifts back up 17cm/s and remains there until I stopped recording, a total of about six minutes. I'm repeating measurements I made with the V I, that velocity was found to be around 17 or 18 cm/s

While the data was collecting I would walk away from the PC after 10 or 20 seconds so I never noticed this shift. Once I noticed, I started watching very carefully and when a shift like this happened, I stopped data collection and started over. After doing this my profiles collapsed on to each other as I was hoping they would. Do you know of anyone else noticing this?

The flow field is very boring, uniform sand bed, no obstructions or waves, 12m long flume 91cm wide, velocity measured at the center line about 7m from the front of the flume. 8.5cm depth. Total discharge is around 13 liters per second...Vavg 17cm/s

Let me know if you would like to see the entire six minute file or the profile we were expecting.

Thanks,

Tim

This is called phase wrapping and means your velocity range is not set high enough. The Vectrino II has several different ping algorithms, described in detail in the manual. Anyway, the velocity range you set versus the velocity range the instrument actually uses will depend on the ping algorithm.

In your all's data file, the problem appears to be with the cross stream receivers since the Y velocity is jumping all over the place. If you take a look at the "Beam Check" tab you'll see there are a bunch of rather large spikes in amplitude within the region you are profiling. Try setting the ping algorithm to "Adaptive" and set the update interval to once. Then start data collection and see if this eliminates the step velocity changes you are seeing.

There's a lot of info about this on the forums if you want to look further into what specifically is happening, just search for "phase wrap" or "ambiguity". The reason you're data screening didn't eliminate this is because it's a large amount of data being wrapped rather than a few points. This creates a bias in the mean (showing up as the really odd profile shapes Prashanth plotted) and causing an outlier filter to not work nearly as well as we would like.

I'd recommend plotting histograms for your data in the future to try and identify this problem. It would show up as a bi-modal or even try-modal distribution with three distinct bumps.

P.J.

Sorry, I forgot to mention. The problem here seems to be related to weak spots as Robert suggested in the other thread. Since the distance to the boundary is changing, the severity of the weak spots is changing since it's a range dependent phenomenon. The Adaptive ping algorithm will do its best to eliminate weak spots but may not be successful. In that case you'll need to manually adjust the velocity range to eliminate the weak spots.

Also, this seems like a fairly high scatter environment with a lot of echoes. If the standard fixes don't improve data quality and eliminate the wrapping, try dropping the power just a little bit and see if this helps. No guarantees, but it might make the interference a little easier to deal with for the instrument.

You're velocity range in terms of magnitude is fine and I'm not expecting there to be phase wrapping because of this. But it looks like the echoes in your flume are causing problems (weak spots or pulse interference) that have symptoms like phase wrapping. Correlations look fine, but there is elevated SNR/amplitude in the near bed region once the sharp change in velocity occurs. I'd still recommend trying the Adaptive ping algorithm and seeing if this helps solve the problem.

Hi Tim:

   This could be related to a bug that I am trying to track down in the adaptive ping algorithm.  If you set the adaptive ping rate to 1/s, does the shift occur more frequently?  Conversely, if you set the rate to Once, does it happen at all? 

   Thanks!

        Robert

Robert, P.J.

Thanks a lot, especially on a Saturday! This makes much more sense now. I'm only going to be in the lab one day next week (hopefully Monday). I expect this will solve my problems. I'll report back.

Tim

We're just suckers for punishment :>.  I've had a closer look at the data and this doesn't have the same characteristics of the bug I'm tracking down.  When the shift occurs, all of the data (velocities, correlations and amplitudes) changes in some way, so this is more representative of interference (the ampltiude data clearly shows weak spot banding) as PJ has said.   The bimodal operation is something that I haven't seen before though, so I'm not sure what to make of that.  Are there any other instruments transmitting at the same time as you're acquiring data?

  As an aside, it looks like the software / firmware that you're running is one revision behind the latest. I don't believe that the problem you're seeing will be affected by the new firmware, but it's always best to be on the latest versions.

  Robert.

The forum and the user manual make it very clear what weak spot are, why they occur etc...but where the wheels come off the wagon for me is identifying them in my collected data (other than the velocity shift as pointed out above). Can you please make a jpg of the amplitude screen and circle what you are looking at when you say "the amplitude data clearly shows weak spot banding"? Even more useful would be side by side good and bad jpg. If there is already something like this on the forum can you please provide a link, my apologies if I just missed it.

And for what it's worth, switching the adaptive check to once per second certainly seems to increase the frequency of the abrupt velocity shift and the magnitude of the shift seems to decrease too. Switching Adaptive Check to once and changing the nominal velocity seems to help me out too. These are just quick observations I made this morning before I start collecting any data.

Thanks,

Tim

Hi Tim,

Here's what Robert and I are looking at and calling weak spots (attached image, around the 10 second mark). We'd also expect to see some type of correlation signature as well, but in this case that's not happening. Anyway, note the change in SNR with a very distinct band near the bed.

I think if you're just doing one adaptive check you shouldn't see this problem. Please let us know if you observe different though.

P.J.

Hi Tim:

     That seems to confirm that this is indeed a bug somewhere in the dynamic Adaptive ping selection.  You'll also see that the switch in data quality occurs at the same time that a VelocityHeader record (generated when the adaptive ping selects new ping intervals) is received.  Now all I need to do is find the bug (!)

      Robert.