Please add more information about RTK/YAW.

[AndKe]

please add more information from dual antenna/ RTK for Yaw devices. As a minimum, display heading information.

[semuadmin]

Hi. I'll need a little more detail.

Which specific attributes from which specific message protocols would you like to see displayed, that aren't already covered?

Track (aka 'course over ground' (cog) or 'heading of motion' (headMot), depending on the message protocol) is already displayed in the top banner. Yaw in degrees (where available from IMU/DR message sources) is already displayed in the user-selectable IMU Monitor widget.

The 'source' field indicates the specific message from which the IMU attitude data was derived e.g. for u-blox receivers,that might be a NAV-ATT (navigation attitude), HNR-ATT (high-rate navigation attitude) or legacy NAV-PVAT (position velocity attitude time) message type or an ESF-ALG (external sensor fusion IMU alignment) message.

[AndKe]

The track normal/single antenna GNSS receievers display is based on movement - so when stationary, they do not "know" the orientation, nor do they know the yaw of the vehicle (as when when crabbing in the wind)
Dual antenna systems report UBX-NAV-PVT headVeh, and there is another parameter(bool) in that packet that tells is headVeh value is an actual value (if the yaw is solved.)
I believe NMEA HDT packet is an alternative source for this.

here are some examples of such chipsets:
https://www.ardusimple.com/product/simplertk-4-dual-rtk-starter-kit/
https://www.ardusimple.com/product/simplertk-4-heading/
https://www.ardusimple.com/product/simplertk3b-heading/

Those devices can provide precise yaw data regardless of speed.

[semuadmin]

Yes, that's correct. The HPG 2.02 protocol defines the following:

The NAV-PVT headVeh and headVehValid values (which are only available on modules with built-in sensor fusion) are parsed by the underlying pyubx2 parser and are already visible in the PyGPSClient console.

How would you prefer to see this information displayed?

The NMEA HDT and HDM sentences output true and magnetic heading respectively, but to the best of my knowledge these do not relate specifically to static heading (yaw) and they are not output by u-blox GNSS modules. Some development kits may include IMU/DR modules or other sensor fusion devices with independent interfaces which are capable of outputting other standard or proprietary NMEA sentences (e.g. Feyman IMU units) - you'd need to refer to the manufacturer's data sheets for implementation details. Again, such information would, if available, be displayed in the PyGPSClient console provided it was connected to the relevant UART port.

[AndKe]

I imagine something simple like this would do (look for hdg:)

it could show headVeh(or NMEA equvalent), when headVehValid (or NMEA equivalent) , or "hdg: n/a" when not.

[semuadmin]

It's easy enough to do, but I'm not convinced of the practical utility.

99.9% of the time, the 'track' (aka 'heading in motion' or 'course over ground') and 'heading' (aka 'yaw') readings would be more or less identical (for terrrestrial vehicles at least) - they would only differ when the vehicle was not in motion (or occasionally when GNSS navigation falls back to dead reckoning) and, as I say, static yaw can already be displayed in the IMU Monitor widget.

Let me give it some consideration - it may, for example, make more sense to display a single heading/track value but indicate whether it represents 'in motion' or 'static'.

Is there a specific use case you have in mind?

[gdt]

I don't have this problem, but in general it feels useful to treat track and heading separately. These are often different for boats and aircraft. In cars, they also differ in hard turns, and stability management intervenes when track-heading is too large.

But, I don't think it merits putting in the main nav screen. If one is showing heading, then it also makes sense to show pitch and roll, and maybe that's "IMU" except that dual-antenna differential isn't actually I, but it's still orientation. That might call for adding track to the IMU screen, and maybe slip angle, which I think is the term for track-heading.

This discussion raises questions about purpose and scope; I see PyGPSClient as a debugging/exploration tool, not something to use for any particular operational scenario. This request seems a deviation from that scope.

[semuadmin]

I see PyGPSClient as a debugging/exploration tool, not something to use for any particular operational scenario. This request seems a deviation from that scope.

Likewise, but if a request can be accommodated relatively easily without compromising the broader purpose or confusing mainstream users, I'm happy to incorporate it. In this particular case I believe the IMU Monitor widget meets the stated requirement, but see comment below about nomenclature

and maybe that's "IMU" except that dual-antenna differential isn't actually I, but it's still orientation

"IMU Monitor" is a misnomer, though that was its original motivation. It actually displays 'pitch', 'roll' and 'yaw' (or 'static heading') attributes from a variety of GNSS and maritime NMEA sources, which may not necessarily be based on inertial management per se. I should probably rename it 'Attitude Monitor', 'Orientation Monitor' or some such. The original widget had a "3D wireframe"-style presentation but I decided that was computationally excessive.

I'm not actually 100% sure if dual antenna rigs necessarily derive 'static heading' or 'yaw' solely from the relative position of the two antennas. I suspect it may in practice be a more complex sensor fusion algorithm.

slip angle, which I think is the term for track-heading.

Not sure - I think 'slip angle' as a synonym for 'track' or what NMEA commonly refers to as 'course over ground' (cog) is only appropriate for certain dynamic models e.g. aviation slip or automotive drift.

Bottom line is - whether it's 'direction you're moving in' or 'direction you're pointed at', PyGPSClient has it covered.

[gdt]

I should probably rename it 'Attitude Monitor', 'Orientation Monitor' or some such.

Attitude sounds good.

I'm not actually 100% sure if dual antenna rigs necessarily derive 'static heading' or 'yaw' solely from the relative position of the two antennas. I suspect it may in practice be a more complex sensor fusion algorithm.

I'm not sure either, but I think a large part of the point is to get attitude separately from trying to infer it from motion, perhaps precisely because track - atitutude is of interest. Agreed that things are ~never well documented; I still haven't seen a single receiver document how the 4 reference frames of the 4 global constellations are combined in a joint non-differential solution. But still, in a 2-antenna unit, I would expect orientation to be simply from carrier phase differential, maybe with a Kalman filter that would be un-noticeable at even 5s (based on vehicle dynamics model). I would never think of putting direction of travel into the orientation mix, except maybe averages with timescale of at least a week for cal.

[semuadmin]

FYI "IMU Monitor" has been renamed "Attitude Monitor" in v1.6.9

[AndKe]

Please add NAV-DAHEADING
It is the main yaw source in at least: NEO-F9P, ZED-F9H , ZED-X20D

[semuadmin]

I can find no reference to a NAV-DAHEADING message or attribute in any of the public domain interface specifications for these modules. Can you clarify where this is defined?

[AndKe]

this is EXACTLY what I just discovered myself and are struggling with finding.
here is a screenshot of antenna-less operation indoors, showing the packets, but no documentation.

The u-center2 "info" icon shows this (but I miss information about bit'n'bytes per field.)

UBX-NAV-DAHEADING
DATA1
This message contains the relative position vector and heading from antenna 1 to antenna 2, along with the corresponding accuracy figures.

version
Message version (0x01 for this version)

reserved0
refStationId
Reference station ID. Must be in the range 0..4095.

iTOW
GPS time of week of the navigation epoch.

See section iTOW timestamps in the integration manual for details.

relPosN
North component of relative position vector

relPosE
East component of relative position vector

relPosD
Down component of relative position vector

relPosLength
Length of the relative position vector

relPosHeading
Heading of the relative position vector

reserved1
relPosHPN
High-precision North component of relative position vector.

Must be in the range -99 to +99.

The full North component of the relative position vector, in units of cm, is given by

relPosN + (relPosHPN * 1e-2)

relPosHPE
High-precision East component of relative position vector.

Must be in the range -99 to +99.

The full East component of the relative position vector, in units of cm, is given by

relPosE + (relPosHPE * 1e-2)

relPosHPD
High-precision Down component of relative position vector.

Must be in the range -99 to +99.

The full Down component of the relative position vector, in units of cm, is given by

relPosD + (relPosHPD * 1e-2)

relPosHPLength
High-precision component of the length of the relative position vector.

Must be in the range -99 to +99.

The full length of the relative position vector, in units of cm, is given by

relPosLength + (relPosHPLength * 1e-2)

accN
Accuracy of relative position North component

accE
Accuracy of relative position East component

accD
Accuracy of relative position Down component

accLength
Accuracy of length of the relative position vector

accHeading
Accuracy of heading of the relative position vector

reserved2
flags
Flags

gnssFixOK
A valid fix (i.e within DOP & accuracy masks)

diffSoln
1 if differential corrections were applied

relPosValid
1 if relative position components and accuracies are valid and, in moving base mode only, if baseline is valid

carrSoln
Carrier phase range solution status:

0 = no carrier phase range solution
1 = carrier phase range solution with floating ambiguities
2 = carrier phase range solution with fixed ambiguities
isMoving
1 if the receiver is operating in moving base mode

refPosMiss
1 if extrapolated reference position was used to compute moving base solution this epoch. (Flag set for protocol versions 27.10, and 27.11, and 31.11)

refObsMiss
1 if extrapolated reference observations were used to compute moving base solution this epoch. (Flag set for protocol versions 27.10, and 27.11, and 31.11)

relPosHeadingValid
1 if relPosHeading is valid

relPosNormalized
1 if the components of the relative position vector (including the high-precision parts) are normalized

DATA2
This message contains the relative position vector and heading from antenna 1 to antenna 2, along with the corresponding accuracy figures.

version
Message version (0x02 for this version)

reserved0
iTOW
GPS time of week of the navigation epoch.

See section iTOW timestamps in the integration manual for details.

relPosN
North component of the relative position vector from antenna 1 to antenna 2

relPosE
East component of the relative position vector from antenna 1 to antenna 2

relPosD
Down component of the relative position vector from antenna 1 to antenna 2

relPosLength
Length of the relative position vector from antenna 1 tp antenna 2

relPosHeading
Heading of the relative position vector.

Clockwise angle, measured in the local horizontal plane, between True North and the projection of the baseline vector from antenna 1 to antenna 2 onto that plane. Range: 0 to 360 degrees.

Valid only when the relPosHeadingValid flag is set.

relPosHeading is offset by the configuration item CFG-NAVSPG-DAHEADING_OFFSET value, in order to report the vehicle forward axis heading instead of the relative position vector heading.

Only relPosHeading is offset by the configuration item CFG-NAVSPG-DAHEADING_OFFSET value. All other relative position vector information in this message still refer to the original relative position vector from antenna 1 to antenna 2.

reserved1
accN
Accuracy of the relative position North component

accE
Accuracy of the relative position East component

accD
Accuracy of the relative position Down component

accLength
Accuracy of the length of the relative position vector

accHeading
Accuracy of the heading of the relative position vector

reserved2
flags
Flags

gnssFixOK
A valid fix (i.e. within DOP & accuracy masks)

diffSoln
1 if differential corrections were applied

relPosValid
1 if relative position components and accuracies are valid and, in moving base mode only, if baseline is valid

carrSoln
Carrier phase range solution status:

0 = no carrier phase range solution
1 = carrier phase range solution with floating ambiguities
2 = carrier phase range solution with fixed ambiguities
isMoving
1 if the receiver is operating in moving base mode

relPosHeadingValid
1 if relPosHeading is valid

[semuadmin]

@AndKe

Please appreciate that these are open source libraries and any message definitions they implement must be sourced from public domain documentation (or at least be easily 'reverse-engineered' from public information) to avoid any potential copyright issues.

The u-center screen shots give me some information, but I'd need the individual attribute lengths, formats and scaling factors to implement both variants of the NAV-DAHEADING message type ('DATA1' and 'DATA2'). Once I have these, it is a trivial matter to add them to the pyubx2 parser.

Having said this, I note that the DATA1 variant appears to be identical to the existing UBX NAV-RELPOSNED message definition, in which case it would parse something like this:

msg = UBXReader.parse(b'\xb5b\x01E@\x00\x01\x00\x00\x00h\xb3\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xa4(')
print(msg)

<UBX(NAV-DAHEADING, version=1, reserved0=0, refStationId=0, iTOW=00:02:39, relPosN=0.0, relPosE=0.0, relPosD=0.0, relPosLength=0.0, relPosHeading=0.0, reserved1=0, accN=0.0, accE=0.0, accD=0.0, accLength=0.0, accHeading=0.0, reserved2=0, gnssFixOK=0, diffSoln=0, relPosValid=0, carrSoln=0, isMoving=0, refPosMiss=0, refObsMiss=0, relPosHeadingValid=0, relPosNormalized=0)>

(pyubx2 automatically combines the standard and high precision (HP) elements of the relPos... attributes)

The DATA2 variant appears to be the same, but without the high precision elements.

Do you have a binary data stream containing 'valid' (i.e. not empty or null) NAV-DAHEADING messages I could test against? I don't have a twin-antenna u-blox module to hand.

[AndKe]

This is what I reverse-engineered from data in these screenshots taken in u-center2 with ZED X20D connected:

My effort was mainly in relPosHeading and relPosHeadingValid , which works fine for me.
The message is/seems structurally identical to ubx_nav_relposned

B5 62 — u-blox preamble
01 — Class: NAV (0x01)
45 — Message ID: 0x45
40 00 — Payload length: 64 bytes (little-endian)
Payload (64 bytes):

Offset Size Type Name Unit Notes

0 1 U1 version — 0x01 = DATA1 format
1 1 U1 reserved0 —
2 2 U2 refStationId — 0..4095 (LE)
4 4 U4 iTOW ms GPS time of week
8 4 I4 relPosN cm North component (signed)
12 4 I4 relPosE cm East component (signed)
16 4 I4 relPosD cm Down component (signed)
20 4 U4 relPosLength cm Baseline length ×0.01 → metres
24 4 U4 relPosHeading 1e-5 deg Heading ant1→ant2 ×1e-5 → degrees
28 4 — reserved1 —
32 1 I1 relPosHPN 0.1 mm High-prec North (−99..+99)
33 1 I1 relPosHPE 0.1 mm High-prec East
34 1 I1 relPosHPD 0.1 mm High-prec Down
35 1 I1 relPosHPLength 0.1 mm High-prec length
36 4 U4 accN 0.1 mm Accuracy, North
40 4 U4 accE 0.1 mm Accuracy, East
44 4 U4 accD 0.1 mm Accuracy, Down
48 4 U4 accLength 0.1 mm Accuracy, baseline length
52 4 U4 accHeading 1e-5 deg Heading accuracy ×1e-5 → degrees
56 4 — reserved2 —
60 4 X4 flags — See below
Flags field (bits, offset 60):

Bit(s) Name Meaning when set

---

0 gnssFixOK Valid GNSS fix (within DOP & accuracy masks)
1 diffSoln Differential corrections applied
2 relPosValid Relative position and accuracies are valid
3 carrSolnFloat } Carrier phase solution status (2-bit field):
4 carrSolnFixed } 00 = no solution
01 = float ambiguities (bit3=1, bit4=0)
10 = fixed ambiguities (bit3=0, bit4=1) ← want this
5 isMoving Receiver is in moving-base mode
6 refPosMiss Extrapolated reference position was used
7 refObsMiss Extrapolated reference observations were used
8 relPosHeadingValid relPosHeading is valid ← must be 1
9 relPosNormalized Relative position vector is normalized
ArduPilot acceptance criteria (all must hold):

Bits 0, 2, 4, 8 set → gnssFixOK + relPosValid + carrSolnFixed + relPosHeadingValid
Bit 3 clear → not float solution
|GPS1_MB_OFS.length − relPosLength×0.01| ≤ 20 % of the smaller of the two
Checksum (2 bytes, after payload):

CK_A, CK_B — Fletcher checksum over class + ID + length + payload
Full message length: 2 (preamble) + 4 (class/ID/len) + 64 (payload) + 2 (checksum) = 72 bytes

[semuadmin]

OK if I add the following guessed payload definitions to pyubx2 (based on the existing NAV-RELPOSNED):

    "NAV-DAHEADINGHP": {  # 'DATA1'  variant, not publicly documented?
        "version": U1,  # 0x01
        "reserved0": U1,
        "refStationId": U2,
        "iTOW": U4,
        "relPosN": I4,  # cm
        "relPosE": I4,
        "relPosD": I4,
        "relPosLength": I4,
        "relPosHeading": [I4, SCAL5],
        "reserved1": U4,
        "_HPrelPosN": [I1, SCAL2],  # added to relPOSN
        "_HPrelPosE": [I1, SCAL2],  # added to relPOSE
        "_HPrelPosD": [I1, SCAL2],  # added to relPOSD
        "_HPrelPosLength": [I1, SCAL2],  # added to relPOSLength
        "accN": [U4, SCAL1],
        "accE": [U4, SCAL1],
        "accD": [U4, SCAL1],
        "accLength": [U4, SCAL1],
        "accHeading": [U4, SCAL5],
        "reserved2": U4,
        "flags": (
            X4,
            {
                "gnssFixOK": U1,
                "diffSoln": U1,
                "relPosValid": U1,
                "carrSoln": U2,
                "isMoving": U1,
                "refPosMiss": U1,
                "refObsMiss": U1,
                "relPosHeadingValid": U1,
                "relPosNormalized": U1,
            },
        ),
    },
    "NAV-DAHEADING": {  # 'DATA2' variant, not publicly documented?
        "version": U1,  # 0x02
        "reserved0": U1,
        "iTOW": U4,
        "relPosN": I4,  # cm
        "relPosE": I4,
        "relPosD": I4,
        "relPosLength": I4,
        "relPosHeading": [I4, SCAL5],
        "reserved1": U4,
        "accN": [U4, SCAL1],
        "accE": [U4, SCAL1],
        "accD": [U4, SCAL1],
        "accLength": [U4, SCAL1],
        "accHeading": [U4, SCAL5],
        "reserved2": U4,
        "flags": (
            X4,
            {
                "gnssFixOK": U1,
                "diffSoln": U1,
                "relPosValid": U1,
                "carrSoln": U2,
                "isMoving": U1,
                "relPosHeadingValid": U1,
            },
        ),
    },

Your first payload above parses as follows...

from pyubx2 import UBXReader
msg = UBXReader.parse(b'\xb5\x62\x01\x45\x40\x00\x01\x00\x00\x00\xe0\xd6\xef\x12\x06\x00\x00\x00\xf6\xff\xff\xff\xe5\xff\xff\xff\x1e\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x43\xb5\xb4\x33\x59\x06\x00\x00\x9f\x02\x00\x00\xfb\x07\x00\x00\x73\x07\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x2f\x00\x00\x00\xc1\x61')

<UBX(NAV-DAHEADING, version=1, reserved0=0, refStationId=0, iTOW=16:14:50, relPosN=6.67, relPosE=-10.75, relPosD=-27.76, relPosLength=30.51, relPosHeading=0.0, reserved1=0, accN=162.5, accE=67.1, accD=204.3, accLength=190.7, accHeading=0.0, reserved2=0, gnssFixOK=1, diffSoln=1, relPosValid=1, carrSoln=1, isMoving=1, refPosMiss=0, refObsMiss=0, relPosHeadingValid=0, relPosNormalized=0)>

... which appears to be consistent with u-center (remember pyubx2 combines the HP elements of relPos...), implying the guessed definitions are correct.

[AndKe]

Thank you.
I am glad you concur ,as I added in later edit: "The message is/seems structurally identical to ubx_nav_relposned" - that observation helped/assured me about some values.

YAW is a upcoming feature that is/will be more and more frequent in the coming years as its getting more and more affordable.

[semuadmin]

I've uploaded a provisional pyubx2 RC-1.3.2 branch which you can install as follows into whichever environment you're running PyGPSClient in:

python3 -m pip install --force-reinstall git+https://github.com/semuconsulting/pyubx2.git@RC-1.3.2

You can test your ZED-X20D against this branch - let me know how you get on.

[semuadmin]

Thank you. I am glad you concur ,as I added in later edit: "The message is/seems structurally identical to ubx_nav_relposned" - that observation helped/assured me about some values.

YAW is a upcoming feature that is/will be more and more frequent in the coming years as its getting more and more affordable.

Yes, but unless and until u-blox formally document these messages (and their associated configuration database keys) in their official Interface Specifications, there's no guarantee this will be a permanent or stable implementation.

[semuadmin]

NAV-DAHEADING (DATA1 and DATA2 variants) added in pyubx2 v1.3.2. Update via PyGPSClient's 'About' panel.