Mesh proxy light switch client, current consumption with the Power Profile kit (PPK)

[Collet]

Hello, I currently using the proxy light switch exemple of the mesh SDK 2.0.1 in this configuration : 

I search to have the less current consumption in the mesh client .

With the Power Profile Kit of nordic I have this result :

 

With a lot of pic comsuption approximately every 10-30 ms. This measure is take when the Client is connected with a serveur( GATT conection) . (The devices are provisonned,  I can light-up the servers leds.)

This is my configuration :

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

(same value for the client and the server)

I don't understand my measure.

I would like to know why the pic isn't every 250ms ( or between 250-100ms). And how I can have less energy comsuption.

Thanks in advance

Axel Collet

[tesc]

Hi,

I suspect that this is a misunderstanding due to our bad naming of the light switch examples of nRF5 SDK for Mesh version 2.0.1.

There are five projects in the light_switch example: Client, provisioner, proxy_client, proxy_server and server. All of those are "normal" Bluetooth Mesh nodes. The proxy_client and proxy_server have both enables the proxy feature, which means they both operate as "proxy servers" according to the Bluetooth Mesh specification.

The project named "proxy_client" is better described as "light switch client with proxy feature", or "light switch client with proxy server". So it is the "light switch" model that is client or server, not the proxy feature.

With that in mind, seeing that the node uses ADV bearer close to 100 % of the time, high power consumption should be expected.

We are working on libraries and applications both for iOS and Android, for the client connecting to the node with GATT proxy feature, but at the moment we have not released those. This means at the moment we provide neither examples nor tools for proxy client. Only for proxy server.

Please note that the use case for the proxy feature is for legacy devices to participate in a Bluetooth Mesh network (primarily targeted at smartphones). It is not for low power operation. For that, you need the friend feature and low power nodes, which we have scheduled for implementation later this year. For more information about planned features and schedules, please contact our sales representative for your area. If you do not know who that is then please ask in a private ticket.

Regards,
Terje

[David Edwin]

I assume you wanted to use the mesh proxy to implement a battery powered node in the Mesh. This would mean that the mesh node should connect to the battery operated node.

The short answer is to shift the GAP roles in the GATT proxy for Mesh so that the battery operated node becomes a Peripheral with a GATT Client and the Mesh node is a Central with the GATT Server. This is done after the nodes are provisioned and configured.

==
Detailed steps
==

All the steps below are after the node has been provisioned and configured.

This means that the battery powered node should run as a Peripheral and send Mesh messages to the Proxy node implemented as a Central.

To do this, you will need to change the GATT proxy_client (Mesh SDK 2.0.1) example to run the Peripheral (battery powered node) and the GATT proxy_server (Mesh SDK 2.0.1) to run as Central.

The Central must Connect to the Peripheral.

Once connected the Peripheral will need to run Service Discovery as the GATT Client in on the Peripheral.

After Service Discovery the CCCD on the GATT Server on the Central is updated to allow Notifications. (Client Configuration Characteristic Descriptor of the Mesh Proxy Service updated to allow Notifications)

** References nRF5x SDK 15.0
**Use the ble_central/ble_app_uart_c to understand the Central creating a connection
**Use the ble_peripheral/ble_app_proximity to understand Service Discovery -- db_discovery_init() and to handle the CCCDs.

Once the link is established, the packets arriving Mesh proxy will need to be sent to the the Mesh stack on the Central. (should be already present in the GATT Proxy Server example)

The Mesh packets being sent from the Peripheral need to sent over the connection to the Central (should be already present in the GATT Proxy Client example)
=
The final step, is for the GATT client to send the proxy configuration messages, so that the proxy will forward packets received for the Mesh address of the low power node over the GATT link.

Is this something that you will be able to do ?

[Ceow]

Hello David,

May I ask you about what GATT proxy_client example you are talking ?

I am interested in that answer and I can only find de light_switch proxy_client example which is not a GATT client, as tesc mentioned above.

Thanks.

[David Edwin]

light_switch proxy client is what needs to be modified and a GATT client should be added to the light_switch proxy client, code changes as above are needed. I will edit the names of the examples to be more precise.

[Ceow]

Ok thank you very much