AQE is now available for preorder

[Dirk Swart]

Hi All,

If you missed out on the Kickstarter and would like to purchase an Air Quality Egg, you can now do so here. (http://wickeddevice.com/index.php?main_page=product_info&cPath=28&products_id=108)

Cheers
Dirk

[NeilH]

Hi Dirk

I noticed you referenced this in Wickeddevice.com - and I really like the basic statement of 

" to collect very high resolution readings of NO2 and CO concentrations outside of their home "

I'm wondering, since you seem to be on the design team, what is the definition of "very high resolution readings" - or maybe a technical question how many effective bits are you considering "very high resolution" to be across what range of readings. I couldn't find any details on the web page you referenced.

I am an electronic engineer and very interested in the product and I am interested in buying it for the excellent price stated ... however I also do my homework and when I buy measuring equipment I look for a specification of what it is measuring - usually  range of readings, absolute accuracy  of those measurements, incremental accuracy (linearity of sensor), units of measurement, and resolution of measurement. 

The resolution of measurement is typically meaningless without absolute accuracy and linearity statements.

I am an active local citizen promoting local community involvement, and the SF Bay Area does advertise bad air days? so how might I use the readings to promote a local discussion on air quality.

Appreciate any insights.

Neil

[Victor Aprea]

Neil,

I'll take a crack at answering your post from a purely electronics point of view. The processing nodes in the AQE system are ultimately based on the Atmel ATMega328 microcontroller and the add-on Sensor modules (which in principle could be made arbitrarily complex with whatever microcontrollers, ADCs, and sensors that people can develop). The first add-on board I made up is designed for the e2v CMOS sensors and incorporates an Atmel ATTiny44A microcontoller. Both the ATMega328 and ATTiny44A have an on-chip Analog-to Digital Converter (ADC) with 10-bit resolution.

As Joe Saavedra stated in a recent post the basic sensors included are 1-wire digital temperature and humidity sensor (DHT22), Carbon Monoxide (MiCS-5525), and Nitrogen Dioxide (MiCS-2710) sensors. The e2v sensor datasheets are readily available from the e2v website. The DHT22 datasheet is widely available on the net. We are publishing all circuit board design files (for now on git-hub and eventually on solderpad.com) and micro-controller code (on git-hub) as it is being developed.

Does that address your questions? Looking forward to hopefully meeting a bunch of community members at the Bay Area Maker Faire next week!

Kind Regards,

Vic

[NeilH]

Hello Vic

Thanks for the  reference to the components. I did look over the hardware spec and the ATtiny44 /10bit ADC 1.1Vref+-10%

I've extensively used a slightly different processor, the ATmega256 10bit ADC and a microchip 18bit ADC.

My personal method was to run through all the calculations of converting sensor readings to use able units before I did any PCB design. 

So if I want to figure out for this design if the physical sensor devices can be used for Air Quality monitoring, 

1) I need to determine what thresholds determine good/bad CO and NO2, and here I'm assuming the sensitivity needs to extend from normal atmospheric to human health impact levels, and I'm not really bothered with excessive levels of CO & NO2.

2) then I need to determine if the combination of sensor devices, Analog input range, ADC10bits, ADCref and temperature drift + influence of humidity, Vcc voltage stability can provide enough resolution round the thresholds for the hardware to be measuring the right window of values.

3) and finally I need to figure out some way of testing if the powered sensors devices are actually measuring anything related to what the manufacturer  claims they measure

4) then normalizing the output of the whole hardware/software to a linear defined range with standardized units, either by calculation or individual sensor threshold checking.

So hope fully someone will run those numbers  and publish the results so that the measurement chain can be understood  with reference to Air Quality thresholds of interest.

Cheers

Neil 

[Dirk Swart]

Neil,

I think my answer to the big question you are alluding to, "Is this kind of measuring approach useful" is that we just don't know. We'll do the experiment, and then we'll know.

On a lighter note, as I write this I have a vision of Neil Degrasse Tyson saying "Stand back - it's actual science".

Cheers
Dirk



Follow me on Twitter now: dswart

[Victor Aprea]

Neil,

One slight correction is that we're using externally regulated voltage for the reference (on the AREF pin), not the internal +/- 10% reference. Also since the hardware includes temperature and humidity sensors, one design goal is that those variables can be compensated for in the network. As you know there are entire other threads relating to calibration in the group discussions, and it sounds like there are some innovative approaches being pursued with respect to network-based calibration and compensation. At any rate, it seems like you have an reasonable "characterization" approach outlined, would you be interested in helping "run the numbers" (under the assumption that the sensor datasheets are truthful - which is one I think we have to make at this point)?

Regards,

 

Vic

 

On Thu, May 10, 2012 at 2:31 AM, NeilH <nei...@sonic.net> wrote:

--

Victor Aprea // Wicked Device

victor...@wickeddevice.com

M: 607.745.1515

T: twitter.com/vicatcu/

[Joseph Saavedra]

quick correction Vic: after testing, and Ricardo chiming in, the resistor values we're using on the MiCS sensors are configured so we can use the internal 5v AREF

_ _ _
Joseph Saavedra
Creative Technologist, Developer

http://jos.ph

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

[Victor Aprea]

Regulated none the less. Not +-10%...

Vic

[Victor Aprea]

Also, may as well use externally regulated 3.3v since the sensors are 1.8v to get better effective resolution from the ADC.

Vic

[NeilH]

Thanks for the answers everyone. 

What I'm trying to ask myself, since you are the developers,  is this a device that can do  measurements that can be interpreted in an Air Quality context.

I don’t know a lot about air quality except it is a matrix of measurements,  so I’m going to have to rely on others.

My understanding is the basic scientific thresholds have been established – now its engineering a lower cost instrument to measure those levels.

Has anybody in your team run the numbers to see if this instrument can theoretically measure

CO to 9ppm with an accuracy of 1ppm. Normal atmospheric ranges are up to 20ppm

NO2 to 100ppb with an accuracy of 1ppb. Normal atmospheric ranges are up to 400ppb.

 

I’ve got these numbers from the   Sonoma Technologies document advertised with the kick starter project

 

 “Desired Characteristics and Information about Major Air Pollutants for Device Manufacturers to Use in Creating Instruments for Non-regulatory Monitoring (e.g., Citizens, Schools, NGOs).

 

This description fits this project exactly and was used to encourage people to support the project.   It has a table

 

Pollutant

Health Concern1

Atmospheric Concentration Range2

Health Standard3

Accuracy7

Time Resolution

Location

Urban

Rural

Near Trans.

Worldwide

Outdoor

Indoor

Season

Gases

Carbon Monoxide

R

0-20 ppm

9 ppm 8-hr

1 ppm

1 min to 1-hr

ü

ü

ü

ü

Year round

Nitrogen Dioxide

R, V

~0-400 ppb

100 ppb 1-hr

1 ppb

1 min to 1-hr

ü

ü

ü

ü

Year round

[Ed Borden]

Neil, I think your questions are speaking to some of the issues that were covered in this update:

http://www.kickstarter.com/projects/edborden/air-quality-egg/posts/208180

[Martin Dittus]

That said, I want to encourage you to keep up your scepticism Neil :)

The questions you raise go right to the core of this project's ambitions, and they will be asked by others; and I'd like us to find good answers to the most important issues, even if the answer may sometimes be "that's not something we're concerned about."

Will start a new thread in a bit with some broader thoughts on this.

m.

[vicatcu]

Neil,

I've just posted some additional documents to the wiki. I strongly recommend reading the MICS sensor FAQ document. In a nutshell the nature of CMOS gas sensors is, in a sense (no pun intended), that each one is a unique and beautiful snow flake. Their response  drifts over time, their baseline resistance varies, their co-variance with humidity, temperature, and other gases differs, etc. Definitively, there is no plan to individually characterize the deployed sensors beyond what is provided in their data sheets. I don't think any of that is inconsistent the fundamental goals of the project / community.

These types of sensors are, however, relatively inexpensive - which is a major driver of the AQE project; we want to discover what information can be gleaned from the available "low end" sensors on the market today, even if it's just data trends. Our aim has never been accuracy in the absolute sense. You can't reasonably get that without investing a lot in infrastructure and effort that it takes to periodically (frequently) re-calibrate each sensor with controlled gas concentrations. The other thing the CMOS sensors have going for them is that they are have good sensitivity in measuring changes with respect a baseline. For what it's worth, the FAQ states that "Applications such as automotive AQS, using only relative sensor signals, do not typically require calibration."

As I understand it, what we are trying to do here is:

1. Deploy lots of low cost sensors and report the sampled data from them over time to the the web, with the implication that a previously non-existant set of data will emerge.
2. Develop applications that digest that data set and extract information about air quality from it (changes over space, over time, etc). The nature of these applications is something that will (I expect) develop organically from the community. I would anticipate they might do something like removing "DC" levels and "normalize" data streams in the process.

I believe that, philosophically, we want to limit the amount of "massaging" of the data at the end points and allow more sophisticated (and globally aware) algorithms and processing to occur at the application layer. It hasn't been determined yet how far we want to take that concept. In the extreme, we could post raw ADC sampled values to the data streams, but i don't think we want to go that far. It probably makes better sense for the microcontroller to transform the ADC value into ppb or ppm measure based on assuming the typical R0 resistance and invoking the log-log plots provided in the data sheets, while using a multiple-resistor ranging technique (for two or three range bins, as described in the FAQ alluded to earlier) to get a sort of sliding scale resolution from the ADC (i.e. since the response is inherently non-linear). 

Anyway, I just wanted to clear the air (sorry I couldn't stop myself) on some of the discussion surrounding the sensors for the project. Hopefully this discussion can continue in a constructive manner, but I feel strongly that we should keep keep the conversation in terms of how to make the best use of the sensors we have identified and have experience with to date.

Regards,

Vic

[NeilH]

Hello Vic

Thanks for the update - and "airing" the open hardware design discussion. Understanding hardware limitations is the first basis of building a software stack to interpret the data.

I must say I enjoy snowflakes and where possible bio-mimicricy is a great way of investigating the natural world.

Deciduous Leaves are also wonderful things, reinvent themselves each year to take in CO2 - the size of the pores is apparently proportional to the amount of CO2 and is used as an investigation into atmospheric carbon in past millenia.

Alas current technology use various metal oxides that exhibit electrical properties that can be measured - and the challenge as you are suggesting is how to make them last and give useful information  - 3 years possibly. I take heart that the e2v.com is talking about automotive sensors for vehicles (10-20yr lifetimes?) which is volume and (I hope) low cost. 

Look forward to reading.

Cheers

Neil

[Victor Aprea]

Neil, 

I believe you are correct that the principle application of the e2v sensors we are pursuing is indeed the automotive industry from what I understand.

Cheers,

Vic