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?
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?
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 ...!
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 ...!
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
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.
I just tried changing the PHY in 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 as suggested in the light_switch example to RADIO_MODE_NRF_62K5BIT. I did not get the units to connect. Looking at the log messages I did not see that there was any conversation between the two units trying to provision. I changed back tho my original hex file and the two units worked just fine.
I tried reprogramming at RADIO_MODE_BLE_2MBIT the units connected just fine. Could there be a problem with the RADIO_MODE_NRF_62K5BIT setting.
Did just not work or did you get an error message of some kind? We have not yet come this far in our tests but hopefully soon.