BLE Server/Clent Parameters

This question is answered

Posted by Peter Clerico

on Feb 15 2012 07:57 AM

Hello, my customer (on copy) is evaluating BLE using the KeyFobDemo server demo with an iOS app. His concerns/comments are below:

"I'm writing the test code for iOS, using Apple's Core Bluetooth. There are some restrictions in connection management imposed by this - the very first is that the client app cannot specify connection parameters, it is up to the server device to negotiate preferred values if they are different from the initial connection values.

The KeyFobDemo has several constants in peripheral.c that appear to specify the connection interval, the slave latency and the supervisor timeout. I've changed these and yet don't see any change in the performance of my app. Using the Packet Sniffer I see there ADV_CONNECT_REQ message, but don't see any response from the device, to negotiate different parameters.

So before I go too far I'm wondering if the server code uses these values, and should it be attempting to negotiate with the client?"

Thanks in advance for any advice/direction.

Peter

All Replies

Posted by kazola

on Feb 15 2012 08:13 AM

Guru11075 points

I think these are some issues that are getting included in the new TI BLE Stack, coming this february.

Bye.

Please click the Verify Answer button on a post if it answers your question! :)

Posted by GregS

on Feb 15 2012 09:12 AM

Verified Answer

Verified by Peter Clerico

Expert4165 points

Hello,

Look at simpleBlePeripheral example. and set the automatic update negotiation.

// Whether to enable automatic parameter update request when a connection is formed
#define DEFAULT_ENABLE_UPDATE_REQUEST         FALSE


    GAPRole_SetParameter( GAPROLE_PARAM_UPDATE_ENABLE, sizeof( uint8 ), &enable_update_request );

Note - that either side should have a range of these values, and the negotiation should find a value both side agree on.

BR,

-Greg

Posted by Don Clark

on Apr 11 2012 07:06 AM

Prodigy130 points

I did that, and re-built the executable, re-flashed into my CC2540 dongle. Running the Sniffer I see traffic, and I see three SIG_Connection_Param_Update_Req go across, and one SIG_Connection_Param_Update_Rsp with value 0x0001. But the connection to the keyfob is never established. The parameter settings should be acceptable to Core Bluetooth - I've included the constants as they are set in my current executable, below. So I'm wondering about the actual negotiation protocol - what should I be seeing? I've included the psd file from the TI packet sniffer.2604.Connection session FAILED-3.psd

// Whether to enable automatic parameter update request when a connection is formed
//#define DEFAULT_ENABLE_UPDATE_REQUEST         FALSE // 2/17/12 dfc made TRUE
#define DEFAULT_ENABLE_UPDATE_REQUEST         TRUE

// Use limited discoverable mode to advertise for 30.72s, and then stop, or
// use general discoverable mode to advertise indefinitely
#define DEFAULT_DISCOVERABLE_MODE             GAP_ADTYPE_FLAGS_LIMITED
//#define DEFAULT_DISCOVERABLE_MODE             GAP_ADTYPE_FLAGS_GENERAL

// Minimum connection interval (units of 1.25ms, 80=100ms) if automatic parameter update request is enabled
#define DEFAULT_DESIRED_MIN_CONN_INTERVAL     80

// Maximum connection interval (units of 1.25ms, 800=1000ms) if automatic parameter update request is enabled
#define DEFAULT_DESIRED_MAX_CONN_INTERVAL     800

// Slave latency to use if automatic parameter update request is enabled
#define DEFAULT_DESIRED_SLAVE_LATENCY         0

// Supervision timeout value (units of 10ms, 1000=10s) if automatic parameter update request is enabled
#define DEFAULT_DESIRED_CONN_TIMEOUT          1000

Posted by Su mington

on Apr 27 2012 00:04 AM

Prodigy60 points

Any update ?

I'm facing the same issue now. The connection is never established if "DEFAULT_ENABLE_UPDATE_REQUEST" was enabled. The connection parameters should be acceptable to my iPhone4S.

Posted by Don Clark

on Apr 27 2012 08:19 AM

Prodigy130 points

Yes. There are some constraints required by Core Bluetooth, and if your settings conflict then the negotiation won't happen. This worked for me, using my iPhone 4S:

// Whether to enable automatic parameter update request when a connection is formed
//#define DEFAULT_ENABLE_UPDATE_REQUEST         FALSE // 2/17/12 dfc made TRUE
#define DEFAULT_ENABLE_UPDATE_REQUEST         TRUE

// Use limited discoverable mode to advertise for 30.72s, and then stop, or
// use general discoverable mode to advertise indefinitely
#define DEFAULT_DISCOVERABLE_MODE             GAP_ADTYPE_FLAGS_LIMITED
//#define DEFAULT_DISCOVERABLE_MODE             GAP_ADTYPE_FLAGS_GENERAL

// Minimum connection interval (units of 1.25ms, 80=100ms, 16=20ms) if automatic parameter update request is enabled
// For Core Bluetooth must be => 20 mSecs (or 16 units), <= 1980 ms (2000 ms - 20 ms)
#define DEFAULT_DESIRED_MIN_CONN_INTERVAL     16    // 20 ms

// Maximum connection interval (units of 1.25ms, 800=1000ms) if automatic parameter update request is enabled
// For Core Bluetooth must be <= 2000 mSecs (2 seconds, or 1600 units)
#define DEFAULT_DESIRED_MAX_CONN_INTERVAL     32     // 40 msecs

// Slave latency to use if automatic parameter update request is enabled
#define DEFAULT_DESIRED_SLAVE_LATENCY         0

// Supervision timeout value (units of 10ms, 1000=10s) if automatic parameter update request is enabled
#define DEFAULT_DESIRED_CONN_TIMEOUT          600 // 6 seconds, max allowed by Core Bluetooth

Posted by Su mington

on May 01 2012 01:41 AM

Prodigy60 points

Following is my setting. Those values should meet the constrains required by Core Bluetooth. Did i make any mistake ?

// Whether to enable automatic parameter update request when a connection is formed
#define DEFAULT_ENABLE_UPDATE_REQUEST TRUE

// Minimum connection interval (units of 1.25ms) if automatic parameter update request is enabled
#define DEFAULT_DESIRED_MIN_CONN_INTERVAL 200

// Maximum connection interval (units of 1.25ms) if automatic parameter update request is enabled
#define DEFAULT_DESIRED_MAX_CONN_INTERVAL 800

// Slave latency to use if automatic parameter update request is enabled
#define DEFAULT_DESIRED_SLAVE_LATENCY 0

// Supervision timeout value (units of 10ms) if automatic parameter update request is enabled
#define DEFAULT_DESIRED_CONN_TIMEOUT 600

Posted by tylerw

on May 01 2012 12:44 PM

Intellectual525 points

https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf

See section "Connection Parameters" within Bluetooth Low Energy.

-Tyler

Posted by Su mington

on May 01 2012 21:42 PM

Prodigy60 points

I use PC software with USB dongle to connect to my device. It has the same situation. So it's not related with iPhone4S.

Posted by Karel Seeuwen

on Jul 18 2012 20:27 PM

Intellectual280 points

Just a comment regarding the CONNECTION PARAMETER UPDATE REQUEST as implemented in the peripheral.c file, and the iPhone4S.

I had been trying for days to get my code working with
#define DEFAULT_ENABLE_UPDATE_REQUEST TRUE
but no matter what settings I used for MIN_INTERVAL, MAX_INTERVAL etc the iPhone4S would disconnect the connection.

Next I downloaded and installed the packet sniffer software (should of done this ages ago) and noticed the iPhone4S was
severing the connection with a LL_Terminate_Ind. I also noticed that the CONNECTION PARAMETER UPDATE REQUEST packet
had IntervalMin and IntervalMax set to the same value, and this value corresponded to the
#define DEFAULT_DESIRED_MAX_CONN_INTERVAL n // n msecs
value.
In reference to https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf where the maxInterval should be
at least 20mSec greater than the minInterval it does surprise me that people have posted that using peripheral.c as is
and setting DEFAULT_ENABLE_UPDATE_REQUEST to TRUE has in fact worked!?!

How I got it working
I made a modified copy of GAPRole_SendUpdateParam from this
bStatus_t GAPRole_SendUpdateParam( uint16 connInterval, uint16 latency, uint16 connTimeout, uint8 handleFailure )
to this
bStatus_t BOGUS_GAPRole_SendUpdateParam( uint16 connIntervalMin, uint16 connIntervalMax, uint16 latency, uint16 connTimeout, uint8 handleFailure )
set DEFAULT_ENABLE_UPDATE_REQUEST to FALSE and "manually" called BOGUS_GAPRole_SendUpdateParam with appropriate parameters
e.g. BOGUS_GAPRole_SendUpdateParam( 30, 46 , 0x0000 , 500 , GAPROLE_NO_ACTION );
and suddenly I started getting a positive response from the iPhone4S.

Notes:
1) where I say "manually", my project uses the UART on the CC2540 connected to a PC via a USB serial dongle and a level shifter.
I send a command from the PC to the CC2540 to "manually" execute the BOGUS_GAPRole_SendUpdateParam command.
I have yet to "reautomatify" (how's that for a new word) the code.
2) the iPhone4S (ios5) does take its time to think about the CONNECTION PARAMETER UPDATE REQUEST. Presently it is
about 5seconds. Maybe in the future they'll offer faster response times for higher paying customers or such like.

D'oh!
Just after posting this I came across this
http://e2e.ti.com/support/low_power_rf/f/538/p/167385/717343.aspx
which you should also read.

Karel Seeuwen