Panasonic SN-GCJA5 Particulate Matter sensor output

[DrG]

I have been working with a Panasonic Particulate matter sensor https://b2b-api.panasonic.eu/file_stream/pids/fileversion/8556

The datasheets are here:
https://b2b-api.panasonic.eu/file_stream/pids/fileversion/8815
https://b2b-api.panasonic.eu/file_stream/pids/fileversion/8814

I have worked with a similar sensor from Honeywell and understand the basic operating principles. I am also confident that the coding is accurate (I am using I²C and it is not that difficult although some of the data communications descriptions are lacking).

Basically, the data output is in two forms; mass density values (ug/m³) and particle counts (sizes [um] are binned).

The problem I am having is in reconciling the two measures. Here are some examples of the output:
The first line is a dump of the data along with a status byte (0=all is well). That line is followed by the concentrations and then the particle counts.

Code: [Select]

C0 5 0 0 73 6 0 0 41 7 0 0 C 0 7 0 3 0 0 0 0 0 0 0 0 0   Status=0

Particle mass density values (ug/m3)
PM 1.0=1.47
PM 2.5=1.65
PM 10.0=1.86

Particle count values (um)
0.3-0.5=12
0.5-1.0=7
1.0-2.5=3
2.5-5.0=0
5.0-7.5=0
7.5-10.0=0

11 5 0 0 C4 5 0 0 7C 6 0 0 F 0 4 0 2 0 0 0 0 0 0 0 0 0   Status=0

Particle mass density values (ug/m3)
PM 1.0=1.30
PM 2.5=1.48
PM 10.0=1.66

Particle count values (um)
0.3-0.5=15
0.5-1.0=4
1.0-2.5=2
2.5-5.0=0
5.0-7.5=0
7.5-10.0=0


/--/
82 A8 4 0 3 A9 9 0 73 30 13 0 92 3 33 3 39 B 0 0 58 0 34 0 F 0   Status=0

Particle mass density values (ug/m3)
PM 1.0=305.28
PM 2.5=633.09
PM 10.0=1257.59

Particle count values (um)
0.3-0.5=914
0.5-1.0=819
1.0-2.5=2873
2.5-5.0=88
5.0-7.5=52
7.5-10.0=15

F6 C7 5 0 D 9 B 0 85 A7 14 0 B2 4 1 4 49 C 0 0 59 0 34 0 F 0   Status=0

Particle mass density values (ug/m3)
PM 1.0=378.87
PM 2.5=723.21
PM 10.0=1353.60

Particle count values (um)
0.3-0.5=1202
0.5-1.0=1025
1.0-2.5=3145
2.5-5.0=89
5.0-7.5=52
7.5-10.0=15

In the first output, the mass density values are:
Particle mass density values (ug/m3)
PM 1.0=1.47
PM 2.5=1.65
PM 10.0=1.86

Note that they are cumulative (smaller particle concentrations should always be included in larger particle concentrations) such that 2.5 > 1.0 and 10.0 > 2.5. Ok, fine, but when I look at the particle counts (which are binned) I get the following:
Particle count values (um)
0.3-0.5=12
0.5-1.0=7
1.0-2.5=3
2.5-5.0=0
5.0-7.5=0
7.5-10.0=0

The problem is that the concentration (ug/m³) shows that there are at least some particles > 2.5 um since the concentration for 10.0 is greater than that for 2.5. That is what I am wrestling with. Note that the data for concentrations and counts are captured at the same time (within the same dump).

That "problem" occurs regardless of overall concentrations.
After the break in the data above, I used a burned match to get a higher concentrations and larger particles (as expected with smoke) and the sensor produces reasonable results and can "count" larger particles.

I just don't understand why the particle count values are not always consistent with the concentration values in the sense that there *should* be particle counts above 2.5 um if the concentration at 10.0 is greater than that at 2.5.

Some of this could be because the concentration reported at 2.5 ug/m³ is actually all particles less than 2.5 um, that is typical I believe. Perhaps the sensor is using some internal averaging. I just can't figure it out.

What am I missing or not understanding? Any thoughts?
 

[schokoschnecke]

Hey DrG! 

I'm working with the same sensor and I'm experiencing some problems as well. I am using UART and I am wondering how you calculated the mass densities out of the raw data bytes. I tried (raw[1] + (raw[2] + (raw[3] + (raw[4] * 256)) * 256) * 256)/1000 for PM1.0 but the results are really unrealistic. Could you tell me how you did it? I tried to figure it out by looking at the raw data you posted but I couldn't. I wish I could help you with your problem but without knowing the mass densities I cannot say if my particle counts are reasonable or not.

Best wishes from Germany

[DrG]

Hey DrG! 

I'm working with the same sensor and I'm experiencing some problems as well. I am using UART and I am wondering how you calculated the mass densities out of the raw data bytes. I tried (raw[1] + (raw[2] + (raw[3] + (raw[4] * 256)) * 256) * 256)/1000 for PM1.0 but the results are really unrealistic. Could you tell me how you did it? I tried to figure it out by looking at the raw data you posted but I couldn't. I wish I could help you with your problem but without knowing the mass densities I cannot say if my particle counts are reasonable or not.

Best wishes from Germany

I confess that I have let the project sit on the breadboard since writing that. I am trying to find someone at Panasonic that I can pose my specific question to. If I can get to an EE, I think I will get an answer and I am almost certain that they do some internal averaging and that is part of it.

As to your question, I use I2C but it is a simple operation...and forgive me, I am running out the door and not being real careful at the moment. Look at this fragment. I read the raw values into an array and then build the variables. There may be more efficient ways, but when I am trying to get things to work, I tend to take the slow but sure way, at least at first. Just make sure that you know the size of the variable types on your compiler and get the endian correct

Code: [Select]

  // calculate mass density values. Note: It is not clear whether all 4 bytes need to be used and at one point in a data sheet
  // it talks of a 20 bit value. So far, testing shows that treating the four values as an unsigned long works fine.
  PM1_0 =  (unsigned long)DataBlock[3] << 24;
  PM1_0 += (unsigned long)DataBlock[2] << 16;
  PM1_0 += (unsigned long)DataBlock[1] << 8;
  PM1_0 += (unsigned long)DataBlock[0];

  PM2_5 =  (unsigned long)DataBlock[7] << 24;
  PM2_5 += (unsigned long)DataBlock[6] << 16;
  PM2_5 += (unsigned long)DataBlock[5] << 8;
  PM2_5 += (unsigned long)DataBlock[4];
  
  PM10_0 =  (unsigned long)DataBlock[11] << 24;
  PM10_0 += (unsigned long)DataBlock[10] << 16;
  PM10_0 += (unsigned long)DataBlock[9] << 8;
  PM10_0 += (unsigned long)DataBlock[8];

  // particle count data
  PC0_3to0_5=(unsigned int)DataBlock[13] << 8;
  PC0_3to0_5+= (unsigned int)DataBlock[12];
  
  PC0_5to1_0=(unsigned int)DataBlock[15] << 8;
  PC0_5to1_0+= (unsigned int)DataBlock[14];

  PC1_0to2_5=(unsigned int)DataBlock[17] << 8;
  PC1_0to2_5+= (unsigned int)DataBlock[16];

  PC2_5to5_0=(unsigned int)DataBlock[21] << 8;
  PC2_5to5_0+= (unsigned int)DataBlock[20];

  PC5_0to7_5=(unsigned int)DataBlock[23] << 8;
  PC5_0to7_5+= (unsigned int)DataBlock[22];  

  PC7_5to10_0=(unsigned int)DataBlock[25] << 8;
  PC7_5to10_0+= (unsigned int)DataBlock[24];   
  

[CamCam]

Hi !

I work with this sensor, too.
I'm not working since very long with I2c, arduino and this particle sensor and i have many trouble to be sure that communication is ok

@DrG: For particle count data, did you have the same difference of informations if you ask register by register or if you ask the whole register as one?  for me I can't have a reliable information: [ Attachment Invalid Or Does Not Exist ] [ Attachment Invalid Or Does Not Exist ] for example to have Particle count 0,3-0,5 and 0,5-1,0µm  and According to datasheet if i ask register 0x0C for 2bytes  then register 0x0E for 2 bytes,  i got values that are completly different as if i ask 0x0C for 4bytes.  I can't find a reason... do you?  register at adress 0x12 and 0x13 don't exist so i guess we need to have 2 request: one for particle up to 2,5µm and a second for particle between 2,5 to 10µm?   
My code is very basic as beginer:
 Wire.beginTransmission(0x33);
  Wire.write(0x0C);
  Wire.requestFrom(0x33,2,true);
  byte L2 = Wire.read();
  byte H2=  Wire.read();
  Wire.endTransmission(false);
  Serial.print("Registre 0x0E avec 2octets: ");
  Serial.println ((H2 << | L2);

  Wire.beginTransmission(0x33);
  Wire.write(0x0C);
  Wire.requestFrom(0x33,4,true);
  byte L3= Wire.read();
  byte H3= Wire.read();
  byte L4= Wire.read();
  byte H4= Wire.read();
  Wire.endTransmission(false);
  Serial.print("Registre 0x0c avec 4octets: ");
  Serial.print ((H3 << | L3);  Serial.print("  "); Serial.println ((H4 << | L4);
  Serial.println("");
  }

[DrG]

@CamCam
It is a little difficult for me to understand exactly what you mean. I would like to help if I can. So I powered up the breadboard circuit which has been sitting here since my first post.

Here is a crappy phone pic of what I have.



I am using a 3.3V ProMini board with a 3.3V USB/Serial board. I am using a 5V power supply on the breadboard to power the Panasonic. The USB serial board is set to 3.3V for serial transmission (to be consistent with the ProMini) and it also powers the ProMini 3.3V.

The I2C pullups are included inside the Panasonic so there are none on the breadboard. Remember, the ProMini, being a 3.3V board, has 3.3V I2C.

The complete testing code that I have been using is attached (as a text file). Use it at your own risk but it has been working fine for me.

I just ran it and this is a sample output:

Code: [Select]

26 bytes read
DE 10 0 0 F9 12 0 0 58 15 0 0 20 0 16 0 6 0 0 0 0 0 0 0 0 0   Status=0

Particle mass density values (ug/m3)
PM 1.0=4.32
PM 2.5=4.86
PM 10.0=5.46

Particle count values (um)
0.3-0.5=32
0.5-1.0=22
1.0-2.5=6
2.5-5.0=0
5.0-7.5=0
7.5-10.0=0

It works fine for me. The results are always systematic. The data are output every 3 seconds and they vary in a reasonable way normally. If, however, I hold a burned match near the detector inlet, the resulting smoke makes all of the particle sizes jump way up, exactly as I would expect.

The only issue is as I described in my original post and I think it is a technical issue that I suspect has to do with how they bin particle sizes and likely do some kind of running average.

I am not sure what is going with your set up. You can compare my code with what you have as well as your hardware set up. If you are using 5V I2C and a commercial voltage translator board, that could be an issue. Be mindful of the I2C start/restart business. It could also be something else. If you give me a more complete picture, I might be able to help more.

This is the the most recent communications data sheet that I could find, https://b2b-api.panasonic.eu/file_stream/pids/fileversion/8814

Hope this helps and let us know what happens.

[CamCam]

Thanks a lot for those details and explanations!!
I have to look and unsderstand the code because it seems I don't have your master level
hoping i won't make explose my feather card with all my trys
thx

[DrG]

I have to look and unsderstand the code because it seems I don't have your master level
hoping i won't make explose my feather card with all my trys
thx

lol@"master level", but thanks and good luck with it - feel free to ask some specific question....and, hey, nobody does this stuff for very long without some magic smoke. 

[niloo_sdp]

Hi schokoschnecke!
I have a Panasonic SN-GCJA5. I don't know how should I wiring it for using UART port. Would you please help me? Also, did you use coolterm for reading data?
Thanks

[DrG]

https://b2b-api.panasonic.eu/file_stream/pids/fileversion/8815

Page 5.

[Tomorokoshi]

That's interesting. I had no idea there were quite a few options for reasonably-priced sensor on Digi-Key. I've been wondering how to check the calibration of my Climet 208.

[DrG]

That's interesting. I had no idea there were quite a few options for reasonably-priced sensor on Digi-Key. I've been wondering how to check the calibration of my Climet 208.

Validating these relatively inexpensive sensors is a problem in itself. In another thread here (which I am too lazy to find) comparing their readings outdoors to a local "official" value, if you are close to one, seemed reasonable. Access to a laboratory grade sensor with laboratory grade standards would be nice.

I did a quick search on the Climet you mentioned e.g., https://www.auction-tucson.com/auction/447/item/climet-208-particle-analyzer-model-c1-208-50686/ Looks pretty serious. Have you ever validated/calibrated it ever? Do you know of any standards that are available (like some kind of gas with a known particulate concentration)?

[Tomorokoshi]

That's interesting. I had no idea there were quite a few options for reasonably-priced sensor on Digi-Key. I've been wondering how to check the calibration of my Climet 208.

Validating these relatively inexpensive sensors is a problem in itself. In another thread here (which I am too lazy to find) comparing their readings outdoors to a local "official" value, if you are close to one, seemed reasonable. Access to a laboratory grade sensor with laboratory grade standards would be nice.

I did a quick search on the Climet you mentioned e.g., https://www.auction-tucson.com/auction/447/item/climet-208-particle-analyzer-model-c1-208-50686/ Looks pretty serious. Have you ever validated/calibrated it ever? Do you know of any standards that are available (like some kind of gas with a known particulate concentration)?

I haven't tried to track down a calibrated particulate-laden gas yet.

I repaired several parts on mine. There are still a couple maintenance items to work on.

It appears to give reasonable readings:
1. Readings drop off by orders of magnitude as the particle size selection goes up.
2. If I stop the airflow the readings go almost to 0.
3. If I filter the airflow I get a drop that is reasonable to expect based on the filter material. For instance, between no filter and a new 3M N95 mask, I get 96%, 97%, and 99% reductions at particle sizes 0.5, 1.0, and 3.0 um.

I used it to characterize masks several months ago at the beginning of the COVID problem. Very interesting results.

Compared to the units on Digi-Key that use a fan, this unit uses a vacuum pump, so restrictive materials can me characterized.

[niloo_sdp]

Thanks for your reply.
I cannot find the code for using UART output as well. would you please help me?