Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Gazell with multiple devices again

Dear Support / forum,

After reading the user and API guides, browsing other posts, and playing around with the ack-payload example, I think I now have a pretty good understanding of how Gazell works but it strikes me that it's not made clear in the guides that multiple devices cannot use the same channel simultaneously, regardless of what pipes/addresses they are configured for. It seems to me that the only way to guarantee that devices do not knock out each other's packets, and that the Host is able to send acks to each of them successfully (normal packet failures mechanisms accepted), is to assign a different subset of the host's channel table to each one. Otherwise, with one common table, you're hoping that the devices connect to the host on different channels and then remain on different channels, regardless of what the channel selection policy of each device is. I think this is a big ask. Have I overlooked something ?

Thanks

Pete

Parents
  • Hi Pete,

     

     

    Otherwise, with one common table, you're hoping that the devices connect to the host on different channels and then remain on different channels, regardless of what the channel selection policy of each device is. I think this is a big ask. Have I overlooked something ?

    I think you've gotten a pretty good overview of the protocol.

    It's correct that if two or more devices start transmitting at the exact same time, with the exact same RF parameters, its likely to cause a big collision on-air, and none of them get through to the host.

    However; this is only in scenarios where the devices are asynchronous to the host. In scenarios where the device is synchronous, its ACK driven from the host, and the device will then "reset" itself based on when it receives its dedicated ACK back.

    For asynchronous devices, where there's potentially a lot of data going through the link simultaneously from several devices, its wise to look at options like diving up the channel tab or similar.

     

    Kind regards,

    Håkon

Reply
  • Hi Pete,

     

     

    Otherwise, with one common table, you're hoping that the devices connect to the host on different channels and then remain on different channels, regardless of what the channel selection policy of each device is. I think this is a big ask. Have I overlooked something ?

    I think you've gotten a pretty good overview of the protocol.

    It's correct that if two or more devices start transmitting at the exact same time, with the exact same RF parameters, its likely to cause a big collision on-air, and none of them get through to the host.

    However; this is only in scenarios where the devices are asynchronous to the host. In scenarios where the device is synchronous, its ACK driven from the host, and the device will then "reset" itself based on when it receives its dedicated ACK back.

    For asynchronous devices, where there's potentially a lot of data going through the link simultaneously from several devices, its wise to look at options like diving up the channel tab or similar.

     

    Kind regards,

    Håkon

Children
Related