This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52832 S132 v6.1.1 Race condition with iOS PHY update to 2 MBit/s when Slave Latency is enabled

Hello,

We're making RuuviTag sensor beacons which log environmental data to flash. Logged data is later read by a mobile phone application over Nordic UART Service. 

The log read flow goes like this:

  1. Mobile phone connects to RuuviTag
  2. Mobile phone registers to Nordic UART TX characteristic notifications
  3. Mobile phone waits for callback from registration.
  4. Mobile phone writes "Start log read" sequence to RuuviTag RX Characteristic
  5. RuuviTag sends logs as TX notifications
  6. Disconnect

Here's a sample RTT log on 1 MBit/s PHY, Hex string is the log read command. 

BLE Connected 
NUS Started
3A:3A:11:5F:95:94:42:00:00:00:00Sending logged data
Logged data sent: 970 elements
BLE Disconnected 
NUS Finished



When we use 2 MBit/s PHY, we separately trigger PHY update on Android with gatt.setPreferredPhy. This works just fine.

  1. Mobile phone connects to RuuviTag
  2. Mobile phone requests update to 2 MBit/s PHY
  3. Mobile phone registers to Nordic UART TX characteristic notifications
  4. Mobile phone waits for callback from registration.
  5. Mobile phone writes "Start log read" sequence to RuuviTag RX Characteristic
  6. RuuviTag sends logs as TX notifications
  7. Disconnect

BLE Connected 
BLE PHY update requested 
PHY update accepted. PHY set to 2 Mbps.
NUS Started
3A:30:11:5F:95:7D:85:00:00:00:00Sending logged data
Logged data sent: 1203 elements
BLE Disconnected 
NUS Finished

However, iOS does the update automatically, and when Slave Latency is enabled on connection this leads to corrupted data being received on RuuviTag some of the time:

BLE Connected
BLE PHY update requested
PHY update accepted. PHY set to 2 Mbps.
01:00app_comms.c:178 WARNING: INVALID_PARAM
BLE Disconnected
NUS Finished

Because this happens only occasionally and I cannot stop the firmware in debugger during GATT connection, I cannot debug what exactly happens. However, it seems that iOS application sends the registration to TX notifications, PHY update and log read command in same connection event. This doesn't happen ever if we set the slave latency to 0. 

I'm sure we can come up with workarounds if needed, but before we start working on a workaround I'd like to confirm if it is a known issue that Slave Latency + 2 Mbit / s connection may cause race conditions and if there is some preferred workaround. We haven't been able to find a callback in iOS which would let us know that a faster connection is being negotiated or PHY was updated, Android has onPhyUpdate

  • Hello,

    I am not aware of any issue no, in general I have seen in the past (with various peers) that initiating procedures on connected event have a tendency to trigger race conditions in the peer. The typical solution is to add a 100ms delay or more before requesting the procedures, this may be as simple as a fixed nrf_delay_ms(100); before sending the request on connected event. It would be interesting to see if this impact the problem in any way.

    I think to get further an on air sniffer log would be helpful (e.g. using nRF sniffer should be possible).

    Best regards,
    Kenneth

Related