intel-iot-devkit
Observation of Stale Manufacturing Data for BLE device
Although quite new to BLE technologies, I've had to climb a steep learning curve when I was given the responsibility to develop an application in java that responded to changes to a device's advertising Manufacturer Data. After searching far and wide on the internet and having a java background, I decided to use TinyB's framework library. I managed to implement the application which is to be deployed on Raspberry Pi machines.
The application is constantly in discovery mode (startDiscovery(), setDiscoveryFilter(TrasportType.LE)). The important parameters exposed by the Manufacturer Data are persisted for each device (potentially more than 100 devices)
Using the BluetoothAdapter.getDevices(), I loop through each device to obtain its Manufacturer Data and compare for changes based on persisted data and then to respond accordingly. This seems to work fine to a degree, however I am having some issues related to the frequency/speed/latency at which the Manufacturer Data is being detected when changes are have been made; it is very slow to respond.
The device is continuously advertising and I have hcitool running at the same time, so I am able to know immediately after triggering a change, when the change is being detected. Its taking between 3 - 5 seconds longer than hcitool, before it is being seen by my application using TinyB.
However, I have also noticed that even when the battery is removed from the device, I continue to see the last old Manufacturer Data as well as RSSI between the 2 devices etc still being detected; BluetoothAdapter.getDevices(). This is also appears to be the case when I run the example application list_mfg provided with the TinyB implementation.
It appears as though the data is being cached? Could anybody please confirm this and if there is way to prevent this happening?
Hi @Dukemo , did you find what was causing the issue? I'm also having problems with cached devices.
Hi @joaopmarques66, Unfortunately not. I was hoping someone in this forum with more experience or may have stumbled onto the reason and the solution may have helped
The reason is, that by default BlueZ has the duplicateData filter active which filters out packets. The library does not support setting the filter but you can add
g_variant_dict_insert_value(&dict, "DuplicateData", g_variant_new_boolean(false));
in BluetoothAdapter.cpp in line 252
