Skip to content

Conversation

jbangelo
Copy link
Collaborator

@jbangelo jbangelo commented Aug 15, 2025

The original massive branch with everything re-written in Rust. I think I'll be breaking this up into smaller PRs for ease of reviewing.

The desire is to re-write as much functionality in native Rust and remove the dependency on the C library. Depending on the C library complicates the builds and can cause issues in downstream applications.

jbangelo added a commit that referenced this pull request Aug 26, 2025
The second chunk of changes from
#122.

This re-implements the GNSS signal related types of functionality in
native Rust

## What's been changed

- The `signal` module has been broken up into multiple files, though
these extra files are not visible via the public API
- The various string conversion functions have been moved to utilize the
derive macros from the [`strum`
crate](https://docs.rs/strum/0.27.2/strum/index.html), but the actual
string values have remained the same
- Conversions to/from `swiftnav-sys` integer types has been replaced
with conversions to/from native Rust integer types
- The conversion error types have changed to no longer contain the
`swiftnav-sys` types and instead contain native Rust types
- The error types use the [`thiserror`
crate](https://docs.rs/thiserror/latest/thiserror/) to reduce boiler
plate code

## What's been removed

- `Code::sig_count()`
- `Code::chip_count()`
- `Code::chip_rate()`

## What's been added

- The `signal::consts` module
- `Constellation::sat_count()`
- `Constellation::first_prn()`
- `Code::get_carrier_frequency()`
- `Code::get_glo_channel_frequency()`
- `GnssSignal::carrier_frequency()`
- `GnssSignal::get_glo_channel_frequency()`

---------

Co-authored-by: Alejandro Duarte <[email protected]>
jbangelo added a commit that referenced this pull request Aug 30, 2025
The next chunk of changes from
#122.

This re-implements the time related functionality in native Rust. This
one is a bit larger, mostly from the fact that the conversions in the C
implementation are very inter-dependent and so several new bits of
functionality were pulled in to make the Rust implementation mirror the
C implementation. There's a few bits of functionality thrown out because
they caused some significant unsoundness, but I'm sure there is still
several bits of unsoundness in this translation (e.g. several
panics/asserts are still present). I'd prefer to keep this PR as close
to a straight translation as possible, and re-consider the soundness
concerns in a future PR.

## What's been changed

- I don't think any implementations are still present but meaningfully
modified

## What's been removed

- `GloTime` - GLONASS time is particularly complicated and rarely used
- `GpsTime::to_glo()` and `GpsTime::to_glo_hardcoded()` - See above
- `impl Sub<GpsTime> for GpsTime` - It turns out a `std::time::Duration`
can't hold a negative value. This implementation would occasionally
panic because of this. [The `chrono`
crate](https://docs.rs/chrono/latest/chrono/#time-delta--duration)
handles this better, maybe we can move towards their approach in a later
PR?
- `UtcParams::decode()` - Decoding low-level messages seem unlikely to
be needed
- `impl Default for UtcParams` - Defaulting this data can cause
unexpected errors
- `impl Default for UtcTime` - Defaulting this type can cause unexpected
errors

## What's been added

- The `time::consts` module
- `GpsTime::from_date()` and `GpsTime::from_date_hardcoded()`
- `GpsTime::to_mjd()` and `GpsTime::to_mjd_hardcoded()`
- `GpsTime::to_date()` and `GpsTime::to_date_hardcoded()`
- `UtcTime::to_date()`
- `MJD::to_gps()` and `MJD::to_gps_hardcoded()`
- `MJD::to_date()`

---------

Co-authored-by: Alejandro Duarte <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant