-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some bluetooth advertising packages never get transmitted over-air (Bluetooth Mesh application) #34852
Comments
Radio Rx utilization will be low, and hence will lower number of advertising reports be generated.
Also, correct me, the advertisement are enabled and disabled in less than 100 ms? If you are only using the controller for mesh, enable the following:
Please provide details of reproducing your issue, steps to build, steps and commands to use to reproduce the issue, upload complete logs, air traces if any, how was the statistics calculated, if there has been changes to code etc., preferably in the format requested in the issue template that was provided when creating this issue. |
Depends on the configuration, but often, yes. |
Thank you for the reply!
For curiousity:
|
Describe the bug
My setup is a Nordic nRF52832-board running the zephyr hci_uart sample which is connected via UART with the host, a GNU/Linux aarch64. The host is running the bluetooth-mesh-daemon proveded by BlueZ and I am using the tool
mesh-cfgclient
, also provided by BlueZ, that is using the DBUS-api provided by the daemon.I have noticed that the reliability of mesh-messages reaching its destination is quite low. And when using a sniffer to monitor the bluetooth traffic, it looks like many of the messages (i.e. advertising packages, the mesh-daemon only uses the ADV-bearer) are never actually transmitted over-air. Only about 40% of the messages are transmitted.
The HCI-communication between controller and host looks healthy and does not report any issues or failures. An example of the sequence that the mesh-daemon uses for sending a mesh-message is shown below (captured with btmon).
What I have tried:
I have found that if the message is sent or not, basically relies on this if-statement evaluating to true:
zephyr/subsys/bluetooth/controller/ll_sw/ull_adv.c
Line 1729 in ebfe9be
CONFIG_BT_TICKER_LOW_LAT
: If-statement will always be true, however the functionticker_cb
is not always entered -> ~70% success rateCONFIG_BT_TICKER_LOW_LAT
and force the if-statement to true (if(1)
): Always enters functionticker_cb
-> ~98% success rate. This is working quite well, but obviously I don't know any side effects this might introduce.Success rate is based on sending a mesh-message and successfully receiving a response, for a number of times.
I'm hoping that someone here can help me understand why so many of the advertising requests are actually never advertised, if there are some configurations that would improve this that I don't know of, or perhaps what potential side effects it might have to force the if-statement to true.
Environment:
The text was updated successfully, but these errors were encountered: