Welcome Guest,Register Now
Log In

ANT Forum

Welcome guest, please Login or Register

   

Slave conflict

Rank

Total Posts: 5

Joined 2017-04-09

PM


Hello,

Occasionally one of a large number (50+) of Slaves would need to send a message after a Master Broadcast. Obviously there is a possibility that this could result in a collision; two Slaves trying to transmit the same time.

Is there any way to avoid this? Do Slaves use a small random delay before responding to a Master so one of them would back off but the other would get through? Or would they both fail?

Using channel sharing would be too much overhead for us so we need a different solution.

On a related subject: I understand that when a Master message is received normally the Slave message (if any) is already there, buffered and waiting and it's sent immediately afterward.
But how immediate does it have to be? Do we have say 2ms for the Slave Host to look at the Master message, then quickly send a response still within the short transmission window after the Master message?

Thanks and Regards,
Steve      
Avatar
RankRankRankRank

Total Posts: 745

Joined 2012-09-14

PM

Hi Steve,

If two or more slaves transmit on the same channel period, they will all transmit concurrently. Typically no message will get through due to the interference, though 1 may get through if it's signal strength is greater than the other transmitters.

If slaves only need to send messages rarely (such as ANT+ Bike Computers to ANT+ Sensors), then it might not be an issue. But if there is a relatively large statistical chance of collisions for the use case, then some form of arbitration will be required to prevent or at least reduce the impact of slave-to-master channel collisions when multiple slaves are paired to the same master.

One method would be to introduce randomized back-offs. For example, the 2 slaves send two messages but receive no acknowledgment back, so one randomly decides to wait 2 channel periods before transmitting, while the other decides to transmit again in the next period. If this doesn't work the second time, the back-off window range is enlarged, giving them a greater chance to find a timeslot where they don't collide. This type of scheme is detailed in the ANT+ Controls Device Profile and is also used in other communications protocols.

If you require a time deterministic approach, your master channel will have to do some work to tell the slaves when they're allowed to transmit, whether that's using the built-in shared channel approach or an application specific approach.

Regarding your second question, the slave must have the message ready and buffered before it receives the next message from the master channel. There is not enough time for the application to respond to a master message it has just received within the same channel period. Slaves do allow you to queue a message before you've even opened the channel, so it can send an initial message instantly.

Best regards      
Rank

Total Posts: 5

Joined 2017-04-09

PM

Thanks a lot for the response. We will implement a random back-off, as you suggested.

Can you please also comment on the related question:

What is the time delay between a Master completing the transmission of a message and then checking for a Slave message? Is there like 1ms delay in-between?
This is important because even just 1ms would be enough for the Slave to process Master's message and respond accordingly.

Best regards,
Steve      
Avatar
RankRankRankRank

Total Posts: 745

Joined 2012-09-14

PM

At this time, no current ANT USB or ANT SoC device can implement replies within the same received message event. Due to latency added by the serial connection and the O/S, it's virtually impossible to implement this over USB, and for the SoC's one main issue is that the application does not get handed back IRQ until the SoftDevice is finished handling the event. This may become feasible in the future but it is not feasible at this time.      
Rank

Total Posts: 5

Joined 2017-04-09

PM

Thanks for the reply.

Is there a channel to recommend improvements to the protocol? Perhaps you could forward my comment if you feel that it's are useful.

Two ANT devices "responding" to a Master broadcast and colliding is problematic. Clearly ANT is struggling due to the lack of a CSMA/CD type of mechanism. Things like Auto Shared Channels are a bit tedious. Building a random back-off at application level is very inefficient.

It would be great if a random delay would be possible before a Slave responds to a Broadcast. Due to this random delay ANT would prevent the "slower" Slave from transmitting (because ANT checks if the radio band is used) and there would be no collision. All done at protocol level. A new command could be introduced to set this mode.

Cheers,
Steve      
Avatar
RankRankRankRank

Total Posts: 745

Joined 2012-09-14

PM

Thanks for the feedback Steve, I can definitely pass on that we should take another look at making the multiple slaves to single master contention use case easier. But while I do agree that having two or more devices collide over an ANT channel is a frustrating problem which addressing at the application layer can be fiddly, generally this is considered a good trade-off for ultra low power wireless protocols like ANT for most use cases when considering cost vs power consumption vs data rate vs latency. As well, there are many technical issues/trade-offs which differ for wireless vs wired networks like Ethernet where CSMA/CD is used.

In particular, Wi-Fi uses CSMA/CA with an exponential back-off algorithm to handle collisions and alleviate the "hidden node problem". But ANT devices typically do not have the luxury of large batteries or AC power to run the radio 100% of the time, as CSMA/CA requires the device to continue to listen to the channel until there is no more usage detected.

ANT also already uses a wireless coexistence scheme conceptually similar to "token ring" to ensure master channels can be spaced tightly within a high-density environment, but where multiple receivers can still communicate with all of the nodes.