This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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

  • 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

  • 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

  • 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

  • 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

  • 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

Related