gap_params_init and connection parameter issue

RE: gap_params_init and connection parameter issue

Einar Thorsrud — Thu, 12 Nov 2020 09:19:01 GMT

Hi,

[quote user="HaiderRPM"]Error I can see on my nRF Connect app is Error 133, defined as: #define GATT_ERROR 0x85 [/quote]

I see. That is very useful information. Unfortunately GATT error 133 is a quite generic error so it is difficult to say what causes it.

[quote user="HaiderRPM"]I'm using it with the similar device but does it matter?[/quote]

It would be interesting to know if this only happens with some specific peer devices. Which phones have you tested with (phone model and Android version), and do you see the same behaviour with all?

[quote user="HaiderRPM"]I also notice it do not connect after disconnection even if I manually tap the connect button on the app. I have to restart my peripheral and connect it.[/quote]

that is interesting. Do you do some debug logging on the nRF side to understand what happens? It would be very useful to see what happens seen form the nRF, bot before the disconnect and which disconnect reason the nRF sees.

Lastly, a sniffer trace could be very useful, though it may be difficult to produce as the disconnect happens so seldomly. In any case logging and a trace of the failed reconnect attempts before the nRF is reset would also be useful.

RE: gap_params_init and connection parameter issue

HaiderRPM — Wed, 11 Nov 2020 16:24:16 GMT

Hello Einar,
Thank you for your kind response

Error I can see on my nRF Connect app is Error 133, defined as: #define GATT_ERROR 0x85

I believe supervision timeout is not the reason for the disconnection. As last night I changed my connection parameters to the default values accept advertisement interval.

#define MIN_CONN_INTERVAL MSEC_TO_UNITS(500, UNIT_1_25_MS) /**< Minimum acceptable connection interval (0.5 seconds). */
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(1000, UNIT_1_25_MS) /**< Maximum acceptable connection interval (1 second). */

#define SLAVE_LATENCY 0 /**< Slave latency. */
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(4000, UNIT_10_MS) /**< Connection supervisory timeout (4 seconds). */

// change by Haider: old value APP_ADV_INTERVAL 40 {Range can be 20ms to 10.24 sec} /**< The advertising interval (in units of 0.625 ms. This value corresponds to 25 ms). */
#define APP_ADV_INTERVAL MSEC_TO_UNITS(250, UNIT_0_625_MS)
#define APP_ADV_DURATION 30000 // originally: 18000

I'm using it with the similar device but does it matter? I also notice it do not connect after disconnection even if I manually tap the connect button on the app. I have to restart my peripheral and connect it.

RE: gap_params_init and connection parameter issue

Einar Thorsrud — Wed, 11 Nov 2020 15:03:50 GMT

Hi,

[quote user="HaiderRPM"]You mentioned about Bluetooth specification, Vol6, part B, section 4.5.2: in your previous reply, would you please forward me the link for this pdf.[/quote]

You can download the Bluetooth core specification here.

[quote user="HaiderRPM"]But it still disconnect after one or two day. [/quote]

What is the disconnect reason? Based on this discussion I assume it is supervision timeout, but I do not see it clearly stated so it would be good to know. Also, have you only tested one Android device, or do you see the same with other devices?

And also, is there a problem with these disconnects? Normally the peripheral would start advertise on a disconnect and the phone would connect again without the user ever notising a difference. Depending on the RF environment etc it may not be possible to ensure that you never get any disconnects.

RE: gap_params_init and connection parameter issue

HaiderRPM — Mon, 09 Nov 2020 13:57:57 GMT

Hello,

I hope you had a great weekend, now I'm following all restrictions you mentioned here. I'm using following new parameters. But it still disconnect after one or two day. I'm using nRF connect app in android (this project is only for android). Can you tell me where I'm going wrong. You mentioned about Bluetooth specification, Vol6, part B, section 4.5.2: in your previous reply, would you please forward me the link for this pdf.

#define MIN_CONN_INTERVAL MSEC_TO_UNITS(900, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(1000, UNIT_1_25_MS)

#define SLAVE_LATENCY 12
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(32000, UNIT_10_MS)
#define APP_ADV_INTERVAL MSEC_TO_UNITS(250, UNIT_0_625_MS)
#define APP_ADV_DURATION 30000 // originally value was: 18000

Thank you

RE: gap_params_init and connection parameter issue

Edvin — Wed, 04 Nov 2020 08:32:43 GMT

[quote user="HaiderRPM"]We have a piezo buzzer (3 mA) and a led (2 mA). [/quote]

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

RE: gap_params_init and connection parameter issue

HaiderRPM — Tue, 03 Nov 2020 21:01:36 GMT

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.

RE: gap_params_init and connection parameter issue

Edvin — Tue, 03 Nov 2020 08:23:31 GMT

[quote user="HaiderRPM"]because of our battery life need to be more than 180 days.[/quote]

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

RE: gap_params_init and connection parameter issue

HaiderRPM — Mon, 02 Nov 2020 15:34:08 GMT

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.

RE: gap_params_init and connection parameter issue

Edvin — Mon, 02 Nov 2020 10:09:33 GMT

[quote user="HaiderRPM"]But I think (1 + connSlaveLatency) * connInterval * 2 constrain don't allow to go beyond 15 sec.[/quote]

I agree.

[quote user="HaiderRPM"]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.[/quote]

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?

RE: gap_params_init and connection parameter issue

HaiderRPM — Fri, 30 Oct 2020 15:41:02 GMT

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

RE: gap_params_init and connection parameter issue

Edvin — Fri, 30 Oct 2020 14:18:12 GMT

err_code = 7 means NRF_ERROR_INVALID_PARAM (look at nrf_error.h).

You have set your conn_sup_timeout to 32 000 units of 10ms = 32 seconds, which is the maximum allowed supervision timeout.

From the Bluetooth specification, Vol6, part B, section 4.5.2:

The connSupervisionTimeout shall be a multiple of 10ms in the range 100ms to 32.0s and shall be larger than

(1 + connSlaveLatency) * connInterval * 2

which is considered in your b. constraint.

When conn_latency = 18:

(1+18) * 800*1.25 * 2 = 38 000, which is already larger than your supervision timeout, so it should probably have returned NRF_ERROR_INVALID_PARAMS.

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).

The reason that this requirement exists is that the devices should have at least two attempts to send a packet before they disconnect. Otherwise, you will get a disconnect every time a packet is lost due to noise on air.

BR,

Edvin