Pprzlink version byte
podhrmic opened this issue · 5 comments
Currently, there is no way to determine which Pprzlink version a given message has, so all nodes in the network have to know in advance which version should be used (1 or 2).
Adding a byte (it can be as simple as a different STX byte for Pprzlink 2.0) it would be possible to auto-detect the pprzlink version.
Indeed this is a significant change, so perhaps it can be made optional (like AUTODETECT_PPRZLINK_VERSION=true/false). Easy to implement on GCS side, harder on autopilot side.
This came as a feature request from one user.
What do you think @gautierhattenberger ?
Then I did the version 2 design, I had this in mind, but do to lack of time, I didn't do it in the end. Eventually, we can think about that a bit more to evaluate the impact of this change.
In the past, we actually had a 0x98 corresponding to a "timestamped" version of the messages. It is not used anymore and the code is currently commented. We could probably use it for v2.
also note this will not work with XBee modems using API mode
I am not familiar with the XBee API mode - but I guess the problem is that XBee uses a different STX? We could add a version byte in a similar way to MAVLINK, but that breaks backward compatibility which some might feel strongly about. Leaving it open for now, as I am not sure about next steps.
The way forward to close this issue could be to add STX byte 0x98 for v1 as change not v2. If no one is bothered by it in a certain grace period we can assume v1.0 is "DEAD" and unused so no need for backwards compatibility?
In which case the version of pprzlink is not matching between the GCS and an airframe ? You should have either reflashed the autopilot or have a fail at md5sum check, don't you ?