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:
- Mobile phone connects to RuuviTag
- Mobile phone registers to Nordic UART TX characteristic notifications
- Mobile phone waits for callback from registration.
- Mobile phone writes "Start log read" sequence to RuuviTag RX Characteristic
- RuuviTag sends logs as TX notifications
- 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.
- Mobile phone connects to RuuviTag
- Mobile phone requests update to 2 MBit/s PHY
- Mobile phone registers to Nordic UART TX characteristic notifications
- Mobile phone waits for callback from registration.
- Mobile phone writes "Start log read" sequence to RuuviTag RX Characteristic
- RuuviTag sends logs as TX notifications
- 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.