Ballpark ppb numbers

[David Holstius]

Hi all---and super big thanks to Wicked Device, Ed, Joe, and everyone! It's great to see Egg hardware rolling off the line! Woo hoo!

I'm starting this thread to reflect the new firmware, which puts out 'ppb' instead of 'ohms'. I'm seeing some numbers literally off the chart, as in, over 1 billion ppb CO and NO2. That is, over 100%. ಠ_ಠ I'm using the PollEggBus sketch, and seeing this output:

===========================
Egg Bus Address: 0x3
Sensor Address: 00:04:A3:27:B4:31
---------------------------
Sensor Index: 0
Sensor Type: NO2
Sensor Value: 1071225242
Sensor Units: ppb
Raw Value ADC: 124
Raw Value Low Side Resistance: 244200
---------------------------
Sensor Index: 1
Sensor Type: CO
Sensor Value: 1126498304
Sensor Units: ppb
Raw Value ADC: 540
Raw Value Low Side Resistance: 68000

I thought it might be a burn-in issue, so I swapped out the sensors for some ones I've had running on an Egg shield for a while. Lower, but still over 1 billion.

Am I looking at some fixed-point numbers, or maybe a floating point encoding interpreted as an unsigned long or something?

Cheers,
David

[Victor Aprea]

David,

First of all, thanks for putting the system under some lab-based scientific scrutiny. I, for one, really appreciate it. It's not out of the question that there could be a bug in the way I converted from ohms to ppb. The hardware I believe does a good job of accurately measuring resistance over a wide range, as is called for by the CMOS sensors. I've tested this using fixed resistors in place of the sensors, which can be thought of as very sophisticated variable resistors themselves. The translation of the resistance to ppb happens (for the most part) on the Nanode through a fairly involved interrogation process with the Egg Shield. 

I stored sampled tabulations of the curves in the sensor datasheets in the ATtiny88 FLASH memory. In order to make enough samples fit, I had to compress them, and I did so by storing them in 8-bit fixed-point representation. Because of memory limitations, I can't really do any floating point math on the Egg Shield so I had to set up a situation where the Nanode could get the necessary data elements off the shield and do the floating point math there. The gory analysis that I went though to come up with these tabulations is in the attached spreadsheets for NO2 and CO.

The heavy lifting is done in the EggBus library (which I just a little while ago posted an update for to Git-Hub). The Nanode reads back the resistance from the Egg Shield. It then interrogates the mapping table for the sensor to determine the two nearest neighbor samples and performs an interpolation between those points to arrive at the mapped ppb value. I tried to 'oversample' the curves in the region of interest from a health standpoint.

The fact remains that the sensors themselves are not calibrated and the published range of "nominal" resistance values in ambient air (R0) have quite a spread to them. If the data you are describing is attributable to the true variance in the sensors, it would be cool to come up with a zero-ing procedure. The EggBus library and the Egg Shield firmware have support for altering the value of R0 (see the PollEggBus_WriteTest example in the EggBus library). It is plausible to run a sketch that would allow you to effectively "zero" the sensors through some procedure we have yet to define, but I consider it something of an achievement that hardware/firmware/software support that at all.

At any rate, I invite and encourage as many people as possible to review the code base and let me know if something smells funny. The code is not trivial, but I think it's understandable and fairly well partitioned. The overall design is well documented here. 

As a sidebar, inevitably there will be "bugs" in deployment. A cool aspect of the project is that the Eggs are re-programmable "in the field" and the software and hardware are all entirely open so we can squash and/or mitigate those bugs as a community. The fact that it's built on the Arduino ecosystem makes the barrier to re-programming very low (you just need an FTDI cable). The barrier to reprogramming is higher for the Egg Shield but the usual 6-pin ICSP header is populated so that even they can be reprogrammed with a little know-how, but my hope is that the code running on the Egg Shields will "just work."

So, that's my initial brain dump relating to this thread. I hope people find it interesting/informative/useful. I believe this is some really good technology we are developing / have developed here. Together, I'm confident we will work out the kinks and make the most of it!

Regards,

Vic

--

--

Victor Aprea // Wicked Device

victor...@wickeddevice.com

M: 607.745.1515

T: twitter.com/vicatcu/

[Victor Aprea]

One other detail, if anyone is interested I used Plot Digitizer to tabulate the response curves in the data sheets and then did the excel witchcraft previously posted based on that. It's a pretty nifty little program that people might find useful in other contexts as well.

Regards,

Vic

[Victor Aprea]

David,

This has really been bothering me for a couple of days now, and tonight I finally found a couple of problems that may explain it in the EggBus getSensorValue function. I made the fixes and pushed an update to Git-Hub. You can see the changes here. 

There were really two problems working against us here. The first was that I was dividing by R0 twice; once on the Egg Shield, and then again in the getSensorValue function. The "independent variable" reported by the Egg Shield is already RS/R0. The second problem was that my interpolation / extrapolation code was off by one in it's treatment of the "row" variable because I have a post-increment operation on that variable in the while loop argument. So row == 0 could never be true in the loop. 

So... can you see if the results look more reasonable with the latest EggBus library? 

Kind Regards,

Vic

On Thu, Nov 8, 2012 at 1:51 PM, David Holstius <david.h...@berkeley.edu> wrote:

--

[David Holstius]

Vic,

The fact that R0 can be digitally changed in firmware, even if the protocol for doing that has yet to be settled, IMO puts this a league apart from other gas sensor modules. Kudos.

I was curious about the effect of different extrapolation schemes off the low end of the MiCS2710 (NO2) sensor response curve. Here's a little analysis:

<http://rpubs.com/holstius/MiCS2710>

BIG CAVEAT. It's not clear that EITHER method is truly appropriate. Both are extrapolations with no nearby data (even on the spec sheet). If EPA---or anyone else---collects good data in this range, we can figure out what the RIGHT function looks like, at least for one Egg, along with the expected error. Then it'd be a matter of comparing other Eggs with that one to get a handle on Egg-to-Egg variability.

IMO, with the current method, a couple more segments toward the lower end of the mapping table might not hurt, even if it means eliminating a few from the higher end to conserve memory. Not a criticism---we're all learning as we go.

A chip like the Tiny doesn't have room for floating-point emulation, but could logarithms be done accurately enough with some fixed-point math across a couple orders of magnitude?

Glad to be working with you on this!

David

[NeilH]

Hi Guys
Great to hear the hardware/firmware is being put through its paces and to hear what it takes.
As someone who has worked in development teams with layers of firmware and software.
The first pass of firmware is to implement algorithms, which can then be used to run verification tests.
From past experience, "white box" verification tests are a bunch of work - but became very valuable for system stability.
The verification tests are to verify the correctness of the firmware implementation as much as anything else. The are called "white box" as the edges of the algorithms are known and can be verified.
Typically, there are going to be manufacturing steps - how to correlate each individual unique sensor output to traceable units.
The firmware is usually firmly routed in what is needed by the manufacturing steps, and may result in some iterations of algorithms to get it right. As Vic says they are putting in place an Rs/R0 procedure and have some table look up capability. Doesn't need to be much, but usually has to be more than 0 capability. Checkout the Mics2710 section in
http://airqualityegg.wikispaces.com/file/view/e2v+Mics+SensorCharacterizationData.pdf
At this stage in a project it often becomes a challenge in the initial assumptions of the project - can the processor cope with the demands of the project.
Some explanation of fixed point math is here
http://www.eetimes.com/discussion/other/4024639/Fixed-point-math-in-C
There is also fractional arithmetic that doesn't overflow - just looses resolution.
Bugs show up as negative numbers (imagine negative NO2) or larger fast changing random numbers when the sensor input ranges assumption are exceeded. This can be tested by soaking at a higher than normal sampling rate, and ensuring that the sensors encounter a wider range of temperature

For air quality I understood that the NO2 sensor needs to have some sensitivity at about 100ppb. http://airqualityegg.wikispaces.com/file/view/Pollutant+Table.doc

Vic the graphs you present only seem to start at 200ppb - can they be taken to 50ppb. I have no idea what that means in terms of a practical setup?

Dave some great graphs of the MICS2710 relationships, however
IMHO, the MICS2710 data sheet is fairly simplistic in its graphs - it doesn't visually represent the effect of Sr - Sensitivity Factor.
The data sheet table on "Sensitivy Characteristics" gives this as typ 55 min=6 max=100. quite a range.
The Mics2714 sensor has a graph that shows a range from 1ppm/1000ppb to 10ppb. Its a non-linear logarithmic scale.
At 10ppb it intersects with Rs/R0 at what looks like 4, but I don't have a feel for 10ppb means. Does synthetic air have some defined NO2 that is very small.
I thought its important for deep sea divers to have no NO2 in their air - so is that quantifiable as less than some Xx ppb that can be used.
During algorithm verification its been my experience that a feel for the numbers develops. What is possible and what is the limitation of the sensors and systems.
So the verification test could be quite "simplistic" - make measurements in synthetic air (less than 0.???ppb NO2?) and then two other values - say 100ppb and 250 ppb.
Neil

[David Holstius]

Hi Neil,

Thanks for pointing out the alternative curve at:

http://airqualityegg.wikispaces.com/file/view/e2v+Mics+SensorCharacterizationData.pdf

It seems like there's a big difference between the two curves, even though they're both supposed to apply to the MiCS2710---correct? I updated the analysis posted at <http://rpubs.com/holstius/MiCS2710>, with a figure comparing the two. Attached as PNG for the lazy.

David

[NeilH]

Hi David
Could the change in slope of the line be accounted for in the sensitivity factor - which the data sheet says varies between 6 and 100?
A thought - and I think you reference this online - how about framing the graphs in the range of Air Quality interest - 10ppb/0.01ppm to 100ppb/0.1ppm with the upper end at somewhere round the 200ppb/0.2ppm ?
The graphs on this scale show there is a defined relationship, and if just two points are defined for the sensors, then it should be possible to provide some basis for teaching the sensor unit real world measurement units, and then with some arithmetic extrapolate between them.

Neil

[Damon Rand]

Hi all (particularly Victor),

> I'm starting this thread to reflect the new firmware, which puts out 'ppb' instead of 'ohms'.

My egg has been running for a few weeks in a pretty uniform indoor environment with only a few episodes of downtime.
https://cosm.com/feeds/89247

Eggbus RO values..
uint32_t r0_values[2] = {2200, 750000};

I've been seeing fairly consistent values of..
Temp -> Sensible numbers around 25 degrees
Humidity -> Sensible numbers around 44 degrees
CO -> 300,000ppb equals 120,000 ohms
NO2 -> Starting down around 500,000 ohms and progressively increasing to 1.2mill ohms. PPB is now "maxed out" and has read 0 for sometime.

I have just
a) Updated to latest shield firmware picking up an adc change and the NO2 heater power change.
https://github.com/WickedDevice/aqe_sensor_interface_shield/commits/master

b) Swapped out my NO2 and CO sensors for replacement ones (I have several eggs here) to see what happens.

No real change in CO with the new sensor and firmware. PPB of 300,000 still seems very high..

However, PPB for NO2_raw is now back within a sensible-ish range and ppb is no longer zero. It is still climbing though so will leave it and see if it tops out again in the next few days.

Both NO2 and CO still seem high but at least with these latest changes NO2 is reading a ballpark-ish figure of 350ppb right now.

Hope thats a useful datapoint for your work!

PS. Do we know the importance of a fan to these readings? I don't have a fan connected which might be an important factor.

Best wishes,
Damon.