I'm wondering whether or not we can make a specific BLE peripheral device with having this ability to be supported by iOS/Android for automatic scanning for automatic reconnecting, i.e without using any extra app.
I think some standard BLE accessory devices (like Heart sensor) are already known by smartphones, so after first-time pairing, the smartphone's OS itself will scan for finding them again automatically for re-connecting each time when the connection gets lost.
Yes. If the device is a HID device then the system will auto connect to the device until you disable it in Android and unpair it in iOS.
But what's the purpose if you don't have an app?
Related
I have to write a BLE application on an embedded device and there are some features where I'm not sure if BLE supports that or whether I've to create some wrapper around everything or if it's maybe not possible at all. The gerenal descriptions of Bluetooth and BLE I found around the internet usually only cover the overall functionality but don't go in too much detail. If this post gets too complex I'll split it up into different smaller ones.
I use the STM32 BlueNRG-MS chip
1. Discoverability (resolved)
The user has to be able to disable the BLE function in case there are several devices in reach. I see that there are functions aci_gap_set_discoverable() or aci_gap_set_non_discoverable() but altough I set it to not discoverable I can still see it in the LightBlue App on my mobile. How would I correctly disable the BLE functionality of a device to make sure no one can see it or connect to it?
Update: Okay that has been a mistake from my end, if I call the aci_gap_set_non_discoverable() function it is actually undiscoverable. So that's fine.
2. Only accept connections of paired devices
I'd like to achieve a behavior such that, if you have an unpaired phone you have to set the BLE device into a pairing mode in order to connect. If the phone has already been paired, the BLE device shall accept the connection request regardless of whether it's currently in pairing mode or not. Is this what the whitelist should be there for or do I have to do this manually by saving the address of the device after successful pairing? If whitelist is the right approach, I read that newer phones cause issues with whitelisting because they change their address on a regular basis, how can I handle this? That's actually where I thought I'm gonna work with the "discoverability".
3. Automatically reconnect
I'm not sure if this topic has to be handled on the BLE device or on the mobile phone. E.g. my phone is paired with my car's radio, so whenever the phone is in the car it automatically connects - how is this done? It's still the phone that acts as central device I assume?
After days of research and trial and error my colleagues and I have to hope that the StackOverflow community has a working solution.
We got an Android Smartwatch. We developed an app which acts as the BLE central. The App shows a QR-Code encoding an UUID which is unique for every Smartwatch. While showing that QR code it's actively scanning for a device advertising a service with that UUID.
We also developed an iOS app which can scan that QR code and start advertising with the service UUID it received. The Android Smartwatch then connects very quickly to the iOS device.
One purpose of the Smartwatch is to show push notifications from the iOS device. So when the connection is successfully established, the Smartwatch-App subscribes to the ANCS Data Source and Notification Source characteristics. This initiates "Just Works" pairing, so you just have to click on "Pair" on the iOS device. Afterwards you have to allow that iOS notifications are shared to the Smartwatch and then the Smartwatch successfully receives notifications.
ANCS is also the reason why the iOS device MUST BE in the peripheral role.
Until here everything works fine.
When the user leaves the bluetooth range or dis- and enables bluetooth on the iOS device, an automatic reconnect should be triggered. It DOES reconnect when the iOS app is in foreground. Unfortunately it DOES NOT work when the iOS-App is in background. This is probably related to the fact, that the iOS device is not advertising with the required UUID when the app is in background as described in the CoreBluetooth documentation:
All service UUIDs contained in the value of the CBAdvertisementDataServiceUUIDsKey advertisement key are placed in a special “overflow” area; they can be discovered only by an iOS device that is explicitly scanning for them.
We tried many different ways to reconnect from the Android Smartwatch to iOS. From my understanding it should be working when making the first connectGatt with autoConnect=false and when the connection is lost, calling connectGatt on the lost device with autoConnect=true, but it never reconnects. At least not within 15 minutes. Scanning again also wouldn't work, as the UUID is not advertised in background anymore.
We also tried to additionally let the Android device act as peripheral, so the iOS can connect to it. After connecting we wrote data to an "INITIATE_ANCS"-characteristic and let the Android device call connectGatt on the device which was passed to onCharacteristicWrite. This led to interesting behavior:
- The connection was working, we could read a Smartwatch-Characteristic from iOS.
- When subscribing to the ANCS characteristics, it initiated pairing. But instead of "Just Works" pairing it showed a 6-digit code on the iOS device which we had to type onto the Smartwatch.
- The pairing was inititated on every new connect and it always created a new device in the systems device managers on both Android and iOS.
- The pairing WAS NOT inititated when the iOS app was in background.
We really did a thorough research and couldn't find a solution. Did we understand something wrong on how BLE for iOS and Android works? We really hope to find an expert here that has the knowledge what has to be done to make the reconnect work.
Edit:
The Android device is running on Android 5.1.1 and currently it's no option to update.
The iOS testing device is running iOS 13.3 and it should be compatible with iOS 13+
I'm using Android Things 1.0.4 in a prototype where it acts as BLE peripheral device: advertising services and running a GATT server.
I encounter an issue in the BLE pairing process when trying to bond the Android Things board (Raspberry Pi 3) and a smartphone.
Since the device has no display, I set using BluetoothConfigManager:
IoCapability = BluetoothConfigManager.IO_CAPABILITY_NONE
which results in the error AUTH_FAILED every time.
Instead,
IoCapability = BluetoothConfigManager.IO_CAPABILITY_OUT
logs the pairing key and prompts the smartphone to enter it during pairing, but it results in the REMOVED error.
Questions:
Is Android Things in peripheral role capable of handling BLE pairing or not yet?
Are there more things that need to be implemented in the app's code to replicate the full-fledged Android logic?
Here's the source code of the Android Things app to test BLE pairing and bonding
The same code stripped from Android Things specific elements completes BLE pairing and bonding successfully when running on an Android phone as Peripheral (server), and an Android device or iPhone as Central (client).
Generally speaking, if you attempt to read an encrypted GATT characteristic before pairing (which triggers the pairing logic automatically), this results in GATT error 137 returned from the read request (AUTH_FAIL). This is because the device doesn't have enough time to finish setting up the bond before a response is sent by the Bluetooth stack. Retying the read request again generally succeeds.
I have not tested this with an iOS client device, but it certainly holds true with an Android client connecting to an Android (Things) peripheral. As such, I would recommend a few things:
Have the client (mobile) device explicitly initiate pairing, and Android Things should simply react to these incoming requests in the BluetoothPairingCallback. This lets the mobile device decide the pairing type based on the reported capabilities of the IoT device.
Separate the pairing flow from the GATT flow. Pair to the discovered device separately from making any attempts to read the characteristics. This tends to be the best way to avoid timing problems.
Regarding capability choices, this depends on your device. In my experience, if you choose IO_CAPABILITY_NONE this results in PAIRING_VARIANT_CONSENT inside of onPairingInitiated() and the pairing operation succeeds once finishPairing() is called. If you adjust your capabilities, you should be prepared for any number of the variants requiring you to display a PIN for the mobile device to enter. I have not not personally tested these paths.
Is it possible to have one app on the android or ios phone monitor 2 or more bands, Place tiles and respond to button/ accelerometer events? I did not see that in the docs.
Thanks
Yes, this is possible. It is a more advanced configuration so you must pair the Band's in the phone's BlueTooth Settings. Then when you query the SDK APIs for devices you iterate over the devices and create one connection per device. This should allow you to then communicate with each device from within one app.
I wonder why my Sparkfun 13.56 Eval card (with sm130) is loosing its green 'search' led when reading my cell phones NFC, and won't come back until reset.
The 'found' led lights for a tiny moment when my Mifare cards reads. I thought NFC could be used with it.
I read something about NFC uses a NDEF formatting, but I can't get a grip on it :-)
I have tried Nokia 1520, Sony Experia Z2, Iphone 5, Samsung Galaxy S2 S3 S4 & S5. All with same result.
Can I use it with NFC, and if so: How?
That depends on what you want to achieve. The SM130 is a MIFARE reader that supports only cards/tags with MIFARE Classic and MIFARE Ultralight protocols. Most Android NFC devices cannot emulate such tags.
Some Android NFC devices have an embedded secure element (or can be used with a UICC-based secure element) that is capable of emulating MIFARE Classic. However it is impossible to modify the data on those secure elements unless you re the logical owner of them (for embedded SE: that's typically the device manufacturer; for UICC: that's typically the mobile network operator).
Many new Android NFC devices support host-based card emulation (HCE). However, with this card emulation functionality you can only emulate smartcard applications on top of ISO/IEC 7816-4 + ISO/IEC 14443-4, so you cannot emulate a card/tag that can be read with the SM130 (as both MIFARE Classic and MIFARE Ultralight protocols operate on lower protocol layers only).
With the SM130 "SELECT TAG" and "SEEK FOR TAG" commands you should be able to detect the presence of an Android NFC device (as well as a Nokia Lumia, as well as an iPhone 6). However, for Android devices, you will typically receive a random serial number (that's a requirement for peer-to-peer mode) on every selection -- thus, no usefule information to identify a device. With an iPhone 6 (with activated Apple Pay) you should receive a serial number that can be used to identify the device.
Yes. That is to say it is technically capable. It can read the frequency and the format.
There is a lot to it but I'm sure it will be a very rewarding journey.
Github link with an NDEF library:
https://github.com/bjepson/Arduino_NDEF_Reader
On that page you will also find a link for the layout and code on which he based his project. It uses the sm130 so you should be able to use this to get running.
Happy coding!