Back to

PMS5003 Readings Understimation

Hi all,

This post is to notify everyone that we have found a bug in the SCK PMS5003 sensor code that provoked an underestimation of the sensor readings, as well as an increase in the readings variability.

As you know, we use the sensor in one-shot mode, meaning, we turn on the sensor for 15s and we take one reading after those 15s (or so we thought). After that, we turn it off until the next reading cycle comes. This was evaluated here and the approach has been reconfirmed here. The PMS5003 sensor was being run in active mode, which means that the sensor is actively collecting data and sending it. Since the sensor communicates with the SCK main microcontroller via serial, the readings were getting accumulated in the serial buffer for some seconds, until the sensor turned off again. Sadly, this bug means that we were not clearing the buffer when we wanted to get the reading at t+15s (one-shot), but most likely at t+1s or t+2s, which meant that the fan and laser in the PMS were probably not stable and hence reducing sensitivity and increasing reading variability

This lead to approximatively 50% underestimation of sensor readings, and an increase of sensor SNR as seen in the graph below (blue, correction - orange, bug)


We apologise and hope this doesn’t impact your experiments. Let us know if we can support on fixing or adding more information to the issue.

Secondly, we strongly recommend to use the firmware fix in the upcoming 0.9.9 release. This will be released very shortly. For those wanting to test it, master branch can be compiled and flashed, but some extra features/fixes are being tested for the new release.


Thanks for your work on this.
Indeed the graph shows a significant reduction in variability, something that I’ve noticed with my readings.
I’m excited to test the result.



Hello all!

So… finally it’s here: Release 0.9.8-PM · fablabbcn/smartcitizen-kit-21 · GitHub

Sorry for long delays (or generating expectations for shorter times…). Let us know if you see any issues.

1 Like

Thanks @oscgonfer ,

I was just prepping the sensor for some more use for tomorrow and saw the update.

Here are my results from a quick test this evening. Not at all the same time scale as your example above. My data is not very thorough with just 20+ minutes of usage.

It looks like there’s less variability with the new firmware, as you stated. Not much to say with only 20 minutes across different surfaces and spaces of data collection however.

Here are some graphs and maps. On the left is the previous firmware, to the right is the new firmware.

These were taken concurrently on a bicycle as shown.


Wow! That’s really nice!

Just to confirm: you say that left is old and right is new?

PD: I love the enclosures by the way. If you want to have them on the enclosures repo, that would be amazing!

Now you have me doubting myself.
I double checked the firmware version, token and account association on my platform and it’s correct.

The left=0.9.8 firmware, right=0.9.8-PM firmware
I had some doubt at first due to the higher values in the old firmware version.
Regardless, longer testing is needed on my part to really see the impact.

The new firmware sensor is with a participant so I can’t provide do more comparative testing until two weeks from now.

I added the models for the case to Printables.

I’ll let you add them to the repo unless you prefer that I make a pull request.
The design has some parts I’m very happy (the case and the quick release bike mount) but the internals need some more work as there’s some vibration/rattling.




Looking forward to see more data.

Eitherway, your setup looks very good. I can add your contribution to the summary table, and, if you want to, you can make a PR too, otherwise this is fine by me:

(so nice!)