updating H1-POS parsing #25
Conversation
- stripping off checksum for parsing - Adding altitude - Removing timestamp, no other messages use it. If we want it back, we should use the waypoint valid at field as it is in every variant (though missing year/month/day) - Removing regexes. now the the only special code is for variant 2 - added test for message that was not parsing
Perhaps there is value for retaining to an attribute for later. I could see validating the message once we figure out the checksum formula.
What explicitly does the timestamp correlate to? |
|
@kevinelliott - definitely on board for adding the checksum to the result, I just didn't because i didn't see a checksum pulled out anywhere else, so i didn't know the best way to add it to the formatted result As for the timestamp, i took it out because i'm pretty sure it's a "data valid" flag for the adjacent field. The end of variant1is |
I would think at minimum just putting the checksum into the raw data structure as a field that can be later pulled (note that while some users of this decoder, such as UIs, may never use it, backend Airframes may use it for historical storage and other things). For formatted outputs, yeah, that can be skipped for sure.
Interesting! If we believe that the timestamp is correlated to confirmation of when a waypoint was either reached (or is forecasted/estimated to be reached), we should definitely capture and correlate with the waypoint. This helps to reconstruct the route according to what the airframe thought it did (versus what external systems measuring it thought it did). |
|
I'll add checksum to the raw result. I'd like your opinion on how to represent this route timing information in the decodeResult before i move forward on that part, though, Maybe we can take it to discord or something. |
Great! Yeah we can chat on Discord any time. Previously we have basically composed the raw structure as consistently as possible across decoder imps, but there has been no hard standard yet, mostly because there were only a few of us working on it before, and also because... discovery. But I think we could probably start forming stronger opinions around the raw/formatted/etc structures and the overall decoded result structure itself. In the short term (for the sake of keeping things moving forward for this PR for example), I'd say an array of positions representing the route (named, apropos,
I can already think of all sorts of issues with this, and I'm already second guessing (for example, thinking the type unnecessary, and to instead embed a sub object named by the type itself -- such as Then we'll have to get together on Discord (with me and @andermatt64 and maybe even Fred) and hash out some standards. I think we could have a pretty lively (productive) convo. |
- waypoint has a name, optional position, and optional time - moved `decodeStringCoordinates` and `coordinateString` into utils class
There could be others that start with `POS/` but i haven't found any. being explicit instead offailing Also adding checksum to the result
| }); | ||
|
|
||
| decodeResult.decoded = true; | ||
| // Once we know what RF stands for, I feel comfortable marking this full |
There was a problem hiding this comment.
ChatGPT thinks it might be "Route Fix" - i haven't found other messages that start with POS/ to know for sure
kevinelliott
left a comment
kevinelliott
left a comment
There was a problem hiding this comment.
Nice work. Looks good to me.
| }); | ||
|
|
||
| decodeResult.decoded = true; | ||
| // Once we know what RF stands for, I feel comfortable marking this full |
2 participants
POS/looking messages