advertising range extender

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

Parents
  • 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

  • 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?

Reply
  • 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?

Children
  • Hi,

    A custom solution (for instance along the lines suggested by ) 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

Related