In particular, no UBX-TIM-SMEAS messages - that's why I started figuring out the SMGR protocol.

Hi Danylo (@dizcza ),

UBX-TIM-SMEAS is almost certainly disabled by default. You will need to enable it with CFG-MSG, or via u-center.

I hope this helps,
Paul

UBX-TIM-SMEAS is almost certainly disabled by default. You will need to enable it with CFG-MSG, or via u-center.

How to do this? I guess I need to simply call

myGNSS.setVal8(UBLOX_CFG_MSGOUT_UBX_TIM_SMEAS_I2C, 1);

but I cannot come up with a value for UBLOX_CFG_MSGOUT_UBX_TIM_SMEAS_I2C - I don't find any mention of how this key value is constructed in the specs datasheet.

I think I managed to output TIM-SMEA but I get garbage on my Serial:

void enableMSG_TIM_SMEAS() {
  uint8_t customPayload[MAX_PAYLOAD_SIZE]; // This array holds the payload data bytes. MAX_PAYLOAD_SIZE defaults to 256. The CFG_RATE payload is only 6 bytes!

  ubxPacket customCfg = {0, 0, 0, 0, 0, customPayload, 0, 0, SFE_UBLOX_PACKET_VALIDITY_NOT_DEFINED, SFE_UBLOX_PACKET_VALIDITY_NOT_DEFINED};

  customCfg.cls = UBX_CLASS_CFG; // This is the message Class
  customCfg.id = UBX_CFG_MSG; // This is the message ID
  customCfg.len = 3; // Setting the len (length) to zero let's us poll the current settings
  customCfg.startingSpot = 0; // Always set the startingSpot to zero (unless you really know what you are doing)

  customPayload[0] = UBX_CLASS_TIM;
  customPayload[1] = 0x13;
  customPayload[2] = 1;    // rate in Hz (measurements per sec)

  // We also need to tell sendCommand how long it should wait for a reply
  uint16_t maxWait = 250; // Wait for up to 250ms (Serial may need a lot longer e.g. 1100)

  // Now we write the custom packet back again to change the setting
  if (myGNSS.sendCommand(&customCfg, maxWait) != SFE_UBLOX_STATUS_DATA_SENT) // This time we are only expecting an ACK
  {
    Serial.println(F("Could not update TIM-SMEAS MSG rate"));
  }
  else
  {
    Serial.println(F("TIM-SMEAS MSG rate successfully updated"));
  }

}

Is this because I pipe raw bytes to serial?

  myGNSS.setOutputPort(Serial);

The LEA-M8F doesn't support the Configuration Interface. You will need to enable the message manually using configureMessage(UBX_CLASS_TIM, 0x13, COM_PORT_I2C, 1);

The message is UBX binary format. It will contain unprintable characters. You could use a logic analyzer to view the bytes as HEX. Or write a very simple binary to HEX converter and run it on another board?

Or - even better - close the serial monitor / terminal emulator and open u-center instead. It will be able to decode the UBX messages and display them correctly.

The LEA-M8F doesn't support the Configuration Interface. You will need to enable the message manually using configureMessage(UBX_CLASS_TIM, 0x13, COM_PORT_I2C, 1);

This one-liner looks much simpler.

Or - even better - close the serial monitor / terminal emulator and open u-center instead. It will be able to decode the UBX messages and display them correctly.

I'm on Ubuntu, I doubt the u-center supports Linux. Even if it does, I eventually need to be able to parse these messages on an ESP32 board via I2C.

Looks like I need to extend the case UBX_CLASS_TIM in the sources and add something similar to packetUBXTIMTM2.

All right, it was quite a change.

Now the example outputs TIM-SMEA messages:

UBX-TIM-SMEAS:
 version: 0
 numMeas: 4
 iTOW: 330285000
 sourceId 0:
   flags:
      freqValid 1
      phaseValid 1
   phaseOffsetFrac -75
   phaseUncFrac 102
   phaseOffset 2
   phaseUnc 8
   freqOffset -77
   freqUnc 93
 sourceId 1:
   flags:
      freqValid 1
      phaseValid 1
   phaseOffsetFrac -17
   phaseUncFrac 237
   phaseOffset 4
   phaseUnc 7
   freqOffset -36
   freqUnc 70
 sourceId 2:
   flags:
      freqValid 0
      phaseValid 0
   phaseOffsetFrac 0
   phaseUncFrac 0
   phaseOffset 0
   phaseUnc 0
   freqOffset 0
   freqUnc 0
 sourceId 3:
   flags:
      freqValid 0
      phaseValid 0
   phaseOffsetFrac 0
   phaseUncFrac 0
   phaseOffset 0
   phaseUnc 0
   freqOffset 0
   freqUnc 0

I added only one way to pass user callbacks, setAutoTIMSMEAcallback, not to overwhelm poor users with otherwise great API.

Hi Danylo (@dizcza ),

I am sorry - I let your Pull Request go stale...! The problem is that I do not have a LEA-M8F board to test it on. I will try to get one.

Best wishes,
Paul

All right. It seems there are not a lot of those who actually use LEA-M8F anyway, in particular, the precise timing feature setup.

Thank you Danylo (@dizcza ),

Merged for testing...

Best wishes,
Paul

I still don't have hardware to test this on. But your code looks good, and compiles OK. I'm happy to merge this into main.

I will merge #238 at the same time - as soon as the missing semicolons are added?! ;-)

Glad that it has finally completed its voyage.