Sensitivity, 125 kbps BLE mode

RE: Sensitivity, 125 kbps BLE mode

Simonr — Wed, 07 Apr 2021 10:39:13 GMT

Dmitry is absolutely correct that there are multiple factors affecting the distance you'll be able to see. Can you provide some details about what exactly the "ideal state" or target distance is for your use case?

Best regards,

Simon

RE: Sensitivity, 125 kbps BLE mode

Dmitry — Thu, 01 Apr 2021 09:33:44 GMT

Hi,

there are too many factors that affect distance. What's the size of your packets? Are you testing outdoors or indoors, are there wifi stations nearby? Is it a 52833 DK or some third-party module? Is your power source clean? Finally, did you check whether channel 7 has not too much noise in nRF-Connect RSSI viewer?

As Simon mentioned, Coded PHY doesn't increase sensitivity at physical layer (it's the same 1Mbps bitstream), it uses a FEC encoder that helps to recover from one-two-bit errors (weak signal) but doesn't help much if there's a strong interference on the channel. If you need a stable audio transmission in a noisy environment, maybe it's better to use 1M or even 2M PHY with short packets and some error correction scheme over a larger transmission window.

RE: Sensitivity, 125 kbps BLE mode

Ellison — Thu, 01 Apr 2021 01:51:39 GMT

hi Simonr

This is the code for the radio configuration I used.

void radio_configure()
{
    // Radio config
    NRF_RADIO->TXPOWER   = (RADIO_TXPOWER_TXPOWER_Pos8dBm << RADIO_TXPOWER_TXPOWER_Pos);
    NRF_RADIO->FREQUENCY = 7UL;  // Frequency bin 7, 2407MHz
    NRF_RADIO->MODE      = (RADIO_MODE_MODE_Ble_LR125Kbit << RADIO_MODE_MODE_Pos);

    // Radio address config
    NRF_RADIO->PREFIX0 =
        ((uint32_t)swap_bits(0xC3) << 24) // Prefix byte of address 3 converted to nRF24L series format
      | ((uint32_t)swap_bits(0xC2) << 16) // Prefix byte of address 2 converted to nRF24L series format
      | ((uint32_t)swap_bits(0xC1) << 8)  // Prefix byte of address 1 converted to nRF24L series format
      | ((uint32_t)swap_bits(0xC0) << 0); // Prefix byte of address 0 converted to nRF24L series format

    NRF_RADIO->PREFIX1 =
        ((uint32_t)swap_bits(0xC7) << 24) // Prefix byte of address 7 converted to nRF24L series format
      | ((uint32_t)swap_bits(0xC6) << 16) // Prefix byte of address 6 converted to nRF24L series format
      | ((uint32_t)swap_bits(0xC4) << 0); // Prefix byte of address 4 converted to nRF24L series format

    NRF_RADIO->BASE0 = bytewise_bitswap(0x01234567UL);  // Base address for prefix 0 converted to nRF24L series format
    NRF_RADIO->BASE1 = bytewise_bitswap(0x89ABCDEFUL);  // Base address for prefix 1-7 converted to nRF24L series format

    NRF_RADIO->TXADDRESS   = 0x00UL;  // Set device address 0 to use when transmitting
    NRF_RADIO->RXADDRESSES = 0x01UL;  // Enable device address 0 to use to select which addresses to receive

     
     *(volatile uint32_t *) 0x40001740 = ((*((volatile uint32_t *) 0x40001740)) & 0x7FFF00FF) | 0x80000000 | (((uint32_t)(196)) << 8);
     // Enable the workaround for nRF52840 anomaly 172 on affected devices.
     
    // Coded PHY (Long range)
    NRF_RADIO->PCNF0 = (PACKET_S1_FIELD_SIZE << RADIO_PCNF0_S1LEN_Pos) |
                       (PACKET_S0_FIELD_SIZE << RADIO_PCNF0_S0LEN_Pos) |
                       (PACKET_LENGTH_FIELD_SIZE << RADIO_PCNF0_LFLEN_Pos) |
                       (3UL << RADIO_PCNF0_TERMLEN_Pos) |
                       (2UL << RADIO_PCNF0_CILEN_Pos) |
                       (RADIO_PCNF0_PLEN_LongRange << RADIO_PCNF0_PLEN_Pos);

    // Packet configuration
    NRF_RADIO->PCNF1 = (RADIO_PCNF1_WHITEEN_Disabled << RADIO_PCNF1_WHITEEN_Pos) |
                       (RADIO_PCNF1_ENDIAN_Little       << RADIO_PCNF1_ENDIAN_Pos)  |
                       (PACKET_BASE_ADDRESS_LENGTH   << RADIO_PCNF1_BALEN_Pos)   |
                       (PACKET_STATIC_LENGTH         << RADIO_PCNF1_STATLEN_Pos) |
                       (PACKET_PAYLOAD_MAXSIZE       << RADIO_PCNF1_MAXLEN_Pos); //lint !e845 "The right argument to operator '|' is certain to be 0"

    // CRC Config
    NRF_RADIO->CRCCNF = (1 << RADIO_CRCCNF_SKIP_ADDR_Pos) |(RADIO_CRCCNF_LEN_Three << RADIO_CRCCNF_LEN_Pos); // Number of checksum bits
    if ((NRF_RADIO->CRCCNF & RADIO_CRCCNF_LEN_Msk) == (RADIO_CRCCNF_LEN_Two << RADIO_CRCCNF_LEN_Pos))
    {
        NRF_RADIO->CRCINIT = 0xFFFFUL;   // Initial value
        NRF_RADIO->CRCPOLY = 0x11021UL;  // CRC poly: x^16 + x^12^x^5 + 1
    }
    else if ((NRF_RADIO->CRCCNF & RADIO_CRCCNF_LEN_Msk) == (RADIO_CRCCNF_LEN_One << RADIO_CRCCNF_LEN_Pos))
    {
        NRF_RADIO->CRCINIT = 0xFFUL;   // Initial value
        NRF_RADIO->CRCPOLY = 0x107UL;  // CRC poly: x^8 + x^2^x^1 + 1
    }
    else if ((NRF_RADIO->CRCCNF & RADIO_CRCCNF_LEN_Msk) == (RADIO_CRCCNF_LEN_Three << RADIO_CRCCNF_LEN_Pos))
    {
        NRF_RADIO->CRCINIT = 0x555555UL;    // Initial value of CRC
        NRF_RADIO->CRCPOLY = 0x00065BUL;    // CRC polynomial function
    }
}

After that, I sent and received like this：

RF_IRQ = 0;
NRF_RADIO->PACKETPTR = (uint32_t)&packet[0];     
                  
NRF_RADIO->TASKS_TXEN = 1U;      
while(RF_IRQ == 0)
{
    __WFE();
}

Receive, I directly configure Radio into RX mode and turn on receiving。

Can't I use 125Kbps?

Thanks and Best regards.

Ellison

RE: Sensitivity, 125 kbps BLE mode

Simonr — Wed, 31 Mar 2021 10:09:38 GMT

Hi Ellison

I'm not sure I understand your question correctly. Are you trying to do something similar to Coded PHY in your own proprietary protocol outside of BLE? If not, please describe the use case in detail so I'm able to understand what you're trying to do.

The long range feature (Coded PHY) in BLE basically transmits the raw data at a rate of 1Mbps, but the data includes redundancy in the user data which brings down the rate to as low as 125 kbps. This redundanct allows the receiver to recover the original data from the errors that occur in the transmission using FEC (Forward Error Correction) algorithms rather than increasing transmit power. The higher the redundancy, the higher the probability of recovering data. So if you want to this in a proprietary protocol you're free to implement this yourself, as we don't have any example code operating outside the BLE stack doing this.

Best regards,

Simon