Avoiding collisions in RF setups.

[Divedeep]

Hi,

I am working on a sensor that reads temperature and humidity and then sends the data to a central webserver where the data is displayed on a webpage.
The radio of choice is the NRF24L01+

To save power the sensors and the radio goto sleep. In sleep mode the radio cannot hear any transmissions.

What i would like to happen is for the central server to be listening for when the sensors wake up. Upon waking up they will send there id number, along with a request to send. If the server is not currently doing anything with another sensor it will reply with a clear to send. If it is busy however the sensor just doesnt get a reply.

This system seems to be an OK way of doing this until i look at what will happen with more and more sensors. If 2 sensors for example wake up at nearly the same time, there is going to be a collision in data, neither will get a reply and if they keep trying to resend there data they will just continually collide until they reach there maximum retry limits.
The other problem i can see is if a sensor send an RTS and gets an CTS back, then another sensor wakes up at the same time as the first sensor is sending its main packet of data. There will be a collision here and as far as the sensor is concerned it was clear to send.

Does anyone have any ideas on a way to make such a system a little bit more bullet proof?

 

[Harald Kapp]

You're not the first to stumble across this issue. One technique to minimize collisions is CSMA/CD (Carrier Sense Multiple Access / Collision Detection). A somewhat more primitive verision of which is represented by the ALOHA protocol.

Both techniques monitor the RF channel from sender to receiver and retransmit in case they detect a collision between data packets. Important is the use of "randomized" interval between retransmissions to reduce the chance of a next collision,

 

[Divedeep]

Thanks for your reply Harald.

The NRF24L01+ does have a carrier detect feature. This would check to see if there is any traffic on the channel before transmission. However Nordic advise that its not much good as by the time you do attempt to transmit there could then be data on the channel and a collision occurs.

Randomized intervals defiantly seem like the way to go. I have seen a few references to this upon looking it up.

 

[KrisBlueNZ]

Yes, random intervals are a good idea. Alternatively you could calculate the retry interval based on the sensor's address, since (presumably) each one has a different address or identifier.

 

[(*steve*)]

The simple technique is to blindly transmit your signal and wait for an acknowledgement. If you don't get one you wait a random time and try again. You keep trying until you get a response.

The important things are:

1. The random interval will be pseudo-random, and probably calculated by some algorithm. You must ensure that all of your transmitters are not stepping their random number generators in sequence (salting the random number generator with part of the data you're sending can help)
2. The duration of your message should be short, and the frequency of messages such that the channel utilisation remains very low. Without any "carrier sense" you might effectively reach saturation at 20% or lower utilization. With carrier sense (especially for longer messages) you can drive that a little higher. You can never achieve 100% utilization with more than 1 device transmitting.

Another option is polling. The "master" polls each unit in turn asking if it has anything to send. The unit responds with either a "no" (indicating it's awake, but with nothing to send), or it sends some/all of it's data, or it doesn't respond at all. Variations on this can drop stations from the polling if they don't respond, and add them again if they respond during a special (and essentially CSMA) window for them to re-announce their presence. This can result in far higher channel utilization and is a great solution where the stations can reach the master, but cannot hear each other. This actually formed the basis of a scheme called "frottle" for getting good utilization from long distance wifi links.

 

[shumifan50]

I would agree with Steve that polling is the better way to go as it leaves the server in control of the channel and therefore much higher channel utilisation can be achieved. As far as the satellites are concerned, when they are ready to send they can wake up and wait until polled, sending their data, before going to sleep again. If a station does not respond, it does not mean it is offline, it might just be sleeping on the first poll. Thereafter it should always respond as it should be waiting to be polled, provided the poll rate is slower than the sleep period. By setting up variable addresses to poll, depending on whether they respond or not, polling can be made more efficient with less timeouts and therefore more regular polling of 'live' stations. In the good old days of 1200bits per second modems, Burroughs(computer company) used this protocol and called it poll/select. The select part is used to check whether a satellite is ready to receive data.

 

[KrisBlueNZ]

I would agree with Steve that polling is the better way to go as it leaves the server in control of the channel and therefore much higher channel utilisation can be achieved.

It depends somewhat on the circumstances - how many stations, how frequent the updates, how much latency you can tolerate between an event occurring at a station and the base finding out about it, how much power each station can afford to waste, how long each transaction takes... There is no hard and fast rule.

 

[shumifan50]

CSMA/CD works well on high speed channels where data occupies the channel for very short periods. Its performance seriously degrade as the packet sizes go up or the channel speed comes down. The critical part of od CSMA/CD is reliable carrier detect to avoid corrupting in-process transmissions. It is normally recommended that CSMA/CD channels should not use more than 66% of bandwidth. Typical poll/select circuits run at close to 100% utilisation as it is continually polling. Retransmissions are kept to a minimum as crashes should occur only because of corruption from external sources.

If you are writing the code yourself, coding the poll/select protocol is significantly simpler to code reliably.

Polling has another side benefit in that as the server controls when to accept data, it cannot be overrun - this can be important on low power servers that have to do some processing on the data.

I agree with Kris there is no hard and fast rule, but there are some guidelines.