node cannot receive message

RE: node cannot receive message

bdieseldorff — Tue, 27 Feb 2018 17:07:12 GMT

Hi, given that the wording is almost exactly the same, did you work with Edvin on case 200832? We've already responded there about this. Here it is for convenience:

No error is returned.
Mesh messages are still being sent. This is known because it was tried with 1 client and 3 servers. The servers don't all stop receiving at once, rather each one fails on its own after some time.
- FWIW, we have seen 2 failure modes:
  - Radio doesn't appear to receive, but UART still works
  - Radio doesn't appear to receive, UART also unresponsive
No persistent storage is used.

RE: node cannot receive message

Mttrinh — Tue, 27 Feb 2018 16:47:01 GMT

Do you get any errors returns from the access in the client? Do you see the mesh-messages on the air if you scan with nRF Connect app or a sniffer? Does the device crash, or does it stop sending? Do you have persistent storage enabled?

RE: node cannot receive message

weizhen — Fri, 23 Feb 2018 16:37:41 GMT

Yes, all the timer and uart things are under priority 7, which is the lowest of mesh

RE: node cannot receive message

Mttrinh — Fri, 23 Feb 2018 14:27:01 GMT

Hi,

I suspect that the issue might be that you are calling the mesh from different IRQ levels. I suggest you to take a look at this to start with. On line 179 in your code, you set the mesh IRQ priority to LOWEST, you have to keep the code consistent and see to that all of the code are on the same level. You have two functions that is being called in your main-loop that ends up calling the mesh, which is something that breaks this. You also have to check that your timer-callback comes back in LOWEST.

RE: node cannot receive message

bdieseldorff — Thu, 15 Feb 2018 16:51:46 GMT

A similar test was run to be even more similar to the light_switch example.

Server code was only modified to use different pins for our board and to toggle an LED when they receive a group message.
Client code was modified to
- Have a timer that ticks every half ms
- Have a divided down variant that ticks every 100ms
- When 100ms timer ticks
  - Toggle an LED
  - Send a group message using access_model_publish (this is doing the same thing as simple_on_off_client_set_unreliable in the example)

Doing this we see client and 3 servers all blink every 100ms initially (as expected).
After some time, which can vary, we see a server stop blinking.
Eventually the other servers also stop blinking.

This is still in line with our earlier findings that servers are not reliably receiving messages for a large volume of messages over time.