gap_params_init and connection parameter issue

[HaiderRPM]

Hello,

I'm working on a firmware for a device that is created using ble proximity example. It is power constrain device and required a connection interval of 30 sec between a master (Android phone only) and slave nRF52810.

I’m using the following version and device.

1. SDK v17.0.2
2. 2. s112_nrf52_7.2.0_softdevice
3. Basically I’m using Android phones as my central or master device and nRF52810 as peripheral or slave.

Basic feature of the firmware

                The architecture is based on Application Timer Event callbacks.

                The firmware was prepared using the BLE Peripheral Proximity example.

In order to minimize power consumption the device runs a minimum of active GATT services listed below:

1. TX Power
2. Instant Alert Service (IAS)
3. Instant Alert Service Client (IAS-C)
4. Connection is BLE_PERIPHERAL

To get the desire interval I'm changing the following parameters. I have used different values for these parameters without violating the following two constrain but seem I'm not able to go beyond 15 sec interval ( 30 sec is desired). Is there anything I'm not doing correct. 

                   //constrains

1. 1. conn_sup_timeout * 4 > (1 + slave_latency) * max_conn_interval
   2. (1 + Conn_Latency) * Conn_Interval_Max * 2 < conn_sup_timeout

                   // Parameters

1. 1. MIN_CONN_INTERVAL               MSEC_TO_UNITS(800, UNIT_1_25_MS)
   2. MAX_CONN_INTERVAL               MSEC_TO_UNITS(830, UNIT_1_25_MS)
   3. SLAVE_LATENCY                   18
   4. CONN_SUP_TIMEOUT                MSEC_TO_UNITS(32000, UNIT_10_MS)

I'm getting the following error whenever I try to increase slave latency.

• gap_params_init();
  • APP_ERROR_CHECK(err_code);
    • I think It might help you “void app_error_handler_bare(ret_code_t error_code)” here error_code = 0x00000007.

[HaiderRPM]

Thank you for your reply, 

I agree with your statement. 

You can't have 30ms connection interval. You can have maximum 4 seconds (you can find the limits in ble_gap.h. Search for BLE_GAP_CP_LIMITS).

But my connection interval is 830 ms and I'm taking advantage of slave latency to achieve effective connection interval 30 sec.

But I think (1 + connSlaveLatency) * connInterval * 2 constrain don't allow to go beyond 15 sec. Or do we have any other way to get the better result. 

Do we have a way to disconnection and reconnect the peripheral with the 30 sec interval and transfer packets. but it is important to slave to sleep during that period of time.

Thanks

[Edvin]

HaiderRPM said:

But I think (1 + connSlaveLatency) * connInterval * 2 constrain don't allow to go beyond 15 sec.

 I agree.

 

HaiderRPM said:

Do we have a way to disconnection and reconnect the peripheral with the 30 sec interval and transfer packets. but it is important to slave to sleep during that period of time.

 Yes, it is possible, but I don't know whether it actually saves you any power. Setting up a connection requires more packets back and forth than just maintaining the "15 second connection interval".

Why do you have this strict requirement of 30ms? Is it to save power? If so, then using 15sec should be fine. You aren't saving much on going from 15 to 30 seconds. Besides, 30 seconds is against the specification. 

So why do you have this strict requirement of 30 seconds connection interval?

[HaiderRPM]

Thank you so much for the your help. We think about your suggestion regarding  more power consumption in disconnect and connect method and agree with you and dropping that idea.

We wanted that spec. because of our battery life need to be more than 180 days. After doing some math we come up with that number. But if its impossible to do, we can compromise over there.  

you mention about Bluetooth specification, Vol6, part B, section 4.5.2:. Do you have link for this PDF. I have a PDF for Apple BLE spec., does something similar exist for Android I looked for it but didn't find any. It will be a great help if you can give me a link for that.

[Edvin]

HaiderRPM said:

because of our battery life need to be more than 180 days.

 What battery are you using? That should be doable using a coin cell battery, but it depends on what other things your application is doing. Perhaps you are looking in the wrong place. 

If a 15 (or 4 second) connection interval makes your battery drain in less than 180 days, then there is either a bug, or you are using a peripheral that is drawing a lot of power (causing the BLE current consumption to become negligible. 

Please check out our Online Power Profiler. 

Using 4 sec connection interval, and a bare minimum application it should consume about 3.3µA:

Edit:

If the coin cell battery contains 200mAh, it should last a couple of years. Of course there is some loss due to leak current, and your application is maybe using some other peripherals drawing a bit of power. The battery's internal resistance also matters.

What sort of battery are you using?

BR,

Edvin

[HaiderRPM]

We are under the following assumptions.

We want to use 110 mAh battery but still in the process of finalizing. We have a piezo buzzer (3 mA) and a led (2 mA). 

This is the alarm sequence

1- LED "on" 500 ms, "off" 2000 ms
2- LED "on" 500 ms, "off" 2000 ms
4- LED "on" 500 ms, "off" 2000 ms
5- Buzzer "on" 500 ms, "off" 2000 ms - 200 Hz frequency
6- Buzzer "on" 500 ms, "off" 2000 ms
7- Buzzer "on" 500 ms, "off" 2000 ms
 

Device will be connected to 99%, 0.5% in alarm state, 0.5% advertising event. Our advertisement interval is 250 ms.

[Edvin]

HaiderRPM said:

We have a piezo buzzer (3 mA) and a led (2 mA). 

 In that case, the current from a 4second connection interval is negligible, so you don't need to spend time trying to increase the connection interval.

Whether the radio uses 3µA or 1.5µA doesn't matter when you are drawing 5mA on top of that. Then your current consumption is 5mA, or 5.003mA if you like, but I assume the 5mA is not a 5.000mA. 

In your case, the LED is on 1/5th of the time, and the buzzer is on 1/5th of the time, so you have 3/5 + 2/5 mA = 1mA on average. Maybe less if the LED and buzzer are not used simultaneously.

0.99*3µA
+ 0.005*1000µA
+ 0.005*38µA

= 
2.97µA
+ 5µA
+ 0.19µA

= 8.16µA on average. 

This makes your 110mAh last 13480 hours = 561 days. 

Reducing the connection interval to 30 seconds if that was possible would take the average current consumption to 6.865µA, which would last 667 days. It is an increase, but you have a lot more to save by reducing the alarm time (shorter on for the LED and the buzzer). 

If that is not an option, I am afraid you need to look into a bigger battery.

BR,

Edvin