This has been sticking with me for a few weeks. A few days ago I contacted a Bluetooth Chip manufacturer by the “attack until you get somebody to explain” protocol. Everything I have heard is that the common problem with SPP over BLE v4 is you need to do several items on Android to get it to work. Since I know my method has continued working successfully until changed I figured I would dump the hints here.
- Schedule on the default Scheduler (main thread) for Android BLE communications – Writes, reads, and other items should be done on the main thread
- Only spin threads to process data once received or written with the BLE stack on Android or iOS
- Store device connections within a management object and only dispose them when you are fully finished with the application otherwise you will run into Null Reference issues and GATT – 133 issues
- If you are using the serial port protocol on your project – it doesn’t mater which product (including Aundino) – do yourself a favor. Delays are your friend. Start writing too fast you are going to have a very inconsistent, at best, development time and support nightmares on release
- Delays are not just for reads and writes – but also opening sessions (characteristic subscriptions), connections, and other items with a SPP single threaded chipset in an IoT project
I think I have gave my side here. If you need more sample projects showing the delay algorithms go to GitHub.
I have a working copy and have offered to help several times. I have done the best I can with my failing health. Time to move on.
- StackOverflow – Using SPP with “Write with no Response”/”Notify” or “Write with Response” in Android