advertising phy coded s8 long range stops at nearly 20m built

[Bjoern Gutgesell]

Hi there,
I have been testing my ble long range app with coded phy (s8), with extended advertising etc. for a few weeks now. Only adv and scan are used. Works well, only the range is almost the same as it is in the 1M phy.

I don't understand that, so I read about it at SIG.

Now I understand that on channels 37, 38, 39 (data rate is 1M phy, not 1M / 8) a pointer points to the data channel that transmits with s8 (125k)? And channels 37, 38, 39 continue to work with 1M?

Is that correct? Because if channel 37, 38, 39 still works with 1M, where is the benefit? Or did I get it wrong.

On scan_report the ch_index has values ​​between 0 and 35 and an rssi between -40db (very close) and -95db (approx. 20m built).

best regards
Bjoern

[Bjoern Gutgesell]

Hi there,
I have been testing my ble long range app with coded phy (s8), with extended advertising etc. for a few weeks now. Only adv and scan are used. Works well, only the range is almost the same as it is in the 1M phy.

I don't understand that, so I read about it at SIG.

Now I understand that on channels 37, 38, 39 (data rate is 1M phy, not 1M / 8) a pointer points to the data channel that transmits with s8 (125k)? And channels 37, 38, 39 continue to work with 1M?

On scan_report the ch_index has values ​​between 0 and 35 and an rssi between -40db (very close) and -95db (approx. 20m built).

best regards

[ovrebekk]

Hi 

The way it works with long range advertising is that you send a small coded phy packet on one of the standard channels (37, 38 or 39) that points to a larger packet sent on one of the data channels. The scanner will have to receive both packets in order to receive the advertising payload. 

The reason it is done this way is to avoid having to send long coded phy packets on the standard advertising channels, which would cause excessive noise on these channels and create issues for other 1M advertisers in the area (a coded phy packet can take several milliseconds to send, compared to a 1M packet which usually only takes a couple of hundred microseconds). 

Can you show me the code you use to configure the advertising payload?

Best regards
Torbjørn

[Bjoern Gutgesell]

Hi ovrebekk,

thanks for reply.

my code for advertiser init: param pa is the array to transmit (max len 18 bytes), param len is the len of pa

uint8_t BF_advertising_init( uint8_t *pa, uint8_t len )
{
    uint32_t      err_code;
    ble_advdata_t advdata;
    uint8_t       flags = BLE_GAP_ADV_FLAG_BR_EDR_NOT_SUPPORTED;
    uint8_t go = 0;

    ble_advdata_manuf_data_t manuf_specific_data;

    if( len > 30 )
      return 1;

    manuf_specific_data.company_identifier = APP_COMPANY_IDENTIFIER;          // das Zeichen 'g' und 'u' für Gutgesell
    manuf_specific_data.data.p_data = pa;                                     // die eigentlichen Daten, serialisiert
    manuf_specific_data.data.size   = len;                                    // die Länge, Anzahl der Zeichen

    // die eigentlichen Daten werden noch durch die "manufacture specific Data" ergänzt


    // Build and set advertising data.
    memset(&advdata, 0, sizeof(advdata));

    advdata.name_type             = BLE_ADVDATA_NO_NAME;
    advdata.flags                 = flags;
    advdata.p_manuf_specific_data = &manuf_specific_data;

    // Initialize advertising parameters (used when starting advertising).
    memset(&m_adv_params, 0, sizeof(m_adv_params));

    #ifdef MIT_CODED_PHY
      m_adv_params.properties.type = BLE_GAP_ADV_TYPE_EXTENDED_NONCONNECTABLE_NONSCANNABLE_UNDIRECTED;
    #else
      m_adv_params.properties.type = BLE_GAP_ADV_TYPE_NONCONNECTABLE_NONSCANNABLE_UNDIRECTED;
    #endif
    m_adv_params.p_peer_addr     = NULL;    // Undirected advertisement.
    m_adv_params.filter_policy   = BLE_GAP_ADV_FP_ANY;
    m_adv_params.interval        = NON_CONNECTABLE_ADV_INTERVAL;
    m_adv_params.duration        = 0;       // Never time out.

    #ifdef MIT_CODED_PHY
      m_adv_params.primary_phy     = BLE_GAP_PHY_CODED;   // a200205
      m_adv_params.secondary_phy   = BLE_GAP_PHY_CODED;   // a200205
    #endif

    #if 0
    //                               76543210
    m_adv_params.channel_mask[0] = 0b11111110;
    //                        1      54321098  
    m_adv_params.channel_mask[1] = 0b11110111;
    //                        2      32109876
    m_adv_params.channel_mask[2] = 0b11111111;
    //                        3      10987654
    m_adv_params.channel_mask[3] = 0b11111111;
    //                        4      98765432
    //m_adv_params.channel_mask[4] = 0b00001111;
    //m_adv_params.channel_mask[0] = 0x0;
    //m_adv_params.channel_mask[1] = 0x0;
    //m_adv_params.channel_mask[2] = 0x0;
    //m_adv_params.channel_mask[3] = 0x0;
    //m_adv_params.channel_mask[4] = 0x0;
    #endif



    // maximal Laenge, die zur Verfuegung steht. Diese muss zu Beginn immer wieder auf den Maxwert gesetzt werden
    // da vorherige Datensaetze den Speicher verkleinern, dieser kleiner Wert gespeichert wird und bei einem 
    // naechsten Aufruf mit einem groesserem Frame zu Problemen führt.
    
    #ifdef MIT_CODED_PHY
      m_adv_data.adv_data.len = BLE_GAP_ADV_SET_DATA_SIZE_EXTENDED_MAX_SUPPORTED;
    #else
      m_adv_data.adv_data.len = BLE_GAP_ADV_SET_DATA_SIZE_MAX;
    #endif
    err_code = ble_advdata_encode(&advdata, m_adv_data.adv_data.p_data, &m_adv_data.adv_data.len);
    APP_ERROR_CHECK(err_code);

    err_code = sd_ble_gap_adv_set_configure(&m_adv_handle, &m_adv_data, &m_adv_params);
    APP_ERROR_CHECK(err_code);

    NRF_LOG_INFO("FPRO, TX, Befehl%i, Ziel%i", BF_Get_Order(pa), BF_Get_Ziel(pa) );

}

my code for start advertising

void BF_advertising_start(void)
{
    ret_code_t err_code;

    gBF_StatusReady = BF_STAT_TRANSMIT;

    // Ausgangsleistung wird auf +6db gesetzt
    sd_ble_gap_tx_power_set(BLE_GAP_TX_POWER_ROLE_ADV , m_adv_handle, 6 );
    
    err_code = sd_ble_gap_adv_start(m_adv_handle, APP_BLE_CONN_CFG_TAG);
    APP_ERROR_CHECK(err_code);

    gBF_Timer_Aktiv = true;
    err_code = app_timer_start(m_bf_timer, APP_TIMER_TICKS(20), NULL);
    APP_ERROR_CHECK(err_code);


}

my code for stop advertising

void BF_advertising_stop( void )
{
  ret_code_t err_code = NRF_SUCCESS;

  // adv_ausschalten
  err_code = sd_ble_gap_adv_stop(m_adv_handle);
  #ifdef NRF_LOG_FPRO_STAT_WECHSEL
    NRF_LOG_INFO("Adv Stop");
  #endif

  gBF_StatusReady = BF_STAT_TRANSMIT_READY;

  app_timer_stop(m_bf_timer);
  gBF_Timer_Aktiv = false;

}

at coded Phy the sdk_config.h

#define NRF_BLE_SCAN_BUFFER 255

#define NRF_BLE_SCAN_SCAN_PHY 4

at coded Phy the sdk_config.h

#define NRF_BLE_SCAN_BUFFER 31

#define NRF_BLE_SCAN_SCAN_PHY 1

All works well, test over serveral days. With coded phy and with no-coded-phy (1M). If the devices are programmed with coded-phy and I test the powerconsumption wiht an oscilloscope, I get the 3 shorte peaks (of channel 37, 38, 39) and one longer peak (of the extended data channel). If it switch to non coded phy (1M), I only get 3 very short peaks (much shorter as before).

But the range is nearly the same (1 to 3m difference, indistinguishable)

best regards

[ovrebekk]

Hi Bjoern

Thanks for attaching your code. Based on what I can see it looks like you are setting it up correctly. 

I think I will need to do some testing on my own to see if I can replicate your findings. 

Unfortunately I am leaving for a short business trip and will have to to start work on this when I'm back. I will do my best to get started on this early next week and get back to you. 

Best regards
Torbjørn

[ovrebekk]

Hi Bjoern

I did some testing indoor, and the long range kit does seem more reliable than the 1M kit when the link gets poor. The test I did was hardly scientific, but when I went to a different floor in the office and the link got poorer the long range kit would receive more packets than the 1M one. 

What is the setup like in your test?

How far away are you from the TX, and do you have any blockers in between?

Would you expect there to be a lot of WiFi interference in the area?

Best regards
Torbjørn

[Bjoern Gutgesell]

Hi Torbjorn,

yes there are 2-3 thin walls between the advertiser and the scanner. More walls (or on flat angle a thin wall becomes thick) reduce the range. But I expected that there is a real big difference between 1M and phy coded. So, that there is a difference with coded phy and 1M in built, like there is range one or two rooms more and not only one or two meters.

But your note with wifi is perhaps the solution. Our wifi leaves out the advertiser channels 37,38,39. But we have much traffic and rf-signals in the other channels and the extended advertisements are in the channels between 0 and 36. I will test it in the evening and shut down our wifi.

One additional question: is it possible to place the extended advertisments with channel maks in the channels next to 37, 38, 39 (like 0, 10, 11 and 36).

best regards

Bjoern

[ovrebekk]

Hi Bjoern

Doing a test without WiFi could be interesting. Long range packets are inherently more sensitive to interference, as they take a longer time to transmit over the air, increasing the chance of packet collision with other RF sources in the area.  

Bjoern Gutgesell said:

One additional question: is it possible to place the extended advertisments with channel maks in the channels next to 37, 38, 39 (like 0, 10, 11 and 36).

There is a channel_mask field in the ble_gap_adv_params_t struct, but unfortunately it only allows you to define which primary channels to map out. We don't support mapping out secondary advertising channels. 

Best regards
Torbjørn