advertising range extender

[Johan.h]

We have sensors that advertise their status to a main device using the NRF-Connect, which works fine.

In this arrangement, the central unit does not initiate connections; rather, the sensors solely advertise their status.

The challenge arises with certain sensors, where the signal strength becomes weak and unreliable, particularly at distances exceeding 50 meters. To address this, I am exploring the possibility of programming a repeater that can continuously scan and then rebroadcast every packet that meets specific criteria.

Is this a feasible solution?

Has anyone attempted something similar before?

I'm also open to the possibility that there might already be an existing solution to this problem.

Thanks

Johanan

[tesc]

Hi,

Depending on your needs, there may already exist a solution in the form of Bluetooth Mesh, which basically works by repeating BLE advertisements.

Please note however that in Bluetooth Mesh, information is put in what in Bluetooth Mesh terminology is called "messages", and that such messages can be spread over multiple actual advertisements, with up to 12 bytes of message payload in each advertisement packet.

Regards,
Terje

[Johan.h]

Thank you for the information. I took a quick look at the Mesh protocol, but it seems too complex for my needs and would require redesigning the current sensors, central unit, and mobile app used for system monitoring and configuration. That's quite a bit of work. What I need, however, is just a simple "node" that continuously scans and re-broadcasts any received packet just once. Is there any issue with implementing such a straightforward solution?

[evdavies]

Yes, it is certainly possible. You just need to set it up to scan for the advertising packets coming off your devices and update the advertising data on the repeater / relay. Wether or not this is feasible is a question of how much data you need to pass through the relay. If your sensors are sending tons of advertising packets really quickly, having several of them go through one relay will be difficult. I'm not going to post my full project, but hopefully this can guide you in the right direction. Disclaimer that some of this can probably be done more efficiently and you'll have to figure out the indexes for your application. This is based on a combination of several examples included in the SDK (notably ble_central_and_peripheral/experimental/ble_app_hrs_rscs_relay)

Initialize the scan to filter for your devices, start the scan, and start advertising

In your scan event handler (for case NRF_BLE_SCAN_EVT_NOT_FOUND in my application), pull the data from the advertising packet:

for (i=0; i<mfg_data_len; i++)
{
    mfg_data[i] = * (p_adv_report->data.p_data + i);
}

I have a static advertising buffer so I can write data in from multiple locations easily. Write the relevant data into the buffer and call the update handler:

for (i=0; i<17; i++)
{
    adv_buffer[i] = mfg_data[i+7];
}

adv_data_update_handler();

Your update handler should look something like:

static void adv_data_update_handler(void)
{
    //Change advertising data
    ret_code_t                  err_code;
    ble_advdata_manuf_data_t    manuf_data;

/* change these values for your application
    new_advdata.p_manuf_specific_data = &manuf_data;
    new_advdata.name_type = BLE_ADVDATA_SHORT_NAME;
    new_advdata.short_name_len = 5;
    new_advdata.flags = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE;
    
    manuf_data.company_identifier = 0xFFFF;
    
*/

    manuf_data.data.p_data = adv_buffer;
    manuf_data.data.size = sizeof(adv_buffer);
    
    err_code = ble_advertising_advdata_update(&m_advertising, &new_advdata, NULL);
    APP_ERROR_CHECK(err_code);  

}

You might need to play with the scan interval, scan window, and advertising interval values. I also had to set the link count values in sdk_config to 0 and APP_BLE_CONN_CFG_TAG to 0. 

Hope this helps

*Edited to correct a little inefficiency 

[tesc]

Hi,

A custom solution (for instance along the lines suggested by evdavies) could also work, yes. Just make sure to have mechanisms such that if you have multiple relays/repeaters, then the message will not jump back and forth indefinitely.

Bluetooth mesh handles this through "managed flooding", where each relay node has a message cache in order to check if a message has been relayed before (to ensure each message is only repeated once) and there is a TTL value (which is decreased for each relay, and messages are not relayed further when TTL reaches 1.)

Other protocols, such as Thread, handles this through setting up a dedicated router network and routing messages through direct links between the router nodes.

Generally this could be an easy or hard problem to solve, depending on the number of nodes involved and the topology of the network.

Regards,
Terje