search

AeroRust / nmea

NMEA 0183 - for communication between marine electronics such as echo sounder, sonars, anemometer, gyrocompass, autopilot, GNSS receivers and many other types of instruments. Defined and controlled by the National Marine Electronics Association (NMEA)
https://crates.io/crates/nmea
Other
56 stars 41 forks source link

Parsing of vendor-specific extended sentences that are not included in the `SentenceType` fails. #90

Open ekuinox opened 1 year ago

ekuinox commented 1 year ago

Regardless of the sentence type, if it is correct as NMEA0183, one would expect it to be parsed using nmea::parse_nmea_sentence, but parsing fails if it is not included in SentenceType.

I don't have any ideas about what to do with the existing PGRMZ, but would it be possible to add an enumerator like VendorExtension(&str) to the SentenceType to handle it?

elpiel commented 1 year ago

There's definitely a place for improvement here. It makes sense to keep our current validation process - if we don't have a parser for the sentences - return an error, however, we could improve the vendor specific sentences although not sure what you envision for it.

PGRMZ is the only Vendor specific sentences and I think it's a good time to discuss how we should handle them

ekuinox commented 1 year ago

For example, if the talker is P and the following vendor code is ABC and the following buffer is abcdefg*hh, I want NmeaSentence to be

NmeaSentence {
  talker_id: "P",
  message_id: SentenceType::VendorExtension("ABC"),
  data: "abcdefg",
  checksum: hh,
}

I would like to make sure that PGRMZ, which already has an implementation, can also fit into this form once without being treated as special.

elpiel commented 6 months ago

Ok, so my current line of thought is to allow a callback for parsing unknown sentences, which will be great to the user as they will add the vendor-specific sentences instead of us. A few things to consider: