What is the best way for "Polling"?

Question

Hi,

This question is related with Microcontroller programming but anyone may suggest a good algorithm to handle this situation.

I have a one central console and set of remote sensors. The central console has a receiver and the each sensor has a transmitter operates on same frequency. So we can only implement Simplex communication.

Since the transmitters work on same frequency we cannot have 2 sensors sending data to central console at the same time.

Now I want to program the sensors to perform some "polling". The central console should get some idea about the existence of sensors (Whether the each sensor is responding or not)

I can imagine several ways.

1. Using a same interval between the poll messages for each sensor and start the sensors randomly. So they will not transmit at the same time.

2. Use of some round mechanism. Sensor 1 starts polling at 5 seconds the second at 10 seconds etc. More formal version of method 1.

The maximum data transfer rate is around 4800 bps so we need to consider that as well.

Can some one imagine a good way to resolve this with less usage of communication links. Note that we can use different poll intervals for each sensors if necessary.

Answer 1

I presume what you describe is that the sensors and the central unit are connected to a bus that can deliver only one message at a time.

A normal way to handle this is to have collision detection. This is e.g. how Ethernet operates as far as I know. You try to send a message; then attempt to detect collision. If you detect a collision, wait for a random amount (to break ties) and then re-transmit, of course with collision check again.

If you can't detect collisions, the different sensors could have polling intervals that are all distinct prime numbers. This would guarantee that every sensor would have dedicated slots for successful polling. Of course there would be still collisions, but they wouldn't need to be detected. Here example with primes 5, 7 and 11:

 ----|----|----|----|----|----|----|----| (5)
 ------|------|------|------|------|----- (7)
 ----------|----------|----------|-:----- (11)
                                   * COLLISION

Notable it doesn't matter if the sensor starts "in phase" or "out of phase".

Answer 2

I think you need to look into a collision detection system (a la Ethernet). If you have time-based synchronization, you rely on the clocks on the console and sensors never drifting out of sync. This might be ok if they are connected to an external, reliable time reference, or if you go to the expense of having a battery backed RTC on each one (expensive).

Answer 3

Consider using all or part of an existing protocol, unless protocol design is an end in itself - apart from saving time you reduce the probability that your protocol will have a race condition that causes rare irreproducible bugs.

A lot of protocols for this situation have the sensors keeping quiet until the master specifically asks them for the current value. This makes it easy to avoid collisions, and it makes it easy for the master to request retransmissions if it thinks it has missed a packet, or if it is more interested in keeping up to date with one sensor than with others. This may even give you better performance than a system based on collision detection, especially if commands from the master are much shorter than sensor responses. If you end up with something like Alohanet (see http://en.wikipedia.org/wiki/ALOHAnet#The_ALOHA_protocol) you will find that the tradeoff between not transmitting very often and having too many collisions forces you to use less than 50% of the available bandwidth.

Answer 4

Is it possible to assign a unique address to each sensor?

In that case you can implement a Master/Slave protocol (like Modbus or similar), with all devices sharing the same communication link:

1. Master is the only device which can initiate communication. It can poll each sensor separately (one by one), by broadcasting its address to all slaves.
2. Only the slave device which was addressed will reply.
3. If there is no response after a certain period of time (timeout), device is not available and Master can poll the next device.

See also: List of automation protocols

Answer 5

I worked with some Zigbee systems a few years back. It only had two sensors so we just hard-coded them with different wait times and had them always respond to requests. But since Zigbee has systems However, we considered something along the lines of this:

Start out with an announcement from the console 'Hey everyone, let's make a network!' Nodes all attempt to respond with something like 'I'm hardware address x, can I join?' At first it's crazy, but with some random retry times, eventually the console responds to all nodes: 'Yes hardware address x, you can join. You are node #y and you will have a wait time of z milliseconds from the time you receive your request for data'

Then it should be easy. Every time the console asks for data the nodes respond in their turn. Assuming transmission of all of the data takes less time than the polling period you're set. It's best not to acknowledge the messages. If the console fails to respond, then very likely the node will try to retransmit just when another node is trying to send data, messing both of them up. Then it snowballs into complete failure...