Electronics :: Egg Shield + CMOS Gas Add-On Module :: Status Update / Peer Review

[vicatcu]

Hey all,

For those that have been following the electronics development (or are just interested), I've been working a bunch on (and have been pushing commits to Git Hub for) both the Egg Shield and the Add On CMOS Sensor module periodically over the last few weeks. I think we are on the verge of being ready to send these designs out for a prototype batch. I would really appreciate it if any fellow electronics geeks in the group would be willing to give these designs a decent review before we have prototypes made if possible. If anything is needs clarification, please ask back to this thread and I will try and respond quickly and incorporate changes as necessary throughout the week.

I've also (very recently) created Solderpad projects for both of these board designs, so you can view the Eagle exported png images of the schematics and layout in a web browser. This should supersede PDFs (which are much more of a pain to generate). This is my first foray into Solderpad so I'm still learning what its capable of, but my first impressions are generally positive (plays nice with GitHub anyway). They appear to have some way of representing the bill of materials in there too, but I haven't gotten around to figuring that out yet. At any rate the project pages are here:

http://solderpad.com/vicatcu/aqe-sensor-interface-shield/

http://solderpad.com/vicatcu/aqe-cmos-gas-add-on/

I'd like to get these boards out for prototype fabrication by the afternoon of Thursday May 31st at the latest, so it would be great if review comments could be submitted by Thursday May 31st at 8AM Eastern (but sooner is better!).

Thanks,

Vic

[NeilH]

Hi great to have the diagrams put out to review. So (with an absence of a design specification) starting from 

“1) Outdoor sensors:  A small electronic sensing system plug into the wall and sits outside your home taking regular readings.  It has an RF transmitter, which sends the data wirelessly …..“

[BTW Wireless – to me - implies there might be a time it runs off batteries and where possible plan to have a good battery life. ]

General: 

G1- Mechanical? What is the mechanical configuration – is it meant to fit into something and go outdoors and have the sensors in air with the rest of the circuit protected from dust and moisture.

G3-Sensors Power Managed. No sensor power can be switched, but data sheet suggests switching it on to conserve life of sensor. 

G4- Physical – What is physical configuration, Looks like CMOS Gas Add-on is just stuck into Sensor Interface Shield

-G4A how do the boards stay stuck together – is it friction of connector.

-G4B how do the CMOS Gas Add on sensors get addressed over the TWI/I2C bus, or know what slot they are in. Does the board/code have to be compiled to say which slot they are in, which would seem to mean that there is danger of cards (Tiny24) with the same TWI/I2C address responding at the same time.

G5 Can all the devices part numbers be identified eg no power regulator is identified U1 or U2.

Shield Board

S1 – Pullups on SDA/SCL ? Is this on the mega328 port pullups or on the shield  board.

S2-  PCA9540B is specified for VddMax=3.6V but Vcc is 5V

S3 - What is the reason for the PCA9540BD I2C Channel Mux? It would seem that with only 4 expansion slots, that the  mega328P SCL(C5)/SDA(C4)) should cope.

S4 – should heater V be switched to design for more stable heater sensitivity and power savings if battery driven. 

Sensor Powering (from An2 FAQ) - 40mW no drift over 6000Hrs (250days) – to me implies a lifetime target of 6000hrs.

Rh(e2v mics2710) range 66-73ohms @1.7V gives 44-40mW (target is 43mw so excellent)

U2Vreg has capability to switch, but needs port.

S5 What are the values of series resistors R1 R2 R3. Mics2710 sense R0 is from 0.8 to 8Kohm, Sensitivity factor is 6-100

Not able to analyze the circuits. Need to do paper analsis for air quality health threshold of NO2 100ppb.

References:

Mother Board Arduino UNO R1/R2 – Mega328P  (R3 shipping – 5V)

http://arduino.cc/en/Main/ArduinoBoardUno

(Some history http://www.ladyada.net/library/arduino/unofaq.html)

[Victor Aprea]

Neil,

Thanks, as always, for the great feedback. I don't think I need to make any changes after consideration, but if others feel strongly that I've glazed over something important, please speak up and we can re-evaluate. I'll respond to each review comment inline below.

On Mon, May 28, 2012 at 7:02 PM, NeilH <nei...@sonic.net> wrote:

Hi great to have the diagrams put out to review. So (with an absence of a design specification) starting from 

“1) Outdoor sensors:  A small electronic sensing system plug into the wall and sits outside your home taking regular readings.  It has an RF transmitter, which sends the data wirelessly …..“

[BTW Wireless – to me - implies there might be a time it runs off batteries and where possible plan to have a good battery life. ]

Battery powered was off the table from early on. I'm not going to go into it again here, but there are a number of reasons that is the case. I recommend searching the group posts for it. Fundamentally it has to do with the sensor power consumption and reading consistency.

 

General: 

G1- Mechanical? What is the mechanical configuration – is it meant to fit into something and go outdoors and have the sensors in air with the rest of the circuit protected from dust and moisture.

The mechanical configuration is still under development. Suffice it to say it will need to accommodate the electronics since they are first out of the gate. I expect the outdoor enclosure will have a means to mount the add-on sensors to the interior walls or something using the registration holes I put in the board.

 

G3-Sensors Power Managed. No sensor power can be switched, but data sheet suggests switching it on to conserve life of sensor. 

I decided software complexity this would add was simply not worth it. The sensors need to "warm up" and I didn't want to deal with having to "manage" the sensor too much. The dangers of over-optimizing too soon and all that. Out of curiosity, can you provide a pointer to which datasheet you are referring and which page number?

 

G4- Physical – What is physical configuration, Looks like CMOS Gas Add-on is just stuck into Sensor Interface Shield

-G4A how do the boards stay stuck together – is it friction of connector.

There will be a cable that runs from the Shield to the Add-on board. I believe the connectors are locking. Both sides are TE Connectivity: 1775470-4 and 440055-4 respectively. The intended cables are like these..

 

-G4B how do the CMOS Gas Add on sensors get addressed over the TWI/I2C bus, or know what slot they are in. Does the board/code have to be compiled to say which slot they are in, which would seem to mean that there is danger of cards (Tiny24) with the same TWI/I2C address responding at the same time.

I tried to explain this in a separate thread. You should be able to plug any sensor module into any "slot." The base controller (Nanode/Arduino) will discover which sensors are present by polling for predefined I2C addresses. The sensor boards will store enough meta-data about themselves that the base controller will be able to know what's out there. I2C addresses will be allocated by "sensor type" so that different sensors will have different addresses. Two sensors with the same address are allowed as long as they are plugged into separate branches of the I2C bus (which is the whole point of the I2C Multiplexer).

 

G5 Can all the devices part numbers be identified eg no power regulator is identified U1 or U2.

I think what you're asking for here is a bill of materials. I haven't got that done yet, but am working on it. The regulators are those that were suggested on a separate thread (Microchip TC1071VCT713).

 

Shield Board

S1 – Pullups on SDA/SCL ? Is this on the mega328 port pullups or on the shield  board.

I thought I put a note in the schematics that the Nanode board will have the I2C pull-ups integrated (i.e. they will be external and 1.8kOhm).

 

S2-  PCA9540B is specified for VddMax=3.6V but Vcc is 5V

I don't think that's true. Table 6 on page 11 of the datasheet provides static characteristics for VDD 3.6V to 5.5V. So 5V should work fine right?

 

S3 - What is the reason for the PCA9540BD I2C Channel Mux? It would seem that with only 4 expansion slots, that the  mega328P SCL(C5)/SDA(C4)) should cope.

See prior comments above. It will allow you to say plug in two separate O3 sensors such that their I2C addresses won't be in conflict as long as you put them on separate branches.

 

S4 – should heater V be switched to design for more stable heater sensitivity and power savings if battery driven. 

Sensor Powering (from An2 FAQ) - 40mW no drift over 6000Hrs (250days) – to me implies a lifetime target of 6000hrs.

Rh(e2v mics2710) range 66-73ohms @1.7V gives 44-40mW (target is 43mw so excellent)

U2Vreg has capability to switch, but needs port.

See previous discussion - the sensors need to be kept in a stable condition, and battery powered operation is outside the scope of the current design. 

 

S5 What are the values of series resistors R1 R2 R3. Mics2710 sense R0 is from 0.8 to 8Kohm, Sensitivity factor is 6-100

Not able to analyze the circuits. Need to do paper analsis for air quality health threshold of NO2 100ppb.

The resistor values are as yet unspecified. The Sensor board will accommodate any of the E2V gas sensors. The resistor values must be chosen to best support the sensor being mounted. I could actually use some help coming out with a good set of values for the sensors we are using. The way it's wired is so that the lower half of the voltage divider can be set to any of:

• R1
• R1 + R2
• R1 + R2 + R3

By selectively grounding the taps in the series chain (while keeping the other taps at high impedance). The idea for this is to allow the microcontroller to shift the ADC range to deal with the non-linearity of the sensors' resistance vs concentration plots.

Regards,

Vic

--

Victor Aprea // Wicked Device

victor...@wickeddevice.com

M: 607.745.1515

T: twitter.com/vicatcu/

[NeilH]

Hi Vic

Appreciate the detailed responses.  I haven't followed  any of the threads. To be able to get good feedback you've gotta capture the details so they can be easily represented and analyzed. 

PCA9540B - ok I agree, I had only found table 5. Weird there is a Table 5 and also a Table 6 with different Maximiums, so they actually mean a range that characterizes the responses I guess.

I'd be interested in the R1,R2,R3 values for specific defined sensors when you put them out. 

Kinda a telling these haven't been done first.

It seems to me they are critical to there being real readings for air quality thresholds. Real air quality readings depend on it.

What I do is  "edges in" design - reduce overall project risk - pick the most difficult unknown edges that are critical to the project first and verify they can work.  

Good luck with it. 

[Joseph Saavedra]

Thanks for your input, as always, Neil.

Concerning R1-R3, what Dirk means is that we have just not *finalized* the values. We're working with air quality researchers from CU Boulder, as well as having prototyped extensively here with the E2V sensors.  You need not worry. The bottom line is that as long as these values are consistent for every egg module produced (obviously they will all be identical), values recorded will be consistent and comparable. 

Just wanted to chime in, thanks for all the feedback!

joe

_ _ _
Joseph Saavedra
Technologist, Developer

http://citizensensor.cc

http://jos.ph

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

[NeilH]

Hi Joe

Yup since its open design - a peer review requested  - and these values are not finalized and in the open  - I'm definitively professionally concerned.

In my opinion - you are raising the risk of there being poor quality measurements by pushing this to the end of the project or even out to when customers buy the product. And resistors values are real devices and can't be downloaded.

Its not difficult calculations - just requires detailed analysis - but its critical to the understanding of what are viable useful air quality ranges.

What for specific sensors is the measurable range of detectable gasses - which is defined by the selected physical sensor in conjunction with  R1-R3 %range across temperature, Vref %range across temperature, and ADC resolution. 

The calculations should demonstrate that the measurable rangers are viable in the context of the target air quality ranges - if they don't make sense, then it could require a change of something like the ADC resolution or Vref accuracy to make the measurable ranges viable.

These can often be small cost increments in parts - say ~$or2  for the CMOS Sensors board for ADC10bits to ADC14bits - but high cost to a project.

Just my two cents.

Cheers

Neil

[Joseph Saavedra]

Hi Neil,

So sorry i'm abroad in south america with super limited internet (and time). I'll respond quickly to this and then later to your more recent message.

i understand your professional concern. Here's the reality: we have made this circuit work great, however it was without the most recent additions of the i2c mux, a new vReg, and the I2C bus among other changes. I want to test this new board as a PCB before finalizing the resistor values, and i want to do so with the power supply we'll be shipping with the AQE units.

As I mentioned, I'm abroad, maybe some others can do calculations, but you can look at previous revisions of the PCB on github to see the R values we have been working with.

Thanks again for your input and participation!

joe

[NeilH]

Hello Joe

Thanks for the update. 

Hope you are having a good trip.

Let me summarize what I see at the moment

1) The sensor hardware is pretty simple and seems like it should work, or be pretty simple to make to work. 

However no system level analysis is present, and figuring it from distributed “streams of consciousness” on other boards is not for me

Taking a professional standard, its great to see the hardware as open source, however 

1A) the hardware put out for review is not well defined, no BOM made available, and incomplete description of hw can be used. 

For an independent peer review – not some one involved in the internal processes -  the hardware needs a greater level of description. So its seems valid and something is moving forward.

1B) The method of making it available for review through http://solderpad.com/vicatcu/aqe-sensor-interface-shield/ is like peaking through a keyhole at the circuit diagram. Shows there is something, and if a competent engineer is working on it, it’s a reasonable deliverable.

1C) A review of the critical real sensor data flow,  from raw physical measurement to a measureable unit is not possible. Resistor values – value and type - are missing. 

The analog data path seems to be ratio metric and probably workable

Personally (as with a lot of other people) I’m donating my time on this and its up to the designers to provide all the details needed for a review of sensors.

I hope you guys are doing a circuit and system verification and also manufacturing calibration. 

Otherwise, in my opinion, the data is going to be relatively worthless.

A wish list of stuff that seems to be missing :) (maybe next release I guess).

1) Put LEDs on the CMOS-gas-add-on so it is easy to see if the boards are working.

2) Make plug-able boards addressable – there are 4 slots - so that a user - local or remote - can see what board is in what slot, with what sensor. Make it simple and foolproof. 

If I understand the way it is right now with the I2C mux the PCA9540B  – a remote user can’t ask for the card in “slot2” to be pulled. 

A  local user could have 4 boards in the slots, and only three report and they wouldn’t know which board is faulty. Especially with no leds.

For two boards of the same type, if they are put in the first two or last two slots, whether they will actually work  is indeterminate.

3) Support extending the life of sensor by making it switchable and using a series resistor for the heater element.

“Long-term tests have shown that at 40 mW, no drift is measurable over 6000 hours.” (which is 250days)

(see App Notes mics_an2-MICS FAQ  at http://airqualityegg.wikispaces.com/Hardware-Sensors 

(http://airqualityegg.wikispaces.com/file/view/mics_an2+-+MICS+FAQ.pdf)

[Victor Aprea]

Neil,

1A) the hardware put out for review is not well defined, no BOM made available, and incomplete description of hw can be used. 

For an independent peer review – not some one involved in the internal processes -  the hardware needs a greater level of description. So its seems valid and something is moving forward.

I'm working on the BOM and will be publishing it to Solderpad in the near future. This is an iterative and interactive process (think spiral, not waterfall). Please try and be patient as the design evolves through the community process... me asking for a peer review from the group doesn't mean the design phase is complete and final. Some aspects of the BOM are not concrete, as I've said before, since the board is meant to accept different sensors, and each sensor may need different resistor values for the range selection chain (TBD).

 

1B) The method of making it available for review through http://solderpad.com/vicatcu/aqe-sensor-interface-shield/ is like peaking through a keyhole at the circuit diagram. Shows there is something, and if a competent engineer is working on it, it’s a reasonable deliverable.

Solderpad has the actual Eagle CAD source files there too (stored in a git repository), the in-browser viewer is just a PNG rendering of those CAD files. If you want to see more detail  (higher resolution) install Eagle freeware and open the source files...

 

1C) A review of the critical real sensor data flow,  from raw physical measurement to a measureable unit is not possible. Resistor values – value and type - are missing. 

The analog data path seems to be ratio metric and probably workable

Personally (as with a lot of other people) I’m donating my time on this and its up to the designers to provide all the details needed for a review of sensors.

I hope you guys are doing a circuit and system verification and also manufacturing calibration. 

Otherwise, in my opinion, the data is going to be relatively worthless.

I, for one, appreciate the time you have been donating so generously, so thanks a ton! Please keep it up. As I have said before manufacturing calibration has never been in the budget and planning/schedule for this phase of the project. The hardware doesn't preclude the possibility of calibration / re-calibration (there's plenty of non-volatile memory in the system for example). I think it's something we will without a doubt revisit (repeatedly) in the future, but it's not productive to dwell on it right now, imho. To deem the data worthless before it even exists, I think is being a tad disrespectful to the subset of this community that is working on addressing the "calibration problem" at the application layer. You are, of course, entitled to your opinion.

A wish list of stuff that seems to be missing :) (maybe next release I guess).

I have dragged my feet in sending the designs out for prototype, so I can in fact incorporate some changes before doing so still. Silver lining I guess.

 

1) Put LEDs on the CMOS-gas-add-on so it is easy to see if the boards are working.

Sure, how about a power red power LED and a green status LED that can blink whenever the sensor board gets polled by the master board?

 

2) Make plug-able boards addressable – there are 4 slots - so that a user - local or remote - can see what board is in what slot, with what sensor. Make it simple and foolproof. 

I need you to explain this concept better please. Right now the design is completely agnostic of which slot the sensor modules are plugged into so long as they are all different sensor types. If you have two sensors of the same type, that is also supported, so long as you plug one of them into Bus 1 and the other into Bus 2. I don't want to add wires to the cable, and I don't want to lose sight of the fact that while there are four connectors on the shield, the design supports the use of something like the Seed Studio Grove I2C Hub as a means of adding more sensors to the bus.

 

If I understand the way it is right now with the I2C mux the PCA9540B  – a remote user can’t ask for the card in “slot2” to be pulled. 

The design is not "hot pluggable." If you want to change which sensors are plugged in, you need to power down the Sensor Box, plug in the sensors where you want them, and then power up. Again, think of these slots as logical attachment points to two Egg Bus address sub-domains. The master board will figure out what Sensor Modules are attached through a discovery mechanism that it can go through once during start-up. The point of the PCA9540B is just to provide for two separate I2C address domains.

 

A  local user could have 4 boards in the slots, and only three report and they wouldn’t know which board is faulty. Especially with no leds.

For two boards of the same type, if they are put in the first two or last two slots, whether they will actually work  is indeterminate.

The Sensor Box doesn't have a User Interface - it's dumb by design. I think incorporating LEDs into the sensor modules as you've suggested is a really good idea, though, to give some minimal diagnostic feedback at the end points.  Users simply need to be smart enough to plug sensors of the same type into separate sides of the Bus, as I said earlier. That can be debated at length, but there's a fundamental trade-off between flexibility and resilience to users at play here, and I leaned toward flexibility in this instance. It's still unclear to me to what extent the "multiple sensors of the same type in a single sensor box" scenario is even realistic, though it is at least supported right now.

 

3) Support extending the life of sensor by making it switchable

I can't see the point in making the voltage regulators software switchable, based on this paragraph from the same app note you referenced:

Heater voltages above the specified maximum rating will 

destroy the sensor due to overheating. Heating by PWM 

between 0 and 5 V has been tested until 100,000 Hz and 

destroys the sensor. The heating voltage must be pure 

DC voltage.

 

and using a series resistor for the heater element.

“Long-term tests have shown that at 40 mW, no drift is measurable over 6000 hours.” (which is 250days)

(see App Notes mics_an2-MICS FAQ  at http://airqualityegg.wikispaces.com/Hardware-Sensors 

(http://airqualityegg.wikispaces.com/file/view/mics_an2+-+MICS+FAQ.pdf)

 

I wasn't quite sure how to reconcile this note with the individual sensor datasheets. The heating elements themselves are characterized as having a min/max operating resistance. How does a series resistor improve matters and how would you "appropriately size" it? I could add the a spot for another 0805 series resistor, but I would really like to understand what its role actually is and if its the correct thing to do or not. Looking at page 15 of the Dev Kit User's Guide it seems like they make reference to 82 ohms to get 76mW and (51 + 82 =) 133 ohms to get 43mW but they are also running the whole thing off of 5V.

In their context, lets take the MiCS-2710 whose datasheet suggests a heating voltage of 1.7, a typical heater resistance of 66 ohms, and a typical heater power of 43mW. So they would invoke a 133 ohms series resistance to get that. The voltage drop over the 66 ohm heater would be 5V * 66 ohms / 199 ohms = 1.65V. Switch over to the MiCS-5525 that has a heating voltage of 2.4V, a typical heater resistance of 74 ohms, and a typical heater power of 76mW. So they would invoke an 82 ohm series resistor. The voltage drop over the 74 ohm heater in that case is 5V * 74 ohms / 156 ohms = 2.37V. 

In our case we are using a regulator to drive the voltage across the heater directly... so what's the difference? I thought using regulators would be a more reliable means of creating the operating voltage drop across the heater called for by the datasheet. It's certainly possible I have misinterpreted the datasheets.

I've posted a question to the electrical engineering stack exchange to see if anyone there has any thoughts on the matter (feel free to up-vote to give the question traction).

Cheers,

Vic

P.S. I would love to hear feedback from others besides Neil as well; good, bad, or otherwise. 

--

Victor Aprea // Wicked Device

victor...@wickeddevice.com

M: 607.745.1515

T: @vicatcu

[David Holstius]

Hi Vic, Joe, et al: I am *more* than happy to run alpha or beta
designs through a quick and dirty response-check protocol. I've got
access to a fume hood, calibration gases, etc., and I can cover the
cost since it's related to my thesis work and a grant I'm funded on.
There should be some variation from sensor to sensor, and from module
to module given tolerances of resistors, etc. It'd be very interesting
to quantify that and, I think, valuable for maximizing the collective
information from locally deployed sets of Eggs. If people can put a
prior on the likely distribution of the responses to a given stimulus
then that's very useful.

I wouldn't necessarily call it "calibration". I'm investing in a bunch
of these, and I'm not expecting perfect performance out of the gate or
even steady performance over time. I work with a bunch of scientists,
statisticians, and engineers. Some of them have concerns similar to
what Neil has put forth. Some of them are more excited about abundant
data, even with all the uncertainties. But, most agree that some sort
of bench testing would multiply whatever value there is. So, again,
I'm more than happy to do it!

[NeilH]

Hi Vic

thanks for the fast response. 

Will look out the eagle app 

see inline

Neil

On Friday, June 1, 2012 6:52:20 PM UTC-7, vicatcu wrote:

Neil,

1A) the hardware put out for review is not well defined, no BOM made available, and incomplete description of hw can be used. 

For an independent peer review – not some one involved in the internal processes -  the hardware needs a greater level of description. So its seems valid and something is moving forward.

I'm working on the BOM and will be publishing it to Solderpad in the near future. This is an iterative and interactive process (think spiral, not waterfall). Please try and be patient as the design evolves through the community process... me asking for a peer review from the group doesn't mean the design phase is complete and final. Some aspects of the BOM are not concrete, as I've said before, since the board is meant to accept different sensors, and each sensor may need different resistor values for the range selection chain (TBD).

Fantastic - sorry not meaning to sound impatient - BTW waterfall applies to hardware when it gets pushed into manufacturing. 

Always nice to have some visibility of where it is in the process especially with "spiral" processes - sometimes of course it looks like a dog chasing its tail:).

 "spiral" is good for software that can be downloaded or pushed out.

 

1B) The method of making it available for review through http://solderpad.com/vicatcu/aqe-sensor-interface-shield/ is like peaking through a keyhole at the circuit diagram. Shows there is something, and if a competent engineer is working on it, it’s a reasonable deliverable.

Solderpad has the actual Eagle CAD source files there too (stored in a git repository), the in-browser viewer is just a PNG rendering of those CAD files. If you want to see more detail  (higher resolution) install Eagle freeware and open the source files...

OK I guess I'll have to load it.  I'm really careful about loading up yet another app. I have two pages on Start->All programs.

My cct package is  www.numberone.com

 

 

1C) A review of the critical real sensor data flow,  from raw physical measurement to a measureable unit is not possible. Resistor values – value and type - are missing. 

The analog data path seems to be ratio metric and probably workable

Personally (as with a lot of other people) I’m donating my time on this and its up to the designers to provide all the details needed for a review of sensors.

I hope you guys are doing a circuit and system verification and also manufacturing calibration. 

Otherwise, in my opinion, the data is going to be relatively worthless.

I, for one, appreciate the time you have been donating so generously, so thanks a ton! Please keep it up. As I have said before manufacturing calibration has never been in the budget and planning/schedule for this phase of the project. The hardware doesn't preclude the possibility of calibration / re-calibration (there's plenty of non-volatile memory in the system for example). I think it's something we will without a doubt revisit (repeatedly) in the future, but it's not productive to dwell on it right now, imho. To deem the data worthless before it even exists, I think is being a tad disrespectful to the subset of this community that is working on addressing the "calibration problem" at the application layer. You are, of course, entitled to your opinion.

Yup - be interesting to see if anybody puts up some algorithms for this.

A wish list of stuff that seems to be missing :) (maybe next release I guess).

I have dragged my feet in sending the designs out for prototype, so I can in fact incorporate some changes before doing so still. Silver lining I guess.

 

1) Put LEDs on the CMOS-gas-add-on so it is easy to see if the boards are working.

Sure, how about a power red power LED and a green status LED that can blink whenever the sensor board gets polled by the master board?

Fantastic.  Personally, I always find LEDs a really good indicator of health of the big system.

RED is often attributed to a failure. Would it work to have the RED led come on when the board is powered, and then turn off  or possibly go into a slow flash when the board is not doing anything. Say 2sec on/2sec off.

If there is anything wrong (analog sense value out of range) then the board could do a fast red flash 

Then when a reading is taken (board polled) the GREEN led comes on for 5 seconds. I know that is a long time for a processor - but its a nice human time to indicate that  something happened.

 

2) Make plug-able boards addressable – there are 4 slots - so that a user - local or remote - can see what board is in what slot, with what sensor. Make it simple and foolproof. 

I need you to explain this concept better please. Right now the design is completely agnostic of which slot the sensor modules are plugged into so long as they are all different sensor types. If you have two sensors of the same type, that is also supported, so long as you plug one of them into Bus 1 and the other into Bus 2. I don't want to add wires to the cable, and I don't want to lose sight of the fact that while there are four connectors on the shield, the design supports the use of something like the Seed Studio Grove I2C Hub as a means of adding more sensors to the bus.

From a user point of view the system is configurable (with power off) - boards can be plugged in/out

However I didn't get your initial concept - 4 sockets on the shield - divided into two controllable busses - which can be further expanded.

So I'm wondering if something isn't working, how is the user expected to check the configuration.

The  Arduinon/nano board has user interfaces (debug terminal) and I'm imagining there will be methods of  listing the configuration - 

but how does the user (installer) debug the configuration if there is a problem

eg two boards of the same type installed on  the same "Bus"

or there are 4 boards plugged in - but only one three show up.

 

 

A  local user could have 4 boards in the slots, and only three report and they wouldn’t know which board is faulty. Especially with no leds.

For two boards of the same type, if they are put in the first two or last two slots, whether they will actually work  is indeterminate.

The Sensor Box doesn't have a User Interface - it's dumb by design. I think incorporating LEDs into the sensor modules as you've suggested is a really good idea, though, to give some minimal diagnostic feedback at the end points.  Users simply need to be smart enough to plug sensors of the same type into separate sides of the Bus, as I said earlier. That can be debated at length, but there's a fundamental trade-off between flexibility and resilience to users at play here, and I leaned toward flexibility in this instance. It's still unclear to me to what extent the "multiple sensors of the same type in a single sensor box" scenario is even realistic, though it is at least supported right now.

Ouch - equipment wanting smart people to drive it. 

My personal experience is that even when I know equipment - things can happen that can just take a long time to sort out.

Gotta go - will come back to the next item later.

 

[NeilH]

..continued

Vic,

Collecting information from different sources on MiCS2710 powering /heating

from data sheet MiCS2710

NO PWM for reasons stated

Ph=43mW for internal temperature to reach 220C

Max heater power dissapation 50mW (no time limit stated presumably a long time in minutes)

Heater power above 120mW can destroy sensor due to overheating

from MiCS_AN2 FAQ

Above a certain operating temperature the heater resistance will increase over time

Long-term tests at 40mW no drift is measured over 6000hrs (250days)

At 80mW the heater RESISTANCE can rise by 30% (presumably under 6000hrs)

By powering with a series resistance on the heater (the above increase) does not impact the sensor power by more than 2% over the same period

and so to your question see inline below, which I've changed around a bit.

On Friday, June 1, 2012 6:52:20 PM UTC-7, vicatcu wrote:

 

and using a series resistor for the heater element.

“Long-term tests have shown that at 40 mW, no drift is measurable over 6000 hours.” (which is 250days)

(see App Notes mics_an2-MICS FAQ  at http://airqualityegg.wikispaces.com/Hardware-Sensors 

(http://airqualityegg.wikispaces.com/file/view/mics_an2+-+MICS+FAQ.pdf)

 

I wasn't quite sure how to reconcile this note with the individual sensor datasheets. The heating elements themselves are characterized as having a min/max operating resistance. How does a series resistor improve matters and how would you "appropriately size" it? I could add the a spot for another 0805 series resistor, but I would really like to understand what its role actually is and if its the correct thing to do or not. Looking at page 15 of the Dev Kit User's Guide it seems like they make reference to 82 ohms to get 76mW and (51 + 82 =) 133 ohms to get 43mW but they are also running the whole thing off of 5V.

In their context, lets take the MiCS-2710 whose datasheet suggests a heating voltage of 1.7, a typical heater resistance of 66 ohms, and a typical heater power of 43mW. So they would invoke a 133 ohms series resistance to get that. The voltage drop over the 66 ohm heater would be 5V * 66 ohms / 199 ohms = 1.65V. Switch over to the MiCS-5525 that has a heating voltage of 2.4V, a typical heater resistance of 74 ohms, and a typical heater power of 76mW. So they would invoke an 82 ohm series resistor. The voltage drop over the 74 ohm heater in that case is 5V * 74 ohms / 156 ohms = 2.37V. 

In our case we are using a regulator to drive the voltage across the heater directly... so what's the difference? I thought using regulators would be a more reliable means of creating the operating voltage drop across the heater called for by the datasheet. It's certainly possible I have misinterpreted the datasheets.

I've posted a question to the electrical engineering stack exchange to see if anyone there has any thoughts on the matter (feel free to up-vote to give the question traction).

The current method is to power off a constant voltage which across the heaters resistance gives a specific power that is needed to heat the sensors.

The sensor though needs a constant power.

If the heaters resistance increases (for whatever reason) because there is a constant voltage across it, the power dissipated drops. Which is a problem as that impacts the sensitivity of the sensor.

AN2 suggests use a series resistor across a higher voltage rail. In the AQE board the same current is used, because it all references back to 5V.

However if the MiCS2710 heater resistance increases, the voltage across the heater will rise, and keep the power more or less constant (within 2%)

3) Support extending the life of sensor by making it switchable

I can't see the point in making the voltage regulators software switchable, based on this paragraph from the same app note you referenced:

Heater voltages above the specified maximum rating will 

destroy the sensor due to overheating. Heating by PWM 

between 0 and 5 V has been tested until 100,000 Hz and 

destroys the sensor. The heating voltage must be pure 

DC voltage.

So what I take from this is  NO PWM switching.

The sensors are tested to 6000hrs/250days with no change of series resistance (but could be higher if left longer as that's what happens at 80mW).

So defensive circuit design - make the heater switchable (off the higher power) but it has to be turned on in the order of minutes before a reading is taken.

For a first pass at the firmware, I would switch the heater on permanently.

At a later date, when more data on heater/sensor interactions are available (and time) is available, if there is going to be readings say every 15minutes,  the heater could be turned off between readings. If the heater is needed to be on for 2minutes before readings taken, then it could be off the other 13minutes. This on paper means the no change in series resistance of 250 days is extended to 7.5*250days.

So was just a suggestion

--------------------------------------------------------------

I've gotta a question about one of the parameters on the MiCS-2710 data sheet and I wonder how you read this

Under Sensitivity Characteristics

NO2 detection range   FS Min=0.05  Max=5ppm

Do you read this as FS= full scale

and the range of the FS can vary from 0.05ppm to 5ppm

Cheers

Neil

[Victor Aprea]

Neil,

Yes, I've been getting some really interesting and insightful answers / dialogue to my question on the EE stack exchange. 

So I'm back to the drawing board, and I am now thinking that it might be better to have a digitally controlled potentiometer (e.g. this one) to control the regulated heater voltage, add a series resistor equal to the nominal heater resistance, and then run the divider voltage back to an ADC input to close the feedback loop and adjust the heater voltage at run-time to keep the heater power constant... but I'm pin saturated right now, so I will need to bump up to a more capable microcontroller (e.g. I'm looking at the ATtiny48).

So if we have the circuit looking like this:

V_x ------ R_heater --- (V_a) --- R_series ------ GND

... and we can control V_x through a digipot (using the same adjustable voltage regulators and circuits currently being proposed) and we feed voltage V_a back to an ADC input, we should in principal be able to calculate the heater power at runtime as:

P_heater = V_heater * I_heater = (V_x - V_a) * (V_a / R_series)

... where V_x is under our control, R_series is fixed, and P_heater is fixed (by the datasheet). So we'd take an ADC reading of V_a, convert it to a voltage, calculate P_heater, adjust V_x up or down accordingly to compensate, wait a few seconds, rinse, repeat. Basically, a control loop using Heater Voltage to control Heater Power. Does this seem like a sound approach or does it seem like overkill? 

I'm going to go ahead an rework the two boards with this concept in mind, but I'll be checking back for feedback, so please keep it coming!

------

My interpretation of the MiCS-2710 data sheet is that the full range of gas concentrations it is sensitive over is 50ppb to 5ppm, and that the sensor resistance does not change measurably outside that range.

Cheers,

Vic

[Victor Aprea]

Caught myself on a significant omission on the Egg Shield... I had completely forgotten the pull-up resistors on the two I2C branches coming off the PCA9540BD. That would have been most unfortunate.

-Vic

[Victor Aprea]

Neil and others,

I'm not quite done with the Sensor Module updates, but the I added a "heater coprocessor" to the Egg Shield to handle the heater feedback constant power regulation control loop. Talks to its own little SPI potentiometer  and monitors the heater divider. I haven't updated resistor values on the egg shield yet, I need to get some sleep at this point, but I wanted to let ya'll know I've been hard at work on it and encourage people to take a look at the progress and provide comments.

Vic

On Sat, Jun 2, 2012 at 9:28 PM, Victor Aprea <victor...@wickeddevice.com> wrote:

--

Victor Aprea // Wicked Device

victor...@wickeddevice.com

M: 607.745.1515

T: twitter.com/vicatcu/

[vicatcu]

OK Electronics Gang,

I've pushed an update to the CMOS Gas Sensor Module. I think it's probably ready for prototype at this point. A summary of the changes are as follows:

- Upgraded processor to the ATTiny48

- Added feedback circuitry (digital potentiometer and ADC input) for closed loop control of the heater power

- Separated Analog and Digital GND planes using a star topology routing to the return path at the connector

- Added power filtering to AVCC

- Added the possibility for the heater power to be shut down by the microcontroller

- General routing changes associated with the above

I would really appreciate it if people could have a look over it and give me some feedback over the next couple of days. As a reminder, the Eagle CAD source files and PNG images are available on Solderpad.

Regards,

Vic

On Sunday, June 3, 2012 1:48:56 AM UTC-4, vicatcu wrote:

Neil and others,

I'm not quite done with the Sensor Module updates, but the I added a "heater coprocessor" to the Egg Shield to handle the heater feedback constant power regulation control loop. Talks to its own little SPI potentiometer  and monitors the heater divider. I haven't updated resistor values on the egg shield yet, I need to get some sleep at this point, but I wanted to let ya'll know I've been hard at work on it and encourage people to take a look at the progress and provide comments.

Vic

[NeilH]

Hi Vic

Just a quick note - I can't open the files on solderpad.

I've installed Eagle 6.2.0 light as freeware

I can open "proto_shield_v5.sch" from arduino 

When i download and attempt to open attempt to open AQE_SENSORMODULE_E2V_CMOS.sch  it says its not an EAGLE file.

On looking at it is structured link .xml file

Some of the documents end with .pdf - but won't open by acrobat.

Any suggestions, am I getting the right files.. 

Cheers

Neil

[Victor Aprea]

Neil,

It probably has to do with how you are saving them to your local machine. The files are stored in a git repository on solderpad and you are meant to check them out from the read-only url git://solderpad.com/vicatcu/aqe-cmos-gas-add-on.git.

In linux, you would run a command like :

git clone git://solderpad.com/vicatcu/aqe-cmos-gas-add-on.git

... to pull the files onto your machine. 

Anyway, let me make this easier and just attach the current files to this post.

Regards,

Vic

[NeilH]

Hello Vic 

got the Eagle boards off your posting thanks.

Apologies for the delay – but I haven’t been able to get to this,

Then I  wrote out some comments, and then checking my comments I found there was other ways of looking at the circuit, especially with firmware doing a lot of the work.

So if you want to make it accessible to being reviewed  it needs a circuit description with it, and I would also say it needs the components with it – at least for one sample sensor.  

For me personally I’ve found it’s a good habit to specify components, with a part number, and then before I send it off to be made – I generate a tentative BOM and verify all the parts are available in the values I specify. 

Circuit Review eggShield.

Heater_Ctrl Circuit – how do you see this working. – are you optimizing for a constant power?

Are the labels swapped around – U1 creates 1.7V which is used on NO2Sensor, but references CO_RH-

No p/n for analog pot

I guess the power can’t be managed/monitored  by the NanoNode 

Personally putting a separate ATiny45 makes me nervous as it’s a separate processor that’s not monitor able – except by measuring the 1.7V or 2.4V over time. 

An alternate design would be to put a duplicate of the E2V_CMOS circuit (Tiny4832A) and make it accessible on SDA/SCL and drive all the local signals from it the same way. Now all the circuits behave the same way.

Analog – seems like you are using ratio-metric to Vcc. For 10bits this puts the per bit at 5mV. I guess it doesn’t make any sense to separate out grounds because SENSE_R1/R2_SEL are digital ports both referenced to GND on the NanoNode

I would think you would want to make sure there is no activity on NanoNode on SCK and SCL when you are doing an ADC on the NanoNode. 

Circuit Review AQE_SensorModule_E2V_CMOS

Great to see two leds for User/Operating person feedback.

Htr Power Circuit – 

Great to see the power circuit switchable, and I assume you are making it variable power to be able to manage the power for individual sensors and across families of sensors. I did see a reference to one of the data sheets to being able to be able to derive some different types of data in the sensor warm up phase. 

So the heater current can be measured across R5   “heater Feedback”

How are you calculating the power consumed in the sensor heater. W=VI 

I would think you would need to measure the HeaterV, which is varied by V1+ to be able to calc the power used in the sensor.

For the -Analog circuit – AVCC  derived from incoming VCC and then separately generated Sensor_VCC 

I’m not sure how its supposed to be working, 

Can you explain it. (it seems like there would be a benefit in keeping the same method for the eggShield)

Initially I assumed you were using the AVcc as the reference, and using a ratiometric output from the sensor – which would place the Sensor output in the full range of AVCC.

Then I saw the Sensor has its own Vcc @ 2.3V and so I’m guessing you are planning on referencing the internal Vint which for ATmega48P 1.1+/-0.1V

So could you give an idea of how you were planning on using it, and what areas you are optimizing for best results

Since the ADC is only 10bits I don’t think it is likely to be that sensitive to analog issues, however if Vint is used @ 1.1V  the sensitivity is 1mV

It seems like it would be a good idea to a do a current loop analysis for the sensitive analog areas.

I’m unfamiliar with Eagle (6.2.0) and can’t do a visual current loop analysis. Eagle is only showing me two planes and there is some connections in what appears to another plane.

So if you are using the Vint=1.1V I have some comments 

There are some  Atmel App Notes AVR040, AVR042 recommending isolating digital noise to the processor with a C-L-C circuit – instead of trying to filter noise going to a AVcc. They also use a tantalum Cap as lower noise than an electrolytic. However I think Ceramic caps at 1uF are probably pretty low cost and could be used instead of tant. 

Regards

[vicatcu]

Neil,

Thanks for the detailed review, great stuff. Sorry for not responding more quickly. Rather than respond point by point, let me just say a number of your comments made me really take a step back and reassess the two boards in context of your many insights. The result was that I've made a number of significant changes to the shield design and pushed the latest files to Solderpad (and also attached the CAD files to this post for convenience). I also recognize the need for design documentation and that it is a challenge to review the design without it - and so I've started writing the design in a Google doc that I will share once it has enough content to be worth reading. 

On a side note, in incorporating all the changes, I found an egregious error in the previous design; the digital potentiometer's chip select pin was not connected; which would have made the communicating with the chip quite difficult :-). This error was on both the Add-on Sensor Module and the Sensor Interface Shield designs.

I'm planning to use 5V as the 10-bit ADC reference voltage across the board. Perhaps the latest design files will make more sense now though, as I've renamed some nets for clarification and corrections and added a separate 2.5V regulator for the NO2 sensor. The adjustable regulators + the digital potentiometers are for feedback control of the sensor heaters to optimize for constant power. Basically, adjust Heater V+ through the digital pots and measure Heater V- to obtain the target power dissipation in the sensor heater. For example: P = (V+ - V-)  * I; I = V- / R18; so P = (V+ - V-) * V- / R18. We know R18 and V+ (ala the digital potentiometer and adjustable LDO known feedback resistor), so we can calculate P and adjust V+ until P is where its supposed to be for that particular sensor. Does that make sense?

One last note on the I2C bus. It's totally serial and sequential. So we don't have to worry necessarily about the SCK and SCL lines wiggling while we take an ADC reading. The slave on the bus can hold the master off through "clock stretching," so it will go something like this: (1) Nanode asks for Sensor Reading, (2) Sensor Controller acknowledges Nanode and takes an ADC reading (while stretching the clock - no I2C activity happens during this time), (3) Sensor Controller calculates and returns the sampled data point to the Nanode...

Feel free to provide further feedback and review comments on the latest design iteration and thanks again!

Kind Regards,

Vic

[NeilH]

Hi Vic

Glad it was useful, and seems like it is firming up. One comment below, but I'm not going to make any other comments till I get your cct description on how you expect it to work.

Cheers

Neil

On Wednesday, June 13, 2012 9:11:19 PM UTC-7, vicatcu wrote:

 The adjustable regulators + the digital potentiometers are for feedback control of the sensor heaters to optimize for constant power. Basically, adjust Heater V+ through the digital pots and measure Heater V- to obtain the target power dissipation in the sensor heater. For example: P = (V+ - V-)  * I; I = V- / R18; so P = (V+ - V-) * V- / R18. We know R18 and V+ (ala the digital potentiometer and adjustable LDO known feedback resistor), so we can calculate P and adjust V+ until P is where its supposed to be for that particular sensor. Does that make sense?

Yes - however I'm not clear how you are getting V+ - as it doesn't seem to be measurable anywhere. 

If you are calculating it, then I wonder how accurate that is likely to be. The variable POT MCP14xx p/n is not defined - but assuming an 100K its +/- 20% with some parts having a TCR of 800ppm

Also I guess I'm not clear why you are using a digital pot with a dedicated powersupply chip - unless its to be able to use a variety of sensors with slightly different heater requirements, and there fore set the V+ in software.

The App Note 2 suggests that just using a serial resistor as a method of stabilizing increases in heater resistance - that would also ellimante the separate power supply requirement as you could take it off 5V.

[vicatcu]

Neil,

Seeing as we have two more ADC inputs on the ATTiny48, you're right, why not measure the Heater V+ voltage directly (rather than calculating it based on the assumed value of the digital potentiometer). I'll make that change tonight or tomorrow on both boards.

I also realized this morning (while waking up) that I neglected to put in a programming header location for the ATTiny48 on the Egg Shield board, so again I'll add that in.

Regarding the digital potentiometers, I figure the 100k variants are a good choice to minimize power in the voltage divider. Any reason to go lower? For the Egg Shield I'm targeting Microchip MCP4231-104E/SL. For the Add-on Sensor Module I'm targeting the MCP4131-104E/SN.

Finally, the adjustable power supply chips are Microchip TC1071VCT713; I'm not using fixed supplies because we are optimizing to keep the heater power in bounds of the datasheet by controlling the heater voltage. Am I missing something in your comment about using a "dedicated powersupply chip"? The sensor operating voltage is fixed on purpose. I can't think of a good reason to justify making it adjustable in software.

Regards,

Vic

[vicatcu]

OK, I've pushed updated design files for the Egg Shield (attached for convenience). I need to make a few analogous changes to the Add-on Sensor Module tomorrow to keep the two boards consistent from a software perspective. I think it's evolving into a pretty solid and sophisticated design and we're almost there on these boards!

Cheers,

Vic

[NeilH]

On Thursday, June 14, 2012 11:41:55 AM UTC-4, vicatcu wrote:

Finally, the adjustable power supply chips are Microchip TC1071VCT713; I'm not using fixed supplies because we are optimizing to keep the heater power in bounds of the datasheet by controlling the heater voltage. Am I missing something in your comment about using a "dedicated powersupply chip"? The sensor operating voltage is fixed on purpose. I can't think of a good reason to justify making it adjustable in software.

Hi Vic

I was trying to figure out why you were using two TC1071s for the two sensor heater voltages. With the addition of  the two MCP4131 the heater voltage(power) is ffectively adjustable by firmware.

If all things are equal and you are only looking to keep the power constant on the sensor heaters, 

an alternative lower cost approach seems to me is to run the heaters off the 5V, with series resistors to provide the current limiting/correct voltage on the sensor heater. 

That is what I thought "AN 2" was suggesting. Then if the heater resistant increases over time,  the voltage across the heater increases as well and the power absorbed by the heater is relatively constant. 

To make the heater power switchable use an DMN5L06DWK (Dual NMOS) on the 0V side.

and since its switchable, AN2 was suggesting a 2nd fast ramp heating power - that would be a 2nd resistor+NMOS sw.

Cheers

Neil

[Victor Aprea]

Neil,

There are two TC1071s because the two sensors require different power. CO wants 76mW while NO2 wants 43mW, so I wanted to be able to manage the heater power on each sensor independently. 

To review AN 2:

Long-term tests have shown that at 40 mW, no drift is

measurable over 6000 hours. At 80 mW, the heater
resistance can rise up to 30%. By powering the sensor with
an appropriate series resistance on the heater, this
resistance does not impact the sensor power by more than
2% over the same period, which is sufficient for most
applications. More sophisticated “constant power” circuitry
can be used to fully eliminate this effect.

What I think I've implemented is the "more sophisticated 'constant power'" circuitry approach alluded to in the last sentence and what I think you were referring to is the "appropriate series resistor" in the middle of the paragraph.

I think you are referring to the "pulsed modes" on the last page of AN 2 in the last part of your response. For our initial implementation, I'm not going to attempt this technique since, to paraphrase AN 2, "these application modes are very powerful and very complex" and "these methods have significant potential but require specific development for each application." But what I've done by incorporating your feedback is to design the hardware to *support* the pulsed modes if we want to try to use them in the future.

Best Regards,

Vic

[vicatcu]

Add-on Sensor Module updates to make it compatible / consistent with the Egg Shield have been implemented and pushed to Solderpad. I've also attached the current files to this post for convenience.

Regards,

Vic

On Friday, June 15, 2012 12:20:10 PM UTC-4, vicatcu wrote:

Neil,

There are two TC1071s because the two sensors require different power. CO wants 76mW while NO2 wants 43mW, so I wanted to be able to manage the heater power on each sensor independently. 

To review AN 2:

Long-term tests have shown that at 40 mW, no drift is
measurable over 6000 hours. At 80 mW, the heater
resistance can rise up to 30%. By powering the sensor with
an appropriate series resistance on the heater, this
resistance does not impact the sensor power by more than
2% over the same period, which is sufficient for most
applications. More sophisticated “constant power” circuitry
can be used to fully eliminate this effect.

What I think I've implemented is the "more sophisticated 'constant power'" circuitry approach alluded to in the last sentence and what I think you were referring to is the "appropriate series resistor" in the middle of the paragraph.

I think you are referring to the "pulsed modes" on the last page of AN 2 in the last part of your response. For our initial implementation, I'm not going to attempt this technique since, to paraphrase AN 2, "these application modes are very powerful and very complex" and "these methods have significant potential but require specific development for each application." But what I've done by incorporating your feedback is to design the hardware to *support* the pulsed modes if we want to try to use them in the future.

Best Regards,

Vic

[vicatcu]

Hi all,

I've made a good amount of progress on writing up the specification / hardware description document. Here is the link:

https://docs.google.com/document/d/1H1Ul2SzwXkJpdXGmgnuToOhtt7pjg2RVEUEVk0KCiwY/edit

I've designated the document as public and anyone can access it and provide comments without signing in or anything. Hopefully this is not an invitation to abuse, but we'll see I've never tried using these features of Google docs yet.

I think what's in there right now is a pretty good start - it explains the concept of the circuitry with respect to controlling and reading the gas sensors. On deck is a description of the I2C Egg Bus and how that all is supposed to work. I welcome feedback and input on what should be added on a continual basis either directly via comments in the document, or for more elaborate / broad discussion on the group as usual. Hopefully this begins to make clear any sources of confusion that might have been hanging out there.

Kind Regards,

Vic

[NeilH]

Vic - thanks just wanted to check on the design target. It looks to be a comprehensive power control circuitry. Cheers Neil 

[Victor Aprea]

Neil,

Yes, a goal is to keep the heater power relatively stable and on target over time to eliminate that variable.

Cheers,
Vic

[NeilH]

On Thursday, June 14, 2012 9:43:05 PM UTC-7, vicatcu wrote:

OK, I've pushed updated design files for the Egg Shield (attached for convenience). I need to make a few analogous changes to the Add-on Sensor Module tomorrow to keep the two boards consistent from a software perspective. I think it's evolving into a pretty solid and sophisticated design and we're almost there on these boards!

Cheers,

Vic

Hi Vic

Here is a review of the EggShield dated 120614 - sorry its taken some time - I've just focused on a few areas that are new and visible as far as an Air Quality metrics are concerned - so I haven't gone through any sort of comprehensive digital interfaces review.

The document is good to have - though I've extended the discussion (usefully I hope).

You can use any of it in the document description if you want to.

eggShield 120614 schematic review

MiCS2710 (NO2)  MiCS-5525 (CO)

Dual Pot  MCP4231-104E/SL -100K 129 taps 

Power Supply TC1071

1) Heater Supply - for MiCS5524 using 5V, schematic references U2/TC1017 output - – document description says 5V

2) Can you say thinking behind separate NO2/CO Sensor operating voltages. NO2_operating_V is specified at 2.5V and how you expect to do ADC measurements and compensate for inherent inaccuracies of different reference sources.

Would think sensors NO2 & CO should have VSENS+ running off AVCC - currently labeled 2.5V & 5V. 

The benefit of using AVCC is common reference measurement for ADC ratio-metric measurements. AVCC is nominally 5V, but practically speaking it doesn’t have to be too accurate and can still maintain the calculations.

3) For NO2 sensor would suggest range of values of R1=2.2K, R2=22K R3=220KΩ - see below

4) For CO sensor would suggest  range of values of R1=6.8K R2=68K R3=680KΩ - see below

5) Would suggest socket for  humidity? ( Sensirion SHT10 or SHT11) and use available  A/D

Temperature – Readable from Tiny48 using int 1.1 vref . 

Sensor Descriptions

As sensor gas concentration increases Vsense swings across scale. 

Dynamic range adjustment allows for variation in sensors base resistance – R0. 

For discussion the following Air Quality standard thresholds are used:

NO2 Air Quality standards threshold:100ppb+/-1ppb range 0-400ppb

(suggested) NO2 Target Required range 50-200ppb objective 0-400ppb (these values shown in MiCS2714)

MiCS2710/2714 has detection range of max Full Scale from 50ppb to 5000ppb, with Manufacturers defined Sensitivity range  at 250ppm.  

Some sensors may not be able to detect up to 200ppb as the manufactures sheet suggest they can be extremely sensitive with FullScale range of 50ppb -however this seems unreasonable (only going to a FS of 50ppb), so a manufacturers check is needed at the required 200ppb

Sensitivity range (RS/R0) is defined as 6-100 typically 55 at 250ppb

I'm referencing MiCS2714 datasheet  as appears to be same sensor specification (in different package), and has  a graph that covers a larger characterization range)

MiCS2710/2714 (NO2) SensorR0 has 0.8K ->20K nominal 2.2K, increasing SensorRs with NO concentration, 

So for R1 (20%of scale) using the lowest value 0.8K would place it around 2.2K

I would choose R1 somewhere around 2.2K. 

This would be one end of a potential calibration point as its synthetic air, which I think means we can assume NO2 is less than 1ppb (need reference).

Then for a range of values (to be confirmed with real sensors)  a max sensitivity of 100 and starting at R0=20K this puts it at 2M 

I would choose R3 at 220K

That could place R2 at about 22K.

E2v.com AN2 recommends R1=6.8K,R2=100K,R3=1200K probably to cover  (higher concentration) emissions likely in an automobile exhaust range.

So I think this is close enough to verify the lower range sensitivities of Air Quality range of R1=2.2K R2=22K R3=220K

Determining minimum measurable ppb around 100ppb we can use the end ranges of sensitivity factors 6-->100 to determine if the ADC10bit resolution is likely to resolve to 1ppb. 

This is only an approximation, and in practice need to use the 250ppb specified in the data sheet, and see if the ADC10bit can at least resolve 250units between R0 and Rs(250)ppb

Using real values if the lowest SensorR0 is 0.8KΩ, and with a sensitivity of Sr=6, then SensorRs=4.8KΩ for 250ppm

So using R1=2.2K Voltage would be from 1.3333V  to 3.4285V for a difference of 2.095V and @ 5mV/bit its 419 units. 

Using real value if the lowest SensorR0 is 20KΩ and sensitivity is Sr=100, the SensorRs=2000KΩ

For R3+R2+R1=222.2K Measured V from 0.41288 to V=4.5000 for a range of 4.087V @5mv/bit = 817units

Using typical value of SensorR0 at 2.2K and a midrange average Sr=50 to SensorRs=110K@250ppb

So using R1+R2 22.2K V=0.2049 to 4.1604V or difference of 3.9555V @5mv/bit = 791 units

In practice Sr is non linear especially at the lower end 10-100ppb range (MiCS2714) and from the graph least sensitive   and then fairly log linear in the 100-400ppb range.

Practically speaking, its also likely that once the real SensorR0 (resistance in syn air) is established, it will define which resistor range to use, which could then be used across the scale of interesting using a single resistance so as to not have to switch scales

For CO Air Quality standards threshold: 9ppm+/-1ppm range:0-20ppm

miCS5525 Specifies SensorR0 100K->1500K  and drops with increasing COppm.

Sensitivity is specified at 60ppm which is way above Air Quality range of interest

From Datasheet Graph Rs/R0 drops from 0,7@1ppm to 0.5@11ppm to 0.4@13ppm

for upper end 1500K could drop to 600K for 13ppm - Suggest R3=680K

for lower end 100K could drop to 40K for 13ppm-  Suggest R2=68K

Because of Sr=5-50 and CO can be measured across a large range suggest R1=68K

 

[David Holstius]

Hi Vic, once again I want to thank you for keeping this design process open & well documented. I've got two questions that I haven't been able to answer based on the materials/documentation so far:

1. Could you estimate the total power consumption of the shield as it's currently designed, including the sensors (CO: 76mW + NO2: 43 mW)? And what about the other add-ons (like O3)? For those of us who are interested in battery-powering Eggs, at least for limited amounts of time, this would be great information. I'm sure it will change since you're alpha testing now---just a ballpark estimate, that's all. Trying to figure out how big of a battery I'll need ... :-)

2. Is the shield still pin-compatible with Arduino-based host boards other than the Nanode? Like the Uno or Pro? 

3. Assuming it's pin-compatible, would you expect the firmware to run on other boards with minimal or moderate revisions? (We could start a thread about firmware, maybe that's appropriate...)

Thanks again, and cheers,

David

[vicatcu]

David,

Sorry for not responding sooner. Answers in-line below.

On Thursday, June 28, 2012 11:12:37 PM UTC-4, David Holstius wrote:

Hi Vic, once again I want to thank you for keeping this design process open & well documented. I've got two questions that I haven't been able to answer based on the materials/documentation so far:

1. Could you estimate the total power consumption of the shield as it's currently designed, including the sensors (CO: 76mW + NO2: 43 mW)? And what about the other add-ons (like O3)? For those of us who are interested in battery-powering Eggs, at least for limited amounts of time, this would be great information. I'm sure it will change since you're alpha testing now---just a ballpark estimate, that's all. Trying to figure out how big of a battery I'll need ... :-)

The Shields power consumption will almost certainly be dominated by the heater power as you have pointed out. So 120 - 150 mW should be in the ballpark. We'll know more once we have an operational system running firmware and so forth. The I2C Mux should take less than a mW looking at the datasheet. In principle, the ATTiny48 naively might take about 40 mW, but it can be put into a low power sleep mode for most of the time, so its contribution should be effectively negligible. 

  

2. Is the shield still pin-compatible with Arduino-based host boards other than the Nanode? Like the Uno or Pro? 

Yes I believe the shield is fully Arduino compatible. It is using the standard Arduino form factor and primarily requires that the host board has its I2C pins on header location A4/A5, as the Uno does.

 

3. Assuming it's pin-compatible, would you expect the firmware to run on other boards with minimal or moderate revisions? (We could start a thread about firmware, maybe that's appropriate...)

The firmware will be written in such a way as the Shield has an Arduino Library associated with it, so yes it should be usable on any Arduino boards. That library will essentially be the logical API for the I2C Egg Bus, which in and of itself should be port-able (in principle, with minimal effort) to any architecture that has an I2C interface (i.e. not just Arduino). 

As an aside, I think a separate firmware thread would not be a bad idea either.

 

Regards,

Vic