# change phy in mesh

asked 2017-11-23 13:08:58 +0100

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?

edit retag close delete

## 4 answers

Sort by » oldest newest most voted

answered 2017-11-24 15:21:42 +0100

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

more

## Comments

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.

( 2017-11-25 14:39:55 +0100 )editconvert to answer

answered 2017-12-12 12:58:15 +0100

The following modification worked for me:

1. In advertise.c, set_default_broadcast_configuration() change radio_mode to use RADIO_MODE_NRF_62K5BIT instead of RADIO_MODE_BLE_1MBIT.

2. In scanner.c, scanner_config_reset() change scanner_config_radio_mode_set() to use RADIO_MODE_NRF_62K5BIT instead of RADIO_MODE_BLE_1MBIT.

3. In radio_config.c, radio_config_config() add the following code at the end:

if (p_config->radio_mode==RADIO_MODE_NRF_62K5BIT )

{
NRF_RADIO->PCNF0 |=(

((RADIO_PCNF0_PLEN_LongRange << RADIO_PCNF0_PLEN_Pos) & RADIO_PCNF0_PLEN_Msk) |
((2 << RADIO_PCNF0_CILEN_Pos) & RADIO_PCNF0_CILEN_Msk) |
((3 << RADIO_PCNF0_TERMLEN_Pos) & RADIO_PCNF0_TERMLEN_Msk) );

}


4.In broadcast.c, time_required_to_send_us() add:

if (radio_mode == RADIO_MODE_NRF_62K5BIT)
{
packet_length_in_bytes += RADIO_PREAMBLE_LENGTH_LR_EXTRA_BYTES;
}


And define RADIO_PREAMBLE_LENGTH_LR_EXTRA_BYTES = 9.

Change 5th element in radio_mode_to_us_per_byte[] from 128 to 64.

Let us know if you don't achieve longer range with this patch.

more

answered 2017-11-29 07:59:27 +0100

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 ...!

more

## Comments

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

( 2017-11-29 08:40:38 +0100 )editconvert to answer

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.

( 2017-11-29 11:19:09 +0100 )editconvert to answer

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.

( 2017-12-01 21:55:17 +0100 )editconvert to answer

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.

( 2017-12-01 22:12:15 +0100 )editconvert to answer

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.

( 2017-12-04 08:09:53 +0100 )editconvert to answer

@jeff I would typically expect a PHY that has a shorter on air time like a 2Mbit/s to work out of the box. I would also expect that the change to a PHY that has a longer on air time like LE Coded PHY will be more work, as the time needed for the TimeSlot API to run will be more for the coded PHY and that has to be adjusted for. If you are using a 125 Kbit/sec then the on air time will be atleast 8 times more and since the LE coded PHY is used you need to also allow for the FEC in the packet so the on-air time is larger.

( 2017-12-04 09:44:12 +0100 )editconvert to answer

Is this timing in the Time Slot API something that can be changed by an application developer is it something needed to be done by Nordic?

( 2017-12-04 10:49:42 +0100 )editconvert to answer

Yes I t just did not work. I got no error messages and no messages indicating an connection attempt. I was thinking the same thing over the weekend that I may have to adjust the receive time. the packets could be timingout and the packet receive time needs to be adjusted. That is what I am going to see if i can find this morning

( 2017-12-04 13:40:25 +0100 )editconvert to answer

@jeff Any chance to look further into this? Was there a timing issue?

( 2017-12-07 10:24:50 +0100 )editconvert to answer

I have requested that when the radio mode is set to a different radio mode, the timing should also be updated. This makes it easy to support whichever mode is needed, the timing to compute for coded PHY is a bit of work and it is more appropriate to do this automatically. No time commitments on this yet.

( 2017-12-08 10:14:11 +0100 )editconvert to answer

@jeff Any news on this?

( 2017-12-12 16:33:33 +0100 )editconvert to answer

@matsublox , @jeff you can see the code changes as suggested by Hung Bui and see if it works for you.

( 2017-12-13 09:28:44 +0100 )editconvert to answer

I got pulled of the mesh to work on another job. I am wanting to try the mods as soon as I can get back to them.

( 2017-12-13 13:42:09 +0100 )editconvert to answer

answered 2017-12-07 13:40:27 +0100

I have requested that when the radio mode is set to a different radio mode, the timing should also be updated. This makes it easy to support whichever mode is needed, the timing to compute for coded PHY is a bit of work and it is more appropriate to do this automatically. No time commitments on this yet.

more

## Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer. Do not ask a new question or reply to an answer here.

[hide preview]

or sign up

## Recent blog posts

• ### nrF52 Tutorial: ETM Instruction Trace with Keil MDK

Posted 2017-12-15 11:15:34 by Bob Boys
• ### One minute to understand BLE advertising data package

Posted 2017-12-15 07:30:51 by viewtool
• ### One minute to understand BLE connection data package

Posted 2017-12-15 07:10:49 by viewtool
• ### One minute to understand BLE MTU data package

Posted 2017-12-15 04:09:47 by viewtool
• ### Debugging on nrf52840 with GDB from CLI on linux

Posted 2017-12-14 14:02:03 by jfcamel

## Recent questions

• ### Send multiple nus packages once

Posted 2017-12-16 11:11:00 by Jax VierMTech
• ### I can't get 4 channel PWM output

Posted 2017-12-16 07:38:24 by NRF CODER
• ### scan response packet in non connectable mode.

Posted 2017-12-16 07:07:09 by Rahul Sahu
• ### send and receive data over BLE

Posted 2017-12-16 06:15:23 by Rahul
• ### Unique access address BLE - uart ble example

Posted 2017-12-16 04:59:24 by Ali97

## Stats

Asked: 2017-11-23 13:08:58 +0100

Seen: 230 times

Last updated: des. 12