Companion Protocol: RESP_CODE_TUNING_PARAMS deviation

[PeterGrace]

In the Companion Radio wiki documentation, the following payload is specified for RESP_CODE_TUNING_PARAMS:

CMD_SET_TUNING_PARAMS {    // RESP_CODE_TUNING_PARAMS uses same
  code: byte,   // constant 21
  rxdelay_base: uint32,    // rxdelay * 1000
  airtime_factor: uint32   // airtime factor * 1000
  reserved: bytes(8)    // set to zero
}

In actual testing, response payload is: [23,0,0,0,0,232,3,0,0]

Shouldn't the returned reserved field be 8 bytes of zero according to the spec?

[liamcottle]

If it were me, I'd just remove the reserved: bytes(8) // set to zero line from the wiki, otherwise we will have two legacy versions of firmware in the wild, one that doesn't append zeros in code, and another that does.

Which means we wouldn't be able to use length checking to see if newly added parameters exist or not in the future.

I personally don't think sending these zero bytes on the wire is needed. Thoughts @ripplebiz?

The mobile app never sent those empty 8 bytes either, as it wasn't read by the firmware.

[PeterGrace]

@liamcottle is there a canonical documentation source for companion protocol, or is it "Read the source from examples/companion_radio?" I've found several things that that code does, which is not documented in the wiki.

[liamcottle]

@PeterGrace currently the source code is the source of truth for how the protocol actually works, and the wiki is just a helpful starting point so it's easier to get going without reading all of the source code. We could of course improve the wiki or produce a real spec document, but things are still in rapid development so things may change.