Hi All - some recent Bluetooth technical details we resolved. Here’s some drill down for those interested -
Bluetooth Pairing Grab
When pairing new devices, a few users reported some interference that required them to pair multiple times before succeeding.
This was not common, and for those few who did report it, it varied over time and device. But when it presented, it was quite an obstacle.
It surfaced more prominently when we made a recent release of the new slot naming convention, responding to some user requests to make multiple back-to-back pairings easier.
Occasioned by the update, users had a reason to re-pair all their slots in one session. That’s when a few saw this effect.
Thanks to the meticulous and detailed reports from one user in particular, (kudos to Derek I.), we got very good data on what was causing it.
The context was several devices on, plus the Air-In dongle on, all in the same venue.
The jump slot 6 for the dongle worked fine, but the other slots required many entries before the pairing took hold.
User would erase a slot and set up a fresh pairing. The normal pairing animation would present as expected,
A slot erase basically spawns a completely new Bluetooth ID, so none of the past pairings could possibly contend. The user would expect to pair with a clean slate, but it would sometimes stall, as described below -
After a 10 seconds in pairing mode, while the PIN entry was being completed, the pairing animation would stop, and switch to the Bluetooth link-down indicator.
Once the PIN entry was completed, the entry was rejected and the host iPad or iPhone would say pairing unsuccessful.
Sometimes this would work fine on the first try, but intermittently it could go 5 to 10 times before succeeding.
After pairing, everything worked fine, but the pairing might take a lot more attempts than normal.
We did a lot of testing in our labs, and with users, and we found the correlation:
All of the pairing interference cases occurred only if the Bluetooth dongle was powered up.
We unplugged it, and it never failed. The pairings succeeded on the first try.
We then set to work on finding out why this was happening for some users and not others, and what the exact mechanism of the failure mode was.
The culprit: a subtle feature of the CSR Bluetooth chip inside the Air-In dongle. After a time delay, the autopair feature of the CSR chip would kick in, and grab any advertising device, in promiscuous mode, without a pin code.
So depending on how quickly a user entered their pin code on the target host, the dongle might switch to promiscuous mode and grab the slot before the pin entry was completed.
It turns out that even though it was already paired to slot 6, when it switched into autopair mode, it would go ahead and grab another slot too.
Rather than re-code the CSR chip protocol, we found a way to modify the fail-safe features of TextBlade so that it would block the promiscuous pairing mode in these cases.
We have to keep a fail-safe path open, so that we can accept promiscuous pairing if say, the TextBlade code image got mangled, and we had to revert to boot-slave mode.
This is important for an upgradable device like TextBlade, so it is protected from bricking during an aborted reprogramming cycle. It works well and lets the TextBlade recover even under severe interference with programming. So we have to keep this feature.
We found a way to reconcile the fail-safe mode with intelligent rejection of the pair-grab scenario.
We tested the new code on our lab systems and sent the new revision to Derek over the cloud to confirm that it did its job. His response:
It worked perfectly. So now we have both fail-safe, and pair-grab rejection in the latest build.
For some, this may seem like an obscure detail, but if you were one of the folks who found themself trying 10 times to pair, at that moment, it would be a big deal to you.
Thanks to the great input of enthusiastic treg users, and plenty of hard work by the dev team, it’s been solved. Since it’s built into the TextBlade itself, even other devices beyond the Air-In dongle, cannot foil TextBlade pairing in this way. That hardens TextBlade’s defenses, and makes it more robust overall.
You’ll never deal with that potential Bluetooth stumbling block, because it doesn’t exist any more.
Hope this vignette gives you an idea of what we’re doing and why.