Mesh LPN application timing out and/or terminating

RE: Mesh LPN application timing out and/or terminating

tesc — Mon, 03 Oct 2022 14:27:44 GMT

Hi,

It could be Friend poll, but it could also be advertising from the GATT proxy feature or publishing. GATT proxy is needed if you want it to be possible to configure the node from a smartphone or other device which only has GATT.

Regards,
Terje

RE: Mesh LPN application timing out and/or terminating

Arif@Lynxemi — Mon, 03 Oct 2022 09:55:46 GMT

We added a 10 uF cap and removed the resistor ladder for the SAADC and managed to get down to this. Very good! Thank you very much for the suggestion. Is there any way to get it down further? The peaks are caused by the friendship polling IIRC, so maybe I should play around with the timings? Right now it'll last 83~ days on a CR2032

RE: Mesh LPN application timing out and/or terminating

tesc — Fri, 30 Sep 2022 14:13:29 GMT

Hi,

If you zoom in on that current draw plot, I think you will find that the peaks are very narrow spikes of one or two data points. That should be easily mitigated using capacitors, giving less maximum power draw as seen from the batteries.

The nature of the power draw would be very similar also in nRF Connect SDK, so this would not be a reason for switching. However, there are other reasons for switching, such as the fact the nRF5 SDK is in maintenance mode and new development will happen only in nRF Connect SDK, ref. the nRF Connect SDK and nRF5 SDK statement.

Regards,
Terje

RE: Mesh LPN application timing out and/or terminating

Arif@Lynxemi — Wed, 28 Sep 2022 08:31:32 GMT

Hi Terje,

Sorry to get back to you so late. I finally got my hands on a PPK2 and for some reason the REPLY buttons are not showing up properly on this forum. I'm measuring the current on my custom nRF52840 board and I'm only using the TWI and SAADC peripherals, which I only turn on and off every 5 minutes to read data from a sensor. This time I'm running with MESH_FEATURE_LPN_ACT_AS_REGULAR_NODE_OUT_OF_FRIENDSHIP=0.

Other definitions of note:

/* The maximum duration to scan for incoming Friend Offers. */
#define FRIEND_REQUEST_TIMEOUT_MS (MESH_LPN_FRIEND_REQUEST_TIMEOUT_MAX_MS) // 1000
/* The upper limit for two subsequent Friend Polls. */
#define POLL_TIMEOUT_MS (SEC_TO_MS(10))
/* The time between LPN sending a request and listening for a response. */
#define RECEIVE_DELAY_MS (100)

mesh_lpn_friend_request_t freq;
freq.friend_criteria.friend_queue_size_min_log = MESH_FRIENDSHIP_MIN_FRIEND_QUEUE_SIZE_16; // 4
freq.friend_criteria.receive_window_factor = MESH_FRIENDSHIP_RECEIVE_WINDOW_FACTOR_1_0; // 0
freq.friend_criteria.rssi_factor = MESH_FRIENDSHIP_RSSI_FACTOR_2_0; // 2
freq.poll_timeout_ms = POLL_TIMEOUT_MS;
freq.receive_delay_ms = RECEIVE_DELAY_MS;

Here's what idle looks like:

It runs much too high for a button cell so we're deploying them with bigger Li-ions. They've been running fine for more than two weeks but we're concerned about the longevity. Do you think moving to the nRF Connect SDK would see some improvements?

Regards,

Arif

RE: Mesh LPN application timing out and/or terminating

tesc — Thu, 08 Sep 2022 14:27:30 GMT

Hi,

Since the MESH_FEATURE_LPN_ACT_AS_REGULAR_NODE_OUT_OF_FRIENDSHIP means the device will stay in RX when out of friendship, it should mean both that it receives messages and uses more power when not in friendship, yes. Power consumption would be low whenever in friendship, so the power consumption impact depends on how much time is spent outside of friendship. Figuring out and fixing the friendship loss issue could therefore improve power consumption by a lot if a significant time is spent outside of friendship, or if friendship is lost (and reinitiated) often.

Regarding the MESH_LPN_POLL_RETRY_COUNT, this will work if the friend is often unavailable due to other operations on the friend blocking it from scanning, or if the LPN is prevented from executing polls. If the friend is actually offline, then a high retry count means there is a longer time period for which incoming messages are lost. The reason for the latter, is that during the time between the friend node goes offline and the friendship is terminated, the LPN considers itself still in friendship, so it does not scan for messages but rather depends on the friend to store messages for it. Therefore, high MESH_LPN_POLL_RETRY_TIMEOUT has the drawback of more messages lost at friendship termination. The same will happen for any friendship termination, as the friend will also discard the already received messages when it hasn't heard back from the LPN and the friendship times out.

The observation regarding app scheduler is interesting. However I have no suggestions why this change should impact friendship in the way you describe. With app scheduler, less should happen in interrupt context, providing more control for the stack to operate, which should improve overall stack performance. May it be too small buffers related to app scheduler, leading to lost operations and/or lost data, impacting the performance of the device? Are you experiencing errors, asserts, etc, leading to LPN or Friend resetting? That could explain lost friendship.

It is not quite clear to me if the difference was seen when app scheduler was disabled on LPN, or on Friend, or on both.

Regards,
Terje

RE: Mesh LPN application timing out and/or terminating

Arif@Lynxemi — Wed, 07 Sep 2022 07:06:48 GMT

Update 2:

For now, my latest two replies there are where I'm at: with the friendship timing out maybe every 10-20mins. I've also set

MESH_FEATURE_LPN_ACT_AS_REGULAR_NODE_OUT_OF_FRIENDSHIP = 1

so that the sensors don't skip a beat with the periodic publications.

Now the LPN devices work fine, and friend nodes reliably deliver their message when they aren't timed out so we have an MVP there. My worry is the power consumption of the device now.

RE: Mesh LPN application timing out and/or terminating

Arif@Lynxemi — Fri, 29 Apr 2022 09:48:25 GMT

Update:

I tested with the LPN with the example Light Switch Server and its soo much more stable. So the trouble seems to be from my custom applications. The main difference between it and the Light Switch server is the implementation of the app scheduler functionality, so I removed that and there seems to be a massive difference:

00> <t:      16117>, mesh_app_utils.c,   66, Device UUID (raw): 46E6DC064D414876A02288131A0A76BE
00> <t:      16121>, mesh_app_utils.c,   67, Device UUID : 46E6DC06-4D41-4876-A022-88131A0A76BE
00> <t:     498977>, ble_softdevice_support.c,  104, Successfully updated connection parameters
00> <t:     592856>, ble_softdevice_support.c,  104, Successfully updated connection parameters
00> <t:    1326563>, main.c,  166, Successfully provisioned
00> <t:    1326573>, main.c,  160, Node Address: 0x0027 
00> <t:    1485224>, ble_softdevice_support.c,  104, Successfully updated connection parameters
00> <t:    1576399>, ble_softdevice_support.c,  104, Successfully updated connection parameters
00> <t:    1804529>, config_server.c,  632, dsm_appkey_add(appkey_handle:0 appkey_index:0)
00> <t:    2104592>, config_server.c, 2555, Access  Info:
00>     element_index=1    model_id = C002-493    model_handle=2
00> <t:    2631745>, config_server.c,  303, Get Pub Status: 0
00> <t:    2631749>, config_server.c,  307, Publish Period: 158 Publish Res: 2, Publish Steps: 30
00> <t:    3053449>, thp_sensor_server.c,   27, Initiating the friendship establishment procedure.
00> <t:    3104532>, main.c,  215, Received friend offer from 0x0014
00> <t:    3108094>, main.c,  256, Friendship established with: 0x0014
00> <t:    3136064>, main.c,  268, Friendship with 0x0014 terminated. Reason: 2
00> <t:    3136071>, main.c,   98, Initiating the friendship establishment procedure.
00> <t:    3169410>, main.c,  215, Received friend offer from 0x0013
00> <t:    3190584>, main.c,  246, Friend Request timed out
00> <t:    3190589>, main.c,   98, Initiating the friendship establishment procedure.
00> <t:    3196110>, main.c,  215, Received friend offer from 0x0026
00> <t:    3199671>, main.c,  256, Friendship established with: 0x0026
00> <t:    3220611>, main.c,  242, Friend poll procedure complete
00> <t:    3531194>, main.c,  242, Friend poll procedure complete
00> <t:    3841777>, main.c,  242, Friend poll procedure complete
00> <t:    4155886>, main.c,  242, Friend poll procedure complete
00> <t:    4466469>, main.c,  242, Friend poll procedure complete
00> <t:    4777052>, main.c,  242, Friend poll procedure complete
00> <t:    5098213>, main.c,  242, Friend poll procedure complete
00> <t:    5415848>, main.c,  242, Friend poll procedure complete
00> <t:    5726431>, main.c,  242, Friend poll procedure complete
00> <t:    6037014>, main.c,  242, Friend poll procedure complete
00> <t:    6347597>, main.c,  242, Friend poll procedure complete
00> <t:    6665232>, main.c,  242, Friend poll procedure complete
00> <t:    6975815>, main.c,  242, Friend poll procedure complete
00> <t:    7293450>, main.c,  242, Friend poll procedure complete
00> <t:    7604033>, main.c,  242, Friend poll procedure complete
00> <t:    7914616>, main.c,  242, Friend poll procedure complete
00> <t:    8225200>, main.c,  242, Friend poll procedure complete
00> <t:    8535783>, main.c,  242, Friend poll procedure complete
00> <t:    8849892>, main.c,  242, Friend poll procedure complete
00> <t:    9160475>, main.c,  242, Friend poll procedure complete
00> <t:    9471058>, main.c,  242, Friend poll procedure complete
00> <t:    9781641>, main.c,  242, Friend poll procedure complete
00> <t:   10092224>, main.c,  242, Friend poll procedure complete
00> <t:   10402807>, main.c,  242, Friend poll procedure complete
00> <t:   10713390>, main.c,  242, Friend poll procedure complete
00> <t:   11038077>, main.c,  242, Friend poll procedure complete
00> <t:   11348660>, main.c,  242, Friend poll procedure complete
00> <t:   11659243>, main.c,  242, Friend poll procedure complete
00> <t:   11969826>, main.c,  242, Friend poll procedure complete
00> <t:   12280409>, main.c,  242, Friend poll procedure complete

0x14 is the custom application with app scheduler and 0x26 is one without. So it seems that the app scheduler is causing problems with the friendship procedure. Is there a workaround?

RE: Mesh LPN application timing out and/or terminating

Arif@Lynxemi — Fri, 29 Apr 2022 07:32:45 GMT

I have set up a way for the Provisioner to send a message to the LPN after configuration. I have also set MESH_LPN_POLL_RETRY_COUNT to 15 as suggested in this link: Friendship Terminated reason 2, How to adjust the friendship setting to have a solid connection - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com)

It's slightly more stable but when it finally establishes a friendship it still times out every 20-30 seconds:

00> <t:   15001333>, main.c,   98, Initiating the friendship establishment procedure.
00> <t:   15006851>, main.c,  215, Received friend offer from 0x0011
00> <t:   15010412>, main.c,  256, Friendship established with: 0x0011
00> <t:   15027827>, main.c,  242, Friend poll procedure complete
00> <t:   15338410>, main.c,  242, Friend poll procedure complete
00> <t:   15648993>, main.c,  242, Friend poll procedure complete
00> <t:   15804171>, thp_sensor.c,  230, 27.51, 63.49, 0.00, 481
00> <t:   15841747>, main.c,  268, Friendship with 0x0011 terminated. Reason: 2
00> <t:   15841776>, main.c,   98, Initiating the friendship establishment procedure.
00> <t:   15936632>, main.c,  215, Received friend offer from 0x0014
00> <t:   15957806>, main.c,  246, Friend Request timed out
00> <t:   15957811>, main.c,   98, Initiating the friendship establishment procedure.
00> <t:   15963330>, main.c,  215, Received friend offer from 0x0010
00> <t:   15984504>, main.c,  246, Friend Request timed out
00> <t:   15984509>, main.c,   98, Initiating the friendship establishment procedure.
00> <t:   16026156>, main.c,  215, Received friend offer from 0x0010
00> <t:   16029717>, main.c,  256, Friendship established with: 0x0010
00> <t:   16043605>, main.c,  242, Friend poll procedure complete
00> <t:   16371801>, main.c,  268, Friendship with 0x0010 terminated. Reason: 2
00> <t:   16371807>, main.c,   98, Initiating the friendship establishment procedure.
00> <t:   16377325>, main.c,  215, Received friend offer from 0x0012
00> <t:   16398499>, main.c,  246, Friend Request timed out
00> <t:   16398504>, main.c,   98, Initiating the friendship establishment procedure.
00> <t:   16404022>, main.c,  215, Received friend offer from 0x0013
00> <t:   16425196>, main.c,  246, Friend Request timed out
00> <t:   16425202>, main.c,   98, Initiating the friendship establishment procedure.
00> <t:   16459584>, main.c,  215, Received friend offer from 0x0012
00> <t:   16480758>, main.c,  246, Friend Request timed out
00> <t:   16480763>, main.c,   98, Initiating the friendship establishment procedure.
00> <t:   16516914>, main.c,  215, Received friend offer from 0x0011
00> <t:   16538002>, main.c,  246, Friend Request timed out
00> <t:   16538007>, main.c,   98, Initiating the friendship establishment procedure.
00> <t:   16574158>, main.c,  215, Received friend offer from 0x0012
00> <t:   16595245>, main.c,  246, Friend Request timed out
00> <t:   16595250>, main.c,   98, Initiating the friendship establishment procedure.
00> <t:   16600769>, main.c,  215, Received friend offer from 0x0011
00> <t:   16604331>, main.c,  256, Friendship established with: 0x0011
00> <t:   16632306>, main.c,  268, Friendship with 0x0011 terminated. Reason: 2
00> <t:   16632313>, main.c,   98, Initiating the friendship establishment procedure.
00> <t:   16690303>, main.c,  215, Received friend offer from 0x0014
00> <t:   16700917>, main.c,  256, Friendship established with: 0x0014
00> <t:   16725377>, main.c,  242, Friend poll procedure complete
00> <t:     276358>, main.c,  268, Friendship with 0x0014 terminated. Reason: 2

RE: Mesh LPN application timing out and/or terminating

tesc — Wed, 27 Apr 2022 11:01:05 GMT

Hi,

There's no standardized way to trigger a friend request remotely, although one ide could be to have the LPN feature disabled by default, and start sending friend requests once the LPN feature is enabled through configuration. That way, the provisioner can configure everything it wants first, then enable LPN as the final configuration.

Alternatively use a timer, so that if no new configurations are received within a certain time-out the configuration is considered done.

Or wait with requesting friendships until the GATT connection to the provisioner has terminated (assuming a GATT device such as a smartphone as provisioner.)

Using a button for triggering friendship is of course also an option.

(PS: Your link was to a different page, but I assume you were referring to the "LPN life cycle" section under Low Power node feature.)

Regards,
Terje

RE: Mesh LPN application timing out and/or terminating

Arif@Lynxemi — Thu, 21 Apr 2022 08:27:24 GMT

Happy Easter hols!

I see, so one possible solution is for the provisioner to send a message to the LPN when it is in the "Normal operation(continuous scan)" mode? See the Typical LPN Lifecycle. That message will just initiate the friendship process and nothing else. Alternatively I have to produce devices with pushbuttons that will do the same thing.

RE: Mesh LPN application timing out and/or terminating

tesc — Wed, 13 Apr 2022 11:31:27 GMT

Hi,

You might be initiating the friendship establishment procedure a bit too early, yes. The node provisioning and configuration is done in two parts. First you have the provisioning, which includes the device into the network. Then you have the configuration of the device, which involves sharing app keys, setting node configurations, configure the models on the device, and so on. I suspect somehting might go wrong if initiating a friendship concurrently with the provisioner configuring the device.

You get the provisioning_complete_cb callback when provisioning is complete, but you still have configuration to do. There is no similar callback after configuration is finished, since it is up to the provisioner what settings to configure (and what settings to leave at default values), and so it is impossible for the device to tell that the configuration is complete.

Please note that we are entering Easter vacation in Norway. You may have to wait until next week for answers to any follow-up questions.

Regards,
Terje