You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 28, 2021. It is now read-only.
Hi,
This is just an observation that will (hopefully) be trumped by multi-valset #20
If you define a custom ubxPacket which holds (e.g.) a UBX-CFG-VALSET message and then send it with sendCommand, it will always timeout as the commandAck checking in processUBXpacket (called from waitForResponse \ checkUblox \ checkUbloxI2C \ process \ processUBX) expects the packet class and ID to be defined in packetCfg, not the custom packet.
The offending line is:
if (msg->id == UBX_ACK_ACK && msg->payload[0] == packetCfg.cls && msg->payload[1] == packetCfg.id)
It would be possible to correct this by passing the requestedClass and requestedID from waitForResponse further down the food chain.
Cheers,
Paul
The text was updated successfully, but these errors were encountered:
Strictly this Issue should probably stay open as I haven't actually fixed it with PR #30 but the problem has gone away as the new newCfgValset, addCfgValset and sendCfgValset functions for Issue #20 work on packetCfg and don't require a custom packet.
I propose we close this though as life really is too short!
Hi,
This is just an observation that will (hopefully) be trumped by multi-valset #20
If you define a custom ubxPacket which holds (e.g.) a UBX-CFG-VALSET message and then send it with sendCommand, it will always timeout as the commandAck checking in processUBXpacket (called from waitForResponse \ checkUblox \ checkUbloxI2C \ process \ processUBX) expects the packet class and ID to be defined in packetCfg, not the custom packet.
The offending line is:
if (msg->id == UBX_ACK_ACK && msg->payload[0] == packetCfg.cls && msg->payload[1] == packetCfg.id)
It would be possible to correct this by passing the requestedClass and requestedID from waitForResponse further down the food chain.
Cheers,
Paul
The text was updated successfully, but these errors were encountered: