I'm creating a watchOS application. The app should connect to a BLE tag, which sends distance values to the apple watch. If the distance falls below a given value, the application should give some feedback to the user about this.
Reading about core bluetooth and background tasks, it doesn't seems like it's possible. If I'm correct, when the application is suspended, it will no longer receive data from the BLE peripheral. How should I approach this task? Is it possible to run an application like this for 8 hours in the background? I can't find any more information about this, and it seems like it's impossible.
There are restrictions to WatchOS apps using Bluetooth in the background, the main being:-
The minimum connection interval is 30ms instead of 15ms (for iOS
devices).
The Apple watch can only operate as a central device.
The Apple watch can only be connected to two peripherals at one time.
The peripheral gets disconnected when the app goes into the background.
More details about this can be found in the following links:-
https://www.raywenderlich.com/336-core-bluetooth-in-watchos-tutorial
https://developer.apple.com/videos/play/wwdc2017/712/
The only exception to this is if you use the HKWorkoutSession. More information about this can be found here.
I hope this helps.
Related
I bought one of these:
https://www.aliexpress.com/item/Smart-finder-Key-finder-Wireless-Bluetooth-Tracker-Anti-lost-alarm-Smart-Tag-Child-Bag-Pet-GPS/32806261079.html
As far as I can tell it is a BLE (Bluetooth Low Energy) location tag.
I downloaded the app for it onto my iphone, and the app instantly recognised it and connected to it. The iPhone app seems to know how far away the tag is - it has a little map of the local area and says how many feet away. I was able to set the device name via the app, but I'm not sure if that set it locally or on the tag itself. The iPhone app also has a "find" button - when you press it, the tag beeps.
So I want to know how I can program this thing myself. I want to be able to identify it when it is nearby, connect to it and make it beep. I've searched for quite a while but not come up with much.
I'm assuming (wrongly/rightly?) that there is some general standard or approach for talking to these BLE location devices and carrying out the basic functions with them - but what is that standard - where is the documentation?
Does anyone have any idea how to program these BLE location tag devices?
BLE devices typically communicate using GATT, either using standard GATT services, or custom ones. The command to make it beep is probably implemented using a custom GATT service.
For finding out the distance to the beacon, typically the RSSI is used. This is a measure of the received power. It needs to be compared to the output power at the emitter. Usually beacons will put their output power in advertisement data, so it can be used without connecting to them. Here since the app is also able to send commands to the beacon, chances are it keeps a connection to it and has a custom GATT protocol to retrieve the output power.
Here is what I would suggest:
Read up on BLE, especially advertising and GATT. For instance read this for advertising and this for GATT. The full BLE spec is available here but should be used for reference and not introduction
Sniff the communication between your device and your phone. You can see this other answer of mine to get started
Replicate the communication protocol in you own app. For that you'll need to use your target platform's BLE libraries. For instance for iOS it is CoreBluetooth
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.
I am working on Android BLE as a peripheral connected to a custom device that runs Nordic NRF51 as a central. The project requires Android peripheral to connect to two NRF51 central devices.
Android is advertising two different Advertisement UUIDs one for left and other for right Nordic NRF51 devices. Ideally, I would like to have both Nordic Centrals to connect to the Android at the same time.
I have two main issues.
First issue. Android can get both connections fine. The problem occurs when Android sending notification or Android sending reply back as result of Write Request from the central. When both Centrals are connected, often notification nor the send reply works. I confirmed that the Nordic central does not receive the notification nor the reply. Does anyone have experiences in Android as a Peripheral supporting multiple connections at the same time? I have tried two BluetoothGattServer instances (one for each device) as well as one instance of BluetoothGattServer and based on the connected device, I can tell which Central the event if for and handle it correctly. It is sending notification or send reply to Write Request that at times it does not get sent from Android. I am using synchronized methods on the GattServerCallback event handlers.
Second Issue. Due to the first issue, I am now only advertising one UUID at a time. The idea is to switch between two advertising UUIDs, thus have only one connection at time. The problem now is switch advertising. About 1 out 3 times, when I start advertising with first UUID with its name (LFDroid), it appears that it is actually advertising second UUID with its name (RTDroid) briefly (1 or 2 seonds) and then advertises what was requested. Note that second UUID advertising was stopped on previous switching. It almost looks like when I ask to advertise, it starts to advertise with the last advertised UUID and name and then quickly advertises what is requested. This now causes problem because both Nordic Centrals sees the advertisement and connects.
Any suggestions would be appreciated.
I'm trying to establish a bluetooth low energy link between a custom pcb and a mobile device. The application requires a tablet device and a BLE link that operates as fast as possible.
Since the BLE Speed is main defined by the allowed number of packages per connection interval and the minimal connection interval I'm trying to find a tablet with those capabilitys.
I have been searching a lot and just found the following information:
IOS device are stuck with a minimal connection interval of 30ms
Android devices are technically able to deliver 6 packets each 7.5ms, but usually it wont settle for anything below 20ms.
I find it very hard to get solid information on that topic. I found nothing about Windows Tablets and Tizen Tablets.
Does anyone have information about that topic?
You see, the standard Android bluetooth code is (with sometimes small adjustments by each manufacturers) the same on every device and the bluetooth controllers available on the market tend to only send 3-6 packets each connection event if the min/max connection event length is set to 0, which it is by default in Android's code.
Is it possible for you to work with AOSP, i.e. modify the Android source code? If so you could change the HCI call where a connection is created or connection parameters are updated. Change the min/max connection event length (Minimum_CE_Length and Maximum_CE_Length) to some large value and you will then be able to write many many packets in one connection event regardless of connection interval.
The relevant places in the code are https://android.googlesource.com/platform/system/bt/+/d35bb40dd563e7f37df0a2fa9c0f61d0958b9601/stack/l2cap/l2c_ble.c#945 and https://android.googlesource.com/platform/system/bt/+/488005b16bd2552ce7e5f9c1e1b3d4072397fc26/stack/btm/btm_ble_bgconn.cc#394.
I'm having the hardest time to get the solution of the following problem.
Main issue:
Several smartphones(up to 30) must communicate with a MCU at the same time.
System overview:
There are many rooms(each room is a cabinet that 30 people can go into), and every cabinet will have one MCU for the smartphone users.
MCU will control some device of the cabinet.
The scenario of this system is as follows:
1. The users go into the cabinet.
2. Smartphone app will recognize the MCU(or MCU will recognize the smartphone) and the MCU will send some data to the smartphone and this data will be noticed to the user.
3. User inputs some data at the smartphone app and this data will be sent to the MCU to control the cabinet device.
4. Up to 30 people can go into the cabinet at the same time and the system should handle all the users simultaneously.
I'm going to develop smartphone application and MCU firmware for this system.
My thought:
I'm thinking to use Arduino/RFduino/Raspberry Pi as MCU and I'm thinking to use Bluetooth LE/Wifi/3G as communication material.
I've tried the following solutions
1. Using bluetooth low energy on Arduino/RFduino/Raspberry Pi.
MCU will be BLE peripheral and my smartphone app will be BLE central.
But I found that a BLE peripheral can only be connected to a BLE central at the same time so I can't use this method.
2. Using wifi on Raspberry Pi
I think that Raspberry Pi can run web service and my smartphone app can communicate with the server through http.
But every time the smartphone user go into the Raspberry Pi based wifi-zone, the user should select the wifi-hotspot at the network setting if he registered this wifi already, and the user should register the wifi-hotspot if this is the first time at the wifi-zone(cabinet).
This is very inconvenient for the users so can't be used for me.
3. Using 3G network on Raspberry Pi
Unfortunately, there's no 3G signal in the cabinet so I can't use this method.
I'm looking forward your kind answer.
Any hints or comments will be welcome.
Thanks for your attention.
Thanks for your answer in advance.
Toltori Kim
Well... I'd go with wifi. And QR codes.
I'd make either a single wifi network for all the cabinets (so only one set of credentials, or even an open one - without security) and then the app can connect to the raspberries using a sort of authentication (where the credentials are written in a QR code inside the cabinet) or a wifi network for each cabinet and its credentials are written in a QR code.
I'd use the first one, maybe without security. So the user has just to go in the cabinet, connect to the common wifi, make a photo at the qr code and then can use the RPi