One or two sensors? and a hardware update

[Ed Borden]

An update on the hardware, a few introductions, and a question or two:

Joe Saavedra (citizensensor.cc) and Leif Percifield (dontflush.me) are
currently in possession of all of the Egg prototype inventory, etc.
(Joe carries it all around in this cute little toolbox, you should see
it.) The Egg is in good hands!

Right now, they are building up a set of wired, single-board
prototypes for use at the Citizen Cyberscience Summit, where the first
block-scale Egg network will be (temporarily, at least) deployed. I
hope. Those units will contain two CO sensors (Futurelec MQ-7 & e2v
MICS-5521), one NO2 sensor (e2v MICS-2710), and temp+humidity. They
will be directly wired to power and ethernet.

At the Summit hackathon, there are a number of challenges devoted
exclusively to the Egg. It will be great to see what happens.

A note on calibration: Impossible. We cannot build a
consumer-focused product that requires regular maintenance/calibration
of the sensors. Moreover, off-the-shelf sensors like we are using do
not come calibrated, and so we would incur significant expenses to
attempt to calibrate them after integration, only to still have the
problem of re-calibration later on.

Therefore, we can, and will, only look at trends in the data. Smart
people, I'm sure, will find savvy ways to interpret this data for us,
match it up with calibrated datasets (government or scientific
institutions may be able to provide these), and /or learn things we
never thought we would learn due to the sensor resolution, update
frequency, and resolution we aim to achieve.

So, a question to you all: Should the Egg sensor system have one or
two of each gas sensor? The thought here was that 1) the sensors are
very cheap and 2) if we integrate sensors from two different
manufacturers, we may learn something from the variation in the
dataset. Furthermore, if one of the sensors goes faulty, we would be
able to tell and still keep sending some good data from the other one.

Any opinions on this?

-@edborden

[Dirk Swart]

Ed, thanks for the update. I would love to see some photos of the eggs.

It is very exciting to see the eggs being temporarily deployed and hacked on.

A note on calibration:  Impossible.  We cannot build a
consumer-focused product that requires regular maintenance/calibration
of the sensors.

 

Ageed. 

So, a question to you all:  Should the Egg sensor system have one or
two of each gas sensor?  

Regardless of how many sensors we install, I think it would be nice to report one value for each variable sensed. That is, for a consumer device this should be under the hood, but accessible to hackers.

My first order guess is that the only way to shed some light on this is to build both configurations and see which one performs better, and if the dual sensor egg performs better, is it worth the extra cost? We could always build a board for two sensors, and only populate one.

Thinking "aloud" about possible sources of error and what a second sensor buys us. Errors could come from:
1- Sensor tolerances (probably a random error).
2- Sensor detection method or type (a bias / non-random error)
3- Faulty sensor (could be either, but I'm guessing it is non-random.)
4- Something besides the sensor - placement, faulty algorithm etc. (both random and not)

It is not clear to me that we would be able to reliably detect if a sensor is faulty unless we have 3 sensors of the same type together. In some cases we could tell, in others not. With two different sensors our only method would be looking for outliers or deviations from expected values. Still, that is probably a good method in this case.

I think the answer is to try it out.

Cheers
Dirk


 

[Joseph Saavedra]

Hi all !

On Feb 9, 2012, at 10:48 AM, Dirk Swart wrote:

Ed, thanks for the update. I would love to see some photos of the eggs.

It is very exciting to see the eggs being temporarily deployed and hacked on.

A note on calibration:  Impossible.  We cannot build a
consumer-focused product that requires regular maintenance/calibration
of the sensors.

 

Ageed. 

So, a question to you all:  Should the Egg sensor system have one or
two of each gas sensor?  

Regardless of how many sensors we install, I think it would be nice to report one value for each variable sensed. That is, for a consumer device this should be under the hood, but accessible to hackers.

This is extremely important, and I believe that Ed's idea to begin with -- even with 2 or more sensors of the same gas, only 1 value for that pollutant is being posted.

My first order guess is that the only way to shed some light on this is to build both configurations and see which one performs better, and if the dual sensor egg performs better, is it worth the extra cost? We could always build a board for two sensors, and only populate one.

This is a good thought, but when we're talking about gas sensors, the footprint in terms of PCB dev is large. And as the form is an "egg", we don't want to spec out an ostrich egg if we only end up using one sensor for each, cutting the required space by quite a bit. On average they are between 1/2 - 1 cubic inches. That's a lot of space when we're trying to cram this circuit into the form of an egg. 

Thinking "aloud" about possible sources of error and what a second sensor buys us. Errors could come from:
1- Sensor tolerances (probably a random error).
2- Sensor detection method or type (a bias / non-random error)
3- Faulty sensor (could be either, but I'm guessing it is non-random.)
4- Something besides the sensor - placement, faulty algorithm etc. (both random and not)

 I agree completely. Let's say we have 2 sensors, and they give contradicting trends - if one is showing an increase, the other a decrease in values during any period of time, how does the algorithm decide which to trust ?

It is not clear to me that we would be able to reliably detect if a sensor is faulty unless we have 3 sensors of the same type together. In some cases we could tell, in others not. With two different sensors our only method would be looking for outliers or deviations from expected values. Still, that is probably a good method in this case.

I think the answer is to try it out.

I propose we test out as many as possible (I have plenty of experience with the MQ series) and see which are most sensitive/reliable in this context and then stick with that. Deciding on just one sensor per pollutant will cut down on both space/size and cost. 

Cheers
Dirk

What do you all think?

Joe

_ _ _
Joseph Saavedra
Creative Technologist, Developer

http://jos.ph

http://citizensensor.cc

Adjunct Faculty,
School of Art, Media, and Technology,
Parsons the New School for Design

[Ed Borden]

If I'm reading correctly, you are saying that actually 2 sensors of
different make doesn't get us anything, but 3 sensors of the same make
does.

I think we can do this. The sensors are extremely inexpensive, and I
think the ability to provide some assurance that at least these cheap
sensors are functioning properly is a good thing.

Regarding how many datastreams get posted, I suppose this is a
question of what kind of smarts are inside the device... and I don't
think there will be any. If we use a WickedNode, for example, and
maintain that in the future the Nanode base will retain the ability to
speak to multiple WickedNodes (ie, I want to upgrade my system to be
able to sense radiation as well), we won't be able to do averages or
filter out bad datastreams locally. All of that stuff has to get
passed up to Pachube, and then whatever application gets written on
top for a UI will parse all of this.

[Dirk Swart]

On Thu, Feb 9, 2012 at 2:35 PM, Ed Borden <borden...@gmail.com> wrote:

If I'm reading correctly, you are saying that actually 2 sensors of
different make doesn't get us anything, but 3 sensors of the same make
does.

Yes, but I think Joe made some good points. Maybe one is just fine too.

Regarding how many datastreams get posted, I suppose this is a
question of what kind of smarts are inside the device... and I don't
think there will be any.  If we use a WickedNode, for example, and
maintain that in the future the Nanode base will retain the ability to
speak to multiple WickedNodes (ie, I want to upgrade my system to be
able to sense radiation as well), we won't be able to do averages or
filter out bad datastreams locally.

We should be able to do some data processing on a Nanode. Filtering or combining streams should not be a problem, so long as we have a simple rule we are working with. We can then pass one stream up to Pachube for each type of data we're collecting.


 

[Victor Aprea]

Whatever we  choose to do with respect to this thread, I think keeping corrupt / invalid data out of the central data store early is probably a better policy than trying to filter it out after the fact, imho...

Cheers,
Vic

[Ed Borden]

Size of the egg isn't a factor here. The Egg isn't holding the
sensors (see the most recent blog post which includes some of the
design changes:
http://blog.pachube.com/2012/01/airqualityegg-people-participating-in.html)

Cost of the sensors isn't really a factor here. They are around $5 ea.

To test all of the the sensors available on the market, that's a job.
And I would think an extensive one? A methodology would have to be
designed, etc. It's not that someone couldn't volunteer to do this
work, or do it as part of some other work, but I'm not sure that
making that evaluation is reasonable in the context of this project.
Is it?

Tim Dye, who is on this thread, actually performed this type of work
around some NO2 sensors already. His stuff is on the wiki:
http://airqualityegg.wikispaces.com/file/view/NO2+Sensors+Report.pdf

So, I think the question is still unanswered: One, two, or three sensors?

[Dirk Swart]

Cost of the sensors isn't really a factor here.  They are around $5 ea.

.. plus board space and any integration hardware needed.

 

So, I think the question is still unanswered:  One, two, or three sensors?

My take on this is that a complicated solution that works invariably starts as a simple solution that works. It is rarely the other way around. If we are not sure, start with one.

Cheers
Dirk
 

[Gustavo Olivares]

Hi all,

I agree with most of the points raised above in terms of calibration
but I think that the question of multiple sensors for the same
parameter is missing the point that the egg (if I understood
correctly) is envisioned to be a mesh of points and in that situation,
the specific value reported by 1 sensor/unit is irrelevant as the real
information comes from the integration of a lot of sensors.
What I mean is that if there are fewer than 10 eggs in a set radius,
then the data obtained by the egg is indicative at best. But if there
are more eggs, then the knowledge of the mesh is what you're actually
after.
In terms of "benefit for the user", then maybe the egg shouldn't
report directly its raw measurements but only the result of bringing
all the available information together.

In my experience, the output of the electrochemical sensors is very
variable in terms of baseline but less so in its response which tends
to be linear.

[Axel Roest]

Hi Gustavo et. al.

You raise a valid point there, but the current design of the egg includes an indicator light. I assume the light is meant to indicate the amount of pollution in his area. 

Now if all the egg does is send raw analog readings to Pachube, and a script on the server aggregates the data and provides meaningful, i.e. scientific results, that's fine by me. But it does mean that then there is no direct 1-on-1 interaction with the egg possible. In designer speak: it is not possible to directly ascertain the correlation between cause and effect. 

If I hold *my* egg next to the exhaust of my car and nothing happens, then I will surely think there is something wrong with my egg.

In my opinion there fore, the egg should not only send data to the cloud, but also be an autonomous unit.

Some local processing, perhaps including data gleaned from the web, is desirable.

Axel Roest

[Ed Borden]

The light on the egg is not meant to indicate the amount of pollution
in its area. The light + button has a separate thread, and is not
defined yet. However, if you take a look through some of the
materials that Albert sent through related to the Kickstarter video
storyboard, you can see some of the possible use cases that the
button+light might address.