Howto read debug info? How to monitor raw data?

[unsermanninchina]

Hi everybody, I have made three sensors and I am still facing some problems. As a basic help it would be nice to read the debug infos. Using Linux since 15 year I am a newborn to IOT. Please excuse if I ask easy questions.

One problem is, that two sensors with SDS011 (one with DHT22, one with BME280) often stop working. The one with DHT22 has a monitor and I see that it stops changing displayed data, it seems to crash. After a restart it works until the next crash, which appears all some hours. The other one seems to crash quite often, too.

Another problem is, that the third sensor with a Plantower A003 it's data is to high. Actually around doubled values, which made me think, that this sensor doesn't work with this firmware. But it should be the same data like the PMS7003. I would like to see the raw data to get an idea about it. How can I pick up the raw data during measuring?

I feel I am not really at the right place to ask this questions. Please let me know if so. Thank you so much!

[dirkmueller]

@unsermanninchina which version of the firmware are you using? we're aware of NRZ-2019-125* being very unstable, investigating on that version isn't worth the effort.

the firmware is currently configured to only print usable debug output on usb-serial, see https://github.com/opendata-stuttgart/sensors-software/blob/master/airrohr-firmware/Readme.md#debug-via-usb-serial for details.

if you set in the webui to "max info" you should be able to see in great detail the sensor reading debug output on serial. Please paste it here for the sensor that is showing double the values. there might indeed be some logical error in the code .

[unsermanninchina]

Hi @dirkmueller ,

thank you so much for your help! To put the serial debug information on level 5 and connected the board using USB-wire to my linux laptop. Then I used a console and used stdbuf -o0 cat /dev/ttyUSB0 >X.log to write the log into a file.

The attached one is from the PMSA003 with DHT22 one running for a little time. It's in the log too, but the firmware on this board is NRZ-2020-129/DE and it never crashed. It's the one with more or less doubled values for 2.5 and 10 PM compared with two SDS011 sensors on two other boards. 2020-01-08_S2_PMSA003_DHT22.log

Don't wonder at which times I reply! I am in Beijing, China, seven hours earlier than CET (MEZ). By the way, thanks to every programmer here for making the firmware! There is no data in the northern villages of Beijing, a region with often but not always much better air quality than in the city center. Your firmware makes it possible to get a better understanding of our local air quality!

[unsermanninchina]

All boards run with firmware NRZ-2020-129, as well the crashing ones. One has SDS001 and DHT22 plus a monitor OLED SSD1306 and it's installed outside. I will remove it and connect it to a computer to debug it. Maybe it delivers some data before it crashes.

[dirkmueller]

@unsermanninchina NRZ-2020-129 was released just yesterday, so the stability issue hopefully is fixed by the newer version alone. Please observe this over the next few days and report back!

Thanks for capturing the serial log, I will look over this later today.

[unsermanninchina]

@dirkmueller I am testing them since 8 hours and no crash. I thought if the firmware was updated, good to know. I gonna continue for some days. Thank you planning to look at the serial log. If you need any more information or logfiles let me know.

[dirkmueller]

@unsermanninchina so I compared the debug output with the protocol description in

https://www.aqmd.gov/docs/default-source/aq-spec/resources-page/plantower-pms5003-manual_v2-3.pdf

and it looks like what the firmware is doing is roughly correct. here's one example (reduced from your output):

PM2.5 (sec.): 15
PM2.5 (sec.): 14
PM2.5 (sec.): 12
PM2.5 (sec.): 11
PM2.5 (sec.): 11
PM2.5 (sec.): 11
PM2.5 (sec.): 11
PM2.5 (sec.): 11
PM2.5 (sec.): 12
PM2.5 (sec.): 12
PM2.5: 11.75

what it does is remove the extremes (one of the 11 and 15) and then does an average which leads to 11.75. I'm saying "roughly correct" because basically we're measuring for 6 consecutive seconds, and PMS has the artefact to send an update more than once per second (which is how we end up having 10 measurements in a time of ~ 6 seconds), while there is only a new measurement every 2.7s, the rest are duplicates.

However, this doesn't explain a "being off by factor two" problem. looking at the raw dump, we're reading what the sensor is sending (we're using the "environmental sensor" reports). what we can try is if it gets better after e.g. cleaning the sensor e.g. by shortly using a vaccuumer or by letting it run with a short measurement interval for some time.

[unsermanninchina]

The PMS is three years old but was never used and all the time in a plastic bag. Maybe he got old already? I gonna try both and see.

[unsermanninchina]

This is before using a vacuum cleaner but I've already changed the PMS to a 30 sec interval:

SDS001   | PM2.5 | 12.5 µg/m³
SDS011   | PM10 | 24.0 µg/m³
PMSx003 | PM2.5 | 44.0 µg/m³
PMSx003 | PM10 | 80.5 µg/m³
PM1 I can't compare:
PMSx003 | PM1 | 24.0 µg/m³

The closest official monitoring station Beijing Changping Dingling in at least similar environment (no traffic, countryside, no industry) has 95 PM2.5 and 30 PM10 at the same moment as shown at aqicn.org. But it's 30 km away and as it has at least a different micro climate it's maybe not comparable. Maybe I should go there and bring my PMS. However, it's cheaper to buy a new one.

[dirkmueller]

That's a pretty huge difference indeed. There are some known influences of air humidity (the more humid the higher the measurement over real values) as well as pressure (higher altitude/less pressure leads to lower measurements)

Although this only really matters at the extremes.

I don't know. There was a comment somewhere that the stability of the power supply might have an effect as well.

Please let us know if you find out the root cause bases.on the serial debug and the protocol description (see earlier links)

[unsermanninchina]

@dirkmueller Both sensors are together at the same place for the testing. Should be only slight differences. I found it here that the power supply could make a difference and changed it already to a stable one with 2A. Actually I could change the place testing it, because at the moment its a glass house which is the entrance into the flat. Quite humid during the night. If I find out anything I will let you know. The crashes are solved. All sensors are running without crashes since the new firmware was installed. I close this as my original questions have been solved. If I have new findings about the reason of the different values with the PMSA003 I will add that here. Thank you again for your help!