Adding BLE Support (SpeedyBee, HM-1X)#1441
Adding BLE Support (SpeedyBee, HM-1X)#1441Scavanger wants to merge 1 commit intoiNavFlight:masterfrom
Conversation
|
Will be redone with UDP and TCP support. |
|
@Scavanger, are you still planning BLE support, or have you changed your mind and only planning WiFI / UDP / TCP support? I don't mind the WiFi approach, but it does either mean that you're having your PC join an AP created by the device or the device has to be on your network. It seems that neither of those are ideal when out at the field. One of the nice things about BLE is it "just works" and doesn't need any network configuration. |
|
@jbienz |
|
Amazing @Scavanger, this would be so helpful. I started looking into this library as a workaround: https://github.com/Jakeler/ble-serial It's supposed to allow you to map BLE devices to COM ports with some hackery of finding the right BLE characteristic to talk to. But unfortunately, if you read all the way down to the end of the page he mentions that Chromium / Electron-based apps won't be able to open the port. So your BLE support directly in iNav is the next best hope! Please let me know if you'd like any additional help testing. I have two different HC-08 modules on the way (one with pincode and one without) as well as a Flywoo BT-Nano. |
Support for Bluetooth low Energy devices:
Supported are:
BLE to UART adapters:
SpeedyBee adapters and FCs with integrated Bluetooth.
Unfortunately, the Chrome BLE API is somewhat limited compared to Android. This results in the effect with the UART adapters, due to the buffers, that either the order of the bytes is messed up or even bytes are missing. Therefore, the FC must split large frames and send them one after the other with a certain delay.
There is a new MSP command for this: MSP2_INAV_SET_MSP_OPTIONS, with which the configurator can request transmission in chunks and a delay between the cunks, see here: iNavFlight/inav#7783
The Speedybee adapters are not affected by this, they seem to have a large enough buffer.
#1001