SOLVED: In Search of Reliable Bidirectional Bluetooth Serial Port Profile (SPP) Communication
Lately, I have been working on some software (Windows using Visual Studio in C# / .NET) to turn my laptop into a "brain" for the "Bittle with BiBoard" robot. To keep things simple, I want to use the well established bidirectional serial streaming communication of the Bluetooth Classic Serial Port Profile (SPP). By simple, I mean in contrast to the more complicated client-server option that is the Bluetooth Low Energy (BLE) with Generic Attribute (GATT) Profile. The ESP32 in the BiBoard supports both options and, I believe, the OpenCatEsp32 source code supports both as well (but see below).
Why is this simpler? Mainly because it is easier to code up a serial transceiver than to code up a GATT client. Also, it is a better fit to this use case because the SPP was designed for serial streaming whereas the GATT is meant for short message exchanges.
Here is the problem. I can only occasionally establish bidirectional Bluetooth communication between the Bittle with BiBoard and my Windows laptop using an SPP communication port. I do this by pairing the laptop with the Bittle and checking if I can send and receive over the Bluetooth SPP communication port that gets created. If I get a bidirectional communication, I move on to further coding work but if I only get unidirectional communication, I unpair, delete the com ports created and try pairing again. Eventually (1 out of 10 tries) I get a Bluetooth SPP bidirectional communication (but see below).
Before anyone asks, I am using the "Outgoing" port that specifically says "'ESP32SPP", meant for this SPP communication purpose, not the "Incoming" port that is also created. And also before anyone can ask this too, the "Incoming" port can only be initialized by the Bittle, not the laptop but this is not my use case, since I want the laptop to initiate and control the communication.
After getting a Bluetooth port that is bidirectional, I send Bittle commands and receive readbacks. However, after a short while (15 min) of back and fourth communication, the port becomes unidirectional. The laptop can send commands but not receive any readbacks.
So, has anyone tried such bidirectional Bluetooth Serial Port Profile (SPP) communication? If so, what kind of reliability have you experienced? More importantly, what might the source be of any unreliability in such communication? I have looked at the OpenCatEsp32 source code but have not found any obvious problems.
Is anyone interested in this capability and in combining efforts to search for the source (and fix) of this apparent (at least in my hands) unreliability?
BTW, I have searched the forum and the closest I found was this post by "Kevin KO" (and related comments): https://www.petoi.camp/forum/hardware/bluetooth-two-ways-communication-question. It sounds like my use case and that of the poster are similar, even though our software tools and Bittle robots (NyBoard with Bluetooth module vs BiBoard with built in Bluetooth) are different.
Those are worthy goals!
I have searched the forum and found only one post, by @Kevin KO, that "may" be close to what I am doing, wherein "Bluetooth two ways communication" difficulties were mentioned. My original post has that link. If there are folks trying to do bidirectional Bluetooth Serial Port Profile (SPP) communication, well, I haven't found them.
I believe the other posts using Bluetooth are using BLE protocol with the GATT profile, not the Bluetooth Classic protocol with SPP. I believe this by inference because that appears to be what the Petoi Mobile App is using and, also by inference, I think that is what the remote control (Bittle as drone) posts are also doing. It is well suited to that use case where the 'k' token plus skill command is sent to initiate skills and where the back communication is typically a one character response, not a stream of sensor data.
I have found no reason to believe there are any problems with how the GATT profile is implemented, over BLE, in OpenCatEsp32. However, I have found every reason to make the code change I proposed when using the SPP in that same source code! Again, I'd love to find someone trying the same thing as me to see what their experiences have been. But, I can't find what hasn't been posted...
As for learning about how Bluetooth is supposed to work, my recommendation is to spin up a hobby project that requires it and then do the usual "[1] google >>> [2] read >>> [3] code >>> goto [1]" cycle, repeated ad nauseam with "question asking" detours as needed.