nRF8001 ChangeTimingRequest

RE: nRF8001 ChangeTimingRequest

awneil — Tue, 15 Dec 2015 12:05:42 GMT

There seems to be another flaw in this approach (or, rather, the SDK implementation of it):

Occasionally, I see an "unsolicited" Timing Event before (all of) the PipeStatus events have been received to indicate that all the Pipes are available for use; ie, before the ChangeTimingRequest has been issued.

The SDK code sees this event, and assumes that it is the result of the ChangeTimingRequest - but it isn't!

So the SDK code starts transmitting before the Pipe is ready - causing Pipe Error 96 (Pipe State Invalid).

RE: nRF8001 ChangeTimingRequest

awneil — Fri, 13 Nov 2015 13:19:15 GMT

Ah - I see.

RE: nRF8001 ChangeTimingRequest

run_ar — Fri, 13 Nov 2015 12:33:20 GMT

The initiator is the central device. So during service discovery we normally use the connection parameters set by the master/central device, not the parameters used by nRFgo studio.

RE: nRF8001 ChangeTimingRequest

awneil — Fri, 13 Nov 2015 12:29:28 GMT

Isn't that what I said?

RE: nRF8001 ChangeTimingRequest

run_ar — Fri, 13 Nov 2015 12:25:24 GMT

No, when the connection is initialized the connection parameters are sent from the initiator in the connection request. Normally the peripheral would then check these parameters to see if they are suitable. If they are not, you can send a connection parameter update request using one of the two functions in lib_aci. One where you define the parameters when calling the function and one where us use the Peripheral Preferred Connection Parameters (this is the values you set in nRFgo studio).

RE: nRF8001 ChangeTimingRequest

awneil — Fri, 13 Nov 2015 09:07:54 GMT

Taking this a little further:

When the device first connects, I guess it uses the timing as configured in nRFgo studio? So the settings in nRFgo studio should be "optimised" for the Service Discovery?

And the ChangeTimingRequest is then used to set timings appropriate to the actual operational requirements of the application?

RE: nRF8001 ChangeTimingRequest

awneil — Thu, 12 Nov 2015 21:37:53 GMT

Great - thanks.

It would be useful if these things were noted in the code.

RE: nRF8001 ChangeTimingRequest

run_ar — Thu, 12 Nov 2015 19:58:15 GMT

There are two reasons for this implementation. First we didn't want to change the timing parameters until after the service discovery procedure completed, and waiting until notifications are enabled (will result in the pipe status event) ensures this. The reason we wanted to wait is that we usually use slower parameters after the update procedure, and we have the same scheme for most/all examples.

The second reason (if I remember correctly) was that iOS wasn't to found of connection parameter update requests being sent to soon after the connection was established. This could in some cases lead to the connection being terminated (I don't remember the exact details).

Unfortunately there is one problem with this scheme. In case you reconnect to a already bonded device, the bonded device will assume the peer keeps the state of it's CCCD's (as per spec), so we don't necessarily get the pipe status event. So there is a risk the connection parameters might not get updated. A better implementation could be to simply check the timing given when the connection was established and use a timer to trigger the Connection parameter update request.