BESTVEL
Best available velocity data
Platform: |
OEM719, OEM729, OEM7500, OEM7600, OEM7700, OEM7720, PwrPak7, CPT7, CPT7700, SMART7, SMART2 |
This log contains the best available velocity information computed by the receiver. In addition, it reports a velocity status indicator, which is needed to determine whether or not the corresponding data is valid. The velocities calculated by the receiver can have a latency associated with them. When present, the velocity time of validity is the time tag in the log minus the latency value.
The velocity is typically from the same source used in the BESTPOS solution. For example, if the BESTPOS is from the pseudorange filter, then the BESTVEL velocity type is the same as for PSRVEL. However, a specific velocity source can be chosen. See the BESTVELTYPE command.
In a BESTVEL log, the actual speed and direction of the receiver antenna over ground is provided. The receiver does not determine the direction a vessel, craft or vehicle is pointed (heading) but rather the direction of motion of the GNSS antenna relative to ground.
The RTK, PDP and PPP velocities are computed from the average change in position over the time interval between consecutive solutions. As such, they are an average velocity based on the time difference between successive position computations and not an instantaneous velocity at the BESTVEL time tag. The velocity latency to be subtracted from the time tag is normally half the time between filter updates. Under default operation, the positioning filters are updated at a rate of 2 Hz. This average velocity translates into a velocity latency of 0.25 seconds. To reduce the latency, increase the update rate of the positioning filter being used by requesting the BESTVEL or BESTPOS messages at a rate higher than 2 Hz. For example, a logging rate of 10 Hz would reduce the velocity latency to 0.05 seconds.
If the velocity in the BESTVEL log comes from the pseudorange filter, it has been computed from instantaneous Doppler measurements. You know that you have an instantaneous Doppler derived velocity solution when the velocity type is PSRDIFF, WAAS or DOPPLER_VELOCITY. The instantaneous Doppler derived velocity has low latency and is not position change dependent. If you change your velocity quickly, you can see this in the DOPPLER_VELOCITY solution. Under typically seen dynamics with minimal jerk, the velocity latency is zero. Under extreme, high-jerk dynamics, the latency cannot be well represented: it will still be reported as being zero, but may be as high as 0.15 seconds. Such dynamics are typically only seen in simulated trajectories.
Message ID: 99
Log Type: Synch
Recommended Input:
log bestvela ontime 1
ASCII Example:
#BESTVELA,USB1,0,57.5,FINESTEERING,2209,502223.000,02000020,10a2,16809;SOL_COMPUTED,PPP,0.250,13.000,0.0025,28.358727,0.0021,0*e9418656
Field |
Field Type |
Description |
Format |
Binary Bytes |
Binary Offset |
1 |
Log header |
BESTVEL header For information about log headers, see ASCII, Abbreviated ASCII or Binary. |
|
H |
0 |
2 |
sol status |
Solution status, see Table: Solution Status |
Enum |
4 |
H |
3 |
vel type |
Velocity type, see Table: Position or Velocity Type |
Enum |
4 |
H+4 |
4 |
latency |
A measure of the latency in the velocity time tag in seconds. It should be subtracted from the time to give improved results (s) |
Float |
4 |
H+8 |
5 |
age |
Differential age in seconds |
Float |
4 |
H+12 |
6 |
hor spd |
Horizontal speed over ground, in metres per second |
Double |
8 |
H+16 |
7 |
trk gnd |
Actual direction of motion over ground (track over ground) with respect to True North, in degrees |
Double |
8 |
H+24 |
8 |
vert spd |
Vertical speed, in metres per second, where positive values indicate increasing altitude (up) and negative values indicate decreasing altitude (down) |
Double |
8 |
H+32 |
9 |
Reserved |
Float |
4 |
H+40 |
|
10 |
xxxx |
32-bit CRC (ASCII and Binary only) |
Hex |
4 |
H+44 |
11 |
[CR][LF] |
Sentence terminator (ASCII only) |
- |
- |
- |
|
Velocity (speed and direction) calculations are computed from either Doppler or carrier phase measurements rather than from pseudorange measurements. Typical speed accuracies are around 0.03 m/s (0.07 mph, 0.06 knots). Direction accuracy is derived as a function of the vehicle speed. A simple approach would be to assume a worst case 0.03 m/s cross-track velocity that would yield a direction error function something like: d (speed) = tan-1(0.03/speed) For example, if you are flying in an airplane at a speed of 120 knots or 62 m/s, the approximate directional error will be: tan-1 (0.03/62) = 0.03 degrees Consider another example applicable to hiking at an average walking speed of 3 knots or 1.5 m/s. Using the same error function yields a direction error of about 1.15 degrees. You can see from both examples that a faster vehicle speed allows for a more accurate heading indication. As the vehicle slows down, the velocity information becomes less and less accurate. If the vehicle is stopped, a GNSS receiver still outputs some kind of movement at speeds between 0 and 0.5 m/s in random and changing directions. This represents the noise and error of the static position. In a navigation capacity, the velocity information provided by your GNSS receiver is as, or more, accurate than that indicated by conventional instruments as long as the vehicle is moving at a reasonable rate of speed. It is important to set the GNSS measurement rate fast enough to keep up with all major changes of the vehicle's speed and direction. It is important to keep in mind that although the velocity vector is quite accurate in terms of heading and speed, the actual track of the vehicle might be skewed or offset from the true track by plus or minus 0 to 1.8 metres as per the standard positional errors. |