[solved] Anyone care to make a stab at this formula in a datasheet?

Status
Not open for further replies.
D

DrG

Active Member
I think I mentioned somewhere that I am working with a CO sensor - here is the datasheet.

A signal, Vgas is used to derive ppm CO. The derivation is improved by some temperature compensation.

There is another signal, Vtem, that is described in the datasheet as - Voltage Output. Vtemp is proportional to temperature.

The relationship, however, is not given in the datasheet (at least nowhere that I can see and I have looked).

Looking further, specifically here, I found the relationship. The relevant section appears below.


I do not understand that formula and am under the impression that something is missing or that something should be inferred/assumed that I am not getting.

I set up a DS18b20 temp sensor right next to the CO sensor and below you see, on each line:
DS temp [C], Vtem [V], and my calculated temp based on my interpretation of that formula.

V+=5.0 and Vtemp is accurately calculated from an ADC.

Code: 
25.31    1.62   [24.45]
25.25    1.62   [24.45]
25.12    1.61   [24.37]
25.69    1.63   [24.71]
26.75    1.65   [25.05]
27.87    1.68   [25.47]
28.50    1.69   [25.73]
28.81    1.71   [26.07]
31.12    1.80   [27.68]
30.62    1.80   [27.60]
29.81    1.78   [27.26]
29.06    1.77   [27.09]
28.69    1.76   [26.92]
28.37    1.75   [26.75]
28.06    1.75   [26.66]
27.87    1.74   [26.49]

Using V+ and Vtem, from those samples, can you tell me how you would calculate Temperature?

I will likely write the company and ask, but maybe I am missing something that everyone elses sees (would not be the first time), so I am asking.
 
Last edited:
JimB said:
Beats me!

JimB
Click to expand...

Yeah, it's bugging me. Thanks for taking a look.

This is how I changed it for use in the first post.


The resulting function is about in the +/- 3C range as advertised - as compared to the ds18b20 and within a small range that I sampled. I need to write the company and ask them.
 

Good luck with that

But you're not alone, it's rare to see any such formulas in datasheets that do make any sense, but in this case it's obviuously seriously misprinted, and the proof reader should be taken out and shot. Perhaps this problem is normal?, and why it's often so confusing.
 
When reading both sheets, It states that temperature change for the zero affects the ppm output and the span effects the voltage output.

Does that mean a calculation just for the zero, and another for the overall calculation??

0.25% /°C for the span is quite a bit..
 

I appreciation the confirmation that, as written, it also does not make sense to others.

There have been occasions (e.g., twice with Honeywell) where I had some very nice and productive discussions of two different products. Not only did my questions get routed to an EE, but he was very helpful. Additionally, I corrected something that he had also said, and he came back to me to say that he had checked it out and that I was, indeed, correct about that point. They came out with an updated product for that sensor which I have not looked into and the point in question was an annoyance rather than a critical function.

I have had some luck with responses in some cases (e.g. above).

I just finished writing them and will let folks know where it goes. I have no problem writing again, if I do not receive a response after a week or so (I did already get an auto-response with a name). In fact, I would have no problem in pointed to this thread where it is being discussed. I think if you can get past a salesperson and to an EE, you can get a good response - at least I am hopeful.

Personally, I think that the "correction" to the formula as I posted may be right. Practically, if I have a temperature sensor with the CO sensor, I would use that for the temperature compensation. Intuitively, they do not seem to be pushing Vtemp as the way to go and outright talk about using a thermister.

As an aside, as a "PIC person", you know the importance of using the most recent version of a data sheet and the importance of checking the erratums. I think that Microchip does a decent job of this aspect (as well they should) although they come under criticism regularly. This company (Spec Sensors) is much smaller and it looks like Digi-Key is their main distributer (I certainly could be wrong about that), so I remain hopeful.
 

I have not (in practice) gotten to that point yet, but that is my reading as well (see the two graphs under temperature compensation in https://www.spec-sensors.com/wp-content/uploads/2016/10/ULPSM-CO-968-001.pdf). The one on the left is the zero span, but notice that even at the upper end of the operating temperature (50C/122F is pretty darn hot), zero ppm is affected to 50 ppm [if you follow my informal description]. At room temperatures (which concern me the most) there is an effect but it is not great.

Just to include how toxic CO for any readers who may not know, look here. If I remember my biochemistry correctly, CO binds to red blood cells just as O2 does, except CO stays on for a very long time, thus preventing O2 from binding and carrying the oxygen to where it needs to go - that is a big problem.

Anyways, I am very impressed with the sensor specs, so far. Earlier, I looked at the MQ-7 can sensors and I was distinctly unimpressed. There was pathetically little information about them and my recollections was that after I spent a lot of time to understand them, I cam to see that the board I had (a very common and expensive board) did not even isolate the heater to enable critical functioning. Now, that is my opinion and I will leave it at that - I just felt that I wanted to do better.
 
DrG said:
As an aside, as a "PIC person", you know the importance of using the most recent version of a data sheet and the importance of checking the erratums.
Click to expand...
True of anything in the engineering world, always use the latest version of the documentation.

It is dissapointing that the manufacturers of this sensor have not updated the datasheets since October/November 2016, when there is such a (glaring) error in there.
They must surely be aware of it, I don't think that you are the first person in the whole world to wonder what that temperature expression should really be.

JimB
 

Maybe they have not updated it (assuming it needs updating) and maybe they are aware but let's see (I actually just looked at when I bought mine - May 2018). Maybe there is an updated version that I don't have or maybe it was a production error associated with pdf production (yeah, I know, why doesn't an EE proof a final product). Maybe there is just something I don't know. At this point, I will just raise it, but yes, it is a little disappointing right now.
 
Nice

From: Ed Stetter <efs@spec-sensors.com>
Sent: Friday, November 22, 2019 9:25 PM
/- snipola -/

Sorry for the trouble, you did indeed find an error.

It looks like there was an error in the conversion of that manual from .docx to .pdf. As a result, a division sign in the formula is not shown.

The correct formula is:
Tcalc = (87.0 / V+) * Vtemp - 18.0


We will correct the documents but hopefully this helps. Sorry again for the mistake.
 
JimB said:
That is the first thing that I tried, but the results did not agree with your measured values.

JimB
Click to expand...

Yes, you are right...that is they do not give anywhere near as accurate a result as what I posted. BUT, I have an error.

To make a long story shorter, V+ is actually 3.3V and NOT 5V as I had stated. That is my error. The ADC is 5V, that is, the correct conversion for calculating Vtemp is: Vtemp=analogRead(AVtem)* (SVcc/1024.0); where SVcc is 5.0V. I sloppily was using 5V (as I posted) but Vcc for the sensor (which is V+ in the formula), is in fact 3.3V (big duhhhhh -->me).

Of course, guessing at what the formula was did not help much. Having the correct formula and having my brain fart dissipated, I see something better.


25.31 1.62 [24.45] [24.71]
25.25 1.62 [24.45] [24.71]
25.12 1.61 [24.37] [24.45]
25.69 1.63 [24.71] [24.97]
26.75 1.65 [25.05] [25.50]
27.87 1.68 [25.47] [26.29]
28.50 1.69 [25.73] [26.55]
28.81 1.71 [26.07] [27.08]
31.12 1.80 [27.60] [29.46]
30.62 1.80 [27.60] [29.46]
29.81 1.78 [27.26] [28.93]
29.06 1.77 [27.09] [28.66]
28.69 1.76 [26.92] [28.40]
28.37 1.75 [26.75] [28.14]
28.06 1.75 [26.66] [28.14]
]27.87 1.74 [26.49] [27.87]



c'mon JimB you should have known I made that error and fixed there's as well, your slipping
 
An update on the project.

I have the sensor up and working with the correct formula.

The temp sensor performs according to specs over the range that I have tested and that range in not too much different than the anticipated operating range. I will use the on board temp sensor.

The only real "trick" is to get the offset. That is, you want the very small difference between the Vgas output in clean air (no CO) and Vref. You can actually just use 0, but I have done a lot of testing on this issue. One thing I learned is that a breadboard circuit and those plug leads are a little flakey for millivolt A2D values. Nevertheless, I have that down and it is about .03-.05 or so. As long as clean air values are less than 1 ppm, I am ok. I am getting +/- .3 so that is ok.

I have also tested averaging 10 values for a read and that seems to increase stability. I can force negative values up to values as high as .5 ppm to zero - I am ok with that. In practice, I only care to display whole numbers. The thing about CO is...any is bad and none is best. I really want to be notified about >1 ppm.

Moving on...the display.

At first, I thought that I would use one of these 0.91 inch, 128 x 32 mono OLEDs that use an SSD1306 controller. They are cheap and I have used them before. You can get two lines of text/numbers, but it is tiny.


Instead, I went with one of these.


It was just a few bucks....it uses an ST7335S controller and (as though I just can't learn my lesson), they are poorly documented and you can expect to spend more than a few hours getting a driver up and running. But, they are a nice little display for my purpose.

I had given up using a promini or other slow Arduino clone and went with a Teensy LC - a decent board. Their "teensyduino" interface software (lets you use the Arduino IDE) comes with an optimized version of the Adafruit 7735 library which also uses the familiar Adafruit GFX library.

Of course, there is no initialization options for this display...you are pretty much on your own for that. I decided to modify the ST7735_t3.cpp driver file (yes, of course I saved a copy of the original). To make a long story short, I had to figure out and change CASET and RASET and change some starting x/y values - and I did this working off of the existing INITR_MINI160x80 options because that initialization code is closest for what I needed (but it is not that close).

Then, I had to uses options for inversion and rotation. Oh yeah, and one more thing, I had to convert the 5-6-5 RGB colors to BGR, e.g.

Code: 
 #define ST7735I_ORANGE     0x041f // 0000010000011111 was 0xFC00

On this point, I would say to anybody who is listening - if what I have written makes no sense, then just buy a board that is supported by the driver. Yes, it is more rewarding to buy a dirt cheap display and get it to work, but.....I spent a lot of time on it AND, the right way would have been to write a custom initialization just for this board. Frankly, I just didn't want to do that, although I probably could. So, the display that I used cost US$3.45 including shipping and I bought two of them. The comparable Adafruit board is US$14.95 not including shipping. Yes, there is a difference, but how much is your time worth?

In any event, the driver is working as far as for what I need so I worked on some displays:


and when we are above the lowest threshold, we have a "yellow" alert (up to 1.5 ppm right now)...


...and at 2 ppm on up we have...


In testing, I am happy with the SPI display speed with the Teensy LC.

The display only uses 20 mA and the sensor is very low power. Feeding the Teensy 5V gives me a regulated 3.3V pin out at 100 mA, so I am good even after adding an alarm.

So, onward...need an alarm...move it of the enclosure...test it in real life...enclosure (ugh).

At this point, I want to state up front that this is a project for my own experimentation. With ANY sensor, calibration is necessary. You have to validate your measure with a standard if you want accuracy. Now, this sensor comes with a coded calibration factor for each individual sensor. That is good, but it is not a replacement for actual calibration of the end product.

I don't know how far I will go with that. A few years ago, I would have bugged someone to test it out in "their" calibration chamber - I don't have that capability so easily now. You can buy calibration gas standards and I will see where it goes. My first test, when it is finished, is to see what it reads at some distance from a known CO source (like an engine exhaust).

Remember (if you are reading this and thinking of building your own) CO is some bad stuff, so be mindful and careful.
 
Last edited:
Status
Not open for further replies.

Similar threads

K
  • Question
Varying voltage in a circuit
Replies
9
Views
730
Kisen
K
N
  • Question
How to check the stability analysis of complex opamp circuit in Ltspice
Replies
2
Views
851
Roff
P
Anyone recognise this receiver?
2
Replies
21
Views
4K
Lightium
P
Anyone recognise this remote?
Replies
2
Views
1K
danadak
  • Question
How to make a very slow relaxation oscillator ?
Replies
12
Views
3K
schmitt trigger
S
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…