Closed proffalken closed 3 months ago
Try setting sleep cycle off by setting sleep cycle to 0 in paxcounter.conf. Remember to clear NVRAM before reflashing, otherwise old value will persist. Alternatively, set sleep cycle by rcommand, this takes place immeditaley.
SDS011 needs ~30 seconds warm up time. You must adapt your run/sleep cycle accordingly, by adjusting values for send cycle (time when values are sent), sleep cycle (time while module and SDS011 will sleep) and home cycle (frequency which with values are read from SDS011).
A good starting point to check is SDS011 is working is to switch off sleep mode, as suggested above.
Thanks, I'll give that a go shortly.
Out of interest, is there any documentation on setting up your own OTA server?
I see references to PaxExpress in a few places, and I know that OTA is supported, but the TLS cert for pax.express expired 255 days ago and I'm not sure if Pax.express actually provides OTA or whether it just displays the data?
It would be a lot easier for me to be able to update these devices via OTA rather than serial!
I don't maintain PaxExpress, thus can't answer questions related to this.
The original OTA function was based on Jfrog Bintray, but Jfrog cancelled Bintray as SaaS. PaxExpress took over this role for paxcounter boards, what means it provides an OTA update server which is compatible to Bintray and works with paxcounter code.
Ok, thanks, I'll look into that.
I tried setting sleep to 0 and clearing the NVRAM but I'm still getting the same results so I'll keep playing with the settings and see what I can gt back from them.
The first reading on boot is always reliable though, so at least I know 99.99% of my device is now working as it should!
The sds011 code was from @AugustQu as i remember, maybe he is still reading here?
please give me one day or two, I will look for it.
Amazing, thank you.
Let me know if I can provide any further data to help.
I checked this today, and found a working configuration with these settings:
Board LILYGO® Paxcounter LoRa V2.1_1.6.1
// SDS011 dust sensor settings
#define HAS_SDS011 1 // use SDS011
// used pins on the ESP-side:
#define SDS_TX (12) // connect to RX on the SDS011
#define SDS_RX (14) // connect to TX on the SDS011
Note: Disable SD-Card when using GPIO 12/14 for SDS!
Keeping the default settings in paxcounter.conf:
// Payload send cycle and encoding
#define SENDCYCLE 30 // payload send cycle [seconds/2], 0 .. 255
#define SLEEPCYCLE 0 // sleep time after a send cycle [seconds/10], 0 .. 65535; 0 means no sleep [default = 0]
#define PAYLOAD_ENCODER 2 // payload encoder: 1=Plain, 2=Packed, 3=Cayenne LPP dynamic, 4=Cayenne LPP packed
#define COUNTERMODE 0 // 0=cyclic, 1=cumulative, 2=cyclic confirmed
#define SYNCWAKEUP 300 // shifts sleep wakeup to top-of-hour, when +/- X seconds off [0=off]
...
#define HOMECYCLE 30 // house keeping cycle in seconds [default = 30 secs]
This setup results to PM10/PM25 values sent every minute, while SDS011 is falling asleep between two send cycles:
12:23:25.505 > I (224018) src/sds011read.cpp: SDS011: pm25: 1.20, pm10: 4.00
12:23:25.505 > D (224018) src/sds011read.cpp: SDS011: go to sleep
Your cycle configuration is as follows:
OK, thanks, so if I wanted to take a measurement every 5 minutes and then go back to sleep in order to save battery, then would the following make sense?
// Payload send cycle and encoding
#define SENDCYCLE 30 // payload send cycle [seconds/2], 0 .. 255
#define SLEEPCYCLE 30 // sleep time after a send cycle [seconds/10], 0 .. 65535; 0 means no sleep [default = 0]
#define PAYLOAD_ENCODER 2 // payload encoder: 1=Plain, 2=Packed, 3=Cayenne LPP dynamic, 4=Cayenne LPP packed
#define COUNTERMODE 0 // 0=cyclic, 1=cumulative, 2=cyclic confirmed
#define SYNCWAKEUP 300 // shifts sleep wakeup to top-of-hour, when +/- X seconds off [0=off]
...
#define HOMECYCLE 30 // house keeping cycle in seconds [default = 30 secs]
If I've understood you properly, then it would read the sensor every 30 seconds whilst it's awake, send the message after 60 seconds (30 = 60/2), and then sleep for 5 minutes (30 = 300/10)?
Apologies if this is a basic misunderstanding on my part - I'm happy to try and update the docs once I've got my head around this!
sorry. I didn't look into this project for about 3 years so I had to make PIO working again. Then I had to copy the code and start the project. So I still have no working copy here. I'm working on this.
if I remember it correctly:
please check the file SDS011.cpp. It contains a piece of code like this one: void SDS011::wakeup() { sds_data->write(0x01); sds_data->flush(); }
This code works for some devices but not for all (it's too tricky).
So please check your code and let me know.
Thanks @AugustQu I'll do that shortly
@AugustQu - apologies for the delay in replying.
That file does not exist in the version I am currently running (git latest), I only have https://github.com/cyberman54/ESP32-Paxcounter/blob/master/src/sds011read.cpp and the code you mention is not in there.
If it helps, this is the serial output:
16:14:55.132 > I (11419) src/lorawan.cpp: LORA send queue created, size 530 Bytes
16:14:55.145 > I (11441) src/lorawan.cpp: Starting LMIC...
16:14:55.145 > I (11442) src/main.cpp: init fine-dust-sensor
16:14:56.162 > I (11957) src/sds011read.cpp: SDS011: Firmware version [year.month.day]: 18.11.16
16:14:56.664 > I (12958) src/main.cpp: Starting Interrupt Handler...
16:14:56.664 > I (12959) src/main.cpp: Starting Timers...
16:14:56.698 > I (12990) src/timekeeper.cpp: Starting time pulse...
16:14:56.698 > I (12990) src/timekeeper.cpp: Timepulse: internal (ESP32 hardware timer)
16:14:57.695 > I (13991) src/main.cpp: Features: DISP LED BATT LORA SDS PACKED TIME
16:14:57.724 > I (14019) src/timesync.cpp: [14.030] Timeserver sync request started, seqNo#47
16:15:02.772 > I (19061) src/lorawan.cpp: DEVaddr: 0x260B1639 | Network ID: 0x000013 | Network Type: 0
16:15:02.772 > I (19062) src/lorawan.cpp: RSSI: 0 | SNR: 7
16:15:02.779 > I (19063) src/lorawan.cpp: Radio parameters: SF7 | BW125 | CR 4/5
16:15:10.051 > I (26336) src/timekeeper.cpp: [26.347] UTC time: 1711728910.000 sec
16:15:10.051 > I (26338) src/lorawan.cpp: 1 byte(s) sent to LORA
16:15:27.738 > I (44022) src/sds011read.cpp: SDS011 Reading
16:15:28.242 > I (44525) src/sds011read.cpp: SDS011: pm25: 141.10, pm10: 1999.90
16:15:54.153 > I (70434) src/lorawan.cpp: 8 byte(s) sent to LORA
16:16:27.738 > I (104022) src/sds011read.cpp: SDS011 Reading
16:16:28.241 > I (104523) src/sds011read.cpp: SDS011: pm25: 0.00, pm10: 0.00
16:16:54.157 > I (130434) src/lorawan.cpp: 8 byte(s) sent to LORA
16:17:27.754 > I (164022) src/sds011read.cpp: SDS011 Reading
16:17:28.257 > I (164523) src/sds011read.cpp: SDS011: pm25: 0.00, pm10: 0.00
16:17:54.174 > I (190434) src/lorawan.cpp: 8 byte(s) sent to LORA
16:18:27.750 > I (224021) src/sds011read.cpp: SDS011 Reading
16:18:28.253 > I (224522) src/sds011read.cpp: SDS011: pm25: 0.00, pm10: 0.00
16:18:54.161 > I (250433) src/lorawan.cpp: 8 byte(s) sent to LORA
16:19:27.751 > I (284022) src/sds011read.cpp: SDS011 Reading
16:19:28.254 > I (284523) src/sds011read.cpp: SDS011: pm25: 0.00, pm10: 0.00
For anyone else who comes across this, the answer is to replace your SDS011 sensor with a new one.
Doing this solved all these probloems.
Best way to confirm that your SDS011 is working is to plug it in to a USB port with the provided adaptor (I'd lost mine so couldn't do this originally!) and then run something like https://github.com/vvidovic/aqi on your laptop to check the values.
A working sensor will return values every few seconds, a broken sensor will not.
Thanks for your note. To me this looks like a firmware issue on SDS011, not a damaged SDS011. Can you read the firmware version and post here? Thanks.
If connected to paxcounter, the SDS011 firmware version is shown in debug log during initialization.
Edit: it's 18.11.16, you showed this in your log above already.
Please check and compare version on your new sensor. Thanks.
Thanks for your note. To me this looks like a firmware issue on SDS011, not a damaged SDS011. Can you read the firmware version and post here? Thanks.
If connected to paxcounter, the SDS011 firmware version is shown in debug log during initialization.
Edit: it's 18.11.16, you showed this in your log above already.
Please check and compare version on your new sensor. Thanks.
New version is running firmware from 2023:
08:04:22.032 > I (11887) src/sds011read.cpp: SDS011: Firmware version [year.month.day]: 23.6.26
I've had a search but can't see a way to update the firmware on the sensors. If that is indeed the issue, then that would mean I can reuse the existing sensors that I have, although the "old" sensors don't work with the python code I posted above whereas the new one does.
Hello again :D
So, this time I've checked all the wiring and the power, and I've uploaded the sketch to my LILYGO v2.1 board.
The SDS011 spins up, and returns a reading the first time it runs, but then only returns 0 after that.
I've tried waiting for a few hours and seeing what happens in case its a delay in the SDS011 library, and I've swapped the SDS011 for a second one just in case it was the sensor itself, but the results are the same:
I've searched through the issues here as well and I can't see anything that relates to this, nor does there appear to be anything in the docs about specifically having to enable the SDS011 (unlike the BME680), so I'm at a loss as to what's causing this.
Relevant parts of the HAL file:
and paxcounter.conf: