ublox-rs/ublox

Rust crate to talk UBX protocol to u-blox GPS devices.

ublox's Issues

Looking for a new maintainer

Much though I would like to pretend, it is now apparent to me that I haven't the time or resources to maintain this crate like it deserves. It's been a great run and the community has really turned this into a crate to be proud of.

So, if anyone wants to take over ownership of this crate, let me know!

u-blox M8 not working? (UbxUnknownPacketRef)

Hardware: Geekstory USB GPS Module Antenna Supports GPS+GLONASS Beidou Built-in Flash for Arduino Pixhawk IPEX Compatible, Better Than VK-162 https://www.amazon.com/gp/product/B07ZR8R17Q/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

$ uname -a
Darwin MacBook-Air.local 22.5.0 Darwin Kernel Version 22.5.0: Thu Jun  8 22:21:34 PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T8112 arm64
$ cargo run -- --port /dev/cu.usbmodem11401
    Finished dev [unoptimized + debuginfo] target(s) in 0.03s
     Running `target/debug/ublox_cli --port /dev/cu.usbmodem11401`
Opened u-blox device, waiting for solutions...
Unknown(UbxUnknownPacketRef { payload: [82, 79, 77, 32, 67, 79, 82, 69, 32, 51, 46, 48, 49, 32, 40, 49, 48, 55, 56, 56, 56, 41, 0, 0, 0, 0, 0, 0, 0, 0, 48, 48, 48, 56, 48, 48, 48, 48, 0, 0, 70, 87, 86, 69, 82, 61, 83, 80, 71, 32, 51, 46, 48, 49, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 80, 82, 79, 84, 86, 69, 82, 61, 49, 56, 46, 48, 48, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 71, 80, 83, 59, 71, 76, 79, 59, 71, 65, 76, 59, 66, 68, 83, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 83, 66, 65, 83, 59, 73, 77, 69, 83, 59, 81, 90, 83, 83, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], class: 10, msg_id: 4 })

There's a support document on the Amazon product page https://m.media-amazon.com/images/I/91+EnzD0qpL.pdf that mentions u-block u-center (M9 and below)

Still trying to identify which u-blox product it is...?

Edit: found it u-blox M8 (ProductID = 0x01A8, VendorID = 0x1546)

How to get length of parsed packet?

Given a PacketRef obtained from a parser iterator, how do you get the packet's original encoded length? There's a class_and_msg_id() method on PacketRef, but I don't see anything similar for length (bytes at offsets 4 and 5).

Release v0.4.3 needs a new release of ublox_derive

Currently, trying to use ublox = "0.4.3" from crates.io fails with errors like:

error: Not supported type, expect one of "u8, i8, u16, i16, u32, i32"
    --> C:\Users\matth\.cargo\registry\src\index.crates.io-6f17d22bba15001f\ublox-0.4.3\src\ubx_packets\packets.rs:1709:15
     |
1709 |     cfg_data: &'a [CfgVal],
     |   
error: expected one of: `map_type`, `scale`, `alias`, `may_fail`, `from`, `is_valid`, `get_as_ref`, `into`
    --> C:\Users\matth\.cargo\registry\src\index.crates.io-6f17d22bba15001f\ublox-0.4.3\src\ubx_packets\packets.rs:3069:9
     |
3069 |         size_fn = data_len,
     |    
error[E0412]: cannot find type `EsfMeas` in this scope
    --> C:\Users\matth\.cargo\registry\src\index.crates.io-6f17d22bba15001f\ublox-0.4.3\src\ubx_packets\packets.rs:3082:6
     |
3082 | impl EsfMeas {
     |      ^^^^^^^ not found in this scope
     |
help: there is an enum variant `crate::PacketRef::EsfMeas`; try using the variant's enum
     |
3082 | impl crate::PacketRef {
     |      

This is because v0.4.3 requires the changes which have been made to ublox_derive since its v0.0.4 release. Overriding the ublox_derive dependency to use the new code fixes the errors, e.g.

[patch.crates-io]
ublox_derive = { git = "ssh://[email protected]/ublox-rs/ublox.git", tag = "ublox-v0.4.3" }

I also noticed that the ublox_derive-v0.0.4 tag points to the same commit as ublox-v0.4.3, rather than its release commit which I think is the tag v0.4.0.

One other minor thing I noticed is that 0.4.3 on crates.io includes the changes from #67 which is after the ublox-v0.4.3 tag, so the ublox-v0.4.3 tag could be changed to 8f3e5e2. I checked this by using cargo vendor and diff against a git checkout.

I see that this crate was moved to an org recently. I'd be happy to help out maintaining this crate if you need an extra set of hands!

How to support repeated structs?

We are looking at adding the NavSat message, but it there doesn't seem to be a way to support repeated structs. Is there a way to do this or is it just not supported yet?

repo ref in manifest missing

Slate a release so this repository can be found easier from crates.io

rp2040 neo6m

Hi,

I'm struggling to talk to a neo 6m chip via uart of an rp2040. Actually, I can send and receive data but I'm not receiving an ACK from the ublox chip. Since the neo6m is EOL I was wondering if that chip is maybe not supported by this crate.
Cheers

Parser should return how many bytes are needed.

Currently, when the buffer length is < 6, None is returned. Instead, the parser should return the minimum number of bytes needed to progress, similar to nom's Err::Incomplete variant.

NavPosVelTime packet not being received?

MacBook-Air:ublox brandon 2023-08-02 13:05:13 $ cargo run --bin ublox_cli -- --port /dev/cu.usbmodem1301
   Compiling ublox_cli v0.1.0 (/Users/brandon/Desktop/ublox/ublox_cli)
    Finished dev [unoptimized + debuginfo] target(s) in 0.29s
     Running `target/debug/ublox_cli --port /dev/cu.usbmodem1301`
Opened u-blox device, waiting for solutions...
SW version: ROM CORE 3.01 (107888) HW version: 00080000
MonVer { software_version: "ROM CORE 3.01 (107888)", hardware_version: "00080000", extension: MonVerExtensionIter { data: [70, 87, 86, 69, 82, 61, 83, 80, 71, 32, 51, 46, 48, 49, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 80, 82, 79, 84, 86, 69, 82, 61, 49, 56, 46, 48, 48, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 71, 80, 83, 59, 71, 76, 79, 59, 71, 65, 76, 59, 66, 68, 83, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 83, 66, 65, 83, 59, 73, 77, 69, 83, 59, 81, 90, 83, 83, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], offset: 0 } }

how long would you expect to have to wait before seeing NavPosVelTime come across? would it come across if there was no fix/it was in the process of getting a fix?

Setup matrix CI builds

With the recent additions, this component is starting to have multiple features. The CI pipeline may be able to be setup to support matrix builds.

Along with that, consider the creation of a test suite that talks to actual hardware.

separate protocol and implementation?

@lkolbly
I use ublox GPS receiver, but it is connected via SPI on my board.
Do you interesting split this crate into two: one for UBX protocol and other part with rs232 and so on?

Proper Versioning Support

This project has so far been really bad about handling different versions of the protocol. For examples, see #33 and #24. The goal of this project is to support "all" versions of the protocol, but so far the API pretends that all protocols are the same.

I'm kind of leaning towards defining a module per version. For example, an import might look like:

use ublox::m8::NavRelPosNed;

This has the advantage that there is a clear delineation of protocols, and what packets are supported in which protocol. But at the same time, it means that extra work must happen to take advantage of similarities between protocols. If the user just wants to parse some simple packet that is common across many versions, and they want their binary to be somewhat device-agnostic, then they must separately parse each version:

if talking_to_m8 {
    // Parse a ublox::m8::NavPosLlh
} else if talking_to_f9p {
    // Parse a ublox::f9p::NavPosLlh
}

Additionally, although there is a clear delineation across broad-stroke "m8", "m7", "f9p" labels, there isn't much ability to focus on sub-product version changes. For example, UBX-CFG-TMODE3 on M8 is only supported in protocol versions 20.x, even though "m8" is protocol versions 15 through 23. So the packet would appear to be supported, and the parser would be generated, for all "m8" products. I think that might be fine though.

Anyway. I'm creating this issue so that there's one place to discuss this issue as a whole. My intent is that this is the next minor-bumping release (so, 0.5.0).

Consider using heapless::Vec?

Hi,

I have just started using this crate. It is very useful, however as someone using it in a #![no_std] environment (Cortex-M), having to use an allocator is cumbersome. Have you considered using heapless::Vec instead of std::Vec (or letting the user decide?) Another great option could be using something like BBQueue.

Even though it's not strictly necessary, I think it would be a great improvement since many people using ublox devices do so on embedded systems with very limited resources.

0.4.5 breaks API over 0.4.2

I have a project built against 0.4.2 which suddenly stopped working with compiler errors.

cargo is free to upgrade between "patch" versions, like from 0.4.2 to 0.4.5 as patch versions are not allowed to change the API. Some changes from 0.4.2 to 0.4.5 introduced API changes and should have come with an increase in the minor version number, e.g. "0.5.0".

It is too late for this now, but would be great for the future to only do API changes only via minor version number increase. More info here: https://semver.org

Workaround is to pin the version using "=0.4.2", but this is generally considered bad practice.

Incorrect fixed payload length for NavPosVelTime?

Hi! Thanks for the great crate!

I'm working off of the u-blox 7 Protocol Specification V14 document.

The payload length of the NavPosVelTime should be 84 bytes according to this spec. See NAV-PVT on page 158. If you are working off a different spec that no longer matches this it's probably best to note what version you support in the README.

https://github.com/lkolbly/ublox/blob/6422f57cf98aa39e3660377de295909e40eeb499/ublox/src/ubx_packets/packets.rs#L90