bird-sanctuary / extended-dshot-telemetry Goto Github PK

Some feedback:

1. With regards to the ESC/FC scheduling of the data, the FC's are already under high-load and ideally should not be 'force-fed' data they don't need. The FC should tell the ESC what data it wants, and the frequency of the data.
2. As noted elsewhere recently the data that people needs changes over time, hence this spec attempt in the first place right?, but an evolving protocol and addition of new frames with new data types and deprecation of old frames with old data types comes at a high cost for everyone involved with consuming the frames that /may/ be given. Then there's also the backwards compatibility issue, should FC firmware be forced to be recompiled and re-released when a frame type with different data is added? Probably not as it incurrs a release cycle of the FC software with all the testing overhead that a release cycle entails.
   We've seen this all before, with various RC protocols such as MSP, LTM, FrSky TLM, SmartPort, CRSF, etc.

IMHO, a flexible frame format, with minimal per-frame overhead, is required.

Perhaps one that uses a discovery, subscription, broadcast and request/response.

I detailed an example solution to this for the CRSF spec, here:

tbs-fpv/freedomtx#26 (comment)

A similar approach could be used for DSHOT telemetry.

The main limitation we have with dshot however is the amount of bits that can be sent in one dshot frame.

So perhaps instead of trying to pre-determine ALL the data that you'll ever need to send now, which you'll likely want to change in the future, maybe split the data over multiple frames.

e.g. FC says:

"I want value X at frequency Y," but say value X is a 16 bit value, so the ESC maybe sends 3 frames to get the data from the ESC to the FC at frequency Y.

1. 001 0 + iiiiiiii -> 8 bit identifier
2. 010 0 + hhhhhhhh -> first 8 bits (msb first) of the 16 bit value.
3. 011 0 + llllllll -> last 8 bits of the 16 bit value.

ESC vendors are then free argue/agree over assignment of 8-bit identifiers to data types. Due to the 8-bit identifier address space care must be taken to only allow good/sane/future-proof data types, part of the 8-bit identifier address space can be reserved for vendors (e.g. the last 32 identifiers. i.e. 223-255.

DShot commands can be added for discovery/subscription/request.

DSHOT TLM frames can be added for discovery response in the same way and sent as a response to a DSHOT discovery request.

1. 1000 0 + iiiiiiii -> 8 bit identifier for 'Temperature'
2. 1000 0 + iiiiiiii -> 8 bit identifier for 'Voltage (Step size 0.25V)'
3. 1000 0 + iiiiiiii -> 8 bit identifier for 'Current (Step size 1A)'
4. 1000 0 + iiiiiiii -> 8 bit identifier for 'Debug 1'
5. 1000 0 + iiiiiiii -> 8 bit identifier for 'Debug 2'
   and so on.

Subscription is a little trickier, as you would have to use a sequence of DSHOT commands, which could be repeated.

Something like:

1. DSHOT_EDT_SEQUENCE_BEGIN
2. DSHOT_MOTOR_0 + <8 bit sub-command>, e.g. EDT_SUBCOMMAND_SUBSCRIBE
3. DSHOT_MOTOR_0 + <8 bit identifier of the data item>
4. DSHOT_MOTOR_0 + <16 bit encoded frequency/rate> for the data item should be sent.
5. DSHOT_EDT_SEQUENCE_END

Obviously, sending motor commands should not cause the motors to spin, so in-order to be backwards compatible the command sequence can only be sent if the FC knows that the ESC supports ETM. However, the FC will know this if the ESC responds to the DSHOT_EDT_DISCOVERY command!

If you want the ESC to respond with a specific bit of data, when disarmed, e.g. for end-of-flight stats, then a dshot command sequence can be sent, as follows:

1. DSHOT_EDT_SEQUENCE_BEGIN
2. DSHOT_MOTOR_0 + <8 bit subcommand> for EDT_SUBCOMMAND_REQUEST
3. DSHOT_MOTOR_0 + <8 bit identifier of the data item>
4. DSHOT_EDT_SEQUENCE_END

So the entire set of new DSHOT commands would be:

DSHOT_EDT_DISCOVERY
DSHOT_EDT_SEQUENCE_BEGIN
DSHOT_EDT_SEQUENCE_END

From above, the ETM frames used would be:

001 0
010 0
011 0
100 0

The initial EDT sequence sub commands needed are:

EDT_SUBCOMMAND_SUBSCRIBE = 0x00,
EDT_SUBCOMMAND_REQUEST = 0x01,

So with this, now you have a method for getting all the data you'll ever want, with no protocol changes ever needed, AND you still have 3 more EDT frames spare!