OpenThread network miss messages when BLE stack stop advertising

[SimonEMB]

Hello

I have an application which requires the use of both BLE and Openthread in the same time.
The BLE is meant to connect an OpenThread mesh network to a smartphone.

I am using the soft device s140_nrf52_6.1.1 with a nRF52840.
I developped my code based on the ble_thread_dyn_mtd_coap_cli example of the Nordic SDK with Keil uVision 5.

When a smartphone is connected to the network, an openthread braodcast notify the devices of a BLE connection to the network.
All devices stop advertising then. It avoid BLE polution and it is also a way to make sure only one smartphone is connected toe the network at a time.
But when advertising is stoped, and I want to read sensor data from my mesh network, it seems that all the devices do not get the read request.
We can see there is an issue with the blinking LED on the Eval Board, its frequency is affected. Like if the BLE stack was using the processor for long period and prevent the openthread stack to get the request.

What exactly happen when we do a sd_ble_gap_adv_stop ? Why would it cause such a bug ?

Thanks in advance for your help.

[AndreasF]

Hi.

Could you please explain a bit more?

When you say:

and I want to read sensor data from my mesh network, it seems that all the devices do not get the read request.

 You are talking about the openThread stack here?

What API calls are you making?

Do you have any sniffer logs of this?

Like if the BLE stack was using the processor for long period and prevent the openthread stack to get the request.
What exactly happen when we do a sd_ble_gap_adv_stop ? Why would it cause such a bug ?

 Are you using the timeslot API?

Best regards,

Andreas

[SimonEMB]

Hi, Andreas

Thank you for your comment.

When I read data from the network, I write bytes into a dedicated BLE service, then the openThread stack is used with a CoAP service to broadcast a read request. And it seems this request is not catched by some devices which are not advertising, if I try a few secondes later it might work, it's random.
I tried without stoping advertising and it works well.

I do not use timeslot API. Should I ?

Right now I do not have sniffer yet, I do not know yet how to use it to see the default since it seems random.
I used the nRF Connect app and I count the number of answers I get.

Best regards

[AndreasF]

Hi again.

What happens if you dont stop advertising? What is the connection interval you're using?

SimonEMB said:

I do not use timeslot API. Should I ?

Look here please.

SimonEMB said:

Right now I do not have sniffer yet, I do not know yet how to use it to see the default since it seems random.
I used the nRF Connect app and I count the number of answers I get.

 You can read more about the sniffer here.

Best regards,

Andreas

[SimonEMB]

This issue seems to be fixed with the Thread and Zigbee SDK V4.0.0.