Library currently fails when using SoftwareSerial

[PaulZC]

Subject of the issue

The recent changes made to the processing of ACKs and NACKs seems to have broken the library on SoftwareSerial.

Your workbench

ATmega328 RedBoard Qwiic (DEV-15123)
ZOE-M8Q Qwiic Breakout
I'm connecting via SoftwareSerial (RX on Pin 2, TX on Pin 3)

Steps to reproduce

Run the new updated Example 18

Expected behavior

I'd like things to go back to how they were...

Actual behavior

I'm seeing many failures. The UBX data just doesn't seem to be being parsed correctly at all.

Possible Root Cause

This is a hopefully logical train of thought that leads to the possible root cause:

• sendCommand sends a packet and then does a waitForResponse
• waitForResponse will return true if:
  • checkUblox returns true (and it always returns true for Serial)
  • AND packetAck.valid is true and commandAck is UBX_ACK_ACK
  • OR packetCfg.valid is true and packetCfg.cls and packetCfg.id match the requested class and ID
• packetCfg.valid and packetAck.valid are both cleared at the start of waitForResponse
• commandAck is reset to UBX_ACK_NONE at the start of waitForResponse and at the start of sendCommand (I think the one in sendCommand is redundant)
• packetCfg.valid and packetAck.valid are both cleared by process when ubxFrameCounter reaches 2
• .valid is set true by processUBX if the checksum matches
• commandAck is set by processUBXpacket immediately after .valid has been set by processUBX (so there is essentially zero gap in time between the two)
• checkUbloxSerial will keep calling process until serial.available returns false (I think the equivalent is true for checkUbloxI2C)
• SO, it is possible that in a single call to checkUblox, from inside waitForResponse, both packetCfg.valid and packetAck.valid could become true if the ACK arrived hot on the heels of the Cfg packet or vice versa
• BUT, because packetCfg.valid and packetAck.valid are both cleared by process when ubxFrameCounter reaches 2, only packetAck.valid or packetCfg.valid will be true at the end of the call to checkUblox
• previously waitForResponse didn't check that packetAck.valid was true when checking commandAck. It returned true if commandAck was true, and so it didn't matter if packetAck.valid had been cleared. Now it does!

I need to give up on this now and go wrap some presents. But I will dig into this again after the festivities. I just wanted to give you the heads-up that the new changes have caused problems.

I also need to check if the same thing happens when using hardware serial, or if this is limited to softwareserial.

Merry Christmas!
Paul

[PaulZC]

Pin 2 was being used for checksum failure analysis by processUBX. That certainly won't have helped. (I've been using Pin 2 as my SoftwareSerial RX pin!). PR #61 corrects this.

[PaulZC]

I see the same problems when using hardware serial, so it is not limited to softwareserial.
I think this might be just related to timeouts, not to the new ACK/NACK code.
Now that we are passing down maxWait correctly, if we call (e.g.) getLatitude its default maxWait of 250 msec gets passed down to getPVT. Whereas the default for getPVT on its own is 1000 msec.
It looks like I might have fixed it by changing the default maxWaits for getLatitude etc....
More later!
Happy Boxing Day,
Paul

[PaulZC]

Hi Nathan (@nseidle),
Yup. It was the flow down of the default maxWaits that was causing the problem. PR #62 fixes this.
I've captured the critical bit of the above Possible Root Cause thought experiment in #63.
This issue can be closed once the PR has been merged.
Enjoy!
Paul

[nseidle]

Merry Christmas! Sorry for breaking the lib. This is why I haven't done a release. Needs more testing but I believe you've fixed the first cause of problems (trickle down of maxWaits). I'm closing this issue but I've got a lot of work and testing to do on the BetterNACKHandling branch.