After calibration, incorrect data #13

shojkeee · 2022-04-19T08:27:57Z

After applying the kolibrovochny sketch. My sensor started showing values in ppm like this: 12002000020

shojkeee · 2022-04-19T08:28:29Z

shojkeee · 2022-04-19T09:11:28Z

RobTillaart · 2022-04-19T09:11:55Z

Assuming kolibrovochny = calibration ? you used - AGS02MA_calibrate.ino ?

Has been some time ago I used the sensor but I recall no problems with it when calibrating (I use Arduino UNO)
Can you post the output of the calibration sketch?

The manual does not give information about failing calibration, only this:

What does uint8_t lastStatus() return?
it might be a communication error?

shojkeee · 2022-04-19T09:14:35Z

Assuming kolibrovochny = calibration ? you used - AGS02MA_calibrate.ino ?

Has been some time ago I used the sensor but I recall no problems with it when calibrating (I use Arduino UNO) Can you post the output of the calibration sketch?

The manual does not give information about failing calibration, only this:

What does uint8_t lastStatus() return? it might be a communication error?

No. There are no communication errors. When there is no connection, I have 0 ppb sent. Let's do the collibration again now. It will take 6 minutes and I will attach the output of the port monitor to you.

shojkeee · 2022-04-19T09:22:08Z

RobTillaart · 2022-04-19T09:26:10Z

Looks OK, every 15 seconds a timestamp
the 1 indicates that the 5 bytes for zero calibration are written to the device. (no I2C error).

shojkeee · 2022-04-19T09:29:44Z

Looks OK, every 15 seconds a timestamp the 1 indicates that the 5 bytes for zero calibration are written to the device. (no I2C error).

Only. When I had the sensor on the window. He fell. But I can't believe that after that it began to show exorbitant values.

shojkeee · 2022-04-19T09:43:57Z

That's also why I'm thinking of collibration. Before the calibration, the sensor transmitted data to the home assistant for a day. And I compared the data with sgp30. And they differed of course. But both reacted to the tvoc change.

RobTillaart · 2022-04-19T09:57:58Z

Only. When I had the sensor on the window. He fell. But I can't believe that after that it began to show exorbitant values.

It might be possible but unlikely in my opinion. If you shake it gently do you

hear loose parts on the inside
see (big) changes in the readings
(any yes would indicate hardware problems, a no is no proof of absence of damage.)

RobTillaart · 2022-04-19T10:06:51Z

That's also why I'm thinking of collibration. Before the calibration, the sensor transmitted data to the home assistant for a day. And I compared the data with sgp30. And they differed of course. But both reacted to the tvoc change.

Factor 10 difference is quite large. Is that difference constant?

Do you power the sensor with 3V3 or with 5V? (5V is more stable as 3V3 is the minimum for the sensor

shojkeee · 2022-04-19T10:20:18Z

No. No damage. I disassembled the case. But I thought that the dust could get into a small hole. Washed it in alcohol and left to dry. I'll check it out in 6 hours and report back. Also, if possible, check your calibrate.19.04.2022, 12:58, "Rob Tillaart" ***@***.***>: Only. When I had the sensor on the window. He fell. But I can't believe that after that it began to show exorbitant values. It might be possible but unlikely in my opinion. If you shake it gently do you hear loose parts on the inside see (big) changes in the readings (any yes would indicate hardware problems, a no is no proof of absence of damage.) —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

shojkeee · 2022-04-19T15:00:26Z

That's also why I'm thinking of collibration. Before the calibration, the sensor transmitted data to the home assistant for a day. And I compared the data with sgp30. And they differed of course. But both reacted to the tvoc change.

Factor 10 difference is quite large. Is that difference constant?

Do you power the sensor with 3V3 or with 5V? (5V is more stable as 3V3 is the minimum for the sensor

I washed the sensor, dried it. It didn't give any results. I used esp32. I decided to try it on arduino Uno. I recolibrated, other values began to be shown. They are also not faithful

RobTillaart · 2022-04-19T15:07:47Z

The calibration command in the library is exact according to the datasheet.
It could have triggered some other bug in the sensor.

just a thought:
Can you check if the UNO gives other values than the ESP?
if so it might point toward problems with power supply.

shojkeee · 2022-04-19T15:13:21Z

The calibration command in the library is exact according to the datasheet. It could have triggered some other bug in the sensor.

just a thought: Can you check if the UNO gives other values than the ESP? if so it might point toward problems with power supply.

Yes. The values are different. ESP32 has:99999 And uno has: 34343

RobTillaart · 2022-04-19T15:18:34Z

Q: did you read the other issue - #11
It is closed, but it shows that there are at least two versions of the sensor V17 and V18.

Can you check which version you have (I have only V17).

shojkeee · 2022-04-19T15:26:21Z

yes. The version is really 118((((. And what should I do now?

RobTillaart · 2022-04-19T15:29:12Z

The calibration command in the library is exact according to the datasheet. It could have triggered some other bug in the sensor.
just a thought: Can you check if the UNO gives other values than the ESP? if so it might point toward problems with power supply.

Yes. The values are different. ESP32 has:99999 And uno has: 34343

So there are two important observations:

The sensor gives different data depending on the board that is requesting data. (could be power issue)
The values reported are too constant, I would expect small but detectable noise (+-1) on the signal.

shojkeee · 2022-04-19T15:31:22Z

The calibration command in the library is exact according to the datasheet. It could have triggered some other bug in the sensor.
just a thought: Can you check if the UNO gives other values than the ESP? if so it might point toward problems with power supply.

Yes. The values are different. ESP32 has:99999 And uno has: 34343

So there are two important observations:

The sensor gives different data depending on the board that is requesting data. (could be power issue)

The values reported are too constant, I would expect small but detectable noise (+-1) on the signal.

Could it be that due to the fact that the version of the sensor is different, the calibration has overwritten everything and now it is faulty? and do I need to program it somehow?

RobTillaart · 2022-04-19T15:32:20Z

yes. The version is really 118((((. And what should I do now?

My experience with version 18 is limited to what is mentioned in issue #11 Lets ask Beanow who also has a v 18.

@Beanow
Question: did you run calibration on your sensor? if so, did you encounter problems like above?

RobTillaart · 2022-04-19T15:59:30Z

Could it be that due to the fact that the version of the sensor is different, the calibration has overwritten everything and now it is faulty? and do I need to program it somehow?

In theory that could be the case, however calibration is a process the sensor does internally.
In this process the sensor makes a lot of measurements until these stabilizes (that is why it takes time to calibrate).
The calibration command itself is typical a command that stores the found (stabile) values in internal EEPROM for later use.
When the sensor is making new measurements it can refer to that zero point, to calculate the right value.
The zero level is typical used as an offset for a raw measurement.

I have two slightly different datasheets of the sensor and both have the same command for the calibration.
None is mentioning that there are differences between versions.
In fact we tries to contact the manufacturer of the sensor (in issue #11 ) and got no new information about V 18.

You might check chapter 8 of the datasheet which mentions several pages of possible problems with the sensor.
They are pretty sensitive to almost anything.

I do not know if there is a way to manually provide calibration data. There are registers in the sensor that are not documented and these might include calibration values (seems logical). No info on this.

shojkeee · 2022-04-19T16:02:50Z

Could it be that due to the fact that the version of the sensor is different, the calibration has overwritten everything and now it is faulty? and do I need to program it somehow?

In theory that could be the case, however calibration is a process the sensor does internally. In this process the sensor makes a lot of measurements until these stabilizes (that is why it takes time to calibrate). The calibration command itself is typical a command that stores the found (stabile) values in internal EEPROM for later use. When the sensor is making new measurements it can refer to that zero point, to calculate the right value. The zero level is typical used as an offset for a raw measurement.

I have two slightly different datasheets of the sensor and both have the same command for the calibration. None is mentioning that there are differences between versions. In fact we tries to contact the manufacturer of the sensor (in issue #11 ) and got no new information about V 18.

You might check chapter 8 of the datasheet which mentions several pages of possible problems with the sensor. They are pretty sensitive to almost anything.

I do not know if there is a way to manually provide calibration data. There are registers in the sensor that are not documented and these might include calibration values (seems logical). No info on this.

The sensor worked exactly out of the box. As soon as I started the calibration, the values became the same and constant and very high.Yes, he fell at me. But I disassembled it, there's nothing to break from the impact.

Beanow · 2022-04-19T17:05:01Z

After my previous experience with the device, and having no different sensor types or controlled environment to compare, I didn't touch the calibration function. But I can test it later.

Voltage

Some things I can say up front, I've had no noticeable issues running on the ESP32's 3.3v, or seen different values for 5v.
I'm even sharing the 3.3v, ground and I2C wires with a BME sensor (board I have requires 3.3v, hence using that).

Too constant

Like @RobTillaart mentioned,

The values reported are too constant, I would expect small but detectable noise (+-1) on the signal.

I agree, even for bad quality readings I normally see fluctuations all the time.

Here's what I got in the past 24h of 1s interval raw data from one. This is indoors and it roughly corresponds to outside air quality and ventilation, but don't have means to determine accuracy properly.

About alcohol

Washed it in alcohol and left to dry.

Keep in mind that the sensor responds to alcohol fumes. Since the datasheet suggests 5 minutes of "fresh air". However they define fresh (Cleanroom levels of controlled environment fresh? Outside urban air fresh?). I wouldn't try calibrating when the alcohol might still spike the readings.

Here's the chart when I hold the sensor directly above an open bottle of 99,9% isopropyl alcohol.
Peak nearly 34k PPB. 10 minutes later still not back to the stable reading from before.

Warmup period

One reason I can think of why you might have had this 10x reading, is warmup period.

In my experience, when the sensor has been powered off for some time (a few days or more). It can take very very long for values to come down to normal. It can sometimes take multiple hours of leaving the sensor running before the reading stabilizes.

For something like calibration, I would suggest you leave the sensor powered on and polling values for something like 10h or more, and then calibrate. I think the datasheet's 5 minutes is extremely optimistic.

Because your values are so extreme, suspicious and constant (99,999 / 34,343). Maybe the internal readings it got were just bad due to warmup issues that the chip is running into some type of integer overflow problems.

shojkeee · 2022-04-19T17:18:56Z

@Beanow It's already late. The sensor now shows nonsense all the time and the maximum values ((( But I agree with you, the values I had all night were gradually getting lower and lower.

Yes. If it is not difficult, try to calibrate. But keep in mind! you can also break the sensor(

Beanow · 2022-04-19T17:28:15Z

But I agree with you, the values I had all night were gradually getting lower and lower.

That looks like the warmup period. When I first connected the sensor it would go from absurdly high like 30k, down fairly quick to <1000 PPB. But going down to something like ~15 PPB on a good (urban) air quality day, would take many hours. Basically in a logarithmic shape. The closer it got to realistic values, the longer it took to warm up.

But keep in mind! you can also break the sensor.

Yeah. I'm fine with that. To be honest I don't trust this sensor at all. The v18 version is basically undocumented because there's no new datasheet to match the new version, the ug/m3 functionality doesn't work. The status flags don't work. I couldn't get a response from the manufacturer. Their HTTP-only website lists the old datasheet...

It's another reason why I don't care too much about the calibration, I only trust it to produce relative values. For example "how much does the value change compared to itself an hour ago, if I open the windows".

shojkeee · 2022-04-19T17:39:47Z

@Beanow I wanted to compare it with sgp30. That's why I decided to calibrate it. Now I don't know what to do(((

Beanow · 2022-04-19T17:47:18Z

Well you said it's late there.
For now, I would upload the PPB example sketch and let it warm up overnight and try again tomorrow 😄
If you're lucky the problem was only bad values from warmup and calibrating again later may give better results.

shojkeee · 2022-04-19T17:51:38Z

@Beanow OK. I'll put it on overnight. and then I'll try to calibrate.

RobTillaart · 2022-04-19T18:23:34Z

@Beanow Thanks for your comments, appreciated.

Beanow · 2022-04-21T18:33:29Z

You could also try to use it to compensate for the bad behavior when it's got the 125 status, if you like the calibration results from an automatic run, you could put the value it found in your sketch and reapply it every time you don't have the 12 status.

RobTillaart · 2022-04-21T18:33:34Z

Well my thinking is, perhaps they have got a full blown formula for their raw value to PPB mapping, and the 100-1k-10k are just precomputed points / ranges, so it's easier to apply?

thinking out loud

If I would make such sensor, I would have some physics that gave me a raw value X (typically a voltage)
To convert that to a value Y = aX + b would mean that calibration needs to find the value for a and b.

a = the slope and that might be related to the area of the sensor (a bigger area gives typical more raw value) This is typical factory calibrated.
b = related to the zero point. This is the value to find.

And to prevent floating point operations all measurements are scaled up a factor F to make them integer.
That is where those 100, 1000 and 10000 come in I think.
(we did not think of registers as floating point values ...)

RobTillaart · 2022-04-21T18:36:37Z

Well that wouldn't support the additional feature of the v118 of being able to set it manually 🤷
It's kind of interesting actually.

Agree, the manual version will be added to the library, but explicit for the user.
My current thought is:

bool AGS02MA::zeroCalibrationManual(uint16_t value = 0)
{
  _buffer[0] = 0x00;
  _buffer[1] = 0x0C;
  _buffer[2] = (value >> 8);
  _buffer[3] = (value & 0xFF);
  _buffer[4] = _CRC8(_buffer, 4);
  return _writeRegister(AGS02MA_CALIBRATION);
}

bool AGS02MA::zeroCalibration()
{
  return zeroCalibrationManual(0);  
}

RobTillaart · 2022-04-21T18:38:32Z

Well my thinking is, perhaps they have got a full blown formula for their raw value to PPB mapping, and the 100-1k-10k are just precomputed points / ranges, so it's easier to apply?

You mean that these are points for non-linear interpolation - different ranges, - different parameters.?

Beanow · 2022-04-21T18:39:49Z

Agree, the manual version will be added to the library, but explicit for the user.

Yeah, I think that makes sense. And we should probably add more helper functions to read it too.
At least the current zeroCalibration value, (REG[1] bank B), maybe the status part too.

I'm thinking what an updated example calibration sketch would look like. And I know I would have loved if it logged the factory value before doing the first calibration, knowing now that I could have reverted the v118 for comparison. As well as what it ended up finding.

RobTillaart · 2022-04-21T18:46:52Z

Sounds like I have some coding to do tomorrow :)

shojkeee · 2022-04-21T18:48:24Z

You guys are very cool. I'm sitting here reading all this and just giving you a standing ovation. Thank you, you are the best.

Beanow · 2022-04-21T18:48:28Z

I can set up a PR as a starting point.
As a sidenote, I don't think I will be needing all three of the sensors I have. If you're interested I can send you a v118 for comparing. If I change my mind, can order new ones later. No guarantee what version that will be though, hence I thought I could send one you know what version it'll be 😛

RobTillaart · 2022-04-21T19:10:54Z

Tinytronics.nl asair-ags02ma-tvoc-gassensor
they said they have version 117 in stock

RobTillaart · 2022-04-21T19:23:25Z

we need

bool AGS02MA::zeroCalibrationManual(uint16_t value = 0)
uint32_t getRegister(uint8_t reg)
uint16_t getRegisterMSB(uint8_t reg) get 2 MSB bytes
uint16_t getRegisterLSB(uint8_t reg) get 2 LSB bytes
uint32_t getZeroCalibrationRegister(); wrapper around getRegister(1)

calibration sketch

reads and prints the version of the library
reads and prints the version number of the sensor (1 byte)
read 5x PPB values before
reads and prints current calibration (4 bytes)
asks for automatic / manual calibration
manual => asks value (0 .. 0xFFFF ?)
reads calibration afterwards (4 bytes).
read 5x PPB values afterwards to see results

interactive example (do we need this?)

calibrate
switch mode
read values
read registers
etc

Beanow · 2022-04-21T19:47:31Z

Haha ok tomorrow it is,

uint32_t getRegister(uint8_t reg)
uint16_t getRegisterMSB(uint8_t reg) get 2 MSB bytes
uint16_t getRegisterLSB(uint8_t reg) get 2 LSB bytes

One thought though, I assume this would be private? I think if people were to extensively rely on directly reading registers, they wouldn't need the library anyway and may just cherrypick I2C protocol code they need 🤷

I feel like the most useful functions are when they do the interpreting for you.
Like getSensorVersion() and readPPB() which add context to an otherwise opaque registers like
[undocumented date | version byte] or [status flags + 24 bit integer]

Such context I think would look more like:

uint16_t getZeroCalibrationStatusFlags(); = getRegisterMSB(1);
uint16_t getZeroCalibrationValue(); = getRegisterLSB(1);
bool setZeroCalibrationValue(uint16_t value);

Edit: actually thinking about that again. Dumping the registers was super useful for reverse engineering all the stuff the datasheet doesn't tell you. If in a few weeks someone gets a hold of a mysterious and misbehaving v119... it would be useful to ask them to make dumps like these. 😄

RobTillaart · 2022-04-22T08:00:29Z

@Beanow

I can set up a PR as a starting point.

Please prepare a PR - version may be bumped to 0.2.0

Beanow · 2022-04-22T14:39:46Z

PR is up! Have a look #15

RobTillaart · 2022-04-24T07:30:15Z

@Beanow

follow up thought about interpolation,

from above

REG[1]	0	12	14	21
REG[2]	0	100	6	162	
REG[3]	3	232	3	251	
REG[4]	39	16	1	102

if I interpret these as (x,y) we have { (18, 3605) , (100,1698), (1000, 1019), (10000, 350) } == some exp(-x) function?
All the register dumps I have seen show this decreasing Y pattern (both 118 and 117 version).
So yes, all dumps are in line with this lookup table hypothesis.

Q: can it help convert a raw measurement to something "cooked"?

Beanow · 2022-04-24T12:16:56Z

Q: can it help convert a raw measurement to something "cooked"?

@RobTillaart that's exactly what I have in mind for #16
Because the register dumping and interpretation happens in the example sketch, it should be easy for ourselves and others to hack around and add more interpretations, without needing to modify the library itself quite yet.

For example, going with the previous interpretation of: maybe they're instead of storing floats.

REG[0x0]	0	0	3	30	C: 166		Sensor data:	0	798
REG[0x1]	0	125	5	129	C: 249		Calibration:	125	1409
REG[0x2]	0	100	1	247	C: 148		Internal LUT:	100	503	y/x:	5.03000
REG[0x3]	3	232	0	179	C: 171		Internal LUT:	1000	179	y/x:	0.17900
REG[0x4]	39	16	0	63	C: 122		Internal LUT:	10000	63	y/x:	0.00630
REG[0x5]	238	72	35	40	C: 205	
REG[0x6]	26	0	0	18	C: 213	
REG[0x7]	0	219	160	169	C: 71	
REG[0x8]	130	118	0	10	C: 112	
REG[0x11]	21	2	3	118	C: 133		Version:	118
REG[0x20]	0	0	219	130	C: 17	
REG[0x21]	26	229	26	229	C: 113		I2C address:	0x1A

Btw, would like to complete the PRs before going down the rabbit hole too much 😅.

Beanow · 2022-04-24T16:23:21Z

Q: can it help convert a raw measurement to something "cooked"?

Or if you meant, using logic in the library to find a PPB value based on the raw data in reg x20. Perhaps that is worth splitting out from the main library. With #16 it would be possible to access the data. Adding a bunch of math to use the raw value and/or maybe an AQI score would probably add code that not everyone is interested in using.

In my case, I use the PPB readings, send it over MQTT it would make just as much sense to do AQI scoring on the server.

RobTillaart · 2022-04-25T11:29:03Z

Agree, lets keep it simple

RobTillaart · 2022-04-25T11:40:32Z

@shojkeee @Beanow
This issue is closed as the calibration code for 118 is merged into the 0.2.0 version of the library.
If needed it can be reopened, but I prefer a new issue if needed.

shojkeee · 2022-04-25T11:40:54Z

Closed?( I have not waited for calibration for version 118(((

RobTillaart · 2022-04-25T11:50:14Z

@shojkeee
Beanow also has a 118 version sensor tested and it worked for him. For me enough reason to merge the code.

If you still have problems with calibration please reopen this issue.

shojkeee · 2022-04-25T11:56:06Z

So I didn't understand anything. You haven't released a new version yet. Where can I get a sketch for the calibration?? I'm completely confused.

RobTillaart · 2022-04-25T11:58:43Z

https://github.com/RobTillaart/AGS02MA

RobTillaart · 2022-04-25T11:59:43Z

It takes a while before the Arduino library manager copies new versions of libraries.
Fastest was within an hour slowest was days even weeks.

shojkeee · 2022-04-25T12:00:49Z

sorry. release 22 minutes ago. I missed((I just watched it a couple of hours ago, there was another version.

RobTillaart · 2022-04-25T12:03:05Z

No problem, I just hope it solves your problem (it should)

Beanow · 2022-04-26T13:29:42Z

Looks like 0.2.0 is available in the arduino library manager, try updating and see if the updated example sketches for calibration solve your issue. 👌

shojkeee · 2022-04-26T16:09:16Z

Yes. Thank you. I updated and calibrated everything yesterday! Thank you all. Very helpful. But I still ordered the sensor))

RobTillaart self-assigned this Apr 19, 2022

RobTillaart added the question Further information is requested label Apr 19, 2022

Beanow mentioned this issue Apr 22, 2022

Manual zero calibration #15

Merged

RobTillaart closed this as completed in #15 Apr 25, 2022

RobTillaart mentioned this issue Apr 24, 2023

v118, Calibration data resets after power loss. Do i have to run calibrate sketch in open air every time the power is lost. is there an easier solution? #22

Closed

After calibration, incorrect data #13

After calibration, incorrect data #13

Comments

shojkeee commented Apr 19, 2022

shojkeee commented Apr 19, 2022

shojkeee commented Apr 19, 2022

RobTillaart commented Apr 19, 2022

shojkeee commented Apr 19, 2022

shojkeee commented Apr 19, 2022

RobTillaart commented Apr 19, 2022

shojkeee commented Apr 19, 2022

shojkeee commented Apr 19, 2022

RobTillaart commented Apr 19, 2022

RobTillaart commented Apr 19, 2022

shojkeee commented Apr 19, 2022 via email

shojkeee commented Apr 19, 2022

RobTillaart commented Apr 19, 2022

shojkeee commented Apr 19, 2022

RobTillaart commented Apr 19, 2022

shojkeee commented Apr 19, 2022

RobTillaart commented Apr 19, 2022

shojkeee commented Apr 19, 2022

RobTillaart commented Apr 19, 2022

RobTillaart commented Apr 19, 2022

shojkeee commented Apr 19, 2022

Beanow commented Apr 19, 2022

Voltage

Too constant

About alcohol

Warmup period

shojkeee commented Apr 19, 2022

Beanow commented Apr 19, 2022 • edited Loading

shojkeee commented Apr 19, 2022

Beanow commented Apr 19, 2022

shojkeee commented Apr 19, 2022

RobTillaart commented Apr 19, 2022

Beanow commented Apr 21, 2022

RobTillaart commented Apr 21, 2022

thinking out loud

RobTillaart commented Apr 21, 2022

RobTillaart commented Apr 21, 2022

Beanow commented Apr 21, 2022 • edited Loading

RobTillaart commented Apr 21, 2022

shojkeee commented Apr 21, 2022

Beanow commented Apr 21, 2022 • edited Loading

RobTillaart commented Apr 21, 2022 • edited Loading

RobTillaart commented Apr 21, 2022

calibration sketch

interactive example (do we need this?)

Beanow commented Apr 21, 2022 • edited Loading

RobTillaart commented Apr 22, 2022 • edited Loading

Beanow commented Apr 22, 2022

RobTillaart commented Apr 24, 2022 • edited Loading

Beanow commented Apr 24, 2022

Beanow commented Apr 24, 2022

RobTillaart commented Apr 25, 2022

RobTillaart commented Apr 25, 2022

shojkeee commented Apr 25, 2022

RobTillaart commented Apr 25, 2022

shojkeee commented Apr 25, 2022

RobTillaart commented Apr 25, 2022

RobTillaart commented Apr 25, 2022

shojkeee commented Apr 25, 2022

RobTillaart commented Apr 25, 2022

Beanow commented Apr 26, 2022

shojkeee commented Apr 26, 2022

Beanow commented Apr 19, 2022 •

edited

Loading

Beanow commented Apr 21, 2022 •

edited

Loading

Beanow commented Apr 21, 2022 •

edited

Loading

RobTillaart commented Apr 21, 2022 •

edited

Loading

Beanow commented Apr 21, 2022 •

edited

Loading

RobTillaart commented Apr 22, 2022 •

edited

Loading

RobTillaart commented Apr 24, 2022 •

edited

Loading