Feedback

[hydra]

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:

https://github.com/tbs-fpv/freedomtx/issues/26#issuecomment-1435738854

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> 5) 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!

[hydra]

I could imagine that if the ESC wanted to send a 32 bit value, then 2 more EDT frames could be used for that purpose for the final two bytes. using a specific frame-per-byte means no sequence number is needed, essentially the sequence number is encoded in the 4-bit EDT frame identifier.

[stylesuxx]

First of all, thank you for your feedback.

To preface my answers, the basic idea with EDT was to introduce additional telemetry without inventing a new protocol, but instead build on top of what DSHOT and bi-directional DSHOT offer, this is not optimal but requires the least amount of implementation on all sides. This is definitely something we should add in a "Considerations" section.

I want to remind you that this is somewhat of a "post mortem" spec - the thing is already implemented (in Bluejay, AM32, BLHeli_32, Betaflight). You can read up on the initial discussion where @sskaug and @joelucid also had their say - so it's not as if we "shot from the hip".

1. EDT is purely optional. It is an addition to bi-directional DSHOT and even when bi-directional DSHOT is used, EDT needs to be enabled explicitly before we "force feed" data to the receiver. If bi-directional DSHOT is active, the receiver expects a telemetry frame anyway, so this adds minimal overhead where the receiver has to check the first four bit and knows what to do. When EDT is being enabled a version frame is sent, in return so the receivers know how they should interpret the data. I understand that this is one of the things you are criticizing in regards to maintainability and test-ability.

2. As per design EDT allows 7 different frames (in addition to the eRPM frame). When enabling EDT the used version is submitted. I understand that handling those different versions is up to the receiver and they have to act accordingly. This also minimizes overhead since each telemetry frame is encapsulated in itself.

If we wanted to prefix them with a header package, we would also need to to that for the "classic" eRPM frame (for the sake of consistency and to not have 2nd class citizens), so instead of sending eRPM frame every other frame we would need overhead for every other package and best case (if only sending eRPM frames) only every 2nd package would contain meaningful information at all.

I like your idea of the subscription model and the generic frames a lot, but I think that this should be topic for an entirely new protocol. The intention for a new protocol has been brought up in the BF slack. I think it would be a good idea to collect all people interested in a discord channel and discuss further. I know that @damosvil has spoken to @AlkaMotors regarding a different protocol (and different bus for that matter).

Again - thanks for your contribution - I am sure it will be a good starting point for a different protocol and showed us some things we need to improve in the specification.

[hydra]

@stylesuxx As I understand it, there's nothing precluding us from adding an implementation of the above at a later date, we can simply reply with a different EDT version number to the initial cut of EDT.

Since this is, as you say, a post-mortem spec, then that's fine, V1 still laid the groundwork for a DSHOT EDT ENABLE command/response as well as having the eRPM frames right shifted as far as possible.

So EDT version 1 seems fine in that regard to me, it achieves what you want now. Bumping up to EDT 2 (i.e. something based on the ideas above) would then be a fairly clear cut excercise and V1 can be compiled-out in ESCs and FC code in due course.

It certainly would have been nice if someone pinged me a bit earlier though, for a perspective on the flight-controller code side of things. 😄

[stylesuxx]

Yes, nothing is preventing us from implementing another version, it just seems the general sentiment is to move away from DSHOT in the long run. Fettec running their own protocol, BF devs suggesting looking into a new protocol - so I am not sure how viable it is to further "hack" DSHOT.

I am sorry you feel left out of the discussion, I'll make sure to ping you in the future. Also feel free to join us in the Bluejay discord.

[hydra]

@stylesuxx I joined the discord server.

Yes, agreed re DSHOT, S2M has promise, but still doesn't cater for the 4-in-1 single MCU use-case, so IMHO that's not idea either. I chatted in the AM32 discord regarding my thoughts on the topic a year or so ago.

IMHO, FD-CAN is fast enough, can use hardware on both sides (ESC and FC) lowering the processing overhead and allowing DMA usage on both sides, works well without CAN transceivers for short distances (FC to 4in1 ESC) and can be used with CAN transeivers in say 'X-Class' sized rigs, uses fewer pins overall, and is far more maintainable long-term.

[damosvil]

Also to say that with CAN all esc receive the same frame at the same time, so they can run in a true sinchronized way. Frames can be 64bytes long, so even octocopters can work with all escs synchronized. Frames can also be scheduled at the escs pwm frequency, so no bus overhead. Bus may be perfectly arbitrated, and data is transmitted at the speed escs can actually consume it, i.e. the pwm cycle time, anything above is discarded until the next cycle. Fc can keep frame data updated instead and send it only when esc can consume it.

[hydra]

Also to say that with CAN all esc receive the same frame at the same time, so they can run in a true sinchronized way. Frames can be 64bytes long, so even octocopters can work with all escs synchronized. Frames can also be scheduled at the escs pwm frequency, so no bus overhead. Bus may be perfectly arbitrated, and data is transmitted at the speed escs can actually consume it, i.e. the pwm cycle time, anything above is discarded until the next cycle. Fc can keep frame data updated instead and send it only when esc can consume it.

Yes, fully agree. with everything you said. We're having discussions in the 'E-ng' discord server regarding all this stuff.