NAV PVT callback not working when using UART on Teensy

[Turtle9er]

Hi,

I have been trying to get the example "CallbackExample6_UseCallbackDataInLoop.ino" to work with UART1 on the SAM-M10Q, and I can't seem to get it to stream in data like when I use the same example with I2C. I have kept the example exactly the same except for adapting for serial. The sensor connects at the correct buad rate and I can read/write settings to the module, however the callback only fires at random times, usually 60+s between each one. The default example with i2c fires every 0.5s without fail.

Serial seems to work with all the other examples, but can't figure out why callbacks won't work. From my research, both serial and i2c should both work with callbacks, since the data is just read in to UBX and then pulled out with my callback. I have also used 'myGNSS.setUART1Output(COM_TYPE_UBX);', and data does show up, just not at the correct interval.

I am using the sparkfun SAM-M10Q module with a teensy 4.1, baud set at 115200

Seems there is a checksum error when using serial
.......process: incoming "automatic" message: Class: 0x1 ID: 0x7 logBecauseAuto:1 logBecauseEnabled:0 ...........Checksum failed: checksumA: 92 checksumB: 92 rollingChecksumA: 33 rollingChecksumB: 206

[PaulZC]

Hi @Turtle9er ,

Thanks for reporting this issue. I think I can reproduce what you're seeing:

My setup - closest I can get:

• Teensy 3.2
• MAX-M10S breakout

MAX-M10S is connected to Teensy:

• Teensy : M10S
• GND : GND
• 3.3V @ 3V3
• RX1 : TX (TXO)
• TX1 : RX (RXI)

I had previously reset the M10S to its defaults and saved the configuration.

Starting with Example2_PositionVelocityTime_Serial:

#define mySerial Serial1
...
mySerial.begin(38400);

works as expected.

Moving to Basics \ Example13_PVT \ Example3_AutoPVTviaUART:

//#include <SoftwareSerial.h>

#define mySerial Serial1 // Use Serial1
// - or -
//SoftwareSerial mySerial(10, 11); // Uncomment this line to connect via SoftwareSerial(RX, TX). Connect pin 10 to GNSS TX pin.

//#define baudRate 9600 // Uncomment this line to select 9600 Baud for the M8
// - or -
#define baudRate 38400 // Uncomment this line to select 38400 Baud for the F9/M10

works as expected. I see PVT data at 2Hz.

Moving to Callbacks \ CallbackExample1_NAV_PVT and adapt it for Serial1:

SFE_UBLOX_GNSS_SERIAL myGNSS;
...
  //Wire.begin();
  Serial1.begin(38400);
...
myGNSS.begin(Serial1)
...
myGNSS.setUART1Output(COM_TYPE_UBX);

this fails. If I enableDebugging I see:

SparkFun u-blox Example
createFileBuffer: Warning. fileBufferSize is zero. Data logging is not possible.
getVal key: 0x10730001

Sending: CLS:CFG ID:0x8B Len: 0x8 Payload: 0 0 0 0 1 0 73 10
sendCommand: Waiting for ACK response
Incoming: Size: 9 Received: CLS:CFG ID:0x8B Len: 0x9 Payload: 1 0 0 0 1 0 73 10 1
packetCfg now valid
packetCfg classAndIDmatch
Incoming: Size: 2 Received: CLS:ACK ID:0x1 Len: 0x2 Payload: 6 8B
packetCfg now valid
packetAck now valid
packetCfg classAndIDmatch
packetAck classAndIDmatch
waitForACKResponse: valid data and valid ACK received after 16 msec
getVal: sendCommand returned: Data Received

Sending: CLS:CFG ID:0x8A Len: 0xE Payload: 0 3 0 0 1 0 74 10 1 2 0 74 10 0
sendCommand: Waiting for ACK response
Incoming: Size: 2 Received: CLS:ACK ID:0x1 Len: 0x2 Payload: 6 8A
packetCfg now valid
packetAck now valid
packetCfg classAndIDmatch
packetAck classAndIDmatch
waitForACKResponse: no data and valid ACK after 11 msec

Sending: CLS:CFG ID:0x8A Len: 0x9 Payload: 0 3 0 0 4 0 74 10 0
sendCommand: Waiting for ACK response
processUBX: NACK received: Requested Class: 0x6 Requested ID: 0x8A
Incoming: Size: 2 Received: CLS:ACK ID:0x0 Len: 0x2 Payload: 6 8A
packetCfg now valid
packetAck now valid
waitForACKResponse: data was NOTACKNOWLEDGED (NACK) after 11 msec

Sending: CLS:CFG ID:SAVE Len: 0xC Payload: 0 0 0 0 1 0 0 0 0 0 0 0
sendCommand: Waiting for ACK response
Incoming: Size: 2 Received: CLS:ACK ID:0x1 Len: 0x2 Payload: 6 9
packetCfg now valid
packetAck now valid
packetCfg classAndIDmatch
packetAck classAndIDmatch
waitForACKResponse: no data and valid ACK after 12 msec

Sending: CLS:CFG ID:0x8A Len: 0xA Payload: 0 3 0 0 1 0 21 30 E8 3
sendCommand: Waiting for ACK response
Incoming: Size: 2 Received: CLS:ACK ID:0x1 Len: 0x2 Payload: 6 8A
packetCfg now valid
packetAck now valid
packetCfg classAndIDmatch
packetAck classAndIDmatch
waitForACKResponse: no data and valid ACK after 11 msec

Sending: CLS:CFG ID:0x8A Len: 0x9 Payload: 0 3 0 0 7 0 91 20 1
sendCommand: Waiting for ACK response
Incoming: Size: 2 Received: CLS:ACK ID:0x1 Len: 0x2 Payload: 6 8A
packetCfg now valid
packetAck now valid
packetCfg classAndIDmatch
packetAck classAndIDmatch
waitForACKResponse: no data and valid ACK after 12 msec
....process: incoming "automatic" message: Class: 0x1 ID: 0x7 logBecauseAuto:1 logBecauseEnabled:0
..........Checksum failed: checksumA: 249 checksumB: 179 rollingChecksumA: 185 rollingChecksumB: 231
....................process: incoming "automatic" message: Class: 0x1 ID: 0x7 logBecauseAuto:1 logBecauseEnabled:0
....................Checksum failed: checksumA: 249 checksumB: 179 rollingChecksumA: 239 rollingChecksumB: 214
....................process: incoming "automatic" message: Class: 0x1 ID: 0x7 logBecauseAuto:1 logBecauseEnabled:0
....................Checksum failed: checksumA: 249 checksumB: 179 rollingChecksumA: 30 rollingChecksumB: 149
....................process: incoming "automatic" message: Class: 0x1 ID: 0x7 logBecauseAuto:1 logBecauseEnabled:0
....................Checksum failed: checksumA: 249 checksumB: 179 rollingChecksumA: 197 rollingChecksumB: 162
....................process: incoming "automatic" message: Class: 0x1 ID: 0x7 logBecauseAuto:1 logBecauseEnabled:0
....................Checksum failed: checksumA: 249 checksumB: 179 rollingChecksumA: 206 rollingChecksumB: 210
....................process: incoming "automatic" message: Class: 0x1 ID: 0x7 logBecauseAuto:1 logBecauseEnabled:0
....................Checksum failed: checksumA: 249 checksumB: 179 rollingChecksumA: 176 rollingChecksumB: 25

[PaulZC]

Why was CLS:CFG ID:0x8A Len: 0x9 Payload: 0 3 0 0 4 0 74 10 0 NOTACKNOWLEDGED (NACK'd)?

It's a standard CFG VALSET, setting Key 0x10740004 to 0x00 in RAM and BBR.

Ah, OK. It is UBLOX_CFG_UART1OUTPROT_RTCM3X. That's OK. We're expecting that to fail on the M10. Code is here.

[PaulZC]

It does occasionally 'get it right', but then goes back to checksum failures:

[PaulZC]

We use the callbacks in our RTK products, running RTK Everywhere Firmware on ESP32 over UART, and it works beautifully. There must be some quirk on Teensy which causes it to fail.

But this is weird. Why does the standard "AutoPVT" example (Example3_AutoPVTviaUART) work, and the callback example fails? Internally, the code is almost identical...

[PaulZC]

OK. I think I've found it. It looks like we're dropping bytes due to the 50 millisecond delay in the loop. If I comment these two lines (print and delay):

void loop()
{
  myGNSS.checkUblox(); // Check for the arrival of new data and process it.
  myGNSS.checkCallbacks(); // Check if any callbacks are waiting to be processed.

  //Serial.print(".");
  //delay(50);
}

it works continuously. If I make the same change to CallbackExample6_UseCallbackDataInLoop, that works too.

It looks like the default Teensy 3.2 UART RX buffer size is 64 bytes. NAV PVT is 100 bytes... If we don't read the data fast enough, we'll see errors due to the buffer overflowing and bytes being lost. A 10ms delay is OK, but 50 is too much.

@Turtle9er : please make the same changes and retest. Thanks!

Best wishes,
Paul

[Turtle9er]

Hi,

Removing the delay and serial print works in the simplified code, however this is part of a larger project and still having issues. I don't have any delays in my code, but will keep testing to see if I can maybe increase the UART RX buffer or something. At least i2c is working, so worse case I still with that. Thanks so much for figuring this out so quickly.

[PaulZC]

No worries! I haven't used Teensy for a while. It was good to blow the cobwebs off...

It looks like Serial1.addMemoryForRead is your friend:

"
Serial1.addMemoryForRead(buffer, size)

Increase the amount of buffer memory between reception of bytes by the serial hardware and the available() and read() functions. This is useful when your program must spend lengthy times performing other work, like writing to a SD card, before it can return to reading the incoming serial data.

The buffer array must be a global or static variable. Maximum total bufer size is 64K.
"

Link: about half way down https://www.pjrc.com/teensy/td_uart.html

[Turtle9er]

Thanks, found the same trick. Tested it out and it now works. Thanks again.

[PaulZC]

Nice one. If you're happy, please go ahead and close this. Thanks!