Hi Nathan (@nseidle),
While I was digging through the code to diagnose the maxWait timeout problem (#60), I thought about the following two suggestions (but wasn't brave enough to include them in PR #62):

• I think setting commandAck to UBX_ACK_NONE in sendCommand is possibly redundant? It gets reset in waitForResponse and I think that's the right place to do it. (I see @matthewgkerr made the same point in Unnecessary reset of commandAck #35)

• the packet .counter and .valid parameters are reset together inside process. I wonder if they should be reset separately? Let's say we do a get of a value. We get both a packetCfg and packetAck in return. Let's say they are followed immediately by an AutoPVT packet, checkUbloxSerial (and possibly checkUbloxI2C) will keep processing bytes and process will reset .counter and .valid for both the Cfg and Ack packets. If you made the following change, it would allow the Ack.valid to remain true and so the sendCommand which started all this would return true instead of timing out?

I'm suggesting changing these lines from this:

 else if (ubxFrameCounter == 2) //Class { packetAck.counter = 0; packetAck.valid = false; packetCfg.counter = 0; packetCfg.valid = false; //We can now identify the type of response if (incoming == UBX_CLASS_ACK) ubxFrameClass = CLASS_ACK; else ubxFrameClass = CLASS_NOT_AN_ACK; } 

to this:

 else if (ubxFrameCounter == 2) //Class { //We can now identify the type of response if (incoming == UBX_CLASS_ACK) { packetAck.counter = 0; packetAck.valid = false; ubxFrameClass = CLASS_ACK; } else { packetCfg.counter = 0; packetCfg.valid = false; ubxFrameClass = CLASS_NOT_AN_ACK; } } 

Worth a thought?
Enjoy!
Paul