Extend DSHOT telemetry

[damosvil]

At the current time DSHOT telemetry is very limited. It can send back to FC eRPM value and nothing else. There are cases where it would be very advisable to send other telemetry values back to FC.

Proposal: Use eRPM 0x0FFF telemetry value as a escape frame.

When one escape frame is sent back to FC, ESC is signaling the FC that the next telemetry frame (extended telemetry frame) will contain extended telemetry data than eRPM data. If two escape frames, one after the other are sent back to FC, it means that 0 eRPM is being sent back to the FC. After receiving extended telemetry frame the FC will expect normal or escape telemetry frame next.

As a telemetry frame can be corrupted, if FC is not expecting an extended telemetry frame, but the corrupted frame could have been an escape one, the next frame shall be discarded. If FC is expecting an extended telemetry frame, and the new frame is corrupted the FC simply discards the frame and will expect a normal or escape telemetry frame next.

Extended telemetry frame format

The extended telemetry frame will be just like the normal telemetry frame as regards the crc. The first 4 bit contains extended telemetry data type, and the next 8 bit with contain the value.

Extended telemetry frame examples

Type 0 ---->>>> data will be temperature in format [0 = -53ºC ---- 254 = 200ºC]
....
....
....
Type 14 ---->>>> data will be debug value high
Type 15 ---->>>> data will be debug value low

Extended telemetry data scheduling

As DSHOT cannot trigger extended telemetry data, the proposal is to schedule it on the firmware side.

Extended telemetry data scheduling examples

1: Type 0, 800ms
2: Type 14, 100ms
3: Type 15, 100ms
So Type 0 will be sent 800ms after starting, type 14 100ms after type 0, type 15 100ms after type 14, and then the scheduling starts over again.

[damosvil]

Found a better way to do this. DHOT telemetry codification repeats almost 50% the values it codes