MESH packet loss problem

RE: MESH packet loss problem

Hung Bui — Tue, 21 May 2019 09:05:07 GMT

Hi Solin,

I don't see any problem having both client and server on same project. But you need to make sure they are not on the same element. In other words, they should have different address.

You can find in this demo we do the same thing, on each thingy there is a light switch client and a light switch server:

https://github.com/NordicPlayground/thingy52-mesh-provisioning-demo

RE: MESH packet loss problem

Solin — Mon, 20 May 2019 09:31:58 GMT

Hi Hung,

I am the same team with Roger. Maybe I know the problem origin, as the light_switch demo has 2 devices (client, server), but our project involves each device that includes both client and server, thats why repeat sending would fail. My question is, under our use case, we cannot ensure which device would initiate the send command (client), thats why we have every device to include client as well server too, is it fine and correct? If not, how can we handle this issue?

Thanks!

RE: MESH packet loss problem

Hung Bui — Mon, 20 May 2019 07:44:44 GMT

Hi Roger,

I assume you meant the "server still cannot receive data" is only for 20% of the time ?

Which nRF52832 module did you use ?

Can you test with normal BLE examples and check if you see the same bad performance ?

When you enable LOG_LEVEL_DBG1, do you see "TX:" in the log on the client ?

RE: MESH packet loss problem

rogery — Thu, 16 May 2019 13:24:45 GMT

Hi Hung,

Using 52832 BLE module.

Using Client to send out by "generic_onoff_client_set", at the same time, we set "Retransmit count" as 5, set "Invertal Steps" as 3, but server still cannot receive data (I've opened the LOG_LEVEL_DBG1, and cannot find any RX wording).

In addition, these devices are placed on the same table nearby each other.

RE: MESH packet loss problem

Hung Bui — Thu, 16 May 2019 11:17:45 GMT

Hi Roger,

Which hardware do you use to test ?

How do you verify that the missing commands were actually sent from the client ?

Which type message you sent from the client. If you want to have more reliable communication you should use set with acknowledge message so that when there is a timeout the stack will retransmit the data.

Please test in an environment with less air traffic (wifi for example)

You may want to turn logging level to LOG_LEVEL_DBG1 to see more log on access layer (look for "TX:" "RX:" log)