change phy in mesh

[kassianson]

I'm working with the nRF52840 PDK and I'm wondering how to change the PHY (preferably to CODED) in a Mesh. Has that been implemented yet? Or when can we expect this feature?

[ovrebekk]

Hi

You could try to change the radio_mode configuration in the set_default_broadcast_configuration(broadcast_t * p_broadcast) function in advertiser.c, and in the scanner_config_reset(void) function in scanner.c

In theory this should allow you to switch the entire mesh over to a different phy, but we haven't tested it so try it out at your own risk :)

We have no concrete plans at the moment to add official support for different phy's, but there is no particular reason it shouldn't work.

Please note that the long range mode is mislabeled. It is called RADIO_MODE_NRF_62K5BIT in the header file, but corresponds to the 125kbps BLE long range mode instead.

Best regards
Torbjørn

[David Edwin]

If you are using the Mesh SDK, an additional caveat would be that the time spent on air for the coded phy will be more so that would mean you would need to increase the time being spent in the Timeslot API to compensate for the longer on air packets.

Edit: See Hung Bui's comments below in modifying the code to get the longer range to work.

[matsublox]

Although this is not yet added to the standard or supported from Nordic, I think this possibility add many new use cases where Bluetooth Mesh can be used (industrial, smart city etc).

Would be interesting yo know if anyone tried this out? We will for sure test it as soon as possible!

Additional comment:

We have a real smart city use case where we are going to test mesh. The idea is exactly as you say David, we intent to start with coverage test using non coded PHY but I would be good to have the long range option at hand if needed (and I see risk for it in this case).

BTW, nice to meet with you again, David. Been a while since we worked on Automation IO ...!

[ovrebekk]

Unless someone else beats us to it, we will probably do a quick test next week.
I will try to update this thread when we do, but if you don't hear from me by the end of next week you might want to send me a reminder ;)

Best regards

[David Edwin]

The existing mesh should be capable of being used for smart city/industrial use cases as it is not so sensitive to packet losses as a connection oriented link. The nRF52840 using the 1Mbit channel for advertising and a 8dbm output power is quite capable of delivering in that direction. The longer coded phy packet is more possible to be corrupted but it does have FEC for handling some of the corrupted bits. Ideally I would go for a mesh over coded PHY if clear data is present that the existing BTLE mesh does not fit a specific usecase, this means doing range tests with existing mesh before we consider coded phy.