Pprzlink version byte

[podhrmic]

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 ?

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

[gautierhattenberger]

also note this will not work with XBee modems using API mode

[podhrmic]

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.

[OpenUAS]

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?

[gautierhattenberger]

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 ?