✘NEO-M8U, ADR and UDR

[Gary E. Miller]

Yo All!

TL:DR: The NEO-M8U is a big disappointment.

The u-blox 8-series and 9-series modeuls have extra cost versions
that add a 6-axis IMU.  A bit odd since 9-axis IMU's are customary
for drones.

The u-blox modules with IMU's are called either Automotive Dead
Reckoning (ADR) and Untethered Dead Reckoning (UDR).  The main
difference between them is that the ADR versions also use Wheel Tick
(WT) input(s) for better accuracy.

Sparkfun has a USB-C board with NEO-M8U for $70 now.  But do not bother
to buy one unless you are going to bolt it to a car.  More on that below.

The ADR and UDR firmware has seen may updates, be sure you have at least
UDR firmware version 1.50 (protVer 19.20), and a copy of gpsd from git
head, to duplicate my results.  The new data can flood the serial port,
so direct USB connection is recommended.

External Sensor Fusion Messages:

U-blox added the External Sensor Fusion Messages (UBX-ESF-) to output
the new IMU and WT data.  Both ubxtool and gpsd can now decode these new
messages.

To poll most of them with ubxtool:
        ubxtool -p ESF

Or enable most of them for periodic output:
        ubxtool -e ESF

Sadly, this will yield empty data:

    UBX-ESF-STATUS:
     iTOW 155049000 version 2 reserved1 20 2 0 0 0 0 0 
       fusionMode 0 reserved2 0 numSens 6 
         fusionMode (Initialization mode)
       sensStatus1 85 sensStatus2 4 freq 10 faults 0
          type (gyro z) used No ready Yes
       sensStatus1 8d sensStatus2 4 freq 10 faults 0
          type (gyro y) used No ready Yes
       sensStatus1 8e sensStatus2 4 freq 10 faults 0
          type (gyro x) used No ready Yes
       sensStatus1 90 sensStatus2 4 freq 10 faults 0
          type (accel x) used No ready Yes
       sensStatus1 91 sensStatus2 4 freq 10 faults 0
          type (accel y) used No ready Yes
       sensStatus1 92 sensStatus2 4 freq 10 faults 0
          type (accel z) used No ready Yes

    UBX-ESF-ALG:
     iTOW 155049000 version 1 flags x90 error x0 reserved1 x20
       yaw 0 pitch 0 roll 0
       flags () status (user-defined/fixed angles)
       error ()

    UBX-ESF-INS:
     bitfield0 x1 reserved1 x0 iTOW 155049000
       xAngRate 0 yAngRate 0 zAngRate 0
       xAccel 0 yAccel 0 zAccel 0
       bitfield0 (version 1 )

Note that yaw, pitch, roll, acceleration and angular rates are all zero.
And they stay that way until "Initialization Mode" is complete.

Turning off doAutoMntAlg does not help:

       ubxtool -p CFG-ESFALG,0

The ADR part will not output data until the device has been driver
around a bit in a car.  Then "Initialization Mode" ends.  So ESF-ALG and
ESF-INS are useless for any application other than bolted to a car that
has been moving.

The curious may want to enable periodic output of the semi-processed
sensor data, with an arbitrary time stamp.  Worse, the time stamp that
jumps back and forth:

Enable ESF-MEAS, rate ignored, as long as it is non-zero:

       ubxtool -P 19 -p CFG-MSG,16,2,1

The sensor data is very noisy, but at least not all zeros.

And to drown in the raw data, with different arbitrary time stamp:

enable ESF-RAW, rate ignored, as long as it is non-zero:

       ubxtool -P 19 -p CFG-MSG,16,3,1

Now the time stamps are in order, the data seems to be a bit less noisy,
but the readings are batched, so not good for real time use.

You will quickly tire of that flood of data, so turn it all back off:

       ubxtool -d ESF
       ubxtool -P 19 -p CFG-MSG,16,2,0
       ubxtool -P 19 -p CFG-MSG,16,3,0

High Navigation Rate Messages:

U-blox added the HIgh Navigation Rate Messages (UBX-HNR-) to output
interpolated, and/or dead-reckoning, data by combining (Fusing) the
IMU data wit the GNSS data.

The maximum GNSS solution rate is 2Hz, combined with the ESF data, HNR
solutions can be output up to 30Hz.  HNR solutions can even be computed
when the satellite signals are lost (Dead Reckoning).

You can poll the HNR messages:

$ ubxtool -p HNR -v 2
[...]

UBX-CFG-HNR:
 highNavRate 10 reserved 0 0 0

UBX-HNR-PVT:
  iTOW 160981000 time 2021/6/28 20:42:43 valid x37
  nano 9 gpsFix 3 flags x1d reserved1 x2712
  lon -1213141213 lat 440688670 height 1114211 hMSL 1135561
  gSpeed 7 speed 9 headMot 23703286 headVeh 23703286
  hAcc 1447 vAcc 2060 sAcc 182 headAcc 3467072 reserved2 x342a3030
    valid (validDate ValidTime fullyResolved)
    gpsFix (3D)
    flags (GpsFixOK WKNSET TOWSET headVehValid)

UBX-HNR-ATT:
  iTOW 160981000 version 1 reserved1 xf4 7a 0
  roll 0 pitch 3575948 heading 23703286
  accRoll 2000000 accPitch 2697010 accHeading 3467072

UBX-HNR-INS:
  bitfield0 x34300000 reserved1 x2e323432 iTOW 160981000
  xAngRate 0 yAngRate 0 zAngRate 0
  xAccel 0 zAccel 0 zAccel 0
    version 0
    bitfield0 ()

Note the fix is still 3D, and not GPS-DR.  No "Fusion".

But it looks like we are getting roll, pith, yaw (heading) data.

So enable the HNR messages at 10 hZ:

$ ubxtool -e HNR

Then move the M8U around, and confirm the roll, pitch, yaw, acceleration
and angular rate never changes.  So much for IMU/DR on the desk...

By default, the receiver will send UBX-NAV-PVT once a second, and
UBX-HNR-PVT about once every 100 milli-seconds.  But things are funcky.

I see this, which looks normal:

HNR-PVT "...23:58.000Z"
HNR-PVT "...23:58.100Z"
HNR-PVT "...23:58.200Z"
HNR-PVT "...23:58.300Z"
HNR-PVT "...23:58.400Z"

Followed by NAV-PVT, late:

NAV-PVT "...23:58.000Z"

The rest of the NAV stuff for that epoch, finished by NAV-EOE

And then back to HNR-PVT:

HNR-PVT "...23:58.500Z"
HNR-PVT "...23:58.600Z"

And sometimes before .400 instead of after it.  Clients will get
confused...

gpsd and clients:

The new data, when sent by the receiver, is decoded by gpsd, and sent on
in JSON ATT and PVT messages.  The user can see them in cgps, gpspipe,
xgps and other gpsd clients.  Pretty to look at, but not useful until
you can driver around and unlock the sensors...

Summary:

So much promise, so little delivered...

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgp2Z0DyjVZ8T.pgp
Description: OpenPGP digital signature