Open dizcza opened 8 months ago
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.
Sketch output:
I don't see any UBX messages from my device (they are set to echo on Serial) even though PPS is flashing and I have a fix (tried setting
minGNSSFix
to 1). Any clue?