pimoroni / pms5003-circuitpython

CircuitPython library for the PMS5003 particulate sensor
MIT License
2 stars 5 forks source link

Frequent "PMS5003 Checksum Mismatch" #3

Open dglaude opened 4 years ago

dglaude commented 4 years ago

I frequently get Checksum error and I can see from raw data very suspect data that are power of two when this is the case.

PMS5003 Checksum Mismatch 371 != 1024 ... 2.5um in 0.1L air: 512 5.0um in 0.1L air: 1024 10um in 0.1L air: 1024

I would love to know if other have that issue... maybe there is a hardware problem with my board or sensor?

None of the exemple code not try to catch those exception and just fail. This might not be the proper way if you want to monitor for a long time, it would be best to safely fail and ignore that data for one sample.

Right now, my work around is retry loop that attempt to read again in case of exception. For that I renamed read(self) into read_once(self). Then in the new read(self) I catch exception and give it another try. There might be other way, but that work for me and hide the problem.

    def read_once(self):
# Was     def read_once(self):
#     ...
        return data

    def read(self):
        for attempt in range(2):
            try:
                data = self.read_once()
            except:
                data = self.read_once()
            else:
                break
        return data
dglaude commented 4 years ago

Are the enhancement from version 0.0.5 of the Python library ( https://github.com/pimoroni/pms5003-python/releases/tag/v0.0.5 ) embeded into this CircuitPython library.

There seems to be a lot more recovery in the Python library.

The following code from Adafruit works best for me (in CircuitPython): https://learn.adafruit.com/pm25-air-quality-sensor/python-and-circuitpython

However with Adafruit new library, when used in UART mode, I get error after a few minutes: https://github.com/adafruit/Adafruit_CircuitPython_PM25/issues/4

Since this is a Feather and a sensor officially supported by Adafruit, you could do like you did for adafruit_st7735r and adafruit_bme280, this mean using their code. Of course, you could contribute enhancement to Adafruit library proposing the trick you use in your Python Library.

PS: I am just a customer... of both Adafruit and Pimoroni and I want the best working code for this hardware. ;-)

Gadgetoid commented 4 years ago

I think you're right with respect to deferring to Adafruit's code here- there's no sense in re-inventing the wheel.

I made the stance to provide non-CircuitPython libraries for all of our devices since this allows Raspberry Pi users to use our hardware without pulling in Blinka - it's always good to have choice - but it doesn't make much sense to try and bring these libraries across to CircuitPython. Frankly right now we don't have the people-power to be causing ourselves unecessary work!

I recognise the concerns of you and other Enviro+ FeatherWing users- and understand that the software on the whole needs some work. However- I don't currently have the capacity to switch over to CircuitPython and make a concerted effort to fix this just yet (the current crises has blown a huge hole in my productivity that's not soon going to recover). Thus any contributions you make are greatly appreciated.

Anyway to summarise I'm happy with any improvements from this library being folded into Adafruit_CircuitPython_PM25 and this library being discontinued. It's worth noting that they make the same incorrect assumption that I did- that sensor readings will be 1/sec. This is mentioned in this issue: https://github.com/pimoroni/pms5003-python/issues/6 and I think may be another reason why serial comms are prone to break (a potential buffer overflow).

(P.S. I received your email and generally agree with your assessment, but for the same reasons do not have the time to write a considered response- I think the above covers it, though)

kevinjwalters commented 3 years ago

It was around every 919ms here, ignore the favg and fmax, they are misleading, from RX pin on Feather:

ss-plotted_combined-withchksumanda5toggle-startup-1-zoomwithfreq-screengrab-freqcrop

I think I've seen it vary a little bit. Without a specification or substantial data it seems unwise to assume a specific, precise rate. I've got some other stuff to do over next few days but I'll have a look at picking up the "passive" mode from the other code out there, that makes it request/response. I'd like to check how snappy that response is first

kevinjwalters commented 3 years ago

Same thing in partner library: https://github.com/pimoroni/pms5003-python/issues/3