So this API can be used to send frames with a different encoding than
UBX. This enables UBX drivers to send RTCM3 correction frames using UBX
API, without having to switch over modem pipes.
Signed-off-by: Luis Ubieda <luisf@croxel.com>
During testing and code inspection, there were various anti-patterns
on this (and U-Blox driver) codebase(s), including obfuscation, and
lack of data validation. This made it increasingly difficult to
introduce further variants of u-blox GNSS modems.
With this patch, both the UBX modem and the M8 driver have been
refactored to ease the reliability and maintainability of these
codebases. Here are some highlights:
WRT UBX modem:
- Helper macros to easily create UBX frames, (including checksum
calculation), at compile time; thus, making it easier to extend UBX
commands.
- Logic validation by the inclusion of the modem_ubx testsuite, used to
refactor the code through TDD.
- Ability to receive unsolicited messages, in order to enable U-Blox
drivers to rely on modem_ubx to transceive all commands, and avoid
hopping between modem_ubx and modem_chat.
WRT M8 driver:
- Remove GNSS specific protocol header files. Instead, unify them under
modem/ubx/protocol.h. Background: After a survey and looking at ubxlib
SDK I conclude the UBX protocol is by definition a GNSS protocol (there
are non-GNSS u-blox modems, but they're not interfaced through UBX
protocol).
- Establish pattern to create and send/receive commands using new
foundations on modem ubx.
- Remove dependency of Modem chat, and instead use UBX unsolicited
messages to get Navigation and Satellites data.
- Switch from the auto-baudrate detection pattern to a pattern of
transitioning between an initial known baudrate to a desired baudrate,
in order to improve initialization time.
- Add dts property to configure default fix-rate.
Signed-off-by: Luis Ubieda <luisf@croxel.com>
The U-Blox M10 seems to interleave UBX and NMEA messages in a way that
confuses the M8 driver leading to missing the same message that directly
follows the UBX part every time (leading to no navigation updates).
As the driver does not parse the UBX blocks during normal operation anyways
it can just be disabled.
Signed-off-by: Jakob Riepler <jakob+zephyr@chaosfield.at>
The driver in tree is for u-blox M8 devices, not M10. The M10 series
devices (from Protocol Version 23.01) use a different, non backwards
compatible interface for configuring the modem behaviour.
Of the two boards tested in the original PR, the "VMU RT1170" is
explicitly listed as having a u-blox NEO-M8N modem, while I have
been unable to find any information online about the "FMURT6" board.
Leaving the naming as-is will cause problems when M10 drivers are
contributed.
Signed-off-by: Jordan Yates <jordan@embeint.com>
