I am working on Bluetooth low energy profiles. I am developing the proximity client and server in Bluegiga USB low energy dongle.
I have written Proximity server on one dongle and a Proximity client on another dongle.
I am able to sent the alert level from client to server. When I am taking the dongles away from each other ( to study the working of the proximity profile) , I am getting 'Link supervision timeout has expired' .
So I would like to know if this timeout information is correct i.e. is it the correct confirmation signal.
When a device recieves disconnection with reason as Link Supervision Timeout, it indicates that the remote device is either out of range or is turned off. Thus the Link Layer waits for "Link Supervision Timeout" time in order to confirm the remote device is no longer connected.
However in Proximity client as per BT-SIG specifications, you application shall calculate the link loss and the path loss [this can be calculated using the remote devices RSSI values] and once the threshold is crossed appropriate alerts needs to be sent to the Proximity Server device. The spec do refers the phenomenon as link loss however it is different from Link Supervision Time out.
Related
First post! Full disclosure, I have a very limited programming / pi background.
I'm working on a project to communicate with a Chroma Bi-Directional power supply (Model #: 62180D-1200) using LXI / SCPI communication. There's more I hope to do in the future, but for the time being I'm simply trying to establish a working communication channel using the "*IDN?" identify command. I have a raspberry pi connected to the same network as the power supply, which I am using to communicate to the 62180D.
Before beginning any of this testing, I have been able to establish that I can communicate with the device via http (web browser). The web page for the device even includes an scpi query tool -- which works!
Successful HTTP communication
To query the device from the pi I have used PuTty to log in to my pi and issue the following command:
lxi scpi -a <device ip address> "*IDN?"
I am expecting to see the same result as shown in the image above (Model No. , Serial No., Firmware Version), but instead I'm receiving the following:
Error: Read error (timeout)
Error: Failed to receive message
I was under the impression that this protocol is fairly plug and play. I have other LXI enabled devices on the same network that I am able to communicate with them using this same approach. Is there some obvious thing I'm missing here?
I'm trying to connect to a BTLE device from Linux from C++ with BlueZ.
Connecting to most devices works fine, but there is a special device which times out with 90% probability. From a standard Android smartphone the connection to this particular device works as intended.
For #Emil's advice in my other question (thanks!) I've setup a Link Layer sniffer tool for further investigation.
During the sniff period I tried connecting to the device(Destination) from both device(Good) and device(Bad).
Device(Good) is working perfectly - it connected
Device(Bad) is not working - timed out
Now I have a Link Layer data of both device connection trials and there is one significant difference between their trials:
Device(Good)'s LL Data for its CONNECT_REQ uses 500 for Timeout value (which is 625ms) while Device(Bad)'s LL Data in CONNECT_REQ uses 42 (which is 52.5ms).
I think Device(Destination)'s response is normally (mostly) arriving between those two, ie after 52.5ms and below 625ms, but sometimes it arrives in less than 52.5ms, and then also BlueZ can connect to it finally.
Is there any possibility to change this Timeout property for CONNECT_REQ in BlueZ? Maybe with setsockopt by any chance?
Or this is something hardcoded into kernel, even for bluetooth adapters attached to USB?
Is there a way in iOS or Android to set up a Bluetooth passkey passcode whenever another device wants to connect to my device via Bluetooth?
My application involves a BLE client connecting to a BLE server and the two devices will transmit data between each other. However, the data transmitted will be very sensitive security-wise. So beyond the standard encryption my goal is to not initiate data transmission until both devices have authenticated each other (e.g., with a passkey).
It seems like a Bluetooth passkey is something set up by the device manufacturer and not something able to be configured by the user. If so and there is no passkey pairing, would an acceptable alternative be to require a passkey to be exchanged (after the devices are paired) before the devices can transmit any sensitive data?
On a Android phone, assuming the phone is GATT server (which provides data for a client device to read), you can safeguard that data held in a characteristic by setting its read permission to PERMISSION_READ_ENCRYPTED_MITM .
For example, when you create a characteristic to be registered with the Bluetooth stack in Android, you do
BluetoothGattCharacteristic characteristic = new BluetoothGattCharacteristic(YOUR_UUID, BluetoothGattCharacteristic.PROPERTY_READ, BluetoothGattCharacteristic.PERMISSION_READ_ENCRYPTED_MITM)
In this way, anyone who wants to read the characteristic needs to create a secure bonding with your phone first, either by entering a passcode or compare two numerical values. The exact way for pairing is up to the Bluetooth stacks of both devices to negotiate (based on available IO on the client).
On the other hand, if the data you want to access is stored in a third remote device, and you don't need authentication (bonding/pairing) to read from it, and you cant access the firmware. Then you can not enforce secure transmission unilaterally from your phone.
In general, two communicate between bluetooth devices, first we perform a bluetooth pairing between two devices and then starts further communication between them.
My problem scenario is simply to transfer a hello packet from one bluetooth device to another bluetooth device.
For this i am planning to use sockets programming technique i.e. RFCOMM sockets.
I got some help about this from http://people.csail.mit.edu/albert/bluez-intro/x502.html
So, my query is do we require bluetooth pairing between two devices before initiating communication with RFCOMM socket connection.
Or does 48 bits device address is only necessary to transfer some data packet from one bluetooth device to other and bluetooth pairing could be avoided.
No, it is not.
Bluetooth device can be in one of the four modes:
Broadcaster
Observer
Peripheral
Central
In broadcaster mode device can only send advertisement messages. This includes name and HwID.
In Observer mode device can only receive advertisement messages.
Peripheral = Broadcaster + can take in connect requests
Central = Observer + can send out connect requests.
If you have an application which does not want to connect use first two modes above.
Please let me know if this addresses your question.
I want to clear of my basics before I Jump into more complicated matter of bluetooth. I have following basic question.
If there is two bluetooth devices(A phone and a bluetooth display). Is it that bluetooth connection is initiated only by the phone.
Suppose there would be lot of bluetooth communication happening from a phone to bluetooth display.Both devices can send messages to any other devices at any time. What is usual design approach of communication. Is it that the phone creates a Socket Connection to the bluetooth display through RFCOMM first time by sending a connect request to the Bluetooth device and this connection is maintained all the time or for every message the Socket connection is made and then socket is closed, after that again reopened and closed for next message.
If the connection is opened till the devices are in nearby range what are the consequences.
What is normal way of communication in case of phone and headset.
Can I get any reference so that i can get some knowledge about that.
1) In general, bluetooth connections can be initiated by either device. For example, with a phone and computer, you could start a connection from either side. With a phone and a display or headset, there may be no input interface on one device, so you would initiate connections from the phone. Devices can also auto-negotiate role switches such that they swap master/slave roles.
2) If you have continuous data to exchange, or require low latency, the connection would typically be left up. If you only have rare messages to exchange, tearing down the connection would save power because the devices are maintaining the connection synchronization by exchanging null packets.
3) You can't maintain a connection with devices out of range. If they can't communicate for some timeout period (on the order of seconds) then they lose sync and kill the connection.
4) Note that phone/headset are not using RFCOMM connections, rather the HSP (headset profile). Connections for isochronous voice data are inherently different than a sporadic data connection like RFCOMM.
5) A good way to see how "real" devices are communicating is to use tools like hcidump, as part of the linux blueZ stack. This lets you fully sniff the protocol messages that happen as you connect devices.