SparkFun Forums

[DrCoolFoolPool]

Hi!
Is it possible to have a controller collect sensor data from 20,000 sensors? What I want is thousands of arduino-sensors in a room, all taking some measurement of the temperature, and reporting to a hub/controller (arduino or rapsberry pi) which in turn relays that info using a GPS-shield to a web server. I'm hoping it can be done with some cheap RF/wifi transmitters. Using for example bluetooth can be pretty costly if multiplied by 20k.

[jremington]

This seems unreasonable. Why do you want to do this?

[DanV]

screw the transmitters - can you even afford to buy 20,000 temp sensors??
And what room is big enough that you can put that many sensors in it??

[Mark K]

Yes it is possible. I have had 40K+ sensors running on a wireless network.
These calculations assume (yeah I know) a one way transmission (sensors are transmit only) with pseudo random transmit times and non critical data (if I miss a reading every once in a while it is no big deal). Here is what you need to calculate for your system.
1) Time each sensor is on air. This will be determined by the data rate and the number of bytes of data.
2) How often each sensor will transmit each day.
These first two things will tell you how many 'time slots' you will have. BUT because of potential collisions that will not be the actual number of sensors you can support from that receiver. You can reliably support about 18% of that calculated number before your reliability suffers.
For example if your transmissions are 200ms 4 times a day 20K sensors is reasonable. I was running with 10ms on air times and hourly transmissions.
For more background on the math wikipedia ALOHAnet or collision domains.

Have fun with your project.
Mark

[lyndon]

Of course it's possible. How much money do you have available to throw at it?

[DrCoolFoolPool]

Well this is a PoC, and if it works theoretically with 20k sensors, and I can demonstrate it in a smaller scale pilot project, a big company is ready to throw millions at it.
I will measure the temp in 5-10 min interval, and every 15-30 mins will try to report that data to the controller (if possible).

[jremington]

Now, why would knowing the temperature at 20000+ points in a room, every 5-10 minutes, be worth millions of dollars? Theory of cloud formation in a large aircraft hanger?

And if the question is so important, given that the infrastructure is simply a matter of resources, why hasn't this been done already?

[DrCoolFoolPool]

Beats me.

[Valen]

...
I will measure the temp in 5-10 min interval, and every 15-30 mins will try to report that data to the controller (if possible).

That's not really compatible to the numbers Mark K suggested. Every 15-30 minutes a day means 48 to 96 times a day. Compare that to what he said: 4 times a day (200ms long) Now, you haven't suggested the amount of data in each packet, or the bandwidth/rate with which they will be sent. So that still leaves enough uncertainties in how long these packets will take to transmit. Cheap RF transmitters are usually of the low bandwidth type, or need much data-redundancy to get the message across intact. That will take it's time. Throwing your 48-96 times a day times 20k sensor units out of the window. If Mark K was in the right ballpark with his numbers.

EDIT:

...will try to report that data to the controller (if possible).

That implies a 2 way communication. The sensor would need to know from the controller that the message was received. That even increases the time that the airwaves are occupied by other transceivers increasing the likelihood of collisions..

[jremington]

The cheap RF TX/RX modules have a maximum bit rate of about 4000/second. If we take 200 milliseconds per transmission, that is about 800 bits, which is enough for a reasonable data message plus packet framing and error checking codes. Divide that bit rate by two or four for better reliability.

200 ms/message gives 432,000 time slots per day. Divide that by 20,000 sensors and you have 21 time slots per day, if everything is perfectly synchronized. That is impossible for one way transmissions, so if you use Mark K's pseudorandom timing approach, that reduces the number of possible collision-free transmissions by a factor of at least 5. You end up expecting four time slots per sensor per day, on a good day!

Not only is four time slots per day "reasonable" as Mark K suggested, it is in fact the best you can expect for this simple approach and the assumptions made previously.

The same topic on another forum raised some entertaining comments, e.g. 20,000 ordinary Arduinos convert around 5 kW of power to heat. http://forum.arduino.cc/index.php?topic=341376.0

I suppose you could just connect 20,000 sensors with wires, but a room with 40,000 crisscrossing wires isn't a normal room. And the time to string and test! Good luck.

[lyndon]

So let me go out on a limb and assume you're serious. If you really want to build this thing, the last thing you want to do as your first step is assume what the answer looks like.

0) We know this is theoretically possible, so the question is "what will it take to do it?"
1) Write clear, accurate, detailed specifications of exactly what you want to accomplish
2) Determine what subset of that you need to do for a Proof of Concept
3) Survey existing technologies for a good fit to your requirements
4) Choose a small subset of those technologies as possible candidates
5) Design, using either all of the subset, or the best one, your proof of concept
6) Estimate cost
7) If OK, go ahead and build your proof of concept prototype

There, I just saved you thousands of consulting dollars!

[edited to clarify step 7]

[jremington]

I would add (5.5) test the prototype and verify the required functionality.

As an undergraduate student some time ago, I helped a team build an "air temperature field monitor" for studying temperature gradients in the air, during light air motion out of doors. The prototype was a 1 meter^3 framework constructed from very thin rods, with fast-acting, microscopic thermocouples at each of the 8 corners of the cube.

It was an interesting project. The data were interpreted to indicate that roughly spherical regions or pockets with different temperatures and densities were moving through the detector.

[lyndon]

I would add (5.5) test the prototype and verify the required functionality.

As an undergraduate student some time ago, I helped a team build an "air temperature field monitor" for studying temperature gradients in the air, during light air motion out of doors. The prototype was a 1 meter^3 framework constructed from very thin rods, with fast-acting, microscopic thermocouples at each of the 8 corners of the cube.

It was an interesting project. The data were interpreted to indicate that roughly spherical regions or pockets with different temperatures and densities were moving through the detector.

Oh, steps 0-7 were all before the prototype is built!

[Mark K]

Fully agree with lyndon and jremington on the steps to take.
I would look at an RF SOC TI or Nordic like the nRF9ES, Plenty of I/O and a 8051 like core. Fast radio for short on air times and because it is a xciever you can implement listen before talk (collision detection) for greater network throughput. With a 4 byte address, 16 bytes payload and a CRC check you can have about 4 ms on air times. This will support lots of transmissions. They are less than a couple bucks in your volumes, SWAG BOM ~$9-$14 per sensor plus your NRE costs.