nRF52840-DK Coded PHY Range and RX Sensitivity

[Daewoong Kim]

Hello,

I'm currently testing BLE Coded PHY by using extended advertising.

I used two nRF52840-DK and nRF5 SDK v17 with compatible softDevice.

I've checked that the hardware oprates in Coded PHY (both primary and secondary advertising channel),

and there is no problem to set the Coded PHY option. However, when I compared a communication range

of Coded PHY(1) with the range of Legacy advertising(2), Both setup has almost same range in LoS condition.

One of the two nRF52840-DK was used as scanner, and the other one was used as peripheral

(beacon with extended or legacy advertising). Beacon Tx power set to +8 dBm.

My question is...

1) Is it correct or possible both Coded PHY (extended adv.) and LE 1M PHY (legacy adv.) range to be similar ... ?

Most of results of other developers represented that Coded PHY's range is almost doubled of LE 1M, but

in my case there is no significant difference. Repeatedly, I've already checked the PHY option was correctly changed.

2) Including the datasheet, many blog posts said that the Rx sensitivity of nRF52840 SoC in Coded PHY (125kbps) is up to -103 dBm.

However, in my case, there is no significant difference on RSSI betweeen LE 1M Scanner vs Coded PHY Scanner. Even though

I select to scan Coded PHY, the minimum RSSI of the received (extended) advertising packet is just -95 dBm. Is there any

option to receive the advertising packet of smaller RSSI about -95 ~ -103 dBm level...?

[Simonr]

1. This is heavily dependent on the environment you're running the devices in. If it's indoors with a lot of interference sources the difference in range won't be very big, but outside in a low interference, line of sight environment you should be able to see a big difference. What ranges are you currently seeing?

2. How do you confirm that your device is in fact in Coded PHY? As the RSSI should indeed go down to -103 dBm. Are you also certain that both the advertiser and scanner is in Coded PHY mode. Doing a sniffer trace of what's going on over the air should confirm this for you.

Best regards,

Simon

[Daewoong Kim]

Oh, I'm sorry, I didn't mention the range.

1. When I tested outdoor, the range between scanner and beacon is about 500 m.. and There is a little difference, but both legacy advertising and extended advertising with Coded PHY had similar communication ragne.

2. This is my Coded PHY setup.

(1) First to changed LE PHY option, I used "Extended Advertising"

(2) Extended advertsing use two types of advertising channel (primary and secondary), and I set the both channel as Coded PHY

(3) When I receiving Coded PHY signal, the scanner also scanned "Coded PHY" layer, and it is only possible to receive beacon packet which was set to Coded PHY

(4) At last, I used an additional nRF52840-DK to operate nRF sniffer tools with Wireshart software, and I've checked the beacon packet uses Coded PHY (S=8) when i've set as it.

When I confirmed the sniffer log, the captured packet also didn't go down to -103 dbm..

Is this level (-103 dBm) of RSSI is only possible in connection mode?

My interest is advertising-based communication (which using Beacon), with Coded PHY..

-

The following is a part of my code to initialize beacon and scanner.

Isn't it Coded PHY (Long-range mode) Setup? Is there any setup did i missed?

Please confirm the below code (nRF5 SDK v17, s140 7.2.0 softdevice)

/*Beacon*/

static ble_gap_adv_params_t 		b_adv_params;
//...

static void Beacon_init(void){
    //...
    b_adv_params.properties.type = BLE_GAP_ADV_TYPE_EXTENDED_NONCONNECTABLE_NONSCANNABLE_UNDIRECTED; // BLE_GAP_ADV_TYPE_NONCONNECTABLE_NONSCANNABLE_UNDIRECTED; //@long-range
    b_adv_params.p_peer_addr     = NULL;    // Undirected advertisement.
    b_adv_params.filter_policy   = BLE_GAP_ADV_FP_ANY;
    b_adv_params.interval        = NON_CONNECTABLE_FAST_INTERVAL;
    b_adv_params.duration        = 0;       // Never time out.
    b_adv_params.primary_phy     = BLE_GAP_PHY_CODED;//BLE_GAP_PHY_CODED; //@long-range BLE_GAP_PHY_1MBPS
    b_adv_params.secondary_phy   = BLE_GAP_PHY_CODED; //@long-range
    b_adv_params.channel_mask[4] = CH_MASK_FOR_ALL;
    //...
}

/*Scanner*/

//...
static void scan_init(void){
    //...
    m_scan_param.interval   = SCAN_INTERVAL;
    m_scan_param.window     = SCAN_WINDOW;
    m_scan_param.timeout    = 0x0000;

    m_scan_param.extended   = 1;
    m_scan_param.scan_phys  = BLE_GAP_PHY_CODED;
}

Best regards

[Simonr]

Hi

If the sniffer picks up the packets as Coded PHY (S=8) you should be in the correct mode, and the snippets of code seems to be correct. You can try connecting the two devices to see if the sensitivity and/or range improves at all, but AFAIK the sensitivity should also apply for scanning/advertising, so there might be something we're missing. Try setting the advertising params to BLE_GAP_ADV_TYPE_EXTENDED_CONNECTABLE_NONSCANNABLE_UNDIRECTED.

Best regards,

Simon

[Daewoong Kim]

Hi, Simon

Thank you for your reply

We've tested further by using other nRF5 SDK version and softdevice, even using s340 6.1.1. However we didn't get the -103 dBm sensitivity. The minimum sensitivity we confirmed is -100 dBm, It is only captured one-times

I know there are some examples and results about long-ragne test, but i can not found that those experiments were conducted by practical advertising (beacon) based application. For example, advertiser transmitted the "iBeacon or Eddystone" format and scanner received the data. In this case, RSSI could go down to -103 dBm.

I'v just thought about that we can get the -103 dBm sensitivity with regular interval, even previously I mentioned scenario. But, I think that RSSI level might be focused on "1 symbol" level, not the overall Link layer packet. So, by using the ATT experiment example, some people get the low RSSI value, but it might be not guarantee in the case of scanning link layer scenario. The below figure is histogram of RSSI value we've got

Anyway, Thank you for your support

Best regards

[Simonr]

Hi Danny

That might be. Do you have any further follow-up questions or action points from my end or should we close this ticket? I see you suggested your latest reply as the answer.

Best regards,

Simon