The mode is a lie? #11

Beanow · 2022-01-20T16:30:25Z

Or at least, the datasheet and output don't seem to match up. Is this how your (v117) devices behave as well?

I've got three (v118) AGS02MA here, that I wasn't able to get into UGM3 measurements on some custom ESP IDF code. Thought I was going mad so I tried an Arduino uno with your library and see the same results, not really changing modes apparently.

Looking at the datasheet, I'd expect the status value to change.

b0000 (decimal 0) for ready + PPB mode.
b0010 (decimal 2) for ready + UGM3 mode.

Using an adaptation of the library example code, I set up one that alternates modes every 10 measurements. Except that it doesn't? Here's some output I'm seeing with the status being 0 throughout. And no noticeable change in measured value either (other than going down as it warms up).

/home/beanow/duino/AGS02MA_PPB/AGS02MA_PPB.ino
AGS02MA_LIB_VERSION: 0.1.3

BEGIN:	1
VERSION:	118
VERS:	118
MODE:	1	0
PPB:	85	0	0
PPB:	85	0	0
PPB:	85	0	0
PPB:	85	0	0
PPB:	85	0	0
PPB:	85	0	0
PPB:	85	0	0
PPB:	85	0	0
PPB:	85	0	0
PPB:	85	0	0
MODE:	1	1
UGM3:	85	0	0
UGM3:	85	0	0
UGM3:	85	0	0
UGM3:	85	0	0
UGM3:	85	0	0
UGM3:	85	0	0
UGM3:	84	0	0
UGM3:	84	0	0
UGM3:	84	0	0
UGM3:	84	0	0
MODE:	1	0
PPB:	84	0	0
PPB:	84	0	0
PPB:	84	0	0
PPB:	84	0	0
PPB:	84	0	0
PPB:	84	0	0
PPB:	84	0	0
PPB:	84	0	0
PPB:	84	0	0
PPB:	84	0	0
MODE:	1	1
UGM3:	83	0	0
UGM3:	83	0	0
UGM3:	83	0	0

//
//    FILE: AGS02MA_PPB.ino
//  AUTHOR: Rob Tillaart
// VERSION: 0.1.0
// PURPOSE: test application
//    DATE: 2021-08-12
//     URL: https://github.com/RobTillaart/AGS02MA
//

#include "AGS02MA.h"

AGS02MA AGS(26);

uint32_t rounds = 0;

void setup()
{
  Serial.begin(115200);
  Serial.println(__FILE__);

  Wire.begin();

  Serial.print("AGS02MA_LIB_VERSION: ");
  Serial.println(AGS02MA_LIB_VERSION);
  Serial.println();

  bool b = AGS.begin();
  Serial.print("BEGIN:\t");
  Serial.println(b);

  Serial.print("VERSION:\t");
  Serial.println(AGS.getSensorVersion());

  // pre-heating improves measurement quality
  // can be skipped
//  Serial.println("\nWarming up (120 seconds = 24 dots)");
//  while (AGS.isHeated() == false)
//  {
//    delay(5000);
//    Serial.print(".");
//  }
//  Serial.println();

  uint8_t version = AGS.getSensorVersion();
  Serial.print("VERS:\t");
  Serial.println(version);
}


void loop()
{
  delay(3000);

  uint8_t kind = rounds % 20;

  // Switch mode every 10 and 20 rounds.
  bool b;
  if (kind == 0) {
    b = AGS.setPPBMode();
    uint8_t m = AGS.getMode();
    Serial.print("MODE:\t");
    Serial.print(b);
    Serial.print("\t");
    Serial.println(m);
  } else if (kind == 10) {
    b = AGS.setUGM3Mode();
    uint8_t m = AGS.getMode();
    Serial.print("MODE:\t");
    Serial.print(b);
    Serial.print("\t");
    Serial.println(m);
  }

  // Read PPB in first half of a 20-round cycle.
  if (kind < 10) {
    uint32_t value = AGS.readPPB();
    Serial.print("PPB:\t");
    Serial.print(value);
    Serial.print("\t");
    Serial.print(AGS.lastStatus(), HEX);
    Serial.print("\t");
    Serial.print(AGS.lastError(), HEX);
    Serial.println();
  } else {
    uint32_t value = AGS.readUGM3();
    Serial.print("UGM3:\t");
    Serial.print(value);
    Serial.print("\t");
    Serial.print(AGS.lastStatus(), HEX);
    Serial.print("\t");
    Serial.print(AGS.lastError(), HEX);
    Serial.println();
  }

  rounds++;
}


// -- END OF FILE --

The text was updated successfully, but these errors were encountered:

RobTillaart · 2022-01-20T16:48:06Z

@Beanow
Thanks for filing this issue. It has been several months I have worked with the sensor and I do not recall seeing such behavior, but I did not test all possible scenario's.

If time permits coming days I will make a test setup and look if I can recreate the problem.

I have one related remark in the readme.md under future check the mode bits of the status byte with internal _mode.

Beanow · 2022-01-20T17:33:17Z

Thanks! Would be great to compare and know if something is different about the 118 version or whether it's the same for 117.

AGS02MA/AGS02MA.cpp

Lines 104 to 111 in e42a538

    
           // unclear what the other bytes have for information. 
        
           // datasheet names these 3 bytes as KEEP. 
        
           // BUFFER        VALUE  MEANING 
        
           // buffer [0] == 20     year ? 
        
           // buffer [1] == 07     month ? 
        
           // buffer [2] == 28     day ? 
        
           // buffer [3] == 117    VERSION 
        
           // buffer [4] ==        CRC

Comparing those it does look like a date in the first bytes btw.
Mine reports 21, 2, 3, 118, CRC looking like 2021-feb-3.

Sourced at https://nl.aliexpress.com/item/1005003131194702.html
Though I can test sketches or ship one if needed for comparison.

RobTillaart · 2022-01-20T18:05:54Z

YES, found the sensor rather quick.

Ran your sketch inhouse

19:01:41.644 -> AGS02MA_LIB_VERSION: 0.1.3
19:01:41.644 -> 
19:01:41.644 -> BEGIN:	1
19:01:41.644 -> VERSION:	117
19:01:41.737 -> VERS:	117
19:01:44.783 -> MODE:	1	0
19:01:44.830 -> PPB:	856	11	0
19:01:47.876 -> PPB:	848	11	0
19:01:50.876 -> PPB:	838	11	0
19:01:53.922 -> PPB:	831	11	0
19:01:56.962 -> PPB:	824	11	0
19:01:59.997 -> PPB:	819	11	0
19:02:03.043 -> PPB:	814	10	0
19:02:06.089 -> PPB:	810	10	0
19:02:09.134 -> PPB:	803	10	0
19:02:12.134 -> PPB:	800	10	0
19:02:15.180 -> MODE:	1	1
19:02:15.227 -> UGM3:	793	13	0                 <<<<<<<<<<<<<< bit strange
19:02:18.270 -> UGM3:	1852	12	0
19:02:21.316 -> UGM3:	1827	12	0
19:02:24.315 -> UGM3:	1809	12	0
19:02:27.363 -> UGM3:	1793	12	0
19:02:30.426 -> UGM3:	1781	12	0
19:02:33.439 -> UGM3:	1786	12	0
19:02:36.496 -> UGM3:	1758	12	0
19:02:39.531 -> UGM3:	1777	12	0
19:02:42.553 -> UGM3:	1786	12	0
19:02:45.563 -> MODE:	1	0
19:02:45.608 -> PPB:	1802	11	0     <<<<<<<  switching artefact?
19:02:48.684 -> PPB:	783	10	0
19:02:51.683 -> PPB:	782	10	0
19:02:54.729 -> PPB:	773	10	0
19:02:57.769 -> PPB:	756	10	0
19:03:00.816 -> PPB:	748	10	0
19:03:03.853 -> PPB:	739	10	0
19:03:06.887 -> PPB:	731	10	0
19:03:09.940 -> PPB:	726	10	0
19:03:12.985 -> PPB:	717	10	0
19:03:15.985 -> MODE:	1	1
19:03:16.031 -> UGM3:	715	13	0     <<<<<<<<<<<<<<<<<<< idem
19:03:19.067 -> UGM3:	1625	12	0
19:03:22.113 -> UGM3:	1614	12	0
19:03:25.159 -> UGM3:	1621	12	0

Although there seems to be a switching artefact I got quite different values for PPB and UGM3.

Beanow · 2022-01-20T18:13:57Z

Whoa that's weird. Plus you seem to have more data in the status byte. The internal use bits I presume. I think the switching artifact might be right. The datasheet does say it takes 2s to switch modes, and my sketch doesn't have the delay for that.

How have you wired it. Are you using any external resistors? I did read something about that, but assumed that is about the internal pullup. Also your readout is a lot higher, mine eventually settles on about ~61 PPB(?) in the living room.

Ah, I see yours is tumbling down, so I assume that's still warmup as well. Mine started at some obscene values like 35000, takes a while to settle down.

RobTillaart · 2022-01-20T18:24:39Z

switching
OK, 2 second delay might solve it (will try later)

Wiring
Arduino UNO - IDE 1.18.19 - no resistors - 10 cm wires.

Values
I let it run for some time as it seems to drop its value still (sensor came from my working room which is more dusty?)
Don't know how far it will drop bit your values seem very low to me.

19:19:59.289 -> MODE:	1	0
19:19:59.336 -> PPB:	961	11	0
19:20:02.407 -> PPB:	418	10	0
19:20:05.418 -> PPB:	418	10	0
19:20:08.463 -> PPB:	419	10	0
19:20:11.483 -> PPB:	419	10	0
19:20:14.557 -> PPB:	416	10	0
19:20:17.551 -> PPB:	417	10	0
19:20:20.622 -> PPB:	418	10	0
19:20:23.633 -> PPB:	417	10	0
19:20:26.705 -> PPB:	414	10	0
19:20:29.682 -> MODE:	1	1
19:20:29.762 -> UGM3:	417	13	0
19:20:32.771 -> UGM3:	952	12	0
19:20:35.816 -> UGM3:	950	12	0
19:20:38.869 -> UGM3:	950	12	0
19:20:41.925 -> UGM3:	954	12	0
19:20:44.956 -> UGM3:	961	12	0
19:20:47.961 -> UGM3:	959	12	0
19:20:51.030 -> UGM3:	957	12	0
19:20:54.036 -> UGM3:	952	12	0
19:20:57.096 -> UGM3:	950	12	0

(You're from Netherlands? Me ZO Brabant)

Beanow · 2022-01-20T18:36:07Z

Yep, Rotterdam here.

Could they have changed (or messed up) the protocol for v118? 🤔
I get no mode switching and no status byte at all.

The value dropping can take a long time indeed. Much longer than the 120s. Datasheet does mention something about that.

Haven't tracked exactly, but did take hours not minutes to settle on 60 PPB.

Switching to another sensor that was powered off, you can see it drop from higher values.


/home/beanow/duino/AGS02MA_PPB/AGS02MA_PPB.ino
AGS02MA_LIB_VERSION: 0.1.3

BEGIN:	1
VERSION:	118
VERS:	118
MODE:	1	0
PPB:	2133	0	0
PPB:	1671	0	0
PPB:	1466	0	0
PPB:	1330	0	0
PPB:	1234	0	0
PPB:	1157	0	0
PPB:	1098	0	0
PPB:	1047	0	0
PPB:	1004	0	0
PPB:	960	0	0
MODE:	1	1
UGM3:	886	0	0
UGM3:	855	0	0
UGM3:	830	0	0
UGM3:	807	0	0
UGM3:	786	0	0
UGM3:	766	0	0
UGM3:	749	0	0
UGM3:	735	0	0
UGM3:	717	0	0
UGM3:	703	0	0
MODE:	1	0
PPB:	680	0	0
PPB:	667	0	0
PPB:	657	0	0
PPB:	648	0	0
PPB:	639	0	0
PPB:	627	0	0
PPB:	622	0	0
PPB:	614	0	0
PPB:	606	0	0
PPB:	602	0	0
MODE:	1	1
UGM3:	586	0	0
UGM3:	580	0	0
UGM3:	574	0	0
UGM3:	566	0	0
UGM3:	560	0	0
UGM3:	556	0	0
UGM3:	549	0	0
UGM3:	543	0	0
UGM3:	539	0	0
UGM3:	533	0	0

Beanow · 2022-01-20T18:43:52Z

I'll try mess around with the wiring. And maybe external power, currently running off USB power to the UNOs. 5v and short wires onto a breadboard from there. Though I do assume this is handled with the internal pullup.

RobTillaart · 2022-01-20T18:50:07Z

If you get readings like that the signal is good to perfect, No pull ups needed.

An excellent reader about pull ups - http://www.gammon.com.au/forum/?id=10896&reply=5#reply5
(there is plenty more info there)

Beanow · 2022-01-20T18:52:11Z

It's at least responding to gasses though. Here's holding it right up to a lighter's gas.


MODE:	1	0
PPB:	125	0	0
PPB:	124	0	0
PPB:	124	0	0
PPB:	124	0	0
PPB:	124	0	0
PPB:	124	0	0
PPB:	123	0	0
PPB:	1376	0	0
PPB:	6278	0	0
PPB:	12794	0	0
MODE:	1	1
UGM3:	25712	0	0
UGM3:	14832	0	0
UGM3:	9008	0	0
UGM3:	5105	0	0
UGM3:	3157	0	0
UGM3:	2148	0	0
UGM3:	1534	0	0
UGM3:	1143	0	0
UGM3:	818	0	0
UGM3:	560	0	0
MODE:	1	0
PPB:	314	0	0
PPB:	250	0	0
PPB:	209	0	0
PPB:	1259	0	0
PPB:	3814	0	0
PPB:	5548	0	0
PPB:	4027	0	0
PPB:	1876	0	0
PPB:	902	0	0
PPB:	381	0	0
MODE:	1	1
UGM3:	165	0	0
UGM3:	2142	0	0
UGM3:	17367	0	0
UGM3:	4294935791	0	0    <==== weird, overflow?
UGM3:	19033	0	0
UGM3:	11041	0	0
UGM3:	5453	0	0
UGM3:	3070	0	0
UGM3:	1946	0	0
UGM3:	1298	0	0
MODE:	1	0
PPB:	497	0	0
PPB:	341	0	0
PPB:	254	0	0
PPB:	201	0	0
PPB:	165	0	0
PPB:	141	0	0
PPB:	124	0	0
PPB:	119	0	0
PPB:	115	0	0
PPB:	112	0	0
MODE:	1	1
UGM3:	107	0	0
UGM3:	104	0	0
UGM3:	103	0	0
UGM3:	101	0	0

RobTillaart · 2022-01-20T18:52:43Z

still dropping on this side

19:50:41.810 -> PPB:	368	10	0
19:50:44.812 -> PPB:	367	10	0
19:50:47.875 -> PPB:	371	10	0
19:50:50.894 -> PPB:	372	10	0
19:50:53.908 -> MODE:	1	1
19:50:53.955 -> UGM3:	370	13	0
19:50:56.991 -> UGM3:	831	12	0
19:51:00.042 -> UGM3:	849	12	0
19:51:03.082 -> UGM3:	833	12	0

RobTillaart · 2022-01-20T18:56:26Z

Thanks! Would be great to compare and know if something is different about the 118 version or whether it's the same for 117.

My datasheet has version V1.2-20200306, yours?
Is there a newer one?

Beanow · 2022-01-20T19:00:37Z

Not that I've found anyway. The vendor didn't list a datasheet at all. So I just searched for it and the v1.2 seems all over the place.

Though if those version bytes are really dates, doth the v117 (2020-07-28) and v118 (2021-02-03) would be later revisions than this document.

RobTillaart · 2022-01-20T19:08:50Z

On the back of the sensor I have SNH 12 02 40 16 36
Serial number, no clue what it means, although reading it backwards it looks partially like a date...

Beanow · 2022-01-20T19:14:00Z

So judging by the footer of the datasheet, the manufacturer's site is aosong.com.
On the english product page there seems to be no datasheet and the chinese page has the v1.2 manual with the same date.

Serials wise I've got

SNI 1212827788
SNJ 1210935393
SNJ 1210934065

RobTillaart · 2022-01-20T19:21:14Z

So serial wise you seem to have at least two different batches. The SNJ number differs 1400 so pretty close.

RobTillaart · 2022-01-20T19:37:19Z

I am preparing a 0.1.4 version to add a function uitn32_t getSensorDate()
if you print the number as HEX you get a date.

uint32_t dd = sensor.getSensorDate();
Serial.println(dd, HEX);

(implementation might change, just a helper function for debugging)

RobTillaart · 2022-01-20T19:39:16Z

works

AGS02MA_LIB_VERSION: 0.1.4

BEGIN:	1
VERSION:	117
DATE:	28072020   <<<<<<<<<
VERS:	117
MODE:	1	0
PPB:	311	11	0

RobTillaart · 2022-01-20T20:08:16Z

BEGIN:	1
VERSION:	117
DATE:	28072020
VERS:	117
MODE:	1	0
PPB:	680	11	0    <<<<  status = 1 0001 busy bit set - meaning not ready which we see in an wrong value
PPB:	301	10	0    <<<<  status = 1 0000 busy bit clear - meaning data ready)
PPB:	305	10	0
PPB:	304	10	0
PPB:	306	10	0
PPB:	314	10	0
PPB:	309	10	0
PPB:	304	10	0
PPB:	297	10	0
PPB:	294	10	0
MODE:	1	1
UGM3:	290	13	0  <<<<  status = 1 0011 busy bit set + mode bit set =>UGM3 mode 
UGM3:	657	12	0  <<<<  status = 1 0010 busy bit clr + mode bit set =>UGM3 mode 
UGM3:	654	12	0

so status field gives correct info.

Question is if the read function should return some error or so?
Need to think that one over...

Beanow · 2022-01-20T20:11:36Z

It looks like the both

Sets the busy bit.
Returns the last known value of the previous mode.
So, possibly yes it might be good to error, since the readout isn't in the mode you'd expect, or what it's reporting!

Beanow · 2022-01-20T20:20:26Z

So I've messed about with resistors, 3.3v and 5v, and an external 1A power supply. None of which made any difference, unsurprisingly. I really think either the protocol changed or something isn't working properly and the v118 exists for silicon shortage reasons xD

RobTillaart · 2022-01-20T20:22:43Z

I have tested with an UNO which is 5V, you tested with ESP32 ?
The sensor works from 3V3 - 5V5 so it might be that the ESP just provides not enough "juice"?

Beanow · 2022-01-20T20:26:38Z

I'm testing with the UNO currently (tried it's 3.3V and 5V outputs).

The ESP-WROOM-32 I tried as well, but not using the Arduino IDE or your library. Wrote the I2C protocol with ESP-IDF referencing your library there and got the same results, no mode switching, 0x00 status byte.

And the juice was what I was thinking as well, hence I tried an external 5V 1A power supply, with the same results.

RobTillaart · 2022-01-20T20:35:24Z

It looks like the both

Sets the busy bit.

Returns the last known value of the previous mode.
So, possibly yes it might be good to error, since the readout isn't in the mode you'd expect, or what it's reporting!

The user can (should) check the ready bit after each mode switch with dataReady()
I can set error flag but the last read value of the previous mode might be useful so I do not clear it.
User needs to check the error or ready flag.

RobTillaart · 2022-01-20T20:39:52Z

added

#define AGS02MA_ERROR_NOT_READY     -13

and code in .cpp to set this error flag.

Beanow · 2022-01-20T21:01:07Z

So, since the datasheet isn't telling the whole truth, I decided to dump the registers.
There's plenty in there that's not mentioned in the datasheet. 🤔

Full dump

REG[0]	OK:1	Err:0	CRC:0	Buff:	0	0	0	4E	F5	
REG[1]	OK:1	Err:0	CRC:0	Buff:	0	7D	2	C0	5B	
REG[2]	OK:1	Err:0	CRC:0	Buff:	0	64	1	3A	9F	
REG[3]	OK:1	Err:0	CRC:0	Buff:	3	E8	0	8C	40	
REG[4]	OK:1	Err:0	CRC:0	Buff:	27	10	0	42	CE	
REG[5]	OK:1	Err:0	CRC:0	Buff:	EE	48	23	28	CD	
REG[6]	OK:1	Err:0	CRC:0	Buff:	1A	0	0	12	D5	
REG[7]	OK:1	Err:0	CRC:0	Buff:	1	B4	2C	85	8A	
REG[8]	OK:1	Err:0	CRC:0	Buff:	52	76	0	14	5	
REG[9]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[A]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[B]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[C]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[D]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[E]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[F]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[10]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[11]	OK:1	Err:0	CRC:0	Buff:	15	2	3	76	85	
REG[12]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[13]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[14]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[15]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[16]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[17]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[18]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[19]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[1A]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[1B]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[1C]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[1D]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[1E]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[1F]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[20]	OK:1	Err:0	CRC:0	Buff:	0	1	B4	82	9B	
REG[21]	OK:1	Err:0	CRC:0	Buff:	1A	E5	1A	E5	71	
REG[22]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[23]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[24]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF	
REG[25]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF
	...
REG[FF]	OK:1	Err:0	CRC:B1	Buff:	FF	FF	FF	FF	FF

removed "duplicates" to make it scrollable

RobTillaart · 2022-01-20T21:07:27Z

Can you make a 2nd dump up to reg 22 to see what changed?

Most is calibration stuff I expect, but it might also have some counters or last measured value?...

known registers
#define AGS02MA_DATA                  0x00
#define AGS02MA_CALIBRATION           0x01
#define AGS02MA_VERSION               0x11
#define AGS02MA_SLAVE_ADDRESS         0x21

see no patterns, too late :)

Beanow · 2022-01-20T21:12:47Z

I've at least grouped them by what the sheet mentions.
I'll have look at doing comparisons over time next.

Sensor data

REG[0]	OK:1	Err:0	CRC:0	Buff:	0	0	0	4E	F5

Zero calibration data

REG[1]	OK:1	Err:0	CRC:0	Buff:	0	7D	2	C0	5B

Undocumented

REG[2]	OK:1	Err:0	CRC:0	Buff:	0	64	1	3A	9F	
REG[3]	OK:1	Err:0	CRC:0	Buff:	3	E8	0	8C	40	
REG[4]	OK:1	Err:0	CRC:0	Buff:	27	10	0	42	CE	
REG[5]	OK:1	Err:0	CRC:0	Buff:	EE	48	23	28	CD	
REG[6]	OK:1	Err:0	CRC:0	Buff:	1A	0	0	12	D5	
REG[7]	OK:1	Err:0	CRC:0	Buff:	1	B4	2C	85	8A	
REG[8]	OK:1	Err:0	CRC:0	Buff:	52	76	0	14	5

Version number

REG[11]	OK:1	Err:0	CRC:0	Buff:	15	2	3	76	85

Undocumented

REG[20]	OK:1	Err:0	CRC:0	Buff:	0	1	B4	82	9B

I2C slave address

REG[21]	OK:1	Err:0	CRC:0	Buff:	1A	E5	1A	E5	71

RobTillaart · 2022-01-21T09:30:25Z

last version 0.1.4 shows explicit the not ready flag (in an uint32_t way)

BEGIN:	1
VERSION:	117
DATE:	20200728           <<<<< ISO date format
VERS:	117
MODE:	1	0
PPB:	0	11	FFFFFFF3    <<<<<<<  error = not ready
PPB:	0	11	FFFFFFF3
...
PPB:	0	11	FFFFFFF3
PPB:	485	10	0
MODE:	1	1
UGM3:	0	13	FFFFFFF3
UGM3:	1062	12	0
....

RobTillaart · 2022-01-21T10:18:21Z

A first (manual) analysis of the hex data gave a few hints

REG      HEX              UINT32_T       UINT16_T
                                           A      B
========================================================
 2      0064 013A         6.553.914       100     314
 3      03E8 008C        65.536.140      1000     140
 4      2710 0042       655.360.066     10000      66
 5      EE48 2328     3.997.705.000     61000    9000
 6      1A00 0012       436.207.634      6656      18
 7      01B4 2C85        28.585.093       436   11397
 8      5276 0014     1.383.464.980     21110      20
 20     0001 B482           111.746         1   46210

The hex codes do not resemble ASCII
REG 2 - 4 look like a look-up table in uint16 view
314 might be PI 314 / 100 ~ PI
others unknown
no obvious link to your serial numbers.

The above could be automated

you might try to interpret the data as a 4 byte float?

Back to work :)

Beanow · 2022-01-21T14:44:48Z

Observing a bunch of these over time I found that registers 2-6 are static for me. 7, 8 and 20 do change.
8 and 20 only update if you pause long enough to update the (reg 0) measurement value. Some intermediate calculations?

Reg 7 seems to be two uint16 parts, the A part seems roughly inversely proportional to the reg 0 measurement value when I spike the reading with some gas. B part is all over the place, can't tell what that is, maybe some clock or counter.

I also learned you can get 3 degrees of readiness, depending on how much you pause between I2C commands.

Enough time to update Reg 0 (for example 1500ms pause between dumps).
Enough to update Reg 7 (A and B), but not Reg 0, 8, or 20 (for example 500ms between dumps).
Only Reg 7's B part updates, while the rest stays fixed (for example 50ms between dumps).

Presumably the I2C commands just hogs all the internal chip's processing cycles, preventing any measuring. And the in between nr 2 state seems to indicate some internal samples being stored in Reg 7.

What that tells me is: my v118's busy bit is also not correct.
Not just the UGM3 mode, but at least in the nr 2 situation where it's able to take some samples but not enough to update Reg 0, it should have the CPU time to flag itself as "busy", but doesn't do so.

Maybe the entire status byte isn't correctly memory mapped to it's functions in v118. Though it returns 0x00 instead of 0xFF like the unused registers, I've not seen it change from 0x00 no matter what I do.

Probably time to try customer support for maybe an updated datasheet and why it's neither using the busy bit correctly and seems to be lacking the UGM3 mode entirely.

RobTillaart · 2022-01-21T15:07:51Z

I have made a request to find out if the datasheet is the latest (through my preferred shop who are reseller)

Beanow · 2022-01-21T15:21:07Z

Thanks I also contacted the reseller I used and aosong.com contact emails, which I assume is the manufacturer's real site.

RobTillaart · 2022-01-21T18:38:56Z

B part is all over the place, can't tell what that is, maybe some clock or counter.

if it is a clock it probably is micros ?
If you do 4 carefully timed reads you might calculate its step size.

So reg 7 can be the raw read of particles, it is multiplied with the constant registers to get uG as I expect it uses a constant factor between the two measurements.
mmm
maybe those constant registers are the molarity thingy ?
You might check the numbers for mass of some molecules? (quick look doesn't ring any bell)
Is it possible to write them?

RobTillaart · 2022-01-22T09:11:47Z

@Beanow

Just reading back the thread I don't think the problem with the status bit is caused by the library. we did not find a way to solve it either yet. So I will keep the issue open at least until there is more info about the datasheet.

FYI - Merged the date PR.

Beanow · 2022-01-22T11:31:22Z

Yes, it's definitely the sensor not behaving as advertised. Thanks for helping debug this, let's wait for the retailer/manufacturer response, as for now this revision just looks partially functional.

RobTillaart · 2022-02-02T14:04:21Z

@Beanow
FYI, got no info so far.

Beanow · 2022-02-03T10:18:26Z

Me either @RobTillaart
No response at all from the manufacturer, not even a confirmation they got my email.
The retailer promised an email with "the information", whatever that'll be, last week. Haven't gotten that email yet.
Apparently though

2022.01.26-2022.02.10 is the Chinese Spring Festival holiday

Perhaps that has something to do with it.

RobTillaart · 2022-02-03T10:45:08Z

Guess so.

Beanow · 2022-02-23T12:07:31Z

So, in the meantime. The retailer sent me the Chinese v1.2 datasheet. Even though I told them I already had the v1.2 and was wondering if there was a newer one.

It's a good thing I gave them a dedicated email address, because who would otherwise open an attachment like this?

Now the technical staff explains:

(With PPB underlined.)

Did they just silently downgrade to an AGS01DB or what? They have AGS02MA printed on though. So whatever this is it looks like ASAIR's shenanigans more than the retailer. Though the retailer removed the product I left a bad review on and posted it again.

Old: https://www.aliexpress.com/item/1005003131194702.html
New: https://www.aliexpress.com/item/1005003918818892.html

Still claiming ug/m3 output mode.

🤔 seems pretty trustworthy.

RobTillaart · 2022-02-23T12:35:03Z

interesting,
I recall that sometimes when production line changes from A to B there are products that are labeled incorrectly.
This happens to sensors, seen ADS1015 labeled as ADS1115, I've even seen it with soup (wrong wrapper around tin).

But that said, it becomes unfixable and I will spend some lines about it in the readme
I won't change the library to handle such exceptions unless it becomes "mainstream".
(would imply to read the version on start and add version dependent conditions and return values in the code. That is a recipe for less maintainable code and increased footprint.)

So for now it seems a "won't fix" issue. If you have an idea for a workable solution, let me know.

Beanow · 2022-02-23T12:52:59Z

Huh, haven't encountered it before. I'd have to dig a bit deeper into the protocol and such if it really is a AGS01DB under the hood, yeah it wouldn't make sense for the library to address as being a AGS02MA flavor.

RobTillaart · 2022-02-23T15:34:35Z

@Beanow

going to add this to the readme.md. Is it clear enough?

Version problem?

The library can request the version with getSensorVersion().
My devices all report version 117 and this version is used to develop / test this library.
There are devices reported with version 118 which only support the PPB and not the ugM3 mode.
It is unclear if this is an incident, bug or a structural change in the firmware.

So if you encounter problems with setting the mode, let me know.
Also if you have a working device, not being version 117 or 118 let me know too.

Beanow · 2022-02-23T15:36:28Z

LGTM, at your discretion could link this issue for context. But I think this should do.

RobTillaart · 2022-02-23T16:00:57Z

link is good idea.
(published)

RobTillaart · 2022-02-24T12:59:20Z

@Beanow
As it looks like we won't find a solution shall we close the issue?

Beanow · 2022-02-24T15:41:25Z

Yeah, if I do get any more insights I'll create a new issue / reopen then :]

RobTillaart self-assigned this Feb 23, 2022

RobTillaart added the question Further information is requested label Feb 23, 2022

Beanow closed this as completed Feb 24, 2022

RobTillaart mentioned this issue Apr 19, 2022

After calibration, incorrect data #13

Closed

The mode is a lie? #11

The mode is a lie? #11

Comments

Beanow commented Jan 20, 2022 • edited Loading

RobTillaart commented Jan 20, 2022

Beanow commented Jan 20, 2022

RobTillaart commented Jan 20, 2022

Beanow commented Jan 20, 2022 • edited Loading

RobTillaart commented Jan 20, 2022

Beanow commented Jan 20, 2022

Beanow commented Jan 20, 2022

RobTillaart commented Jan 20, 2022

Beanow commented Jan 20, 2022 • edited Loading

RobTillaart commented Jan 20, 2022

RobTillaart commented Jan 20, 2022

Beanow commented Jan 20, 2022

RobTillaart commented Jan 20, 2022

Beanow commented Jan 20, 2022

RobTillaart commented Jan 20, 2022

RobTillaart commented Jan 20, 2022

RobTillaart commented Jan 20, 2022

RobTillaart commented Jan 20, 2022

Beanow commented Jan 20, 2022

Beanow commented Jan 20, 2022

RobTillaart commented Jan 20, 2022

Beanow commented Jan 20, 2022 • edited Loading

RobTillaart commented Jan 20, 2022

RobTillaart commented Jan 20, 2022

Beanow commented Jan 20, 2022 • edited by RobTillaart Loading

RobTillaart commented Jan 20, 2022 • edited Loading

Beanow commented Jan 20, 2022

RobTillaart commented Jan 21, 2022 • edited Loading

RobTillaart commented Jan 21, 2022

Beanow commented Jan 21, 2022 • edited Loading

RobTillaart commented Jan 21, 2022

Beanow commented Jan 21, 2022

RobTillaart commented Jan 21, 2022

RobTillaart commented Jan 22, 2022 • edited Loading

Beanow commented Jan 22, 2022

RobTillaart commented Feb 2, 2022

Beanow commented Feb 3, 2022

RobTillaart commented Feb 3, 2022

Beanow commented Feb 23, 2022

RobTillaart commented Feb 23, 2022

Beanow commented Feb 23, 2022

RobTillaart commented Feb 23, 2022

Version problem?

Beanow commented Feb 23, 2022

RobTillaart commented Feb 23, 2022 • edited Loading

RobTillaart commented Feb 24, 2022

Beanow commented Feb 24, 2022

Beanow commented Jan 20, 2022 •

edited

Loading

Beanow commented Jan 20, 2022 •

edited

Loading

Beanow commented Jan 20, 2022 •

edited

Loading

Beanow commented Jan 20, 2022 •

edited

Loading

Beanow commented Jan 20, 2022 •

edited by RobTillaart

Loading

RobTillaart commented Jan 20, 2022 •

edited

Loading

RobTillaart commented Jan 21, 2022 •

edited

Loading

Beanow commented Jan 21, 2022 •

edited

Loading

RobTillaart commented Jan 22, 2022 •

edited

Loading

RobTillaart commented Feb 23, 2022 •

edited

Loading