I am a bit confused at the ping protocol messages around protocol version, firmware version, device type, device model and device revision.
For Common :
message 4 has dev_type [u8] and dev_revision [u8], and firmware version as [u8]:[u8]:[u8].
message 5 has the protocol version as [u8]:[u8]:[u8].
But then moving to the Ping1d specific messages for the same information:
message 1200 has device type [u8] and device model [u8] that both seem to be covered by the dev_type field from common message 4
message 1200 also has the firmware version, but this time as a [u16]:[u16], so the major and minor fields can takes on unlikely large values and patch field is absent.
It looks like the protocol has evolved. Should I check all of these fields? Are the major and minor versions of 1200 really only [u8] and the should the patch_version in 4 be ignored?
I can read all these messages, but it’s not clear to me which fields are essential and which are deprecated, if any.
All I really need to know is how much I need to read to ensure that the driver can recognise when it should be allowed to talk to the device that is plugged in and when it should instead report a compatibility error.
For some context here, ping protocol is intended as a means of collaboration between device designers (who aren’t directly working together) and interfacing software developers (who may have no connection to the device designers / firmware developers).
I’ve just touched on this in my latest response in your Ping1D firmware thread, but the protocol started out with message sets relevant for two specific devices, and has expanded from there largely at the whims of device designers, without much consideration for cross-device consistency. I consider it in need of a cleanup, so it can better serve as a unifying protocol, ideally without redundancy, and fully supportive of new features which may not yet be implemented.
The protocol version is intended to capture updates, but is challenging to increment in a synchronised fashion with changes in individual message sets, especially since firmware versions (which currently need to report the protocol version they support) may be released before official support for their new features is recognised in the protocol.
I believe it got updated to v1.1.0 to reflect some updates in the ping360 message set, but beyond that I don’t believe it has been meaningfully updated or accounted for in existing software or firmware - changes have just been made in firmware releases and eventually trickled into the protocol so they can be supported in the official versions of the available libraries and the like.
There is indeed some redundancy in the device type field, although the device model (e.g. Ping Sonar) and device revision (e.g. original variant) are principally distinct, so the messages aren’t completely identical. That said, I don’t expect fields other than the device type to be particularly meaningful (or adhered to) at the moment
I’m not sure why the common one wasn’t just used for this, since the extra number range seems unnecessary, and the patch field can actually be meaningful in some instances (although it’s yet to be used in Ping Sonar firmware). I’d be inclined to just use the common one (4) for this, although it’s worth at least a cursory check that the devices you’re explicitly supporting actually implement the message.
Right now the key components would be:
device type
if unknown, maybe provide a warning that it’s likely unsupported, even if you then allow the driver to try to perform its other functions?
protocol version
if major > 1 then expect it doesn’t work and raise an error, and if minor > 1 then maybe provide a warning that some new protocol features may not be supported?
