If the “BR/EDR Not Supported.” bit is set as "0" or "1" what does that mean? I have been confused for the last hour about how to interpret it.
If the bit is set as 1, does that mean the "BR/EDR Not Supported" is false which means that BR/EDR is indeed supported? Or is it the other way around with the bit set as "0"?
The following is from BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 3, Part C:
• For a device of the LE-only device type with all the following flags
set as described:
a) The ‘BR/EDR Not Supported’ flag to set one.
b) The ‘Simultaneous LE and BR/EDR to Same Device Capable (Controller)’
flag set to zero.
Having a 1 for the BR/EDR Not Supported flag means it does not support BR/EDR. i.e: it is an LE only device.
Related
How do I interpret the output of 'hcitool con'?
% hcitool con
Connections:
< ACL 00:11:22:33:44:55 handle 1 state 1 lm SLAVE AUTH ENCRYPT
More specifically, I would need details of the following parts:
handle:
This seems to be some enumeration of connections, but can I be confident that a new connection always get the lowest free 'handle' number? Does 'handle 0' indicate ongoing connection?
state:
That are the states and which numbers are they associated with? I've seen 1, 5, 8, and 9.
SLAVE:
Does this mean that the remote device is slave? Or the local?
This question is more or less stated (but not answered) here: Need detail explanation of Bluetooth command "hcitool con" and hcitool sr
hcitool was deprecated by the BlueZ project in 2017. If you are following a tutorial that uses it, there is a chance that it might be out of date.
bluetoothctl is the command line tool that should be used for connecting to remote devices.
There is also the btmgmt tool where you can can get information on the current connection with sudo btmgmt con.
For BLE advertising type LOCAL_NAME_COMPLETE, is there a minimum length requirement?
I could not find any length specification in the spec (other than it needs to fit in the advertising packet of 31 bytes minus anything else already in the advertisement packet), but am running into an issue where it may seem that there is. I wanted to confirm here.
According to the BLUETOOTH SPECIFICATION Version 4.0 [Vol 3] section 12.1:
...The Device Name characteristic value shall be 0 to 248 octets in length. A
device shall have only one instance of the Device Name characteristic.
But since the AD packet is limited to 31 bytes then I guess that if it's too big then one should broadcast the shortened name instead of full name (different AD types)
So it seems like there is no limitations on a minimum size. Hope it helped.
I am trying to make a BLED112 behave like an iBEacon and also advertise few more GATT services. While advertising user data for iBeacon as in Bluegiga examples works fine, I do not know how to also advertise the list of available GATT services. Any ideas are highly appreciated!
Take a look at my website for some potential help regarding using the BLED112 and Bluegiga tools: http://www.sureshjoshi.com/tag/bluegiga/
Otherwise, you shouldn't really be explicitly advertising anything. If you've set up your gatt.xml correctly, the GATT characteristics are advertised inherently (it's a BLE thing, not an explicit thing).
Are you sure you're setting them up correctly? Take a look at my BLE113 examples, specifically dealing with gatt.xml and see if there is anything helpful there: https://github.com/sureshjoshi/ble113-firmware-examples
One approach would be to use the Bluegiga dual-mode advertising as a guide and instead of the Physical Web Beacon, advertise your GATT service there. Assuming you have a 128 bit service UUID of 112233-4455-6677-8899-00AABBCCDDEEFF your advertising data would look like this:
procedure gatt_service_advertisement()
# Beacon mode
beaconMode = 1
#Stop advertisement
call gap_set_mode(0,0)
# Length
service_adv(0:1) = $11
# Incomplete list of 128 bit UUIDs (use $07 if the list is complete)
service_adv(1:1) = $06
# GATT Service UUID - should be little endian I think
service_adv(2:1) = $FF
service_adv(3:1) = $EE
...
service_adv(16:1) = $11
service_adv(17:1) = $00
# Set advertisement interval to 100ms.
# Use all three advertisement channels
call gap_set_adv_parameters(160, 160, 7)
# Set advertisement data
call gap_set_adv_data(0, 18, service_adv(0:18))
#set to advertising mode - with user data
call gap_set_mode(4, gap_undirected_connectable)
end
You can use that procedure to alternate advertisements between iBeacon and your GATT service by calling it in a repeating timer like in the linked dual-mode example.
Another approach would be to advertise the GATT service in the scan response, but without knowing more about your particular use case, it's hard to say if that's an option for you.
I develop an Android application running on Motorola RAZR XT910 with OS version 4.0.4.
This application uses the Motorola_ICS_R2_sdkaddon_100 BluetoothGattService.jar and BluetoothGatt.jar libraries and communicates with Bluetooth
Low Energy Sensor Tags (TI CC2540,TI CC2541,Blue Radios Sensor Tags).
On Discovery procedure I always read the rssi value equal to 0 . I use the following code
to read the rssi value on receiving the Intent BluetoothDevice.ACTION_FOUND:
short rssi = intent.getShortExtra(BluetoothDevice.EXTRA_RSSI,(short) 0);
Also for non Bluetooth low energy devices,the rssi value i read is ok (not equal to 0).
Can anyone help me??
thanks
I found a similar issue on the TI discussion site for using the Vender Specific query for RSSI. It seems that it works for Classic BT but returns an error code of 2 for BLE.
http://e2e.ti.com/support/low_power_rf/f/660/t/289391.aspx
It might be a fundamental limit that you can't get the value. In your case, the getShortExtra might not return the error code (2) and just return a 0 as RSSI.
Are there any workarounds to connect to HID device using L2CAP in JAVA ME (using JSR-82 specification implementation native to mobile device not BlueCove etc.)?
I know that HID devices usually uses PSMs (Protocol Service Multiplexor) with 0x0011 value. Unfortunately as I found:
Legal PSM values are in the range (0x1001..0xFFFF), and the least significant byte must be odd and all other bytes must be even.
Above explains why javax.microedition.io.Connector connect() method throws exception when I try following code:
Connector.open("btl2cap://600010120296:11");
This page suggests that the restriction was removed in JSR-82 1.2:
Legal PSM values are in the range (0x0005..0xFFFF), and the least significant byte must be odd and all other bytes must be even. When a server connection string does not have a psm parameter, the server PSM value assigned by the implementation must be no less than 0x1001.
And the comment:
Remove reserved ranges from L2CAP PSM values, to allow a Java application to use a Bluetooth protocol that is built on top of L2CAP using a PSM value in the "reserved" range.
Also, the "interrupt endpoint" is PSM 0x13 (that's where keyboards, mice, etc will send unsolicited reports just like they would send on the control channel (0x11) in response to GET_REPORT).