crownstone
[android] length 0 of device manufacturer data
Error with one of the properties regarding device manufacturer data.
04-09 12:47:29.517 3910 4310 D bt_btif_gattc: btif_gattc_update_properties BLE device name=Crown len=5 dev_type=2
04-09 12:47:29.517 3910 4310 E bt_btif : property type:241, len:0 is invalid
04-09 12:47:29.517 3910 4310 E bt_btif_dm: ### ASSERT : system/bt/main/../btif/src/btif_dm.c line 4655 failed to save remote device manufacturer (1) ###
Is the length properly set for the custom data that is sent?
Isnt this an issue for bluenet lib android?
On 9 Apr 2017, at 13:03, Anne van Rossum [email protected] wrote:
Error with one of the properties regarding device manufacturer data.
04-09 12:47:29.517 3910 4310 D bt_btif_gattc: btif_gattc_update_properties BLE device name=Crown len=5 dev_type=2 04-09 12:47:29.517 3910 4310 E bt_btif : property type:241, len:0 is invalid 04-09 12:47:29.517 3910 4310 E bt_btif_dm: ### ASSERT : system/bt/main/../btif/src/btif_dm.c line 4655 failed to save remote device manufacturer (1) ### Is the length properly set for the custom data that is sent?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
Feel free to move to appropriate location. If this is intended behavior on Android device it belongs here (I thought). If it reflects a bug in the firmware, it might be moved there.
In https://github.com/crownstone/bluenet/blob/master/src/ble/cs_Stack.cpp#L358
void Nrf51822BluetoothStack::configureIBeaconAdvData(IBeacon* beacon) {
The getArray() function from cs_iBeacon.h is used, which is hardcoded to 23. So that can't go wrong...
In https://github.com/crownstone/bluenet/blob/master/src/ble/cs_Stack.cpp#L411
void Nrf51822BluetoothStack::configureBleDeviceAdvData() {
The struct _advdata.p_manuf_specific_data is not set, neither the size of that struct.
This function seems not to be used? In a case CONFIG_IBEACON_ENABLED in cs_main_crownstone.cpp:
bool enabled = *(bool*)p_data;
This needs a low-level check to see how the packets actually look.
In wireshark I see the following:
Device d6:cc:73:b4:9c:be:
Bluetooth HCI Event - LE Meta
Event Code: LE Meta (0x3e)
Parameter Total Length: 40
Sub Event: LE Advertising Report (0x02)
Num Reports: 1
Event Type: Scan Response (0x04)
Peer Address Type: Random Device Address (0x01)
BD_ADDR: d6:cc:73:b4:9c:be (d6:cc:73:b4:9c:be)
Data Length: 28
Advertising Data
Service Data - 16 bit UUID
Length: 20
Type: Service Data - 16 bit UUID (0x16)
UUID 16: Unknown (0xc001)
Service Data: 0170f842830d8f9aae0b540d4ddf25faa6
Device Name (shortened): Crown
Length: 6
Type: Device Name (shortened) (0x08)
Device Name: Crown
RSSI (dB): -88
Device cb:69:b8:69:14:6e:
Bluetooth HCI Event - LE Meta
Event Code: LE Meta (0x3e)
Parameter Total Length: 40
Sub Event: LE Advertising Report (0x02)
Num Reports: 1
Event Type: Scan Response (0x04)
Peer Address Type: Random Device Address (0x01)
BD_ADDR: cb:69:b8:69:14:6e (cb:69:b8:69:14:6e)
Data Length: 28
Advertising Data
Service Data - 16 bit UUID
Length: 20
Type: Service Data - 16 bit UUID (0x16)
UUID 16: Unknown (0xc001)
Service Data: 01181fba5e9422fc47a8951a348dacd26f
Device Name (shortened): Crown
Length: 6
Type: Device Name (shortened) (0x08)
Device Name: Crown
RSSI (dB): -92
There are no differences that I can spot at first sight.
Then the same devices again, but for their iBeacon advertisements:
Device d6:cc:73:b4:9c:be:
See: Event Type: Connectable Undirected Advertising (0x00)
Bluetooth HCI Event - LE Meta
Event Code: LE Meta (0x3e)
Parameter Total Length: 42
Sub Event: LE Advertising Report (0x02)
Num Reports: 1
Event Type: Connectable Undirected Advertising (0x00)
Peer Address Type: Random Device Address (0x01)
BD_ADDR: d6:cc:73:b4:9c:be (d6:cc:73:b4:9c:be)
Data Length: 30
Advertising Data
Flags
Length: 2
Type: Flags (0x01)
000. .... = Reserved: 0x0
...0 .... = Simultaneous LE and BR/EDR to Same Device Capable (Host): false (0x0)
.... 0... = Simultaneous LE and BR/EDR to Same Device Capable (Controller): false (0x0)
.... .1.. = BR/EDR Not Supported: true (0x1)
.... ..1. = LE General Discoverable Mode: true (0x1)
.... ...0 = LE Limited Discoverable Mode: false (0x0)
Manufacturer Specific
Length: 26
Type: Manufacturer Specific (0xff)
Company ID: Apple, Inc. (0x004c)
Data: 021521719e9ddbb9434a9d9085e335fcccba778527dbc4
RSSI (dB): -89
Device cb:69:b8:69:14:6e:
See: Event Type: Non-Connectable Undirected Advertising (0x03)
Bluetooth HCI Event - LE Meta
Event Code: LE Meta (0x3e)
Parameter Total Length: 42
Sub Event: LE Advertising Report (0x02)
Num Reports: 1
Event Type: Non-Connectable Undirected Advertising (0x03)
Peer Address Type: Random Device Address (0x01)
BD_ADDR: cb:69:b8:69:14:6e (cb:69:b8:69:14:6e)
Data Length: 30
Advertising Data
Flags
Length: 2
Type: Flags (0x01)
000. .... = Reserved: 0x0
...0 .... = Simultaneous LE and BR/EDR to Same Device Capable (Host): false (0x0)
.... 0... = Simultaneous LE and BR/EDR to Same Device Capable (Controller): false (0x0)
.... .1.. = BR/EDR Not Supported: true (0x1)
.... ..1. = LE General Discoverable Mode: true (0x1)
.... ...0 = LE Limited Discoverable Mode: false (0x0)
Manufacturer Specific
Length: 26
Type: Manufacturer Specific (0xff)
Company ID: Apple, Inc. (0x004c)
Data: 021521719e9ddbb9434a9d9085e335fcccbaf93a43fec4
RSSI (dB): -92
Do I have an old version for one of the Crownstone's firmware? Where can I check that?
Correction. They both send out connectable and non-connectable iBeacon advertisements.
That is by design. Alternating these adheres to the iBeacon spec enough for the phones to keep alive :)
On Sun, Apr 9, 2017 at 2:16 PM, Anne van Rossum [email protected] wrote:
Correction. They both send out connectable and non-connectable advertisements.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/crownstone/CrownstoneApp/issues/28#issuecomment-292782342, or mute the thread https://github.com/notifications/unsubscribe-auth/AFHWTd0DqlWUXTvsgMXdI_3LqsewNF5dks5ruMw1gaJpZM4M3_l3 .
This probably stems from not using a UUID from SIG yet as 16-bit Service Data UUID.
The question is... Do we need it? Do we actually use the Shortened Local Name (0x08) type in the scan response, see https://github.com/crownstone/bluenet/blob/master/docs/PROTOCOL.md?
I think we can get rid of these 10 bytes and use a 128 bit UUID that does not need registering.
Another road would be to not use scan responses at all. Just use our own advertisement type. We already have a company UUID. So it makes sense to use Manufacturer Specific (Data GAP 11.1.4) with the 16 bit company identifier.
If we use the 128bit UUID, we don't have enough bytes left for the data. 1B AD len + 1B ad type + 16B UUID + 17B data = 35B, while we only have 31B. We only made the name as long as possible, and would drop it if it wouldn't fit.
For the other road: we could indeed interleave iBeacon messages with the data messages, and not use a scan response at all. However, I think IPhones may not be able to recognize which IBeacon messages belongs to which data messages (as you don't get the MAC address), @AlexDM0 should know.
iPhones do not get mac adresses. The app database knows which major minor should match to which crownstone but I can't tell it to connect to one of them. The uuids I get instead of mac addresses are not provided when I get the iBeacon information. Those are only available for scan responses. I listen to the uid of the Crownstone (cloud short I'd of stone) and store their handles so I can look for them in the future.
On 10 Apr 2017, at 10:08, vliedel [email protected] wrote:
For the other road: we could indeed interleave iBeacon messages with the data messages, and not use a scan response at all. However, I think IPhones may not be able to recognize which IBeacon messages belongs to which data messages (as you don't get the MAC address), @AlexDM0 should know.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.