-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RuntimeError: Invalid PM2.5 header #24
Comments
Have you tried wrapping the code in a function to protect it, allowing it to try again if it runs into an error up to a specified retry limit? UART has a tendency to occasionally just glitch out, and trying again a few times is a valid solution to add robustness to your code. It might solve your problem as I'm not sure if there's a better way around that kind of comms glitch. def read_pm25(pm25_sensor):
read_tries = 0
read_attempt_limit = 5
while read_tries < read_attempt_limit:
try:
particles = pm25_sensor.read()
break
except RuntimeError:
print("RuntimeError while reading pm25, trying again. Attempt: ", read_tries)
read_tries += 1
time.sleep(0.1)
if read_tries >= read_attempt_limit:
# We tried too many times and it didn't work. Break the program to alert the user there's an error
raise RuntimeError
return particles
pm25_sensor = PM25_UART(uart, reset_pin) This lets it try again after sleeping for a small period of time, hopefully long enough that comms work again. If it fails repeated it still raises an error so you don't miss larger issues, like a physical wire disconnecting. #9 indicates that there is a larger bug somewhere and #10 has foundations to implement it, however in the interim 'try again' might be a functional solution. Please let me know if this doesn't help though, I have this code running on my microcontroller that uses the UART plantower's sensor so I think it should work. |
Hello, Thank you very much for this! I will definitely try it out, I did not figure it could be the actual connection method, Still new to CircuitPython and Arduinos in general. I will update you if anything new comes up. |
Wanted to check back in, does the code seem more stable with this protection in place? |
Hello, I appreciate you checking in. At this moment the code is still hanging, but it is not always the header problem. Sometimes its a connection issue. So Ive been adding more Try, Except checks in my code. I also was interested in knowing if its better to put up the setup code stuff like pm25 = PM25_UART(uart, reset_pin) in the While loop with the try checks. I am monitoring it on MU atm to see what problems arise. Usually my Checks will reload the program but something is causing the whole thing to break at random intervals. |
What is the uptime you've been getting before an error? Additionally could you post a sample of your code, and a selection of the errors you receive with the full stacktrace for the error? For the connection errors are you sure your wiring is solid? I'm trying to figure out if the issue is with this Adafruit_CircuitPython_PM25 library, and if so what changes can be done to mitigate the issue and where the issue is. |
Hello, I am monitoring my Serial monitor now looking for the most common error. And the uptime is all over the place. Could be hours, could be a few minutes. Here is my code.
|
So ive noticed it mainly hangs up when getting to the "Sampling AQI" section. It will just not run the code afterwards or raise an error. Im pretty sure my wiring is solid but soon im going to actually solder all of this on a board. Is there a way to implement a timeout? |
Before you solder things in place, I'd suggest removing the other peripheral sensors and trying just running this program stripped down for just the PM2.5 sensor and that sensor alone. It strikes me as odd that the aqi section is only occasionally hanging. it's easier to divide the problem up into smaller things to try this way. Additionally the error could be a power issue, where with all of the sensors on the microcontroller draw just enough power that the comms are on the edge of working. If removing all of the other sensors and running this for a while doesn't solve the problem then we can be more confident that the issue has to do with the communication protocol |
Okay thank you for the suggestion. I will try that and you saying that reminds me that the Teensy4.1 runs at a high freq and draws a lot of power for it. I might also try reducing the clock rate on and seeing if that helps too! |
How is it running with fewer sensors attached? |
So I just moved so I am just now setting up the sensor again. (Sorry about how long this is taking). Ive noticed that its the same for the most part. Still hangs on the "Sampling AQI" part which if i removed that function and just went with the basic read then it would be the header problem. I am going to rewire everything again just in case something got loose during the move. |
Is this with the other sensors removed? If this is related to a power issue, and the other sensors are connected then even if the code isn't calling it the power draw could still be an issue. |
Just wanted to check again and see if better wiring and fewer peripherals drawing power helped increase the stability. I haven't been able to replicate this hanging but I'm using a metro esp32-s2 |
Hello, I just now soldered a lot of the components onto a breakout board and it seems to be running well so far. It will always hangout within 24hrs so ill be sure to give an update tomorrow. |
How has it been running? Is it stable or is the bug persistent? |
Still running into the same bug I believe. Sometimes it is hard to detect exactly what is going wrong.
Its weird to me that it will run for lets say 12hrs then randomly just completely brick itself. If it was a power issue I would assume that it would stop earlier. It could also just be at a certain point all the components are drawing too much power and the Teensy bricks. |
Update. It has been running for 24hrs which is the longest it has ever gone. I created a boot.py file and added
What might be happening is whenever the MCU hard crashes/resets due to some type of failure (Still unsure if its due to the PM sensor) it is not booting back properly with the correct configurations. Basically I have still not figured out what the problem is but I am making it restart (Is my guess to what I did). |
Hey I wanted to check back in on this and see if this has been stable, or if you've narrowed in on if the issue with with the PM2.5 sensor or not. Hope the project has been going well and been collecting informative data this past month! |
So yes and no. It runs for longer than a day but still crashes. When it crashes i cant see any reports and it does not reset/reboot. Do you know of a way to log crash reports/ collect logs? Thanks for reaching out again, ive been quite busy with other projects and apologize. |
Hmm. Boy this is a bunch of open ended questions that this opens up haha, let's start working through them. First, do you think the PM2.5 sensor is the issue? If not it might be best to close this and migrate the discussion someone more apt (and where folks more familiar with the 'more likely core issue' are). I don't know about crash report/logs (that's an aspect of circuit python I need to get a better handle on) but you could do the inverse--make 'success' logs: Are you writing to the sd card at any point? It might help to write to the SD card a lot:
With each of these writes, it'll be helpful to add some extra info, like gc.mem_free() so we can also track the memory in case there's a memory leak in your code. Basically this will create a ton of data so you're very aware of where the program was when it broke, and over time you can see if it's consistently at that location when it broke or in the event that it breaks at inconsistent locations it might be an entirely different issue than we're zeroing in on. I still have a suspicion what you're experiencing is a power supply issue and you're experiencing a brownout that resets your board (I had a similar issue on one of my boards-long uptime, random crash that I couldn't pinpoint) but this might help you identify if the error is consistently in the same location, and give you an idea of the state of the board before it crashed. |
Thank you for the suggestion. I will implement that and look into it. Im running the latest stable circuitpython build. If you are running a similar build what temp sensor are you using? I just looked into that the BME280 sensor might have its own brownouts that could be causing the problem. (Of course thats no the PM sensor, but i was just wondering since ive never gotten an error for the sensor because its the thing causing the problem.) |
My setup has a few more peripherals on it. The base micro is an Adafruit Metro ESP32-S2, with a BME280, SGP40, and an SCD40 on the i2c bus, with the Serial PM2.5 sensor you have on the serial pin. It used to have an Adafruit MiCS-5524 Gas Sensor Breakout on an analog pin as well. The code loop sampled every sensor at 1 Hz and if a data queue was full, it was post the sensor values in the queue to a home server waiting for the data. It would inconsistently hit a random error and hard crash. I had uptime on the order of weeks to months prior to a crash, but I had a similar sensor node design that used a Adafruit ESP32-S2 Feather, the BME280, SGP40, and an i2c PM2.5 sensor setup outside that never crashed. The two microcontrollers were running the same control loop so I was sure the hard crash on the Metro wasn't related to the code. Recently I redesigned the hardware housing for the Metro so I could mount the sensors on the wall (since I liked the data it was receiving) and chose to remove the Adafruit MiCS-5524 Gas Sensor. Since that hardware redesign I haven't experienced a crash and it's matching the uptime of the Feather board. I had been suspicious that the Adafruit MiCS-5524 Gas Sensor was putting me over my power budget for a while and I think now that I've removed it I was probably right. Looking at your board setup I know the Teensy4.1 draws and uses a lot of power, I know anything that uses wifi uses a lot of power, and writing to an SD card can consume a lot of power. Depending on what's going on in the code it might be trying to read from the serial bus after it's just used a lot of power, and unable to send data at the correct voltages because of that. The intermittency of your issues, the number of power consuming parts you have connected to the board, combined with how hard it's been to pinpoint the source of the problem makes me think you're experiencing a power issue like I did. But that could be my own recency bias because it was the problem I recently solved. Regardless of the source issue, over logging might help to start narrowing down some variables. Make sure you also include timestamps with it so we can get a sense of how much time has passed between each type of behavior, that'll be a huge help too. |
How has added logging gone over the past couple of weeks? Has it helped focus on a region that's causing an issue, or is it inconsistent? |
Just going to reach out once more to see if you've been able to log more information, or if you've removed peripherals for more stable power. The closest I ever got to 'reliably' reproducing the error (I say 'reliably' due to it's intermittences, and the part of the code which broke would change) was when I overloaded my board with too many peripherals and started occasionally browning it out. Since removing the Adafruit MiCS-5524 Gas Sensor from my setup I haven't had it crash in months. |
Following this guide https://learn.adafruit.com/pm25-air-quality-sensor/python-and-circuitpython with minor adjustments I keep running into this error...
"Traceback (most recent call last):
File "code.py", line 190, in
File "/lib/adafruit_pm25/init.py", line 83, in read
RuntimeError: Invalid PM2.5 header"
I am using a Teensy4.1 instead of the Feather to control the WiFi Module, Temp sensor, and PM25 Sensor. I am using the UART connection method. What will happen is it will run for a random amount of time, sometimes 5 hours, sometimes 30 minutes before running into this error. I'm unsure how to fix the problem without just looping a reset but that does not solve the problem.
Thanks,
W
The text was updated successfully, but these errors were encountered: