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

Questions regarding Gazell/ShockBurst: differences, pipe assignment, interference, multiple devices

Hi all,

I am investigating different protocols to support a network of very low-power Devices and Hosts. The Devices are mostly static (i.e. they don't move around very much), but the network should handle devices physically relocating and moving into range of a new Host. The Hosts act as gateways and are connected to a central server. The data transmission rate is very low, I expect a Device to send 10-20 byte every minute or so. Devices and Hosts will be based on either the nRF52832 or nRF52840. The Gazell/ShockBurst protocols look like a good place to start.

I would love to have the following questions answered before I decide on the protocol to use:

  • What are the differences between Gazell and ShockBurst? Which would protocol would be more suited for the network topology I have described?
  • I understand the need for static pipes/addresses in a Gazell/ShockBurst network configuration. The issue of pipe (re)assignment when Devices move between Hosts reminds me of IP address assignment in a computer network -- taking inspiration from the way DHCP solves this, could I perhaps set all Devices to use Pipe 0 initially and count on a Host to assign a new address, thus "adopting" the new Device into its cluster? This solution obviously runs the risk that Pipe 0 becomes very congested, but some sort of random interval between address requests would guarantee that all devices are eventually assigned addresses, when addresses are available.. Right?
  • What will happen if a Device appears within range of several Hosts? Am I correct in assuming that a Device connected to a Host on Pipe 0 will cause interference on another Host's Pipe 0 if it is within range?
  • Hung Bui's answer here has me confused. He says that "Gazell was not made for multiple device (more than 2) connect simultaneously. I think you should consider to try ESB.", can someone please clarify this statement? Looking back at my first question, how does ESB solve the issue of "more than 2 devices"?

Any help is greatly appreciated.

Best,

Fredrik

Parents
  • Hi,

    You can find a description of Gazell and ESB here:
    http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v15.0.0/user_guides.html?cp=4_0_0_5 

    The host implementation of Gazell haven't really been considered for low power at all, it is mainly focused for hosts with unlimited power (e.g. steady power supply such as USB or similar). So likely Gazell is not the way to go here.

    Using Shockburst you will have full control of timing and can potentially create very low power hosts and devices. However this will require more time to develop, for instance to ensure your protocol can handle interference, clock drift, pairing, etc. Several devices may use the same pipe, but then you need to add a header in the payload so the receiver may identify the origin.

    A better solution (at least quicker) may be to consider ANT protocol: https://www.thisisant.com/developer/ant/ant-basics/ In ANT all nodes are low power.

    Best regards,
    Kenneth

     

     

  • Hi Kenneth, thanks for getting back to me. 

    To clarify, our hosts will have unlimited power. The low-power requirements apply only to the devices, and as far as I understand, nodes configured as devices in Gazell networks are power optimized. I have been tinkering with Gazell these past couple of days, and I'm realizing that we would have to build quite a substantial layer on top of Gazell in order to ensure reliable connections that can handle interference between Gazell networks.

    I skimmed through the ANT overview, and it looks like ANT addresses many of the limitations of Gazell in terms of scalability and reliability. Knowing that hosts have unlimited power, do you still think ANT would be the better option, or would we perhaps be better off in the long run by building on top of Gazell (or ShockBurst)? My biggest concerns at the moment are power usage in our devices and network reliability.

    Best,

    Fredrik

  • Hi Fredrik,

    From you description "I expect a Device to send 10-20 byte every minute or so". Then no matter what protocol you choose it will be low power, e.g. rough numbers:

    sleep current to handle RTC wakeup: ~2uA
    + 10ms continuous radio activity (~10mA*10ms/60s): ~1.6uA
    = ~3.6uA average.

    Presuming a CR2032 battery of 220mAh nominal (~220mAh/3.6uA): ~7years.

    I took 10ms and 10mA as a worst case value here, likely you will only have a peak current for ~1ms every 60seconds, and likely well below 10mA since the radio will also be ramping up/down. But just to show some numbers.

    I think I have would have gone for ANT, simply because of development time, and it's a proven solution. 

    Best regards,
    Kenneth

     

     

Reply
  • Hi Fredrik,

    From you description "I expect a Device to send 10-20 byte every minute or so". Then no matter what protocol you choose it will be low power, e.g. rough numbers:

    sleep current to handle RTC wakeup: ~2uA
    + 10ms continuous radio activity (~10mA*10ms/60s): ~1.6uA
    = ~3.6uA average.

    Presuming a CR2032 battery of 220mAh nominal (~220mAh/3.6uA): ~7years.

    I took 10ms and 10mA as a worst case value here, likely you will only have a peak current for ~1ms every 60seconds, and likely well below 10mA since the radio will also be ramping up/down. But just to show some numbers.

    I think I have would have gone for ANT, simply because of development time, and it's a proven solution. 

    Best regards,
    Kenneth

     

     

Children
  • Hi Kenneth,

    You're right, ANT gives us a lot more flexibility in the long run. As you say, average power consumption will probably be similar between all protocols.

    Do you know if any of the Nordic ANT examples can serve as a good start for a simple star network where the devices minimize their radio activity (similar to Gazell)?

    Thanks for your help!

    Best,

    Fredrik

Related