I'm trying to develop an app that connects via BLE to my CC2650 sensor tag from Texas.
I'm able to connect to my tag using GATT protocol the problem is that if when I'm connected the connection fails it is not restored. But if I reconnect the phone to the device and I repeat the procedure (turn off and on the tag) it automatically reconnects to the phone.
I just don't understand the difference between the first behavior and the one after a reconnection...
Any idea?
Alex
Android should be documented better. Anyway, here is the explanation:
When you call connectGatt (https://developer.android.com/reference/android/bluetooth/BluetoothDevice.html#connectGatt(android.content.Context, boolean, android.bluetooth.BluetoothGattCallback)) with autoConnect set to false, that will only make a one-shot connection to the device. When it disconnects, it doesn't reconnect.
When you instead connect using the .connect() method on the BluetoothGatt object, that is the same thing as closing the current BluetoothGatt object and then connect again with connectGatt and the autoConnect parameter set to true.
When the autoConnect parameter is set to true, that means that you would like to keep the device connected forever, i.e. for whatever reason it disconnects, Android will always try to attempt to reconnect to the device.
You can check out my list of differences for autoConnect here: https://stackoverflow.com/a/40187086/556495.
Related
I have one BLE application.
When I start the device scanning, the DeviceWatcher.Added event will call immediately and shows the previously connected devices which is currently powered off. But in the DeviceWatcher.Removed event it will be cleared.
How can I prevent this situation. In my application I am trying to connect the device immediately when ever there is the device listed in the DeviceWatcher.Added event. I don't want to wait till the DeviceWatcher.EnumerationCompleted event.
Because of this implementation, the connection API BluetoothLEDevice bluetoothLEDevice = BluetoothLEDevice::FromIdAsync(GetId()).get(); is returning success. And in the service scan API GattDeviceServicesResult result = m_BluetoothLEDevice.GetGattServicesAsync(BluetoothCacheMode::Uncached).get(); I am getting GattCommunicationStatus::Unreachable status.
I need this status in the initial time of scanning. Or there is any other way I can check the device is unreachable or not?
The sample written here is in C#, you could find the C++ replacement in the learn.microsoft.com
You could get all the paired BLE devices like this.
var pairedBleDevices = await DeviceInformation.FindAllAsync(BluetoothLEDevice.GetDeviceSelectorFromPairingState(true)); # Return all the paired Bluetooth LE devices
Now, if you want to remove the pairing of a specific device, you could loop through the pairedBleDevices and find your removal device by matching specific property, let's say device name or address.
foreach (var device in pairedBleDevices )
{
if (!device::Name.Contains("myDevice")) continue;
await device.Pairing.UnpairAsync();
break;
}
Now, as you have all the previously paired LE devices with properties, as Mike suggested, you could use BluetoothLEAdvertisementWatcher to discover BLE devices and filter the advertisement by matching the BluetoothAddress(from the paired device). If you find a new device, pair the device or execute the GATT operation and start communicating.
You are getting GattCommunicationStatus::Unreachable that's probably the device you are trying to communicate with is in sleep mode. So the best way is to capture the advertisement first using BluetoothLEAdvertisementWatcher and, after that, initiate the pairing or GATT operation.
I've done a lot of searching but have yet to find any examples of the data format for accessing a simple BLE characteristic. I have a CC41 (HM-10 clone) that I have set to master mode and successfully connected to a BLE server device using a PC terminal program and the AT commands. I now want to send the proper data to access a service such as Immediate Alert (0x1802) and it's Alert Level characteristic (0x2A06). I know the full service and characteristic UUIDs and the data value for turning the alert on/off. I can do so from the nRF phone app but it doesn't tell me the data protocol that is actually sent from the app. I assume that the UUID needs to be sent as hex data, not a string, but nothing I've tried so far works. If the phone app can do it, then I would think that I can do it manually as well. Any ideas?
I want to try to set up an ESP8266 (using the Arduino IDE) to occasionally connect to a wifi SSID to send telemetry back. I also would really like to be able to have it running a softAP for configuration/settings purposes. (i.e. so if you want to change internal settings in your code, you can connect directly to the device to access a web form to do so)
The problem is, I am not 100% sure how I know which is which when making an outgoing telemetry json query. I want it to go out on the STATION mode connection. Presumably in most cases the AP mode won't be connected, but there may be rare instances where both are connected at the same time. Thus how do I tell the device to specifically use the STA side of things when it needs to send data back over the internet?
I can't even seem to find any specific examples to ask if one or the other is connected. (you can poll WiFi.status() but - which one is it reporting?)
Any help is appreciated
I have two peripheral devices, say device1 & device2 and one Android device for central role. Android can connect to both by BluetoothDevice.connectGatt() method with autoConnect = false.
Problem is - While autoConnect functionalities work well for device1, device2 even does not connect for once with autoConnect = true.
onConnectionStateChange callback is not called in either side (android & device2).
Advertisement and scan-response packets been customized in device2, is that causing the problem? Though we know that, settings for autonomous connection is to be provided entirely at central side, peripheral side has nothing to do with it, change in peripheral device also changing auto-connect behavior at central side.
any insight? Thanks in advance.
I'm writing a Linux program (using Qt 4.8 and libusb 1.0) which will communicate with a custom USB device (currently being programmed by a co-worker).
Step 1 is to have a "heartbeat" going back and forth over USB at regular intervals.
I'm currently using asynchronous bulk transfer.
For testing, I've put my "Send_Heartbeat()" on a button click. If I click on the button a LOT and queue up a number of messages to send, as long as I keep my queue busy, the messages keep sending and my USB device keeps receiving them.
If I stop for a few seconds, then resume and add more messages to the queue, the USB device stops receiving them.
BUT, my program's Transfer Callback DOES return with a transfer status code of 0, indicating success, even though my USB device isn't receiving them.
My questions:
Why does the callback's transfer status indicate success if my USB device appears to have stopped receiving them?
Has anyone heard of this type of behaviour?
It's worth noting that if I disconnect the USB device, I get proper status codes returned in my callback indicating that the device has gone away.
If the USB Device is left connected and running, and I "Detatch" and then again "Attach" to force a re-connection and try sending more test heartbeats, it works! The USB device starts receiving messages again.
My "Detatch" is the following calls:
libusb_release_interface()
libusb_reset_device()
libusb_close()
Then my "Attach" is:
libusb_get_device_list()
libusb_get_device_descriptor()
libusb_open()
libusb_set_configuration()
libusb_claim_interface()
My next step is to narrow down which of the libusb commands is re-establishing the communication.
Meanwhile, I'm hoping someone recognizes these symptoms and has a suggestion.
As it's my first time programming USB communication, I'm wondering if there is some fundamental which I've missed.
Thanks!
The issue is here I guess:
My "Detatch" is the following calls:
libusb_release_interface();
In your detatch, you need to attach kernel driver
detatch_kernel_driver();
libusb_reset_device();
libusb_close();
Then my "Attach" is:
libusb_get_device_list();
libusb_get_device_descriptor();
libusb_open();
libusb_set_configuration();
Here you need to check if the kernel driver is active or not. So,
check what attach_kernel_driver(); returns, and call detatch_kernel_driver(); if needed
libusb_claim_interface();