One master, many slave sensor, suggestions?

[hmmpic]

One master, many slave sensor, suggestions?

Working on a project with a PC connected to a master node, and some slave node, about 10-25.
All node is collection data and must send them to the master.
Master is a PC with a C# program there store all in a db. From the DB the data can be used to other things…

Master and the node is wireless on the same frequency!

Problem is the slave node, each must work on battery ex. CR2450 and work for long time. Therefore slave must sleep most of the time.

All node and master is working on the same frequency, therefore only one node must be on the air at the time.
Each node have a id number, but no one must talk at the same time!

Master and slave is paired once at setup time. I have control over that part. The setup include sleep time, sampling rate of date, a node number, and more.

I can think of more than one solution for it to work, but is there a better one?

1)
Slave wake up from sleep, and now waiting for a call from the master.
This way each node must be wake for long time maybe 1 minutes, because master have many node there must be served.
With a sleep time for ex 10 minutes, and then a listen time for about 1 minutes, my battery will be empty fast.

2)
Slave wake from sleep and listen, if there are nothing in the air it send what it have.
Master are all time online and listen.
After it have send the data it wait for a confirm from the master, if ok then it sleep 10 more minutes.
If no confirm, something went wrong, now listen again for silent, then resending and wait for confirm…
This way is not perfect because there will be some processing time from master get the data and it can send the ok. In this time another slave can send data… this will keep a slave wake for a longer time than expected, but ok for me.

I looking for the 3) model, but can’t find the most clever way.

A solution is _not_ to suggest other hardware because we have what we have, and all is working on the same frequency….

Any suggestion on this?

[Ttelmah]

Honestly the PC is the slave not the master here. Since the remote units can trigger transmission without being asked, they are masters.
What you are describing is a multi master situation.
However generally the RX side of a radio needs only tiny amounts of power. So the normal way would be to have the receiver on, and then have the master initiate all transfers (which then would be a master/slave setup).
Question is whether the slaves have any way of knowing the data has got through, or of knowing that another device has transmitted while they were transmitting?. If the PC can be told to acknowledge all packets, then the method would be:
s) Sensor wakes.
w) Checks if anything is transmitting?.
If so, wait.
If not, transmit packet with an 'ID' containing a counter, and the sensor ID.
If master acknowledges this ID, then sleep and go back to 's'. If not, wait for a pseudo random interval, based on the sensor ID, and go back to 'w'.

[temtronic]

What is the 'wireless' device ? You talk about a single cell battery being the power supply so have you 'done the math' to see just how long the battery will last powering the 'wireless device'. Some (most ?) wireless devices require a huge amount of power to transmit, so a supercap is probably needed to keep the 'electron bank' from dipping and resetting the PIC.
What operating conditions? If outside, how cold will it get? Batteries, ALL batteries lose a LOT of their capacity when it gets below' human operating temperature'.
What is the data? How many bytes ? How often? 1 datastream per minute? per hour?
Microchip have an 'application note' about battery life/PIC/etc. it is a 'must read'. While 20+ years old, it is still valid today.
The PIC is the least of your problem. It's need for energy is very small.
How many 'slaves' or remotes ? If under 255, there are tricks that can be played but again what data is needed (2-3 bytes or 100 ?) Again, more tricks can be used if we know what the data is. Say it's just temperature (24,25,26*C) if you use 'bit math' where a bit represent 1* then you have a range of -127 to +128*C within a single byte. That alone saves you 3 bytes to send, thus saving power.

[Ttelmah]

One trick used is 'timing overlap'.
For instance if you have a receiver that wakes for 2mSec perhaps every ten seconds, and listens for it's ID. Sleeps the rest of the time. Then have the 'master', when it wants data, start sending the ID it wants to talk to at 1mSec intervals, for just over 10 seconds. Because you will always receive one of these, you can then just reply with the data. The master obviously stops when it sees the reply.
Since you then only need to listen for 0.002 sec/ 10 seconds, the consumption need only average just over 1/5000th the receive consumption....