What is the best way to "poll"?

Question

This question is related to the programming of microcontrollers, but anyone can offer a good algorithm to handle this situation.

I have one center console and a set of remote sensors. The center console has a receiver, and each sensor has a transmitter operating at the same frequency. Thus, we can only implement Simplex communication.

Since the transmitters operate at the same frequency, we cannot have two sensors sending data to the center console at the same time.

Now I want to program the sensors to do some “polls”. The center console should get an idea of ​​the existence of sensors (regardless of whether each sensor responds)

I can imagine several ways.

• Using the same interval between polling messages for each sensor and randomly start the sensors. Therefore, they will not transmit at the same time.

• Using some round gear. Sensor 1 starts polling after 5 seconds, the second in 10 seconds, etc. A more formal version of method 1.

The maximum data transfer rate is about 4800 bps, so we must take this into account as well.

Can anyone imagine a good way to resolve this with less use of communication channels. Please note that, if necessary, we can use different polling intervals for each sensor.

Answer 1

I assume that you are describing that the sensors and the central unit are connected to a bus that can only transmit one message at a time.

A common way to deal with this is collision detection. This, for example, how Ethernet works, as far as I know. You are trying to send a message; then try to detect a collision. If you find a collision, wait for a random amount (to break the ties), and then resend, of course, with a collision check again.

If you cannot detect collisions, different sensors may have polling intervals, which are different individual numbers. This ensures that each sensor will have dedicated slots for successful polling. Of course, there will still be collisions, but they will not need to be detected. Example with examples 5, 7 and 11:

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

It is noteworthy that it does not matter whether 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 synchronization, you rely on the clock on the console and the sensors never go out of sync. This can be normal if they are connected to an external, reliable time reference, or if you go to the point that the battery supports RTC on each of them (expensive).

Answer 3

Consider using all or part of an existing protocol if the protocol design is not an end in itself - in addition to saving time, you reduce the likelihood that your protocol will have a race condition that causes rare fatal errors.

In most protocols for this situation, the sensors remain silent until the wizard specifically asks them for the current value. This makes collisions easy to avoid, and it makes it easier for the wizard to request retransmissions if he believes that he missed a packet, or if he is more interested in monitoring one sensor than others. It may even give you better performance than a collision detection system, especially if the commands from the wizard are much shorter than the responses from the sensors. If you end up with something like Alohanet (see http://en.wikipedia.org/wiki/ALOHAnet#The_ALOHA_protocol ), you will find that the trade-off between non-transmission is very common and with a lot of collisions makes you use less than 50% of the available bandwidth.

Answer 4

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

In this case, you can implement Master / Slave protocol (for example, the Modbus or similar), all devices use the same communication link:

• A wizard is the only device that can initiate communication. He can interrogate each sensor separately (one after another), passing its address to all slave devices.
• Only the slave that was addressed was sent.
• If after a certain period of time (timeout) there is no answer, the device is unavailable, and the master can poll the next device.

See also: List of Automation Protocols

Answer 5

A few years ago I worked with some Zigbee systems. This only had two sensors, so we just encoded them with different waiting times and always responded to requests. But since Zigbee has systems. However, we looked at something like this:

Start with the announcement on the "Hello everybody, let me make a network!" The nodes are all trying to respond with something like "I'm hardware address x, can I join?" This is crazy at first, but with some random retry times, the console eventually responds to all the nodes: "Yes, hardware address x, you can join. You are node #y and you will have a timeout in milliseconds from the moment you receive your request on data '

Then it should be easy. Each time the console requests data, the nodes respond in turn. Assuming that transferring all the data takes less time than the polling period you set. Better not to recognize messages. If the console does not respond, then most likely the node will try to retransmit only when the other node is trying to send data, entangling them both. Then it slides into complete failure ...