Coder Social home page Coder Social logo

ublox's Introduction

uBlox for Rust

Rust ublox on docs.rs MIT licensed rustc v1.65

This project aims to build a pure-rust I/O library for uBlox GPS devices, specifically using the UBX protocol.

Examples of usage of the library can be found in the examples/ directory. A basic CLI for interacting with an uBlox device can be found in examples/ublox-cli directory. See the specific examples/README.

Constructing Packets

Constructing packets happens using the Builder variant of the packet, for example:

use ublox::{CfgPrtUartBuilder, UartPortId, UartMode, DataBits, Parity, StopBits, InProtoMask, OutProtoMask};
let packet: [u8; 28] = CfgPrtUartBuilder {
   portid: UartPortId::Uart1,
   reserved0: 0,
   tx_ready: 0,
   mode: UartMode::new(DataBits::Eight, Parity::None, StopBits::One),
   baud_rate: 9600,
   in_proto_mask: InProtoMask::all(),
   out_proto_mask: OutProtoMask::UBLOX,
   flags: 0,
   reserved5: 0,
}.into_packet_bytes();

For variable-size packet like CfgValSet, you can construct it into a new Vec<u8>:

use ublox::{cfg_val::CfgVal::*, CfgLayer, CfgValSetBuilder};
let packet_vec: Vec<u8> = CfgValSetBuilder {
    version: 1,
    layers: CfgLayer::RAM,
    reserved1: 0,
    cfg_data: &[UsbOutProtNmea(true), UsbOutProtRtcm3x(true), UsbOutProtUbx(true)],
}
.into_packet_vec();
let packet: &[u8] = packet_vec.as_slice();

Or by extending to an existing one:

let mut packet_vec = Vec::new();
CfgValSetBuilder {
    version: 1,
    layers: CfgLayer::RAM,
    reserved1: 0,
    cfg_data: &[UsbOutProtNmea(true), UsbOutProtRtcm3x(true), UsbOutProtUbx(true)],
}
.extend_to(&mut packet_vec);
let packet = packet_vec.as_slice();

See the documentation for the individual Builder structs for information on the fields.

Parsing Packets

Parsing packets happens by instantiating a Parser object and then adding data into it using its consume() method. The parser contains an internal buffer of data, and when consume() is called that data is copied into the internal buffer and an iterator-like object is returned to access the packets. For example:

use ublox::Parser;
let mut parser = Parser::default();
let my_raw_data = vec![1, 2, 3, 4]; // From your serial port
let mut it = parser.consume(&my_raw_data);
loop {
    match it.next() {
        Some(Ok(packet)) => {
            // We've received a &PacketRef, we can handle it
        }
        Some(Err(_)) => {
            // Received a malformed packet
        }
        None => {
            // The internal buffer is now empty
            break;
        }
    }
}

no_std Support

This library supports no_std environments with a deterministic-size Parser. See the documentation for more information.

Minimum Supported Rust Version

The library crate will support at least the previous year's worth of Rust compilers. Currently, the MSRV is 1.65.0. Note that, as we are pre-1.0, breaking the MSRV will not force a minor update - the MSRV can change in a patch update.

ublox's People

Contributors

lkolbly avatar adrian-kong avatar reitermarkus avatar gwbres avatar aholtzma-am avatar dushistov avatar maximeborges avatar andrei-ng avatar digital-gemini avatar niclasj avatar mattico avatar afonso360 avatar drahnr avatar jbeaurivage avatar larsjaeger avatar resset avatar

Stargazers

Dhruv Gramopadhye avatar Gaute Hope avatar Aaron Covrig avatar Patrick Recher avatar Ren Lawrence Lin avatar Nick avatar Deniz Hofmeister avatar  avatar Kristoffer Berdal avatar Yuil avatar  avatar Francesco Marcato avatar bazingaJojo avatar Alexander van Saase avatar Amadeusine avatar Hideaki Tai avatar Lachezar Lechev avatar  avatar  avatar Mike avatar Muhammad Ragib Hasin avatar Luis Roel avatar  avatar Giovanni Cammisa avatar chris m avatar Andrew Gazelka avatar Przemysław Węgrzyn avatar  avatar Tim Docker avatar  avatar Adit Sachde avatar John Wass avatar  avatar  avatar Marcel avatar  avatar  avatar Claudio Vesco avatar  avatar  avatar Runchao Han avatar Jacob Tinkhauser avatar Yishen Miao avatar Rust avatar  avatar

Watchers

yuanhong avatar  avatar  avatar  avatar  avatar  avatar

ublox's Issues

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).

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?

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

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?

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

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.

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!

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!

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.

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.

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)

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).

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.