Vectrino data stream description and commands

Hello,

I'm with a group doing field work at Heron Island Research Station on the Great Barrier Reef, and we are trying to integrate Vectrino ADVs into a control loop for a measurement system - the instruments arrived yesterday and look great!

We need to use a controller to run the Vectrino, and I have a few questions I haven't found answers to in the system integrators guide, vectrino manual or forum:

Is there a way to take a single sample (poll the instrument) under software control? I thought the AD command may do this, but it appears to sample continuously when I issue the AD command. If we had an available RS485 or GPIO (I read Sven's post on using TTL) line, would sync provide a single measurement per strobe?

If there is no convenient way to poll,  I'd like to understand the data stream format a little better. It looks like there may be several types of packets: velocity header, velocity data, and distance. When are velocity header and distance packets generated? can they appear at any time in the stream? Are there other types of packets that will automatically be included in the data stream?

Is it true that the Vectrino does not log internally?

Do the Vectrino set/read clock (SC, RC) commands work on Vectrino? I always get all zeros when I read the RTC, and RC returns ACK ACK, but doesn't appear to change the time/date.

Thanks in advance for your help!

Cheers,

Kent Headley

Hi Kent,

I can answer a few of your questions but not all of them. I think Sven or Atle should know the answers to the others.

There are three modes of operation for the Vectrino: free running (user sets a sample rate, e.g. 100 Hz, and instrument collects data at this rate), start on sync which is the same as free running but the instrument waits for a TTL pulse to start data collection, and sample on sync. Sample on sync allows complete control of the data output rate, with velocity data averaged over the interval between rising edges of the TTL signal. The first edge would start data collection and the first velocity sample is output on the second rising edge (this is Chapter 8 in the most recent edition of the Vectrino manual).

The Vectrino is not equipped with an internal recorder and has no capability to log samples in an autonomous mode.

The Vectrino is also not equipped with an internal (real time) clock.

Hope that helps and Sven should be able to fill in the gaps on the binary data format. Good luck with the setup and let us know how it goes!

P.J.

Thanks very much for your speed reply, Peter.

This information is very helpful - it's good to know there wasn't an operational mode I missed somewhere, and to confirm about logging and RTC.

I'll wait to hear from Sven or Atle about the data stream formats; Sven recently gave me some good advice on sampling the Aquadopp; I think the sampling and parsing strategy  will be virtually the same, and it will be good to know what I need to do with the other packet types to produce velocity measurements in engineering units.

Many thanks for your help,

Kent

Previously Peter J. Rusello wrote:

Hi Kent,

I can answer a few of your questions but not all of them. I think Sven or Atle should know the answers to the others.

There are three modes of operation for the Vectrino: free running (user sets a sample rate, e.g. 100 Hz, and instrument collects data at this rate), start on sync which is the same as free running but the instrument waits for a TTL pulse to start data collection, and sample on sync. Sample on sync allows complete control of the data output rate, with velocity data averaged over the interval between rising edges of the TTL signal. The first edge would start data collection and the first velocity sample is output on the second rising edge (this is Chapter 8 in the most recent edition of the Vectrino manual).

The Vectrino is not equipped with an internal recorder and has no capability to log samples in an autonomous mode.

The Vectrino is also not equipped with an internal (real time) clock.

Hope that helps and Sven should be able to fill in the gaps on the binary data format. Good luck with the setup and let us know how it goes!

 

P.J.

Hi Kent,

I'm with a group doing field work at Heron Island Research Station on the Great Barrier Reef, and we are trying to integrate Vectrino ADVs into a control loop for a measurement system - the instruments arrived yesterday and look great!

Sounds like you are in a good spot for field work

Is there a way to take a single sample (poll the instrument) under software control? I thought the AD command may do this, but it appears to sample continuously when I issue the AD command. If we had an available RS485 or GPIO (I read Sven's post on using TTL) line, would sync provide a single measurement per strobe?

Like P.J. said the Vectrino is a bit different from our other instruments. It is more of a sensor as opposed to our other instruments that have more sensors built in, a lot more elaborate power management and they are also capable of sampling other senors and storing data for stand alone deployments.

If there is no convenient way to poll,  I'd like to understand the data stream format a little better. It looks like there may be several types of packets: velocity header, velocity data, and distance. When are velocity header and distance packets generated? can they appear at any time in the stream? Are there other types of packets that will automatically be included in the data stream?

The distance packets are generated when a separate start command is used which starts a continuous distance measurement. So you do not have to worry about those. The velocity data header is output once at the beginning of each measurement followed by a continuous stream of velocity data packets. Assuming you are only interested in the velocity I would recommend one of these approaches:

1. If you are concerned about power consumption you should configure the Vectrino with the desired configuration and start the measurement from the Vectrino software. You can then power the Vectrino on/off from your controller to control the data collection. You controller should then be programmed to look for the velocity data packets. When the required data has been received the Vectrino can be powered off until the next measurement.

2. If power consumption is not an issue you can leave the Vectrino running and just decode the velocity data packets at desired intervals.

The velocity data structure is described in the System Integrator Guide and it contains everything you need to decode velocity data, i.e. you can discard the other data packets. Make sure you pay attention to the scaling bit in the status field as this will tell you if the data is output with a scaling of mm/s or 0.1mm/s.

Cheers,

Sven

Thanks very much for the help Sven - it is indeed a nice spot )

I'm mostly interested in a single current component; we are trying to measure the average current velocity as ocean current passes through a rectangular box structure that is 25Wx25Hx100L (cm).

I've been looking at the system integrators guide, and have been comparing the ASCII and binary output of a few samples taken in air using the factory default instrument configuration. The packets contain a single cell for each beam.

I'm afraid I'm more than a little uneducated in processing this data, and so have a few more questions:

- what determines the number of cells that will appear in each velocity data packet? How many cells can there be? Is each cell the current at some point along the sample volume?

- though it's possibly a lot to ask,  is there an algorithm you could provide or point me to that will allow me to compute the Vx inside the box using the velocity packet data?

I realize you won't be able to fully educate me in all of the signal processing nuances, but anything you can provide would be greatly appreciated.

Cheers,

Kent

Previously Sven Nylund wrote:

Hi Kent,

I'm with a group doing field work at Heron Island Research Station on the Great Barrier Reef, and we are trying to integrate Vectrino ADVs into a control loop for a measurement system - the instruments arrived yesterday and look great!

Sounds like you are in a good spot for field work

Is there a way to take a single sample (poll the instrument) under software control? I thought the AD command may do this, but it appears to sample continuously when I issue the AD command. If we had an available RS485 or GPIO (I read Sven's post on using TTL) line, would sync provide a single measurement per strobe?

Like P.J. said the Vectrino is a bit different from our other instruments. It is more of a sensor as opposed to our other instruments that have more sensors built in, a lot more elaborate power management and they are also capable of sampling other senors and storing data for stand alone deployments.

If there is no convenient way to poll,  I'd like to understand the data stream format a little better. It looks like there may be several types of packets: velocity header, velocity data, and distance. When are velocity header and distance packets generated? can they appear at any time in the stream? Are there other types of packets that will automatically be included in the data stream?

The distance packets are generated when a separate start command is used which starts a continuous distance measurement. So you do not have to worry about those. The velocity data header is output once at the beginning of each measurement followed by a continuous stream of velocity data packets. Assuming you are only interested in the velocity I would recommend one of these approaches:

1. If you are concerned about power consumption you should configure the Vectrino with the desired configuration and start the measurement from the Vectrino software. You can then power the Vectrino on/off from your controller to control the data collection. You controller should then be programmed to look for the velocity data packets. When the required data has been received the Vectrino can be powered off until the next measurement.

2. If power consumption is not an issue you can leave the Vectrino running and just decode the velocity data packets at desired intervals.

The velocity data structure is described in the System Integrator Guide and it contains everything you need to decode velocity data, i.e. you can discard the other data packets. Make sure you pay attention to the scaling bit in the status field as this will tell you if the data is output with a scaling of mm/s or 0.1mm/s.

Cheers,

Sven

Hi Sven,

As a test, I tried putting the sensor head into some water with a small current and took some data using Nortek's software, then examined both the ASCII and binary data. The binary data included 4 beams with one cell each. The velocity data for each beam appears to correspond directly to the velocities in ASCII data file and to the values that were being displayed by the Nortek software as it was running.

If that's all there is to it, then I'm all set.

I don't know under what conditions (if ever) I would have more than one cell per beam, or how to use additional cell velocities to calculate Vx, Vy or Vz (I only need Vx). Also, I don't know how the Amplitude and Correlation values are used.

Cheers,

Kent

Hi Kent,

You can safely assume that there will always be one cell per beam in the velocity data so I think you are all set. For the Vx you can simply configure the Vectrino to output data in XYZ coordinate system and use the X-component directly. Of course you have to make sure that you point the probe in the correct direction, using the mark that indicates the X-direction.

The correlation value is great as a quality parameter so you may want to screen your data based on that. You can find a lot of information about that on the forum so you should start by browsing through a few threads here.

Cheers,

Sven

Thanks so much Sven - that's great news for us.

Really good to know about the correlation value as well; I'll have a look through the forum.

Again, thanks very much for your timely help.

Cheers,

Kent

Kent,

I'd also suggest you check out the Practical Primer NortekUSA just published last month. It explains in a bit more detail how the instruments work and some of the considerations for deployment and data processing. Best of luck with the system integration and research.

P.J.

Thanks Peter -

I haven't seen that document yet, and it sounds great! I'll definitely look it up.

Cheers,

Kent

Previously Peter J. Rusello wrote:

Kent,

I'd also suggest you check out the Practical Primer NortekUSA just published last month. It explains in a bit more detail how the instruments work and some of the considerations for deployment and data processing. Best of luck with the system integration and research.

 

P.J.