I know this question is in line with many asked previously - with multiple senders and one receiver, however my scale is different.
Problem: I am building a sensor system, with the possibility of 250 sensors placed around the house as a college project. There is a possibility that all the sensors may try and transmit at the same time - how can I address that cheaply ? I also need to send an acknowledgement to the sensor, so that it does not transmit the same data again.
I am aware that Zigbee modules can take care of this - since they listen before transmitting - or so I believe. Is there a way of doing this cheaply - lets say for a RF module budget of max $5. Xbee's cost a bomb and I have no knowledge of using CC25xx modules.
I was thinking of using units like HC-12 which are $2.5 on Aliexpress, but not sure if there is an open source code that takes care of the listening before sending part, and maybe resolve collisions.
Thanks a ton!
Make your receiver the master, which emits the sensor numbers repeatedly. If the addressed sensor is active and has data, it answers almost immediately. Else, after a timeout, the next sensor number is requested.
DrDiettrich:
Make your receiver the master, which emits the sensor numbers repeatedly. If the addressed sensor is active and has data, it answers almost immediately. Else, after a timeout, the next sensor number is requested.
+1
My experience is with nRF24L01+ modules but they may not be capable of penetrating walls and floors in a house and lower frequency modules such as the HC12 would probably be more appropriate. But the technique DrDiettrich has suggested can be implemented with most wireless systems.
DrDiettrich:
Make your receiver the master, which emits the sensor numbers repeatedly. If the addressed sensor is active and has data, it answers almost immediately. Else, after a timeout, the next sensor number is requested.
Working will all depend on how often each sensor needs to be serviced. If there are only a few that need service more often, put their address more often on the address list.
Think of your receiver as the teacher.
Think of your sensors as the pupils.
Everyone in the classroom will hear everyone else.
So each sensor that wants to speak, needs to broadcast a identifier packet of data and wait for teacher to call back it’s time to send. Every other sensor hears the teacher give permission to that one sensor and then waits a set+random time to call out for the teacher itself.
Would not be unreasonable to have the teacher send out a heartbeat signal that the sensors know the teacher is ready to respond, like a teacher turning around to see which hand goes up first.
The HC-12 looks like it has 100 plus usable channels, if you set your sensors into “banks” you could change your master to a channel, let everyone on that channel know your available to receive, then after a timeout period, switch to the next channel and repeat.
Slumpert:
So each sensor that wants to speak, needs to broadcast a identifier packet of data and wait for teacher to call back it’s time to send.
What happens if two sensors send their identifier packets at the same time? Neither will be received. Remember in a classroom the students can raise their arms as a flag - but that is a visual rather than an audible signal so there is no problem with multiple simultaneous flags. And raised-arms don't need to be responded to instantly. There is a well known system called CSMA-CD that could be adapted to deal with wireless collisions but it seems to me it would be a lot of hard work compared with the simple polling system that DrDiettrich suggested.
The HC-12 looks like it has 100 plus usable channels,
If "channel" means frequency (as it does with the nRF24) then I reckon using multiple channels would just add to the complexity. It would also mean that one sensor could not know if another sensor was talking.
Repeated transmissions after collisions cost more energy than listening for a request.
If a node wants to send data it starts waiting for the transmission of its ID, then transmits and goes back to sleep.
DrDiettrich:
Repeated transmissions after collisions cost more energy than listening for a request.
That depends on how many retransmissions there are, and how long it's idle listening for a request - in other words, how often the nodes have to send data to or are inquired by their master.
ripperpc:
So the receiver has to chose when to send the data..
You have given us no idea about the frequency of sending data. That can have a huge effect on the design of the system.
I must confess to a liking for the suggestion in Reply #9. If the master could send a message and receive a reply in (say) 20 millisecs (which is probably generous) then it could poll all 250 sensors every 5 seconds. So any sensor that wishes to send data only needs to listen for about 10 seconds to be sure of hearing a request from the master. If the sensor sends data every 5 minutes (say) then it can sleep for over 95% of the time. And it would be unlucky if it had to listen for 10 secs every occasion.
With an nRF24 the round trip time would be less than 5 msecs which is why I said that 20 msecs is generous. With a shorter round trip time the listening period would be shorter.
Usage: For a period of 8 hours every day, anyone can come to any RFID tag reader, press a button to wake it if needed and scan a tag, that tag should come on the 'server', the receiver should then get an acknowledgement of the tag having been received at the center. It is completely possible, that 2 tags are scanned together on different locations and no tag is scanned for hours - which was the motivation behind a sender initiated transmission.
My solution so far using a server initiated transmission (using the excellent info posted above):
Since the RF modules are cheap-ish ($2.5 or less each), I can get 5 of them, get a 'server' (mega 2560?) with lots of UARTs, assign different channels to sensors (50 sensors - 1 channel), and then poll them simultaneously (5 sensors at a time all of which are on diff. channels).
Details on senders (sensors):
RFID reader
Push button to turn on the device if needed
Battery powered
Communication should be very very reliable - and reasonably fast:
ex if someone scans an RFID tag, the 'server' should get to know it asap
Q: Please recommend a solution for the above use case. I intend for the battery to last atleast 6 months and will have to provision their size accordingly.
Q:Will Zigbee take time to associate everytime it is turned on from sleep or power reset ?
Radio communication simply isnt very very reliable.
Its even less reliable when you are using frequencies which are shared with other users, and thats the case for just about all the radios you can buy which are class licensed.
When you have a large number of radios all on the same frequency of which any can transmit at any time , the likleyhood of interferance goes up exponentially with the number of radios.
The only reliable way to make such a system work reliably is 250 transmitters and 250 receivers all on differant frequencies.
Any other method means the reliability goes down.
You will have to decide how reliable the system needs to be , and what happens if transmissions are lost.
ripperpc:
Communication should be very very reliable
reasonably fast:
'server' should get to know it asap
How can anyone 'recommend a solution' without some indication of what you mean by the above ?
And I agree with mauried, whilst we can only guess at what 'very very reliable' really means, I would not rely on any RF based system using a shared frequency, you need to plan for failure.
get a 'server' (mega 2560?) with lots of UARTs, assign different channels
If by lots you mean four, that is fine.
However collision detection by listening to see if the channel is not being used will not work reliably, because if two senders listen at the same time both will see the channel is free and then both will start transmitting at the same time.
An RFID reader will need at least 100mA in standby so you will need an activate switch.
It looks like you are trying to implement an access control system. Have you considered how much current it takes to keep a door closed? Also you need signals like microswitches on each door to know when to lock it again after it has been opened.
Having worked designing access control systems then you are a long way off with your specification. I would expect a professional group to take 6months to a year to design and build such a system.
Very Reliable:
Even if the radio has to send the data multiple times, it should get to the server.
The server should send an acknowledgement, only on receiving the acknowledgement, would an 'OK' LED light up.
Reasonably Fast:
The user who taps the RFID card, will wait for the OK led to light up, indicating that the server received the ID, so wait time has to be less than 2 seconds. That is the time in between tapping the RFID card on the receiver and getting the LED to light up - that is the expectation.
srnet:
How can anyone 'recommend a solution' without some indication of what you mean by the above ?
And I agree with mauried, whilst we can only guess at what 'very very reliable' really means, I would not rely on any RF based system using a shared frequency, you need to plan for failure.
Its not an access control system, its more on the lines of ' i'm here in this room in case you need to reach me ' kind of system, essentially people tag in when they come in. The focus is on getting the RF to work.
Would a Zigbee setup work in this case ?
Grumpy_Mike:
If by lots you mean four, that is fine.
However collision detection by listening to see if the channel is not being used will not work reliably, because if two senders listen at the same time both will see the channel is free and then both will start transmitting at the same time.
An RFID reader will need at least 100mA in standby so you will need an activate switch.
It looks like you are trying to implement an access control system. Have you considered how much current it takes to keep a door closed? Also you need signals like microswitches on each door to know when to lock it again after it has been opened.
Having worked designing access control systems then you are a long way off with your specification. I would expect a professional group to take 6months to a year to design and build such a system.
ripperpc:
Very Reliable:
Even if the radio has to send the data multiple times, it should get to the server.
The server should send an acknowledgement, only on receiving the acknowledgement, would an 'OK' LED light up.
Check out the RadioHead library, it has a "reliable datagram" function that does resends and acknowledgements.
