Egg Unit No. 03

[Carsten Dannat]

Hi all,
I'm Carsten and I've received air quality egg no. 03 at London Citizen
Cyberscience Summit a week ago. @EdBorden - thx a lot for giving me
the opportunity to get my hands on an egg :-)

At the moment the egg's location is indoors. The unit itself has to be
reset every 4 to 6 hours, which is done using a time switch.

I do see periodic spikes in the CO and airQuality signals which looks
rather unusual to me.

The sensor data is fed to pachube: https://pachube.com/feeds/48307
Eggs location ( Northern part of Germany nearby Hamburg ) on Google
maps: http://bit.ly/AHR-Sensoria

Take care,
Carsten

[Joseph Saavedra]

Hi Carsten,

Happy to hear you found a spot for the sensor.

The CO data actually looks pretty good!

if you check out this blog post you'll see an image from their datasheet, and it's pretty similar. http://thesis.jmsaavedra.com/prototypes/technology/mq-7-carbon-monoxide-sensor-breakout/ . The final version of the CO sensor that you're using is this board: http://thesis.jmsaavedra.com/kit/mq-7-breakout-kit-maker-faire-talk/

Also, I failed to mention that in fact nothing is hooked up to the "Air Quality" sensor.

That was left there because we were considering connecting an MQ-185 to that port - but ended up not doing this on the board you have.  Don't forget that these are prototypes! :)

Last thing: the needing to reset the board is a known flaw of most ethernet arduinos. They simply time out after several hours of connectivity. If you look on your board there is a white wire that has been "dotted" with a sharpie marker. Make sure that wire connects digitalPin 3 to the RESET pin.  

code is here: http://github.com/jmsaavedra/Air-Quality-Egg

thanks, talk soon --

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

[Carsten Dannat]

Hi Joe,
thxs for your links. The egg unit 03 has changed location. The
measurements are taken outside now. We should see more changes in
temperature and humidity during 24h at least.
Still have to find an approbiate egg housing for permanent relocation.

The CO-spikes I have observed in the raw data are reoccurring roughly
about every 120 minutes. This does not match the heating cycle
interval of 150s you have described.

Take care,
Carsten

[Carsten Dannat]

Oops,
forgot that the updates to pachube are using their own time interval
as well. So what were are seeing on pachube might be explained by
interference effects between the measurement period and the update to
pachube period.

Carsten

[Carsten Dannat]

Hi,
as of today the egg moved back to an indoor location. Temperature and
humidity data taken outside were fine, but sensor readings for CO and
NO2 have been constantly zero. Now, I'm asking myself why there's such
a difference in the CO and NO2 data taken in- or outside?

Egg 3 feed: https://pachube.com/feeds/48307

Carsten

[Gustavo Olivares]

Hi Carsten,

Quoting Asimov ... "That's funny"

I have 2 theories as to why this behaviour.
First, instrument malfunction. Given the abrupt change in behaviour in
the CO and NO2 data streams, it is possible that they just didn't like
to be taken outside. Condensation from the cold air outside, sensors
not exposed to air, etc. What makes me think this is possible is the
fact that the CO data stream is FLAT, not "near zero" or "featureless"
but dead flat except for 5 points. As Joe indicated before, the CO
*must* be going up and down because there is a power cycle in there
and you should get spikes when the sensor is "high". Now, this may be
because the plot I can see for last week just doesn't have that high
resolution so I just can't see the cycles but if the high frequency
data doesn't have the cycling behaviour, then the sensor is wrong. The
NO2 on the other hand doesn't fit this so this leads me to what I
think is the most likely explanation:

Indoor sources. The CO sensor used (MQ7) has very poor sensitivity and
it requires quite a bit of CO in the air to register anything. I'd bet
that it is also the case for the NO2 one. I've run several of these
kinds of cells on "ambient air" and unless you're near a combustion
source, the output is very low. The options I can think of are:
1.- Smokers inside
2.- Unflued gas heaters
3.- Kerosene heater
4.- Gas kitchen
5.- Hydrogen source in the house

Some exotic solvent used in the house?

If someone can recover the raw 1s data I can make more informed
guesses.

Regards
/El Gus

[joe saavedra]

Hi Carsten and Gustavo --

So, Gustavo is very much right about the sensors not "liking" being outside.

This is entirely due to the temperature and humidity. 

The gas sensors we are using are metal-oxide sensors. They work by using a heating element to heat a filament which is coated in a chemical sensitive to whichever gas that sensor is targeting. Then, the variable resistance of that filament changes when it is exposed to the specific gas.  When the element does not get hot enough, the sensor is unable to take a reading.

That's what's happening here. Humidity also can have an effect on the sensors. That's why we always will need to measure temp and humidity along with sensor data.

We can absolutely compensate for this.  On both the CO and NO2 sensors there is a pull-down resistor that helps the values for both be in an appropriate range for the ADC on the microcontroller to read. If we lower the value of this resistor we will pull the sensors into a better (higher) range. The values set in this first round of prototypes were based on a previous design which used a different microcontroller. I have a hunch that the Nanodes are actually outputting less current than my previous circuit, putting the sensors at a different range than before, in this case quite a bit lower.

I was noticing this even when yours are indoors -- the values are quite low on both. We should be aiming for a base-line range around 400 - 600 (about half of what the 10-bit ADC on this chip are able to measure, 0 - 1023).

We are going to deploy 3 units, with identical circuits to yours, Carsten, here in NYC this week. I am nearly 100% sure we'll end up seeing the same the changes, with the gas sensors bottoming out when put in the cold.

Totally fine, and as I said will be addressed in the second round of prototypes, and can easily be altered with a tiny amount of snipping and soldering. 

Thanks so much for helping with this prototyping!! and for being patient. After we fix those resistor values, we'll send you a replacement unit. Or maybe we can talk and I can point out exactly which resistors to clip and the new values for replacing.  One big question:  What did you end up enclosing the unit inside of?  This can also make a difference in the numbers passed. If there's a ton of exposure to wind, that will help keep the sensors too cold. Enclosures will all be uniform across the units, hence the "egg" idea.

Thanks, talk soon -

joe

[joe saavedra]

this is 100% correct. spikes we're seeing are just the ones that are happening at the moment the data is pushed to Pachube.

[Carsten Dannat]

@Joe
I haven't used an enclosing at all when the measurements were taken
outside. Temperatures might drop below freezing point at night right
now here in Hamburg. I moved the egg to an ouside loacation again,
but I've changed the setup a little bit. The egg is now covered with a
tupperware bowl which may give some shelter. Replacing resistors
shouldn't be problem.

@El Gus
Have to check my poison cabinet for toxic solvents ;-) Two years ago
the gas heating, which is located in the basement, had emitted to much
CO. Now it's fixed - luckily us, but our CO source for egg testing
vanished.

Carsten

[Gustavo Olivares]

What's the pushing strategy in the eggs?

Are the "live" values being sent to Pachube at update time or is there some buffering, conditioning or other process in between?

My question is mainly because of the non-continuous nature of the CO signal. In a couple of projects I've made I've flagged the data so I know which records have valid CO data and which ones I need to discard but I was saving every second and I wonder if the egg's firmware holds the last valid CO reading to push to Pachube or does something else.

/El Gus

[Carsten Dannat]

Hi El Gus,

currently the raw sensor data is sent to pachube at update time. If the CO sensor is in "heating mode" the previous measurement is taken instead.

@Joe: Please correct me, if I'm wrong.

Carsten

[Dirk Swart]

Hi Gus,

This is certainly possible to do without too much trouble.

Cheers
Dirk


Follow me on Twitter now: dswart