-
Notifications
You must be signed in to change notification settings - Fork 83
UBX Protocol Parsing #164
Description
Subject of the issue
When a UBX protocol packet is received, it appears to be parsed incorrectly.
Your workbench
Cypress PSoC 6
Steps to reproduce
Unless I'm missing something obvious, in SFE_UBLOX_GPS::process(uint8_t incoming, ubxPacket *incomingUBX, uint8_t requestedClass, uint8_t requestedID), when incoming is 0xB5, we set the following values:
ubxFrameCounter = 0;
currentSentence = UBX;
packetBuf.counter = 0;
activePacketBuffer = SFE_UBLOX_PACKET_PACKETBUF;
A bit later in the method...
if (currentSentence == UBX)
{
The only clause that is satisfied by the fact that ubxFrameCounter == 0 is
if ((ubxFrameCounter == 0) && (incoming != 0xB5)) //ISO 'μ'
currentSentence = NONE; //Something went wrong. Reset.
so we end up at
...
else // if (activePacketBuffer == SFE_UBLOX_PACKET_PACKETBUF)
processUBX(incoming, &packetBuf, requestedClass, requestedID);
Since activePacketBuffer == SFE_UBLOX_PACKET_PACKETBUF, we call processUBX(uint8_t incoming, ubxPacket *incomingUBX, uint8_t requestedClass, uint8_t requestedID), with incoming == 0xB5 and incomingUBX == &packetBuf.
In SFE_UBLOX_GPS::processUBX()
if (incomingUBX->counter == 0) // a.k.a. packetBuf.counter
{
incomingUBX->cls = incoming; // incoming == 0xB5
}
This assigns the packet class the value of the first sync byte, 0xB5.
Expected behavior
The packet class should be assigned the value of the third byte of the packet.
Actual behavior
The packet class is assigned the first byte of the packet, which is always 0xB5.