Misrepresentation of "High-Resolution"

[Ed Borden]

I want to briefly bring up a point that NeilH has put forward: That
we have misrepresented the Air Quality Egg in that we've described it
as a sensor system that can collect "high resolution readings of Air
Quality data". The original intent of this terminology was used to
primarily describe the FREQUENCY of datapoints/updates as compared to
the official datasets available currently, but we also had the
potential DENSITY of the sensor network as a whole in mind as well
when that was written. I can see this as possibly being confused with
a description of ACCURACY, which is most certainly not what was meant!

Now that the kickstarter is done, this is largely a moot point, but I
did want to at least recognize the ambiguity and at least make a point
of being clear about that issue moving forward.

The nature of a project like this is speed and experimentation. We
won't get everything perfect along the way.

[NeilH]

Hello Ed

Great to flush out some of these issues – even if the project has already got a head of steam.  Aesop’s fable on the Tortoise and the Hare springs to mind.

BTW it’s a great technology chain from pachube.com to the Arduino based sensors. However it ain’t gonna work just because somebody wants it to work – its gotta be engineered and designed, teaching about sensor accuracy/calibration is critical to understanding measurements.

I have consistently been asking for the AQE Sensor Specifications – in industry this is typically labeled “Draft” early in life and it evolves from there, The Atmel processor Mega256 Specifications have gone from AàN versions.

 I would have hoped for a “Draft AQE Sensor Specification” to include such items

1)Max frequency of update – knowing the architecture even every minute would be high frequency and doable.

2)Accuracy of AQE <XXX> sensor reading/units

3)Resolution of  AQE <XXX> sensor reading/units

4)Environmental specifications – can it go outdoors  -20C to +70C with rain & ice.

There are physical sensor accuracies and resolutions directly translatable from the e2v sensor specifications, processor ADC and Voltage Reference and front end signal processing over a working temperature range. They should be stated at a minimum. I guess someone will do it once the circuits and code are defined – but that becomes a qualification stage – and its better if it happens earlier in the process as a specification verification.

Since I’m reading an open source hardware project (hey you’ve a crowd sourced peer review), and I’m a hardware/software engineer “high resolution readings of Air Quality” has very specific connation’s to me.

I am very excited by that marketing level statement.

However when I decoded the statements like http://www.kickstarter.com/projects/edborden/air-quality-egg  “The Air Quality Egg is a sensor system designed to allow anyone to collect very high resolution readings of NO2 and CO concentrations outside of their home”

 Combined with "Update #5: Why sensor calibration and precision is the wrong conversation"

 I started to wonder what does this mean: “the breadth, resolution, and update frequency of the network has high value.”

I ain’t heard any real engineering propositions on this – but I’m still reading the forums to see if anything comes up.

So just my “skeptical” engineering 2 cents – I think the technology stack is great – but its going to require some “smart people” somewhere to extend themselves  – and my guess is that is going to be on specifying the Sensors to be able to make measurements that relate to already defined “Air Quality” thresholds for specific gasses (at an acceptable price point).

[Ed Borden]

Good to have someone like you around to keep the color in the place, Neil :)

In general, I just want to make a few quick statements and will have
to put off answering many of the details later:

1) All of the things that you have noted here that you would have
"hoped" to have had BEFORE we knew if anyone even gave a shit about
this is fantastic, but completely backwards. If we would have
engineered the sensor system, understood all the nuances of every
problem with using these off-the-shelf sensors, and understood
everything about the data model and how we were going to make sense of
a dataset that had never been collected and studied before, well I
THINK you might be getting ahead of our capabilities here. That's the
way large bureaucratic organizations work and how they waste
incredible amounts of resources doing things slowly and poorly and
building things no one cares about. We have raised a relatively
insignificant amount of money and are utilizing the work of many
people who are largely contributing for free and doing something that
is unprecedented. We are contributing a level of work to the
environmental community that would have taken probably millions of
dollars and years to accomplish if we were a non-profit trying to
sustain itself. The trade-off you make is that the process is messy
as hell. Welcome to Sensemakers.

2) We are "crowdsourcing" as much as possible, yes. This is a
community project, developing an open source, open-data system,
selling the hardware AT COST. This is not a business and the
expectations that you might require of a commercial organization
really don't apply here. We do need "smart people", so my suggestion
is that many of the questions you are asking might be right up your
alley to solve yourself and contribute back into the community. And,
many of the questions that you might not be getting answers to are
actually being worked on as we speak by people who are busy as hell
and are still trying to figure this stuff out.

3) Be positive. The attitude we are taking is WHAT CAN WE DO with the
hardware that we've got, not how can we change it to be the same thing
as every other air quality project on the planet solving the same
problems they are. This is how innovation happens.

[Ed Borden]

BTW, the Tortoise and the Hare is bull. We don't sleep.

[Martin Dittus]

On 22 May 2012, at 23:48, NeilH wrote:
> I would have hoped for a “Draft AQE Sensor Specification” to include such items
> 1)Max frequency of update – knowing the architecture even every minute would be high frequency and doable.
> 2)Accuracy of AQE <XXX> sensor reading/units
> 3)Resolution of AQE <XXX> sensor reading/units
> 4)Environmental specifications – can it go outdoors -20C to +70C with rain & ice.

What's involved in getting this data collected? How much of this can be gauged by looking at component data sheets?

Maybe it's something we can do as a group, might be a fun little exercise.

(I expect that some of the details are in flux as long as the design is still changing.)

See also:
http://airqualityegg.wikispaces.com/Hardware-Sensors
https://github.com/jmsaavedra/Air-Quality-Egg

m.

[Cesar Garcia]

We approached this topic briefly yesterday, so here is some initial input about it:

-MQ-7 CO sensor operates using 90 secs + 60 secs warm/cold cycles. So the maximun frecuency of updates would be 1 data for each 150 secs.

Right now, it seems data is uploaded bulk, and some postprocessing should be done to get just the CO data. I think this is by design, to keep data flowing even if nanode reboots or hangs suddenly.

Regarding accuracy, I was told yesterday that official sensors in measurement stations accuracy should be 15% (or below), except for PM 25%.

I think once we get final components, we could check datasheet to collect maximum and minimum operating conditions for each one, keeping the most restrictive set.

Best,

César

m.

--
Cesar García - @elsatch

Ando con encolamiento para responder correos y los proceso lunes, miércoles y viernes. Si es algo urgente/rápido contáctame por Twitter. Gracias!

[Cesar Garcia]

I just have to say, I agree totally about we don't sleep! Sometimes even too literaly ;)