In the currently released GoTenna firmware and Android SDK there are a bunch of problems that prevent most applications from maintaining a connection to a GoTenna for more than 30 to 90 minutes or so (NS1 Dashboard is an exception due to the two months of fixes and stability testing I’ve ended up doing):
- GoTenna’s Bluetooth transceiver resets itself more or less randomly (every 30 minutes to 60 minutes I would estimate): https://github.com/gotenna/PublicSDK/issues/31
- The Android GoTenna SDK connects to the GoTenna device with “reconnects” enabled, but when it is notified of a disconnect, attempts to reconnect itself. This creates a race condition, and if the “original” connection reconnects before the “new” connection, the “original” connection is orphaned, and a force stop of the application and subsquent relaunch is required, since the orphaned connection will attempt to reconnect if you simply restart the GoTenna.
- The Android GoTenna SDK has some pretty bad bugs in its BluetoothGattCallback method implementations, including one where it purposely orphans the Bluetooth connection on status code 133, and another where it throws an exception, and due to a bug in many versions of Android, crashes the entire Bluetooth stack on the device, which requires the Bluetooth adapter to be reenabled.
- The Android GoTenna SDK has an issue where if a connection to a GoTenna is lost in the middle of receiving data during a command, the data of the command can occasionally cause the SDK to be unable to process any new commands.
Note that although issue #1 makes issues #2 through #4 much more common, those issues can still occur simply due to the GoTenna being power cycled or going out of range temporarily. I’ve communicated with Rahul quite a bit about these issues (and a couple other improvements), and provided suggested ways of addressing them and log information.
Are these issues going to be resolved when the new firmware comes out either through the firmware itself in the case of #1, or by an associated new version of the Android GoTenna SDK for the other issues?
Even with issues #2 through #4 (and a couple other minor changes), an application still needs to have extension mitigations in place to maintain long connection durations:
- A watchdog that stops a reconnection attempt and restarts it after a period of time (simply relying on the reconnect doesn’t work).
- A watchdog that looks for the GoTenna being discovered, but the connection process is taking too long, and responds by restarting the Bluetooth adapter.
- A watchdog that checks to see if the Android Bluetooth service has shut itself down, and if so, re-enables it. In some cases issue #1 occuring results in the Android Bluetooth adapter becoming disabled without broadcasting the usual events (this seems to be specific to Android 7.0, and I haven’t released a version of the NS1 Dashboard app with this fix in place quite yet)
The NS1 Dashboard application has the added complexity of maintaining a Bluetooth connection to the Vehicle Interface portion of the NS1 Gauge System at the same time it is maintaining a GoTenna connection. Before adding GoTenna support I had a single watchdog that was looking for a stalled connection, where Android thought it was connected, but data from the device wasn’t being received over the link. Adding GoTenna support involved adding a socket connect watchdog that detected attempts to connect that took too long or too short, and responded by the usual re-enabling of the Bluetooth adapter.
The NS1 Dashboard also has the ugly complexity of reconnecting the GoTenna and Vehicle Interface after a Bluetooth adapter re-enable. This involves attempting to disconnect things before disabling, remembering what was connected, and of course kicking off reconnection attempts.
With fixes and mitigations in place the NS1 Dashboard app can maintain connections to a GoTenna indefinitely. This connection durability is quite important when you think about it:
Say you have 4 people in a group. With a restart of the Bluetooth transceiver in the GoTenna every hour it means that on average someone has a GoTenna disconnect and not reconnect every 15 minutes or so. If people stay on top of it they can usually catch the problem within 5 minutes. That still leaves the entire system of 4 people not functioning correctly 1/3 of the time.
In reality, after restarting the app and GoTenna every hour or so the users eventually get tired of devoting time to managing the system, which usually means that within a couple hours at least one or two people have just given up. So the system works for a couple hours the first day or two, and after that everyone has decided it isn’t worth the effort and doesn’t bother to even turn the GoTennas on.