element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Members
    Members
    • Benefits of Membership
    • Achievement Levels
    • Members Area
    • Personal Blogs
    • Feedback and Support
    • What's New on element14
  • Learn
    Learn
    • Learning Center
    • eBooks
    • STEM Academy
    • Webinars, Training and Events
    • More
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • More
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • More
  • Products
    Products
    • Arduino
    • Dev Tools
    • Manufacturers
    • Raspberry Pi
    • RoadTests & Reviews
    • Avnet Boards Community
    • More
  • Store
    Store
    • Visit Your Store
    • Choose Another Store
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
RoadTests & Reviews
  • Products
  • More
RoadTests & Reviews
Blog Getting started with the Panasonic SN-GCJA5 Laser Type Particulate Matter (PM) Sensor using UART TTL
  • Blog
  • RoadTest Forum
  • Documents
  • Events
  • RoadTests
  • Reviews
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
  • SN-GCJA5
  • raspberry pi pico
  • panasonic
  • PM-Sensor
  • arduino
  • Subscribe by email
  • More
  • Cancel
  • Share
  • Subscribe by email
  • More
  • Cancel
Related
Recommended

Getting started with the Panasonic SN-GCJA5 Laser Type Particulate Matter (PM) Sensor using UART TTL

BigG
BigG
23 Dec 2021

Introduction

I’m in the process of road-testing the Panasonic SN-GCJA5 Laser Type Particulate Matter (PM) Sensor and I wanted to see how easy or difficult it would be to receive a data stream from the sensor as my minimum viable solution.

According to the data sheet, the SN-GCJA5 PM Sensor offers two communication modes, via I2C bus and a single UART TTL TX terminal. It seemed to me that UART would be the simpler of the two so I decided to start with that.

But before I jumped into the software side of things I needed to determine the electrical characteristics of the sensor and review the configuration settings for the UART serial connection.

Thankfully everything is provided in the documentation.

Sensor Interface characteristics

Let’s start with the electrical characteristics. Within the Product Specifications documentation we are provided with some handy diagrams:

As these diagrams show, the sensor requires a 5V DC power source but that the I2C and UART logic levels operate at 3.3V.

So, based on this knowledge, I decided to use a Raspberry Pi Pico board as it uses 3V3 logic and it also provides 2 serial ports.

The Communication Specifications documentation provides us with details about the UART configuration used. Here we are told that the baud rate used is 9600bps, it sends 8 bits of data, it uses an Even Parity and a has single stop bit. Thus this config setting (8E1) is slightly different to the default config setting (8N1) used with many of the popular development board SDKs such as Arduino.

Armed with this knowledge I could now connect my sensor to the Raspberry Pi Pico and start developing some minimal viable software.

Test Firmware

I planned to use the Arduino IDE for this endeavour as there are plenty of generic code examples that work on the Pico board. In this case the Arduino IDE provided just the example I needed to get things started, which is SerialPassthrough.ino.

This example required just one change to start receiving the data stream, with an additional change to make the data stream readable in the Serial Monitor.

You don't have permission to edit metadata of this video.
Edit media
x
Upload Preview

/*
  SerialPassthrough sketch

  Some boards, like the Arduino 101, the MKR1000, Zero, or the Micro, have one
  hardware serial port attached to Digital pins 0-1, and a separate USB serial
  port attached to the IDE Serial Monitor. This means that the "serial
  passthrough" which is possible with the Arduino UNO (commonly used to interact
  with devices/shields that require configuration via serial AT commands) will
  not work by default.

  This sketch allows you to emulate the serial passthrough behaviour. Any text
  you type in the IDE Serial monitor will be written out to the serial port on
  Digital pins 0 and 1, and vice-versa.

  On the 101, MKR1000, Zero, and Micro, "Serial" refers to the USB Serial port
  attached to the Serial Monitor, and "Serial1" refers to the hardware serial
  port attached to pins 0 and 1. This sketch will emulate Serial passthrough
  using those two Serial ports on the boards mentioned above, but you can change
  these names to connect any two serial ports on a board that has multiple ports.

  created 23 May 2016
  by Erik Nyquist

  https://www.arduino.cc/en/Tutorial/BuiltInExamples/SerialPassthrough
*/

void setup() {
  Serial.begin(9600);
  // change Serial1 configuration to 8bits for data, even parity and 1 stop bit
  Serial1.begin(9600, SERIAL_8E1);
}

void loop() 
  if (Serial.available()) {      // If anything comes in Serial (USB),
    Serial1.write(Serial.read());   // read it and send it out Serial1 (pins 0 & 1)
  }

  if (Serial1.available()) {     // If anything comes in Serial1 (pins 0 & 1)
    Serial.print(Serial1.read(), DEC);   // read it and send it out Serial (USB) - we changed this to print for readable format
  }
}

Now that wasn’t difficult at all. The next step was to parse this data according to the communications spec sheet.

As shown here, 32 bytes of data is streamed, which includes a header byte (0x02) and a trailer byte (0x03). Then contained within this byte array are 3 x 32bit values for PM1.0, PM2.5 and PM10 Particle Mass Density value and 6 x 16bit values for Particle Count based on different particle sizes. Then there is a sensor status register, which gives you an error code if something is not right, and an XOR value, which is the XOR result of the array of bytes from index 2 through to 30 (I’ve not tested this).

And here is my Arduino code, which outputs the parsed data:

/*
  Panasonic Laser Type PM Sensor UART sketch

  This sketch allows you to emulate the serial passthrough behaviour. Any text
  you type in the IDE Serial monitor will be written out to the serial port on
  Digital pins 0 and 1, and vice-versa.

  created 22 December 2021
  by C Gerrish (BigG)

  Permission to use, copy, modify, and/or distribute this software for any 
  purpose with or without fee is hereby granted.
*/

const byte PLSIZE = 30;
const byte STABLE = 20;

uint32_t PM1_Reg = 0;
uint32_t PM25_Reg = 0;
uint32_t PM10_Reg = 0;

uint16_t Reg1 = 0;
uint16_t Reg2 = 0;
uint16_t Reg3 = 0;
uint16_t Reg4 = 0;
uint16_t Reg5 = 0;
uint16_t Reg6 = 0;


byte Payload[PLSIZE] = {0};
byte cntr = 0;
byte StableCntr = 0;

bool Header = false;
bool StableFlag = false;

void setup() {
  Serial.begin(115200);
  Serial1.begin(9600, SERIAL_8E1);
  // When the dust sensor is first powered on the spec sheet says there's an 8 second delay before 1st reading
  // Then we will have 20 seconds before stable readings occur. For the purposes of this sketch
  // we assume the first 20 readings are always unstable. This sketch does not take into account
  // the sensor being unplugged while the sketch is running and plugged back in while MCU running.
}

void loop() {
  if (Serial1.available()) {     // If anything comes in Serial1 (RX pin 1 on the Raspberry Pi Pico)
    byte c = Serial1.read();
    //Serial.println(c, HEX);   // read it and send it out Serial (USB)
    if (Header) {
      if (cntr < PLSIZE) {
        Payload[cntr] = c;
        cntr++;
      }
      else {
        // Lookout for the trailer byte which is 0x03
        if (c == 0x03) {
          Header = false;

          // Extract all the Particle Mass Density values as per spec
          PM1_Reg = (Payload[0] | Payload[1]<< 8 | Payload[2]<< 16 | Payload[3]<< 24);
          PM25_Reg = (Payload[4] | Payload[5]<< 8 | Payload[6]<< 16 | Payload[7]<< 24);
          PM10_Reg = (Payload[8] | Payload[9]<< 8 | Payload[10]<< 16 | Payload[11]<< 24);
          
          if (!StableFlag) Serial.println("*** UNSTABLE READINGS (within approx 28 secs of power on) ***");
          Serial.println("Particle Mass Density (μg/m3):");
          Serial.print("PM1.0: "); Serial.print(PM1_Reg, DEC);
          Serial.print(" | PM2.5: "); Serial.print(PM25_Reg, DEC);
          Serial.print(" | PM10: "); Serial.println(PM10_Reg, DEC);

          // Extract all the Particle Count values as per spec
          Reg1 = (Payload[12] | Payload[13]<< 8);
          Reg2 = (Payload[14] | Payload[15]<< 8);
          Reg3 = (Payload[16] | Payload[17]<< 8);

          Reg4 = (Payload[20] | Payload[21]<< 8);
          Reg5 = (Payload[22] | Payload[23]<< 8);
          Reg6 = (Payload[24] | Payload[25]<< 8);

          Serial.println("Particle Count:");
          Serial.print("0.3-0.5μm: "); Serial.print(Reg1, DEC);
          Serial.print(" | 0.5-1.0μm: "); Serial.print(Reg2, DEC);
          Serial.print(" | 1.0-2.5μm: "); Serial.print(Reg3, DEC);
          Serial.print(" | 2.5-5.0μm: "); Serial.print(Reg4, DEC);
          Serial.print(" | 5.0-7.5μm: "); Serial.print(Reg5, DEC);
          Serial.print(" | 7.5-10.0μm: "); Serial.println(Reg6, DEC);
         
          if (Payload[28]) {
            // If there's a non zero value then we have an error. Spec gives further
            // details on how to parse. Not done here.
            Serial.print("Sensor Status:0x"); Serial.println(Payload[28], HEX);
          }
          else Serial.println("Sensor Status:OK");
          Serial.print("XOR value of array: "); Serial.println(Payload[29], DEC);
          Serial.println();
        }
      }
    }
    else {
      // Lookout for the header byte which is 0x02
      if (c == 0x02) {
        //Serial.println(c, HEX);
        Header = true;
        cntr = 0;
        if (StableCntr < STABLE) StableCntr++;
        else StableFlag = true;
      }
    }
  }
}

You don't have permission to edit metadata of this video.
Edit media
x
Upload Preview

Anonymous

Top Comments

  • genebren
    genebren 6 months ago +1

    Looking good!  I came to the same conclusion, that the UART path would be the way to go.  The library that I use for I2C does not handle the 'repeated start' or have a way to insert a delay into the read…

Parents
  • genebren
    genebren 6 months ago

    Looking good!  I came to the same conclusion, that the UART path would be the way to go.  The library that I use for I2C does not handle the 'repeated start' or have a way to insert a delay into the read process.  So far the UART method has been working well for me.  Continued good luck on your roadtest!

    • Cancel
    • Up +1 Down
    • Reply
    • More
    • Cancel
  • BigG
    BigG 6 months ago in reply to genebren

    Thanks Gene. I've yet to look at I2C so thanks for that insight. Best of luck with your roadtest too.

    • Cancel
    • Up 0 Down
    • Reply
    • More
    • Cancel
Comment
  • BigG
    BigG 6 months ago in reply to genebren

    Thanks Gene. I've yet to look at I2C so thanks for that insight. Best of luck with your roadtest too.

    • Cancel
    • Up 0 Down
    • Reply
    • More
    • Cancel
Children
No Data
Element14

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2022 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • Facebook
  • Twitter
  • linkedin
  • YouTube