I'm working on a project that involves an nRF8001-based device as a Bluetooth Smart slave, in combination with master-side software running on an iPhone.
When the devices initially connect, the master downloads a series of log entries from the slave. There can be several hundred of these, each of which requires a round trip to transfer, so the slave tries to set the connection timings to a low value by sending an ACI ChangeTimingRequest packet to the nRF8001. (That is, it specifies that the connection interval and latency be low, so that connection events are frequent.)
Once the log has been transferred, power consumption on the slave becomes a more important concern than raw throughput, so the slave resets the timings to make connections less frequent.
One thing I've noticed about this system is that there's often a 30-second delay between the ChangeTimingRequest and the master actually setting the new timings.
I had assumed that the fault lay with iOS on the master side, but I now have a BTLE sniffer, and the packet traces appear very incriminating for the nRF8001. From firmware debugging, I see the ChangeTimingRequest go out over the ACI link with no delay. Then the nRF8001 sits on the request for 30 seconds. Finally, the SIG_Connection_Param_Update_Req packet goes out over the air, and the iPhone responds immediately with an LL_Connect_Update_Req.
The effect appears to be some sort of throttle, since the first timing update in a connection often goes through immediately. Later updates usually get delayed by 30 seconds.
There's no mention of this behavior in the documentation, and it's really quite counterproductive. It seems to me that the slave should be able to request timing changes as often as it pleases.
So, I guess my questions are: 1) Is this intentional or is it a bug?, and 2) Is there a workaround?
Thanks!
