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

ESB maximum number of pipes

Hello,

I am evaluating the possibility to use ESB protocol on nRF52840 development kit. As far as I understood, for HW limitations, the maximum number of pipes in a star network configuration is 8. Unfortunately, for my application I need to connect up to 20 transmitters to a receiver. I have seen in this ticket that there is the possibility to increase the maximum number of pipes but it is not clear to me how to proceed.

Can you please give me some more details? In case, is there any example available?

Thank you in advance.

Best regards,

Enrico  

  • Hi Enrico

    You can't extend the number of pipes beyond 8, but you don't technically need to provide unique pipes to all devices. 

    As an example our Bluetooth stacks support up to 20 devices, and they all run on the same pipe, but each link is given a unique timeslot for communication to avoid mixing up the devices. 

    Do you have any particular latency or data throughput requirements for your protocol?

    Are you planning to have each transmitter send data at a fixed interval, or could they send data at random points in time?

    Best regards
    Torbjørn

  • Hi Torbjørn,

    thank you for the romp reply. To answer your questions:

    1. my aim is to update the receiver with new data with a frequency of, at least, 50 Hz. So, due to the number of devices (20) and the star network configuration, the receiver should be able to receive new data every ms (1kHz) and each transmitter to send data every 20 ms. The data payload length is in the order of 100 bytes.

    2. Transmitters have to be synchronized so the plan is to send data at fixed interval.

    I hope my answers are clear.

    If I well understand your answer, a possibility to increase the number of devices sending information to a receiver would be to connect more devices to the same pipe and give each device a unique timeslot. 

    Any further help for the implementation is welcome...

    Thank you and best regards,

    Enrico 

       

  • Hi Enrico

    1 packet pr millisecond should be possible, at least if you use the 2Mbps on air data rate. 

    In this mode a 100 byte payload, adding 8 bytes or so of overhead (address, length, CRC etc), should be sent in 432us, leaving you sufficient time for radio startup, and possibly sending an ACK packet in return. 

    One way to synchronize this is to assign each device a unique ID in the range 0-19. Then the receiver can send a sync packet every 20ms, and the receivers can use this packet to calculate a unique timeslot in which to respond to the receiver based on their unique ID. 

    A second option is to have the receiver poll each transmitter independently. In this case you would have to either include the unique ID in the payload, so that the receivers know when they should respond, or set up the receiver on different RF addresses so that the transmitter can choose the device just based on the address. 

    In both cases you can configure the devices to disable the radio outside of their own timeslots, in order to optimize current consumption. 

    Best regards
    Torbjørn

  • Hi Enrico, Hi Ovrebekk,

    These exchanges are very promising!

    I'm trying to get data (12 bytes) from 9 boards with nrf52832, hopefully at 25Hz at least (it seems realistic).

    I'm dreaming about a cross platform way to do this without dongle but it seems tricky...

    Would you happen to have any advice with example code?

    Thanks a lot!

    Cedric ;)

    PS: I used to hope to do that with BLE broadcast (by hiding data in the manufacturer packets) but it's probably messy...

  • Hi Cedric

    Sorry for the slow response. I have been out in leave for the last couple of months, and didn't get back until yesterday. 

    When you say cross platform are you thinking of mobile platforms only (Android, iOS), or PC's as well?

    BLE is definitely the protocol to go for if you don't want to use a dongle, but if you need 9 boards transmitting data it becomes a bit tricky. 

    When doing BLE broadcasting you can have 9 boards no problem, but the challenge with broadcasting is that you don't get any acknowledge, and you have to expect a high degree of packet loss when using broadcast packets. 

    When establishing a BLE connection you will have acknowledged data, but there is no guarantee that the BLE host will be able to connect to 9 devices at the same time (the nRF52 devices support up to 20 concurrent connections when running the S132 or S140 SoftDevices, but phones or PC's might have a different limitation). 

    If you had some relay device based on the nRF52 you could receive data from 9 devices there, and aggregate all the data on a single link with the phone/PC, but this isn't really any more elegant than using a dongle. 

    If you can provide me a bit more details about your project I will try to come up with some pointers and advice. 

    Best regards
    Torbjørn

Related