New improved communications protocol

[casainho]

We need to write the specification for a new improved communications protocol. Some needs of improvement:

• configurations data will increase more at least 40 bytes for the torque sensor full calibration (10 points for each pedal, 2 bytes for each point) and so they need to be sent at least one at startup and every time they change, with a confirmation the motor controller received it. The motor controller should not start the motor until receive at least once the configurations.

Wiki page for writing the specification: https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki/Improved-communications-protocol

[geeksville]

Misc thoughts:

• At a minimum ach packet should inculde start of packet + packet type byte + CRC
• a protocol version byte is optional if you just use new packet type #s when the version changes. Alternatively include the protocol version in a packet you send only occasionally. When a display first connects to a motor it will wait until it sees this packet.
• the link is far from saturated, so you can also include a packet length byte in the header which will make it easier to extend packets for new features without having to bump protocol version.
• periodically send # of received packets back to the sender (include this in the occasional info packet). If this number stops going up, the display can then know that the TX wire to the motor is now busted.
• This is not protocol change specific: but for any future development (v21) I would encourage only the use of new branches from the TSDZ2 tree. i.e. don't just copy the files into a new git repo and lose all history & mergability. I assume this is the plan but just wanted to mention it.

[geeksville]

Possibly use nanopb and most of this stuff is handled for you: https://jpa.kapsi.fi/nanopb/benchmark/ & https://github.com/nanopb/nanopb

Though probably not worth the hassle given the small number of packet types and client devices.

[casainho]

My worries on motor controller side:

• the memory is VERY limited (we have free only 6K bytes from total of 32 kbytes and there are other important features as full torque sensor calibration to be done and a wish for better high cadence mode). Let´s not forget that original firmware even uses only 16 kbytes of flash memory, that should be the official microcontroller memory amount.
• it is very slow and has no interrupts when it sends data to the display so it hangs waiting for full send. The processing power should mainly be dedicated to the motor control and so keep a good energy efficiency for FOC / battery range

I don´t think that in future, like next 2 or 5 years, they will upgrade this motor controllers - I think they will continue to be with this memory and processing limitation.

So, I think we should stick to very basic and having only the things we strictly need.

[geeksville]

I haven't looked at the motor controller code, but one idea if memory is tight on the MC: Move everything out of that controller that is possible (i.e. just have the motor PID (or whatever) control loop). Anything else, calibration etc... could be done with the help of the display controller. The display controller could even send down a raw preformatted 'config packet' which is just blindly used for whatever settings the motor controller needs.

On Wed, Nov 6, 2019 at 10:04 PM casainho notifications@github.com wrote:

My worries on motor controller side:

• the memory is VERY limited (we have free only 6K bytes from total of 32 kbytes and there are other important features as full torque sensor calibration to be done and a wish for better high cadence mode). Let´s not forget that original firmware even uses only 16 kbytes of flash memory, that should be the official microcontroller memory amount.
• it is very slow and has no interrupts when it sends data to the display so it hangs waiting for full send. The processing power should mainly be dedicated to the motor control and so keep a good energy efficiency for FOC / battery range

I don´t think that in future, like next 2 or 5 years, they will upgrade this motor controllers - I think they will continue to be with this memory and processing limitation.

So, I think we should stick to very basic and having only the things we strictly need.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OpenSource-EBike-firmware/TSDZ2-Smart-EBike/issues/125?email_source=notifications&email_token=AABXB2IDSG3LFBH2NGTWB7LQSOVXNA5CNFSM4JJOPYJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDKUWJA#issuecomment-550849316, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABXB2KIDS7KMVQB4YWVCWLQSOVXNANCNFSM4JJOPYJA .

[casainho]

Needs:

• motor controller firmware version: so the display can at least show to the user and maybe refuse to work for incorrect version

How should we number the various firmware versions??

[lowPerformer]

My suggestion for a more versatile and yet simple protocol: 1st Start Byte (always the same) 2nd Lenght Of Frame (all following bytes) 3rd Type Of Frame 4th and following Payload (including CRC alway at the end)

With this information it will be possible to: 1) Low Level functions can receive (and CRC check) those frames just scanning for startbyte & receiving LengthOfFrame bytes. 2) Higher Level functions can decode those frames dependent on TypeOfFrame

Version of motorcontroller/protocol f.i. can be in a special "heartbeat" frame or just put it in the current data stream.

So this seems to be more or less the same just adding two bytes (2nd and 3rd byte).

[casainho]

Done!! Seems to work well, I already drove some kms with it.