nRF52832 + SDK 14.2 + S332 5.0.0 : How to solve Android MAC cache issue by firmware?

[Manu_Nts]

Hi,

we have developed a nRF52 based product using SDK 14.2 + S332 5.0.0. The product is self-controlled by a Ionic-Cordova App (Android and iOS).

Unfortunately, late in the project development we found that there is a knows issue with Android that does not refresh MAC cache and tries to connect to several devices at the same time: the right MAC address device connects correctly but the others get hooked in PHY negotiation, do not pass to service negotiation (NUS in our case).

We also know that there is a method to refresh MAC address list in Android (solve the issue) but unfortunately is not implemented in the Ionic-Cordova Bluetooth plugin that we are using from the beggining of the project... and since we are in pre-production we do not evalute changing the plugin at all.

We have explored some ways to place a timer/timeout in the PHY negotiation stage until the service connection event but some of them have induced more connection issues.

Any suggestion to solve the issue by firmware? What PHY/Service events we'd need to monitor/observe to detect/sove the issue without harming a normal connection?

Than you!,
Manuel.

[Kenneth]

We don't have any experience with this plugin I believe, at least I can't find other cases or projects. Maybe you should check the https://forum.ionicframework.com/c/cordova/16 forum for help.

It may help to understand if you mean "gatt table cache" instead of "mac cache" and what you mean by different devices "getting hooked in phy negotation".

[Manu_Nts]

Hi Kenneth,

sorry: as you could guess I am not an expert on BLE. I'll try to explain better, point by point:

1. Our App connects to nRF52 using MAC address (not pairing/bonding). We use NUS service.
2. Our App can have registered/stored different devices (nRF52) and their MAC addresses.
3. When the App scans and founds only one registered device in range it connects correct to the device.
4. When the App scans and founds more than one registered device the user can choose wich one to connect. In that case the App connects to the choosen device correctly but also connects, to rest of known devices in range but do not send to them the service request: more or less what happens when you connect a nRF52 using Nordic "nRF Connect" App, connection without service. It only happens in Android. As you suggested it would be a gatt table bug instead a MAC bug.
5. So when it occurs you have one device right connected but other devices "kidnapped" by the App. Moreover, if you use the App to disconnect from the "rigth device" it does not disconnect from the rest of devices: they still "kidnapped". And finally, even if you kill the App Android continue connected to the wrong devices and the only ways to disconnected from them is: reboot the phone, reset the devices or get them away from range.

 

In abstract: we'd like to know if there is some way to take control about this behaviour by firmware? I mean: detect when nRF52 is connected to a central but has not received NUS service request in a certain time.

Thank you.

[Kenneth]

Manu_Nts said:

In abstract: we'd like to know if there is some way to take control about this behaviour by firmware? I mean: detect when nRF52 is connected to a central but has not received NUS service request in a certain time.

Maybe in firmware you can simply reset a timer counter on each received data from the peer, the timer counter may for instance increment every 100ms and if no data is received within for instance 2 seconds from the app, then simply disconnect and start advertisement again?

Then the app need to write some data every <2 seconds, but I guess that should be doable?

Best regards,
Kenneth

[Manu_Nts]

Hi Kenneth,

under our experience the less timers you place during connection the less fail connections occur.

Now we are doing something similar to what you comment but:

1. We do not reload a timer.

2. We do not accept whatever data as a sign that the connection is still "alive".

We:

1. Launch a 5 seconds timer in "BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST"

2. Monitor not overlap the timer just in case we receive the event twice or more times.

3. Kill the timer in "BLE_NUS_EVT_COMM_STARTED".

4. If the timer interrupt "jumps" we close the connection.

We tested to launch the timer in other events but we found connection problems: even "hangs"... needing to reset the microcontroller.

Do you find any gaps in the strategy?

Thank you!

[Kenneth]

I think your approach also will work yes.

FYI: My idea was to setup a timer running every 100ms (not reload), and then in the timeout handler simply increment application counter, e.g.:

timeout_handler_100ms()
{
  time_since_data_received_counter++;
  if(time_since_data_received_counter>TIMEOUT_VALUE)
    disconnect_link();
}