Can you sync the connection interval with the fine timer?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
joki_2146851
Level 3
Level 3
5 likes given First like received First like given

Is there a way to kludge syncing up the connection interval with the fine timer for the 20732?

0 Likes
1 Solution
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

In the example there is wicked_sense_connection_handle what would be the relevant variable I am assigning in my code.

     The connection handle is 0 at creation and in connection down. In connection up, however, set it as seen in wiced_sense:

               wiced_sense_connection_handle = (UINT16)emconinfo_getConnHandle();

Also at what point do you deinit?

     In wiced_sense, deinit is called in connection down. I'm not sure if this is necessary or a power saving technique, but you can't go wrong putting it there.

if I'm understanding things correctly,this event will fire ahead of a connection, so how much jitter is there in this firing?

     The timing of this callback must be perfected, you must call it as close to the radio tx as possible without overlapping it otherwise you'll get unwanted behavior. 

Also it would seem u need to not use the fine timer otherwise it might be called twice

     This is the tricky part. If you have your fine_timeout still registered as a timer, yes, it will be called twice. If you don't want this, stop the timer using the killtimer call found in the API. But this now produces the problem that your timer won't be called in connection down. So to balance between the two, in connection up kill your timer and register for connection notifications. In connection down, start your timer and kill connection notifications.

Does the host (in my case a tablet), have a final say on the connection interval, or are the parameters to this function determining this?

     The client in the BLE does have the final say in the connection interval, but the server can request some interval and it is generally granted as long as its reasonable.

Jacob

View solution in original post

0 Likes
6 Replies
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

jkindem

It won't necessarily be syncing your fine timer to the connection interval. What you'll be doing is registering a callback for some number of ms prior to connection. If you choose to use your fine timer as this callback, so be it.

This is a very vital aspect of the WICED Sense app. You may need to download a newer SDK in order to gain access to that sample app (although you won't use the newer SDK for the 32 chip).

At the top of your app import the following functions:

    extern void blecm_connectionEventNotifiationInit(void);

    extern void blecm_connectionEventNotifiationEnable

                              (void (*clientCallback)

                              (void*, UINT32),

                               UINT32 clientContext,

                               INT16 offset,

                               UINT16 defaultPeriod,

                               UINT32 connHandle);

    extern void blecm_connectionEventNotifiationDisable(void);


Utilize the init and deinit as expected, use init prior to cb registration. The actual registration of your fine timer as the callback of this event is more complex. It takes a lot of parameters to fine tune the callback to your needs. The example as pulled from WICED Sense app:

  blecm_connectionEventNotifiationEnable(

          (void (*)(void*,UINT32))your_fine_timer_here, 0, 6250/625,

           30000/625, wiced_sense_connection_handle);


    *the division by 625 is in order to express the number in terms of slots


Jacob

In the example there is wicked_sense_connection_handle what would be the relevant variable I am assigning in my code.

Also at what point do you deinit?

So a few questions , so if I'm understanding things correctly,this event will fire ahead of a connection, so how much jitter is there in this firing? Also it would seem u need to not use the fine timer otherwise it might be called twice, or is the prevented by the system, And if the fine timer is not called, then if I'm not connected, will this event get synthesized, or does nothing get called?

Does the host (in my case a tablet), have a final say on the connection interval, or are the parameters to this function determining this?

Thanks for the help

Sent on the new Sprint Network

0 Likes
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

In the example there is wicked_sense_connection_handle what would be the relevant variable I am assigning in my code.

     The connection handle is 0 at creation and in connection down. In connection up, however, set it as seen in wiced_sense:

               wiced_sense_connection_handle = (UINT16)emconinfo_getConnHandle();

Also at what point do you deinit?

     In wiced_sense, deinit is called in connection down. I'm not sure if this is necessary or a power saving technique, but you can't go wrong putting it there.

if I'm understanding things correctly,this event will fire ahead of a connection, so how much jitter is there in this firing?

     The timing of this callback must be perfected, you must call it as close to the radio tx as possible without overlapping it otherwise you'll get unwanted behavior. 

Also it would seem u need to not use the fine timer otherwise it might be called twice

     This is the tricky part. If you have your fine_timeout still registered as a timer, yes, it will be called twice. If you don't want this, stop the timer using the killtimer call found in the API. But this now produces the problem that your timer won't be called in connection down. So to balance between the two, in connection up kill your timer and register for connection notifications. In connection down, start your timer and kill connection notifications.

Does the host (in my case a tablet), have a final say on the connection interval, or are the parameters to this function determining this?

     The client in the BLE does have the final say in the connection interval, but the server can request some interval and it is generally granted as long as its reasonable.

Jacob

0 Likes

Jake,

I did a search for blecm_connectionEventNotifiationInit in the SDK 1.1, and I cannot find it (I need to use 1.1 for the 20732s chip). Does it exist in that SDK?

Joel

0 Likes
Anonymous
Not applicable

My understanding was that this notification is a new feature in SDK 2.2.1

If your client is an iPhone, there are very specific rules for what is an acceptable connection interval.  These rules are available by a simple google search for iOS develpers guideline for BLE.

In addition I have found that the minimum and maximum connection intervals requested must not be equal to each other or iOS will reject your connection parameter request and you will get whatever iOS wants which is typically 30 msec intervals but could be less depends on what iOS thinks it can spare based on its overall performance needs.  The supervisor timeout can't be more than 6 seconds.

Here is what I found on the iOS developer guidelines:

// The connection parameter request may be rejected  by iOS client if it does not comply with all of these rules:

// * Interval Max * (Slave Latency + 1) <= 2 seconds

// * Interval Min >= 20 ms

// * Interval Min + 20 ms <= Interval Max Slave Latency <= 4

// * connSupervisionTimeout <= 6 seconds

// * Interval Max * (Slave Latency + 1) * 3 < connSupervisionTimeout

Speaking of the advance notice feature, I tried this and my first couple of tries failed.  It didn't work for me... but I didn't have time to debug it and abandoned the attempt after a few hours.  If anybody has had lessons learned to share that would be great.  I see there are some in this thread already and I may give those a try soon.

eric

0 Likes
Anonymous
Not applicable

Hello Joel,

Eric is correct.  This is a new feature in SDK 2.2.1

Thanks,

JT

0 Likes