nRF Connect SDK 2.8.0 Mesh with Coded PHY (Long Range)

RE: nRF Connect SDK 2.8.0 Mesh with Coded PHY (Long Range)

tesc — Tue, 25 Mar 2025 17:34:08 GMT

I will leave this thread open in case the original poster has anything to add. Apart from that, I refer to the general information provided previously in this thread.

If you are still stuck, then please create a new ticket with the specifics for your application and use case, then we can look into that in particular.

Regards,
Terje

RE: nRF Connect SDK 2.8.0 Mesh with Coded PHY (Long Range)

RJengr — Fri, 14 Mar 2025 22:39:23 GMT

I am stuck on the same warnings/error:
[00:00:05.282,287] <wrn> bt_hci_core: opcode 0x2041 status 0x12
[00:00:05.282,318] <err> bt_mesh_adv: starting scan failed (err -22)

Do you know how you got around this? I have tried altering the scan window/interval and advertising interval to no help.

RE: nRF Connect SDK 2.8.0 Mesh with Coded PHY (Long Range)

tesc — Tue, 07 Jan 2025 12:24:13 GMT

Hi,

[quote user="rmarques"]I may have fixed the issue somewhere else.[/quote]

Most likely this would be change of advertising type and/or advertising parameters. Maybe something is different now from then, even though most parameters are back at the initial values.

[quote user="rmarques"]Still, I don't see a noticeable difference in the message RSSI with and without long range. I'm going to run some simple tests to count the number of messages arriving successfully to a device with and without long range to see if there's something else other than the RSSI to tell me if this is working or not.[/quote]

Coded phy does not change RSSI, as the TX power is still the same. The difference is that more time is spent for each symbol, essentially allowing for some error correction, and successful reception at slightly lower RSSI. Please note also that RSSI is received signal strength indication, and not an accurate measurement of the actual signal strength. Rather, it is based on the general power level received from the antenna, at or close to the given frequency, when the packet is being received. It is often a good measure, but there will be some variability.

You should get some indication from power measurements (showing the time spent for each advertisement packet), or from a BLE sniffer (which should show you for each packet what physical layer was used.)

[quote user="rmarques"]In the meantime, would you be interested in having a look at what's needed for Mesh with Long Range in nRF Connect?[/quote]

My previous answer covers the general gist of what must be done. We don't have a full detailed list of what changes are needed. If you run into any specific issues along the way, then we are more than happy to help you overcome those issues.

Regards,
Terje

RE: nRF Connect SDK 2.8.0 Mesh with Coded PHY (Long Range)

rmarques — Thu, 02 Jan 2025 15:22:18 GMT

Hi tesc, thanks for the pointers. I have been experimenting with increasing MESH_SCAN_INTERVAL and MESH_SCAN_WINDOW in adv.c and while it looks like it worked, having returned the defines to the original values it doesn't complain about starting the scan. I may have fixed the issue somewhere else.

Still, I don't see a noticeable difference in the message RSSI with and without long range. I'm going to run some simple tests to count the number of messages arriving successfully to a device with and without long range to see if there's something else other than the RSSI to tell me if this is working or not.

In the meantime, would you be interested in having a look at what's needed for Mesh with Long Range in nRF Connect?

Happy New Year!

Best,

Rúben

RE: nRF Connect SDK 2.8.0 Mesh with Coded PHY (Long Range)

tesc — Fri, 20 Dec 2024 15:49:20 GMT

Hi,

I am afraid we do not have time to look thoroughly at this before the holidays, but in general:

A Bluetooth Mesh solution built on top of Coded Phy is not qualifiable as a Bluetooth Mesh product, since the Bluetooth Mesh Protocol specification mandates use of the ADV_NONCONN_IND PDU type, which by Bluetooth Core specification is for 1M Phy only.
That being said, there is nothing else in the BLE stack or the Bluetooth Mesh stack which should prevent such a solution from working, with a few caveats covered, e.g.:
- that there are enough bytes available in the advertising packets used for the full contents of the Bluetooth Mesh related Advertising Data types
- that advertising parameters and scan parameters used by the stack are compatible with Coded Phy
- etc.

Now, for a Coded Phy solution to work, every part of the Bluetooth Mesh stack which touches upon advertising or scanning, might potentially need an update, in order to use an advertisement PDU type which is compatible with Coded Phy. I see that your changes are of that nature, but I am not sure if you have covered all the required places. Please note also that features such as GATT Proxy also uses BLE, and for that you may want to use Coded Phy or 1M depending on what can be supported by the central device, typically a smartphone.

To the particular issue that you are seeing right now, error code 22 is "invalid argument". In other words, the scan_param provided to bt_le_scan_start() inside bt_mesh_scan_enable() in adv.c is not considered valid. It might be as simple as the scan failing to start due to MESH_SCAN_INTERVAL / MESH_SCAN_WINDOW not working well with Coded Phy (e.g. too short?) or if the scan type (BT_HCI_LE_SCAN_ACTIVE or BT_HCI_LE_SCAN_PASSIVE, depending on the value of active_scanning) is somehow incompatible with Coded Phy. At least it looks like some change is needed, either for the constants used, or the code itself, for bt_mesh_scan_enable(), in <sdk folder>\zephyr\subsys\bluetooth\mesh\adv.c.

Regards,
Terje