Back to the MTU topic, I was thinking how DFU update could be made faster and when reading about larger MTU and data length extensions and long writes and more packets per connection interval I am still confused how it works together and what could be done. Few questions - maybe someone has answers?
If I keep DFU PACKET characteristics length in bootloader at 20, can longer MTU help me? Can BLE put more 20 byte write operations into one longer packet? Or it is strictly one ATT packet per BLE packet.
If I increase the length of the characteristics (to e.g 256) will this be backward compatible when MTU is negotiated to be standard 23? Or am I supposed to change length of characteristics according to negotioated MTU, but that may not be even possible?
In theory more packets per conenction interval can make it faster too according to Figure 6 in https://punchthrough.com/maximizing-ble-throughput-part-3-data-length-extension-dle-2/ however I don't know how to enable it in Bluez linux stack (or DFU bootloader) or how supported it is in general. I even don't know how to make connection interval shorter from linux side, that could help with current short packets too. Anyone knows?
Asking because I got python DFU flasher working in linux on the Raspberry Pi via builtin BLE but the speed is 1.5KB/s so wondering how this can be improved.
BTW the flasher is fork of https://github.com/dingari/ota-dfu-python - there is both legacy and secure dfu procedure implemented in pure python via scripting gatttool command in interactive mode :-) So no python BLE library is used at all. Pretty cool hack IMO. I have added bootloader/softdevice dfu modes,resuming when some notifications get occasionally lost in the middle of update and support for Desay bootloader used in DS-D6 and HX03W. It is surprisingly useful and stable for me now (especially when considering how it is done). Only the speed could be better.
© Espruino, powered by microcosm.
Report a problem