I have two Samsung Android devices and two LilyGo Meshtastic devices.
First and primary Android is a Samsung Galaxy S9+ phone, Android 10. The other is a Samsung Galaxy Tab A tablet, Android 9. Both have the latest updates and patches.
The LilyGo tbeams have been flashed with 9.6 firmware and appear to function properly : readable output on the OLEDs , output monitor via PlatformIO IDE in VScode on Windows Server 2016, the same setup on a ASUS Zenbook running Ubuntu 20.04 plus monitoring output via screen, and connected to a Raspberry PI 4 running Raspbian 10 with output via screen.
However, Bluetooth pairing using the Playstore mestastic app fails with a generic fail message on the S9+ and fails with an error message to turn location services on the Tab A (and the Tab A is kinda paleo). Both Androids have Bluetooth on and can see the tbeams. All the location services options are enabled and all the meshtastic app permissions are enabled.
This is extremely puzzling. I have only started to dig into the code on PlatfomIO and am not familiar enough with the architecture and flow to spot anything with the short scans so far.
It seems to me that I’m missing something really basic. Using my pins as well as the suggested pins doesn’t make any difference in the pairing response
I would double check this, and make sure you have location permissions turned on for your phone/tablet (in android settings) and in android settings /apps/ meshtastic. I had this same problem once, and although location permission was turned on for the app, it was off in the main android settings.
you might have missed my email, but that message on a samsung device means (the extra and non-standard) “settings / location / high-accuracy” option in android settings needs to be turned on.
Using my pins as well as the suggested pins doesn’t make any difference in the pairing response
I’m not sure what this means. The only pins to enter are the ones printed on the screen of the device.
but @mc-hamster was kind enough to let me grab logs off a samsung device he has that had problems .
I think the root cause is this (samsung did something non standard (again) with their rules on BLE scanning):
09-12 14:38:37.420 4471 4633 D ScanRecord: parseFromBytes
09-12 14:38:37.422 4471 4633 D ScanRecord: parseFromBytes
09-12 14:38:37.423 4471 4633 D ScanRecord: Not a Multi Manu data
09-12 14:38:37.423 4471 4633 D ScanRecord: Not a Multi Manu data
09-12 14:38:37.423 4471 4633 D ScanRecord: Not a Multi Manu data
09-12 14:38:37.423 4471 4633 D ScanRecord: Not a Multi Manu data
09-12 14:38:37.423 4471 4633 D ScanRecord: parseFromBytes
09-12 14:38:37.424 4471 4633 D ScanRecord: parseFromBytes
09-12 14:38:37.427 4471 448 D BtGatt.ContextMap: sendClientScanResult for app id 8
I’ll change the filter in today’s alpha release and perhaps you can try that and report back?
Hmm puzzling. Would you mind capturing a short video of the whole flow? Clicking to pair, then showing the device screen then entering the pin and the message the phone gives?
I think the most likely theory is that you are not keying in the Bluetooth paring code. In your video you key in 1234. The pairing code is a random six digit sequence to securely prove you own the other device. (This is standard for all BLE devices)
It is printed on the screen of the display with a message that says “key this into your phone”. Do you have a display installed? If not, we also print it to the serial port.
K. It was not obvious that that is the process - I am not a big user nor fan of BLE. Mistaken assumption on my part that the code was either 0000 or 1234 as shown on the Android device.
BTW the Galaxy Tab A still shows the message to enable location services but the pairing works. The Tab is Android 9.
The code did not show on the terminal monitor in VS Code PlatformIO on Windows SRV 2016.