wrong messurement SDS011

[carli-eb]

The sensor SDS011 delivered incorrect measured values. The new sensor now shows this behavior after less than a year. The picture of the measured values shows the behavior best. Every day for a certain period of time maximum values are displayed, which can't have to do anything with a measurement. A google-search didn't give me any clues about the cause of this behavior. Do I have to buy a new sensor again?

[pjgueno]

Hi, Can you give me the ID of sensor (ESP8266) and the ID on the map. I will check when it started.

[carli-eb]

Hi,

here it is: Sensor on the map 7545 (ChipID: esp8266-29628)

https://maps.sensor.community/#13/51.4551/12.6139

Thanks for checking.

[RikDrabs]

I looked carefully at the history of your measurements, and the fenomenon did not start abruptly. I've seen such things before.

Have you tried to replace the SDS011 ? It might have become supersensitive, multiplying the real measurement by a factor of 10, 100, or more. I had this case at least 4 times over a period of 2 years, on a batch of some 1200 (active!) sensors.

Rik Drabs.

[carli-eb]

This is my second sensor with such a behavior. I will buy another one soon.

[pjgueno]

@carli-eb Check the dates. Maybe it has something to do with the way you give electricity to the sensors. data.xlsx

[carli-eb]

@pjgueno I use an "intelligent" usb-power-adapter with 5 V and 3 A with 5 meter distance to the sensor. I will look for a different power-supply and shorter cable.

[carli-eb]

After 4 hours with a different power-supply, the error is back. My last test will be with a shorter cable tomorrow.

[pjgueno]

Have you checked that there is no spider web or something similar in the air inlet ? You could unscrew the fan and look how it looks like in the black case.

[carli-eb]

Now I use a power-supply with a fixed (short) cable and since 24 hours the signal is true. There was no spider inside the sensor.

[carli-eb]

I am interested to know which power supply with a cable length of 4 m is recommended. I tried a 5 V 2 A power adapter with a separate 4 m cable with micro USB connector from LogiLink but this doesn’t work. Another power supply with intelligent output from Energenie does not work too. Any hint? In the building instruction of luftdaten.info there is only a USB cable of 2 m recommended but I need 4 m.

[RikDrabs]

There is a reason for the cable of 2 meters. Any electronics like the ESP8266-V3 board need special measures to stabilize the power supply over a long cable, even if, like this board, the 5 Volts is regulated down to 3.3 Volts before any load on the board. I suggest you solder a large electrolytic capacitor (47 µF or 100 µF, voltage at least 6 Volts - attention for the polarity of the capacitor!) beween adjacent pins VU(+) and G(-) on the ESP8266-V3 to solve the power supply induced instability problems, to start with, if indeed the cause of your problems is the 4 meter long USB cable. This method should work with any cable, any power supply, provided these are OK on a standard 2 meter cable. But check the SDS011 too! Its power does not come from the 3.3 Volts regulator on the board, but instead directly from the 5 Volts USB power supply. You should not use a power supply raising its voltage above 5 Volts, to compensate for a long cable, as this will certainly damage the SDS011, which is specified for a minimum power supply level of 4.7 Volts and a maximum power supply of 5.3 Volts. Use regular 5 Volts USB power supplies/chargers only. Use a voltmeter to check the voltage over the SDS011 (or on the pins VU and G) if in doubt, to measure the real voltage on the SDS011, both in rest, and while running/measuring.

[dirkmueller]

so the issue is solved with the shorter power supply cable?

[carli-eb]

Yes with a power supply with fix, short cable the measurement is correct since September, 29th. I will continue this test further. We can close the issue for now.

[dirkmueller]

Thanks for the confirmation! This was a valuable learning exercise. I am keeping it around for a bit to see it can be documented somewhere.

[hteibler]

team, just deployed 3 new sensors on the same place with completely different values: any idea?

SDS011 PM2.5 5.2 µg/m³ SDS011 PM10 6.7 µg/m³ DHT22 Temperatur 8.6 °C DHT22 rel. Luftfeuchte 99.9 %

SDS011 PM2.5 25.3 µg/m³ SDS011 PM10 35.5 µg/m³ DHT22 Temperatur 10.4 °C DHT22 rel. Luftfeuchte 59.8 %

SDS011 PM2.5 0.1 µg/m³ SDS011 PM10 0.1 µg/m³ DHT22 Temperatur 9.9 °C DHT22 rel. Luftfeuchte 68.8 %

[RikDrabs]

Please what are the chip-id's of the 3 meters concerned, so that i can take a look, and see the evolution. Are these brand new meters with brand new components, redeployed old meters, or meters reassembled with old components? As some values point to problems with old components? (Luftfeuchte=99%) & (PM2.5/PM10=0.1µg/m³)

[hteibler]

TYPE: SDS011, 5001-B45D on the back V2.16

all the same HW, and currently all on the same place :-) https://opensensemap.org/explore/60315d1337bfd7001bfa2df0 https://opensensemap.org/explore/60321e0937bfd7001b57c75f https://opensensemap.org/explore/603f3b7e8ad04a001b02de10

[RikDrabs]

The 3 sensors you mention are NOT at the same place, but at least between 50 and 400 meters apart, according to your map. PM values can fluctuate enormously, according to (near or far away) pollution source, terrain & wind conditions, wheater, etc... To compare measured values the meters need to be next to one another (even within a couple of centimeters!!), and in exact the same hardware, firmware, and "air" conditions. And even then the manufacturer specified tolerance of the SDS011 is +/- 10%, which means that one meter can measure a value 20% higher or lower than the other, and still be according to manufacturers specifications.

I notice you use a non-standard configuration, and even a non-standard map. If you do not use the standard Luftdaten firmware, on the standard ESP8266, connected to the Luftdaten (now called sensor.community) network, anything in your hardware or firmware can be wrong, buggy, or worse. Please contact your supplier, or the network for details and solutions for your percieved problem.

[hteibler]

HI Rik They are on the same place beside each other, ( map shows where they might be in future) they all have the same FW from https://codefor.de/projekte/stgt-dust-sensor/ I bought all the HW at the same time

[RikDrabs]

Hi, OK, I believe you, they are on the same place. As you apparently follow the standard build of Luftdaten sensors, and the standard firmware 133, as i can see according the last link you provide, the Chip-ID's must be available, with which the meters are connected to the Madavi servers to distribute their measurements in graphic form with Grafana. Can you send me the 3 Chip-ID's, so i can evaluate the meters from a distance? And are these 3 meters permanently connected, so that correct graphics spanning multiple days of measurements can be produced? And are they measuring together inside, or outside? And are they build with the fragile "loose wire" method, or with a more solid PCB method? (see: https://github.com/CivicLabsBelgium/influencair-pcb). Multiple meters connected to the same WiFi cannot influence each-other. I do this frequently at home, with 3 or 4 meters ...

P.S. When connecting the meters to your WiFi, they shortly become AP (Access Point) with an SSID showing their Chip-ID. (SSID = Feinstaubsensor-xxxxxxxx or AirRohr-xxxxxxxx , where the xxxxxxxx represents the Chip-ID) You can also readout the Chip-ID with the Luftdaten Tool (see: https://luftdaten.info/flashtool/luftdaten-tool.zip)

[RikDrabs]

Please use: https://github.com/opendata-stuttgart/sensors-software/issues/797 to comment or to read comments (edits are not propagated ...)

[hteibler]

Hi Rik connected via "loose wire" :-) data currently only on opensensemap, since 1 Week

ID: 16674657 (bcddc2fe6f61) Firmware: NRZ-2020-133/DE (Nov 29 2020)

ID: 16659405 (bcddc2fe33cd) Firmware: NRZ-2020-133/DE (Nov 29 2020)

ID: 16675631 (bcddc2fe732f) Firmware: NRZ-2020-133/DE (Nov 29 2020)

[pjgueno]

Only the last produces data currently : https://api-rrd.madavi.de/grafana/d/GUaL5aZMz/pm-sensors?orgId=1&var-chipID=esp8266-16675631

Can you plug the sensor on an USB2TTL dongle and read directly the values in screen or Putty or with a script:

https://gist.github.com/marians/dde90d448e4c6f9d850102067ab0f842

There are other examples on the internet.

[RikDrabs]

Ok, suppose they are at the same place. Measured temperatures and humidity tell a different story. And these are measured with the DHT22. A humidity of 70,5, 80,1 and 99,99 % can only be explained by a different environment, old sensors with deviations, or configuration problems. And this has nothing to do with the SDS011's measuring PM values that also deviate widely. Are you sure that your non-standard software configuration to opensensemap is not the source of the differences and the problems? Already tried to switch DHT22's and/or SDS011's from one meter to the next, and check if the measurement stays with the meter, or goes with the sensor? Already tried a conventional configuration with the same 3 meters, which would be easier to debug from a distance, being able to produce a grafana result on the 3 meters, instead of only on one of them? The grafana results of that only one are typical of a SDS011 sensor without air flow. Such low values are impossible in outside air. Are you sure to have used the correct power voltages on that SDS011? It needs a voltage between 4.75V and 5.25V to work correctly, and underpowered adaptors are known to result in problems.

[M10CUBE]

Hi Rik, I am following here your discussion hoping to find a solution to a similar problem. Recently I put in operation 6 sensors. (ESP32, SDS011, BME280) for our local comminity My sensors: https://maps.sensor.community/#16/39.3606/22.9694

60264 PM

https://maps.sensor.community/#16/39.3636/22.9498

61208 PM

https://maps.sensor.community/#16/39.3708/22.9654

61284 PM

https://maps.sensor.community/#16/39.3463/23.0015

61409 PM

https://maps.sensor.community/#16/39.3636/22.9498

61208 PM

https://maps.sensor.community/#16/39.3751/22.8845

61825 PM

using default airroht-firmaware Arduino IDE What is in the box is my own design here: https://hackaday.io/project/171770-m10cube/log/192701-m10sensor-construction Before I put the sensors with airroht-firmaware and using my own firmware ( continually reading the SDS011) I had measurements very close to sensors installed my the local university plus the one installed by the government With airroht-firmaware PPM data (I am referring only for PM 2.5 because PM10 we all know is a derivative of PM2.5 for those sensors) never exceeds 2.5-3. Government for town Volos (Central Greece only PM10):
https://www.eea.europa.eu/data-and-maps/explore-interactive-maps/up-to-date-air-quality-data and university of Volos, Greece sensors: http://greenyourair.org/en/chartsen/volos

for the same area covered Governmental sensors shown 5-20 instead of 0-2.5 for our sensors. Same deference for PM10 too.

I use default parameters in firmware

constexpr const unsigned long SAMPLETIME_MS = 30000; // time between two measurements of the PPD42NS constexpr const unsigned long SAMPLETIME_SDS_MS = 1000; // time between two measurements of the SDS011, PMSx003, Honeywell PM sensor constexpr const unsigned long WARMUPTIME_SDS_MS = 15000; // time needed to "warm up" the sensor before we can take the first measurement constexpr const unsigned long READINGTIME_SDS_MS = 5000; // how long we read data from the PM sensors constexpr const unsigned long SAMPLETIME_NPM_MS = 1000; constexpr const unsigned long WARMUPTIME_NPM_MS = 15000; constexpr const unsigned long READINGTIME_NPM_MS = 15000; // how long we read data from the PM sensors

So is anything to do on the SDS011 configuration to increase accuracy? At the moment our PM values are nearly 100% lower that the governmental values.

Any help will be greatly appreciated any help and direction since this is a community network and citizens of Volos, Greece relay on that as having a source as close as possible to real data. (At least as this kind of sensor permits)

Thank you very much in advance

[Petarkir2000]

@M10CUBE I think one of the biggest drawbacks of your sensor is design. You use a tube to remove air from the box. Didn't you think that this would lead to an increase in air resistance, and hence a reduction in flow and a significant reduction in the readings of the SDS 011 sensor?

[M10CUBE]

Yes @Petarkir2000. That is a strong possibility and I never thought. Last year with my own software SDS011 was in open air or only inlet tube in position. I will remove now from sensor https://maps.sensor.community/#16/39.3606/22.9694 located in my home the outlet tube. I will see results in an our and talk again

[Petarkir2000]

@M10CUBE Note that the length (20 cm) as well as the diameter of the inlet tube is also essential. I have seen a study at the Dutch Institute, where only a few centimeters more or less affect over 24-30% of the result.

[M10CUBE]

@Petarkir2000 so far I removed the outlet and put it on line The inlet is less that 10cm. (nearly 9cm) That is according to instructions. May be the hose diameter is a prioblem One thing I can do in the next ours. I will prepare another one (same characteristics) and put SDS011 on open air (no hoses) . That will show us if inlet outlet hoses is a problem. Then I can exchange the SDS011 between the tow to see id one with the inlet 9cm hose creates a problem

• Can I have this review from the institute ? (about the hose length)
• • Are the default setting in firmware correct? I read that the SDS011 must work for 60 seconds for the measurement to be correct

[Petarkir2000]

@M10CUBE It turned out that the study was not Dutch, but German. See the attached file. That is why in Bulgaria we do not register stations that have other parameters than those from Sensor.community (Luftdaten). Our goal is for everyone to be the same - without changing settings or configuration. Shorter interval, shorter sensor life ... messungen_mit_dem_feinstaubsensor_sds011.pdf

[M10CUBE]

Well @Petarkir2000 here we are: . Sensors side by side Old sensor on the left with low readings (but now without the outlet hose) #60264 https://maps.sensor.community/#16/39.3603/22.9697 New sensor on the right (free air) #62665 https://maps.sensor.community/#16/39.3605/22.9689 The new (#62665) I think is starting showing a bit higher values. But I will see it after some hours working Do I have change (in defines.h) the default SDS011 settings? like warm up period, number of measurements , measuring intervals etc? I have the default so far and it looks that the fan working time is not very long. (For the record I measure 4.8Volts on fan wires)

Finally I totally agree on building the construction according to Luftdaden directions. I strongly believe that and I I did some modification of my own was just because of ignorance. I really want to do my build as close as possible to Luftdaden. I did some homework on the sensebox construction and I admit that the do not have the outlet hose. Anyway I have to translate in English the pdf sent me about the SDA011 directions. Meanwhile sensor is sending data and I am open to suggestions because I am in the middle of crises here with citizens asking me why our sensors have so low values.

[M10CUBE]

For your info After experimentation little increase achieved with the changes in hose in/out (about 15% increase). Real change done by substituting the SDS011 with PMS5003. https://maps.sensor.community/#16/39.3605/22.9689

Now sensor #62665 is reading similar to governmental one. I ordered the PMS7003 instead of 5003. It is only 11 euros! I believe SDS011 is far behind it. Thank you @Petarkir2000 for your time Any comments welcomed