Getting at Rs/Ro through EggBus library

[David Holstius]

Thanks to Sam for putting up the aqe_cosm sketch. I'm using it to pipe to <https://cosm.com/feeds/86281>.

Quick question: what combination of multiplying/dividing values returned by these functions:

EggBus::getSensorIndependentVariableMeasure
EggBus::getIndependentScaler
EggBus::getSensorR0

... gives values in units of Rs/Ro? (For the built-in CO and NO2 sensors, that is.)

Thanks!
David

[Victor Aprea]

David,

IndependentVariableMeasure * IndependentScaler is Rs / R0.

Vic

--

[David Holstius]

Thanks Vic!

So after flashing new firmware (reference below), I went from this (IndependentScaler=0):

Air Quality Egg Shield to Cosm - v0.0.1
=======================================
Initializing network
---------------------------------------
IP: 192.168.1.5
GW: 192.168.1.1
DNS: 192.168.1.1
SRV: 64.94.18.121
---------------------------------------
NO2,0.000000 * 387 = 0.00
CO,0.000000 * 760 = 0.00
Humidity,38.20
Temperature,25.30

.... to this (IndependentVariableMeasure=0):

Air Quality Egg Shield to Cosm - v0.0.1
=======================================
Initializing network
---------------------------------------
IP: 192.168.1.5
GW: 192.168.1.1
DNS: 192.168.1.1
SRV: 64.94.18.121
---------------------------------------
NO2,0.000100 * 0 = 0.00
CO,0.000400 * 0 = 0.00
Humidity,40.00
Temperature,24.50

That is, I'm still getting 0, but for a different reason. I'm now using:

- https://github.com/WickedDevice/aqe_sensor_interface_shield
[commit 0b98d79419481681b519024ae03e9fba0a163bbc]

- https://github.com/jmsaavedra/Air-Quality-Egg/tree/master/libraries/EggBus
[commit 9cda83c29521085aebe38fa6538408a53698154a]

David

[David Holstius]

For what it's worth, my sketch (forked from Sam's) is at:

<https://github.com/holstius/aqe-shield/blob/master/aqe_cosm/aqe_cosm.ino>

[Victor Aprea]

Need to flash both the hex and eeprom files... Might be your problem.

Vic

--

[Victor Aprea]

Also try running the poll egg bus sketch?

Vic

--

[David Holstius]

OK. I have this as the command & flags to flash the .hex:

avrdude -p t88 -c avrisp2 -e -P usb -U flash:w:aqe_sensor_interface_shield.hex

What's the command & flags to flash the EEPROM?

Taking notes at http://www.davidholstius.com/air-quality-egg/. Maybe should be starting a wiki page?

David

--
 
 

[vicatcu]

David,

Sorry I wasn't detailed enough.

avrdude -p t88 -c avrisp2 -e -P usb -U eeprom:w:aqe_sensor_interface_shield.eep

That should do the trick.

Vic

[David Holstius]

Thanks, I flashed the EEPROM. Here's what I now see with PollEggBus. Still 0 for measured value. Also, Ro is the same for both sensors: Ro=4294967295=0xFFFFFFFF. That seems weird, like maybe there's an addressing bug?

===========================
Egg Bus Address: 0x3
Firmware Version: 3
Sensor Address: 00:04:A3:9F:C0:8C
---------------------------
Sensor Index: 0
Sensor Type: NO2
Indep. Scaler: 0.00010000
Table X Scaler: 0.40000000
Table Y Scaler: 1.70000004
Measured Value: 0 => 0.00000000
R0: 4294967295
Implied Resistance: 0.00000000
Table Row 1: [62, 117] => [24.80000114, 198.90000915]
Table Row 2: [75, 131] => [30.00000000, 222.70001220]
Table Row 3: [101, 152] => [40.40000152, 258.39999389]
Table Row 4: [149, 188] => [59.60000228, 319.60000610]
Table Row 5: [174, 204] => [69.59999847, 346.80001831]
Table Row 6: [199, 219] => [79.59999847, 372.30001831]
Table Row 7: [223, 233] => [89.20000457, 396.10000610]
Table Row 8: [247, 246] => [98.80000305, 418.20001220]
Sensor Value: 85.3922653198
Sensor Units: ppb
---------------------------
Sensor Index: 1
Sensor Type: CO
Indep. Scaler: 0.00040000
Table X Scaler: 0.00300000
Table Y Scaler: 165.00000000
Measured Value: 0 => 0.00000000
R0: 4294967295
Implied Resistance: 0.00000000
Table Row 1: [134, 250] => [0.40199999, 41250.00000000]
Table Row 2: [168, 125] => [0.50399999, 20625.00000000]
Table Row 3: [202, 49] => [0.60599999, 8085.00000000]
Table Row 4: [232, 12] => [0.69600000, 1980.00000000]
Table Row 5: [241, 6] => [0.72300000, 990.00000000]
Sensor Value: 122536.7734375000
Sensor Units: ppb

When I unplug either sensor, it's correctly detected as "OPEN CIRCUIT". I swapped both sensors with another pair I had lying around. No change, measured value still reported as 0. I suppose all 4 could be bad.

I hope I'm not doing something really boneheaded like using the wrong version of some library. Should "Firmware Version" be 3? Here's the version info for the shield firmware I just flashed:

aqe_sensor_interface_shield holstius$ git log | head
commit 0b98d79419481681b519024ae03e9fba0a163bbc
Author: vicatcu <victor...@wickeddevice.com>
Date: Sun Oct 28 20:33:43 2012 -0400

added r0 calibration capability (write)

David

[Victor Aprea]

David,

R0 = 0xFFFFFFFF looks to me like an erased EEPROM... order matters with avrdude. First burn the EEPROM, then burn the flash.

avrdude -p t88 -c avrisp2 -e -P usb -U eeprom:w:aqe_sensor_interface_shield.eep

... wait a couple seconds ...

avrdude -p t88 -c avrisp2 -e -P usb -U flash:w:aqe_sensor_interface_shield.hex

See if that helps.

Vic

--

--

Victor Aprea // Wicked Device

victor...@wickeddevice.com

M: 607.745.1515

T: twitter.com/vicatcu/

[David Holstius]

Same thing, Ro = 0xFFFFFFFF and measured value = 0. (Side comment, if
I try to burn the flash before the EEPROM, PollEggBus doesn't even
run, so that's definitely the order I'm doing it in.) Thanks for your
help & I hope I'm not wasting your time. (DAE have this problem?)

I'm using CrossPack for AVR (fresh copy downloaded today, never before
installed on this machine), with its default avrdude.conf, on OSX
Server 10.7.5. avrdude seems happy with the result:

$ avrdude -p t88 -c avrisp2 -e -P usb -U
eeprom:w:aqe_sensor_interface_shield.eep

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9311
avrdude: erasing chip
avrdude: reading input file "aqe_sensor_interface_shield.eep"
avrdude: input file aqe_sensor_interface_shield.eep auto detected as Intel Hex
avrdude: writing eeprom (8 bytes):

Writing | ################################################## | 100% 0.01s

avrdude: 8 bytes of eeprom written
avrdude: verifying eeprom memory against aqe_sensor_interface_shield.eep:
avrdude: load data eeprom data from input file aqe_sensor_interface_shield.eep:
avrdude: input file aqe_sensor_interface_shield.eep auto detected as Intel Hex
avrdude: input file aqe_sensor_interface_shield.eep contains 8 bytes
avrdude: reading on-chip eeprom data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 8 bytes of eeprom verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.


$ avrdude -p t88 -c avrisp2 -e -P usb -U flash:w:aqe_sensor_interface_shield.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9311
avrdude: erasing chip
avrdude: reading input file "aqe_sensor_interface_shield.hex"
avrdude: input file aqe_sensor_interface_shield.hex auto detected as Intel Hex
avrdude: writing flash (4796 bytes):

Writing | ################################################## | 100% 1.66s

avrdude: 4796 bytes of flash written
avrdude: verifying flash memory against aqe_sensor_interface_shield.hex:
avrdude: load data flash data from input file aqe_sensor_interface_shield.hex:
avrdude: input file aqe_sensor_interface_shield.hex auto detected as Intel Hex
avrdude: input file aqe_sensor_interface_shield.hex contains 4796 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 1.37s

avrdude: verifying ...
avrdude: 4796 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.

[Victor Aprea]

David,

 

It's no trouble. You raised some doubt in my mind, so I deleted my local files and downloaded them from github.

 

AQE Shield HEX and EEP files from: https://github.com/WickedDevice/aqe_sensor_interface_shield

EggBus Library from: https://github.com/jmsaavedra/Air-Quality-Egg

 

Re-burned the shield. Re-uploaded the PollEggBus example. Plugged in a couple resistors in place of the sensors. Got the following output:

 

Egg Bus Address: 0x3
Firmware Version: 3

  Sensor Address: 00:04:A3:9F:AE:57

---------------------------
  Sensor Index: 0
    Sensor Type: NO2
   Indep. Scaler: 0.00010000
  Table X Scaler: 0.40000000
  Table Y Scaler: 1.70000004

 Measured Value: 245909 => 24.59089851
              R0: 2200
Implied Resistance: 54099.97656250

     Table Row 1: [62, 117] => [24.80000114, 198.90000915]
     Table Row 2: [75, 131] => [30.00000000, 222.70001220]
     Table Row 3: [101, 152] => [40.40000152, 258.39999389]
     Table Row 4: [149, 188] => [59.60000228, 319.60000610]
     Table Row 5: [174, 204] => [69.59999847, 346.80001831]
     Table Row 6: [199, 219] => [79.59999847, 372.30001831]
     Table Row 7: [223, 233] => [89.20000457, 396.10000610]
     Table Row 8: [247, 246] => [98.80000305, 418.20001220]

    Sensor Value: 197.9429626464

    Sensor Units: ppb
---------------------------
  Sensor Index: 1
    Sensor Type: CO
   Indep. Scaler: 0.00040000
  Table X Scaler: 0.00300000
  Table Y Scaler: 165.00000000

 Measured Value: 342 => 0.13679999
              R0: 750000
Implied Resistance: 102599.99218750

     Table Row 1: [134, 250] => [0.40199999, 41250.00000000]
     Table Row 2: [168, 125] => [0.50399999, 20625.00000000]
     Table Row 3: [202, 49] => [0.60599999, 8085.00000000]
     Table Row 4: [232, 12] => [0.69600000, 1980.00000000]
     Table Row 5: [241, 6] => [0.72300000, 990.00000000]

    Sensor Value: 94875.0078125000
    Sensor Units: ppb

I'm struggling to understand what you could be doing differently (your avrdude output looks good)...  Another thing you can try is using the PollEggBus_WriteTest example to change the R0 values that way. NO2 should be set to 2200, and CO should be set to 750000. Just change the example from:

 

uint32_t r0_values[2] = {1234567, 7654321};

 

to

 

uint32_t r0_values[2] = {2200, 750000};

 

Run that sketch once, then switch back to the regular PollEggBus sketch and see if things look better.

 

Regards,

 

Vic

[David Holstius]

OK, thanks! I flashed the EEPROM too. Here's what I see with PollEggBus. Still 0 for measured value. Also, Ro is really high---and it's the same for both sensors: Ro=4294967295. That seems weird, like maybe there's an addressing bug?

> --
>
>

[Ken Boak]

David,

 

The value returned for R0 looks as though it is equal to FFFFFFFF

 

This suggests that the EEPROM still contains F's - as though it has not been successfully programmed in those locations.

 

Perhaps we need details of how to program R0 maintained on a wiki page.

 

 

 

Ken.
             

   

[Victor Aprea]

Have you tried the PollEggBus_WriteTest sketch pet my previous suggestion?

Vic

--

[David Holstius]

That fixed it! Just got out of meetings & was able to test. Thank you. Below is what I now see.

Maybe the line in PollEggBus_WriteTest should be

uint32_t r0_values[2] = {2200, 750000};

... by default? So that people can just run it if they're having trouble like this.

Alternatively, what if there were an auto-zeroing sketch to estimate Ro---as the value of Rs in a "clean" environment---and set it at the same time? The sketch would just need to iteratively set Ro, maybe at 5 minute intervals, so that Rs/Ro approaches 1. I'm hypothesizing it would converge pretty quickly in a stable environment. We could try it to see how long it takes.

===========================
Egg Bus Address: 0x3
Firmware Version: 3
Sensor Address: 00:04:A3:9F:C0:8C
---------------------------
Sensor Index: 0
Sensor Type: NO2
Indep. Scaler: 0.00010000
Table X Scaler: 0.40000000
Table Y Scaler: 1.70000004

Measured Value: 321477 => 32.14769744
R0: 2200
Implied Resistance: 70724.93750000

Table Row 1: [62, 117] => [24.80000114, 198.90000915]
Table Row 2: [75, 131] => [30.00000000, 222.70001220]
Table Row 3: [101, 152] => [40.40000152, 258.39999389]
Table Row 4: [149, 188] => [59.60000228, 319.60000610]
Table Row 5: [174, 204] => [69.59999847, 346.80001831]
Table Row 6: [199, 219] => [79.59999847, 372.30001831]
Table Row 7: [223, 233] => [89.20000457, 396.10000610]
Table Row 8: [247, 246] => [98.80000305, 418.20001220]

Sensor Value: 237.6009826660

Sensor Units: ppb
---------------------------
Sensor Index: 1
Sensor Type: CO
Indep. Scaler: 0.00040000
Table X Scaler: 0.00300000
Table Y Scaler: 165.00000000

Measured Value: 356 => 0.14240000
R0: 750000
Implied Resistance: 106800.00000000

Table Row 1: [134, 250] => [0.40199999, 41250.00000000]
Table Row 2: [168, 125] => [0.50399999, 20625.00000000]
Table Row 3: [202, 49] => [0.60599999, 8085.00000000]
Table Row 4: [232, 12] => [0.69600000, 1980.00000000]
Table Row 5: [241, 6] => [0.72300000, 990.00000000]

Sensor Value: 98838.2421875000
Sensor Units: ppb

[Victor Aprea]

David,

Awesome! Yea that would be a good idea. I don't think there would be any need to write  the value back until convergence was determined.

You want to avoid writing to the EEPROM too frequently. It can only endure 100,000 writes (guaranteed).

I think a "sensor zero sketch" is not terribly difficult to write. I would propose this would be a command/response serial terminal application that could show you what sensors are present so that you could identify the one you are targeting for zeroing.

You would type something like "scan" to list the sensors with handles to them.

Then you would type something like "choose 23" to select sensor with handle 23 for zeroing.

Then you would type something like "stat" periodically to read running statistics  for the chosen sensor (moving average,  standard deviation, current value) of (independent measure * independent scaler * R0) = Rs.

When you are satisfied it has converged, you would type something like "commit 2200" to write 2200 as R0 for that sensor.

You could envision an automation layer built on to of this basic concept with something like a Processing application running on a PC.

I still have a bunch of other of software to write and test for add on modules, but this seems within reach.

Thoughts?

Regards,

Vic

--

[netnut]

So this must be my issue as well. Because any amount of reseating of the sensors or the shield did not impact the result for the NO2 and CO sensors which always returned zero.

I need a pointer to the programming model so that I can get going with these new sketches. is there a primer somewhere ? I have downloaded the github repo and am also the proud owner of an ftdi cable.

Sanjay

[Ken Boak]

Vic, David,

 

What assumptions were made to use 750,000 as the R0 value for the CO sensor?

 

Was this a manufacturer's typical value, or just a mid-range value of the range in the datasheet?

 

I think David's idea of zeroing the sensor in clean air, until convergence to a stable value would be preferable,

 

In the example given this would reduce R0 to closer to 150K ohms and make the reading for clean air CO much closer to what is expected indoors.

 

Whilst this may appear a kludge to fix the readings to what we expect, I think it would be a better starting point, for the newcomer.

 

 

regards

 

 

 

Ken

[David Holstius]

Even simpler might be to sample Rs for five minutes, or until the mean is stationary.

[vicatcu]

I've written up a quick blog post that summarizes setting your R0 values using the EggBus examples. http://blog.wickeddevice.com/?p=385

Let me know if something is unclear or needs more details.