It is very untypical that you have this problem with our default code. What software are you using it with?
My apologies, I forgot that I’m running a branched version of code from an author on the Home Assistant forum. This post can be closed since it is not directly related to the AirGradient supported code.
If you are using it with Home Assistant, you may consider ESPHome as well. I find it very easy to work with and with the original DIY kit, it has been working great. Just waiting for my new conversion kit to arrive.
I’m seeing the same running ESPHome on my AG PCB v2. Every couple of days the OLED display freezes, showing all white until I power cycle the device. I’ve built 2 AGs using PCB v2 and both do it. It’s usually just the display having the issue though as sensor data is usually still coming through to Home Assistant. Sometimes the Senseair data stops too. (FWIW, I’m not yet seeing this issue on my AG Pro DIY device, also running ESPHome.)
In ESPHome, you can add a virtual restart switch to the device and create an automation to have it restart as often as desired: Restart Switch — ESPHome This method mitigates the issue for me.
FYI I’m seeing the same issues with three separate DIY Pro 3 pre soldered airgradients all flashed using ESPHOME and being used with homeassistant.
I’ve addressed the freezing by having them plugged into wifi power plugs and then homeassistant detects the lack of updates and power cycles them when they freeze.
Not sure where to go to further debug what the root cause is of the freezing but wanted to flag that there are others out there experiencing this issue.
I just put together a DIY Pro kit + SGP41 flashed via the build instructions web page and I immediately noticed that the display stops updating after a few minutes or a few hours, but it is still uploading to the dashboard. Usually. Power cycling brings it right back. I tried flashing the example sketch and my custom sketch modified to support the SGP41 NOx readings and they all seem to behave the same. One thing I noticed is that it seems MUCH improved (maybe completely solved??) if I power the D1 mini board instead of the USB C connector on the PCB. Not sure if that is a useful clue.
Also, often, it would not read any temp/RH data after some time and I would get 32F/0% until I power cycle it. Not sure if this is related.
Please post some pictures of the front and back of the PCB. I would like to see the solder points.
Thank you. Soldering looks ok. What kind of power supply do you use? Did you try with a different one?
I’ve tried a variety: I’ve used the USBA 3.1 port on my desktop PC, an EC Technology portable battery, an OEM USB-C charger for my Google Pixel, a OEM USB-C charger for my Steam Deck, and a RavPower 65W USB-C charger. All of these I’ve tried with both the USB port on the D1 Mini itself and the connector on the PCB directly. For the cable, I’ve used the included AirGradient cable, an Anker USBA-toC cable, an Anker USBC-toC cable, OEM Google Pixel White USBC-to-C cable, and the Steam Deck charger’s fixed-attached cable. Feels like it works when plugged into the D1 directly and not for very long with plugged into the PCB, but I have to wait around for hours for each test, so I don’t have rigorous testing and logs to know for sure.
Looking at the dashboard, seems like the temp drops out to 0C/32F/0%Hum quite often and maybe before the TVOC/Nox goes to 100/1. And no idea when the screen stops updating because I’m not staring at it for hours to catch it stopping. But I did modify the code to put in a spinning character (-,,|,/) with each screen redraw so that I can tell if it has stopped. I just don’t know when it occurred. Will need to write a time-stamp to the screen to be able to tell.
But it’s interesting that eventually, the display stops updating, and it feels like everything on I2C is stopped. Temp gets stuck at 0C/32F hum 0%, TVOC stuck at 100, and display obviously stopped updating. But the D1 mini keeps running and updating the dashboard with new CO2 readings and PM readings. The S8 and the PM5003 are on obviously not on the I2C bus. I’m a hardware design engineer, but just don’t have any equipment at home. Maybe I need to rig up something to sniff the I2C bus… Hopefully, putting a load on the bus doesn’t somehow make it work… or maybe that would be a good thing.
@Achim_AirGradient I did some more investigation. I noticed I2C is behaving strange. I confirmed there are no pull-ups on the TVOC board. There are, however, 10K pull-ups on the SHT board to 5V Is that intentional? I noticed there is 10K resistance between SCL & SDA when there should be 20K. That got me curious and after removing SHT, TVOC, and D1 mini boards, I was able to confirm 20K between SCL & SDA on the PCB. That means the OLED display board likely has 10K on each line. Upon further inspection of the OLED PCB, I found SCL and SDA are each pulled-up through R3 and R4 to a 3.3V 662K LDO (Q1) output rail. This means that the I2C lines are pulled up to both 3.3V and 5V. This is bad. I will remove the pull-ups from the SHT board and re-test, but I wanted you to be aware of this.
@Achim_AirGradient I haven’t removed the pull-up resistors from the SHT yet. I’ve simply unplugged the entire SHT board and updated my code to display millis() in hour/minute format to the screen to test how long it will run without the SHT board and its 5V pull-ups. Test is running now.
However, I looked deeper into the datasheets of the various components. Specifically, I noticed the Sensirion SHT3x datasheet specifies that the Vih min = 0.7xVdd. That’s going to be a problem because 0.7x5V = 3.5V and the pull-ups to 3.3V on the OLED screen is not going to meet this requirement. It’s close, and with real-life manufacturing/engineering tolerances, it may work most of the time.
Disabling the OLED’s pull-ups and pulling up to 5V is not an option either because the Sensirion SGP41 datasheet specify that “the sensor’s interface is compatible with 1.7–3.6 V I2C bus voltage levels depending on the supply voltage level.”
Was there a reason for the SHT slot to be 5V? It would be ideal to run the SHT at 3.3V and leave the pull-up resistors on the OLED display since it’s permanently mounted to the PCB anyway. I think that would solve all the issues on the I2C bus with the current components. But I will need to calculate the power budget for 3.3V since it looks like the power is coming from a 500mA ME6211 LDO on the D1 Mini.
The SGP41 now outputs a VOC index instead of TVOC concentration (ppb), but the code and the AirGradient dashboard still refers to this as “TVOC”. The two measurements are not directly comparable. In fact, the index of 100 for VOC and 1 for NOx appears to be always index to the 24H average, so any readings above/below those values represent an “event” or deviation from the average, and not an absolute VOC concentration measurement.
Also, in the build instructions are outdated and tell the user is given the choice to put the SGP30 in either the 3V or 5V slots. The current SGP41 board that AirGradient sells will not work in the 5V slot and will likely be permanently damaged, so it’s worth updating the instructions:
Optional SGP30 TVOC Sensor
If you want to measure chemicals you can connect a Sensirion SGP30 TVOC sensor to one of the I2C slots on the top left of the PCB. Check the module specifications if it should be installed in the 3 volts or 5 volts slot. Most modules can be installed in both. However since all I2C modules already have pull-up resistors on the I2C bus, the system might become unstable.
EDIT: Forum doesn’t allow more than 3 consecutive replies, so I have to edit my latest reply to add this instead:
@Achim_AirGradient Okay, I’m looking at this more and the <v3.7 instructions page shows schematics that have all sensors on 5V. Obviously, the v3.3 PCB I have is not like that based on the silkscreen, gerbers, and my measurements. And the SGP41 wouldn’t work on a board like that anyway.
But the v3.7 schematics and gerbers show that all i2c slots are now 3.3V, which is exactly what I need to make everything work reliably. That and removing the extra set of pull-ups.
Are you seeing other people with the same issues? The kit/design really can’t work in its current state. I would need to cut the 5V trace and wire 3.3V to the SHT slot. I know you said that v3.3 was current when I placed my order, but but it’s simply not a working kit with only one 3.3V slot. Plus, the code provided for v3.7 boards is what is needed to even get correct measurements for VOC/NOx that was sold with the kit – I’ve had to modify the code to work with my <v3.7 board. Would you consider swapping my v3.3 board for the v3.7?
Thank you for the detailed analysis!
The newest version of the PCB (v. 3.7) that we are now shipping has all i2c slots and components on 3.3v (and removed the 5v slot we had previously).
This new PCB is also open sourced. Air Quality Sensor - EasyEDA open source hardware lab (PCB 3/4).
For the software, you can send the TVOC and NOx index to a separate property in our database. The latest code can be seen here: arduino/DIY_PRO_WITH_SENSIRION_NOX.ino at master · airgradienthq/arduino · GitHub
It seems that somehow not many people were affected by this issue, but yes we would be happy to send the new PCB to affected people.
Even though I received the kit less than a week ago, I must have just missed the cut-off for the new version. Are you now removing the pull-ups from the SHT board too like you’ve done with the SGP boards? Even though the OLED PCB pulls to 3.3V also, they are not the same rail, so it’s still not a good idea to have both sets of pull-ups on the bus.
Great! Thank you. How do I start this process?
After reading this thread, I’m considering it could be similar to the issue I posted few hours ago
The subject of this thread didn’t attract my attention before
I’ve figured the same things out here New AirGradient DIY Kit Version 3 Feedback and Discussion - #197 by Hendrik and did some recommendations which I’m happy to hear @Achim_AirGradient did integrate in their new pcb layout.
I will probably contact for a new pcb because I did some hard modifications myself to supply all sensors with 3.3v and removed enough pullups to have a stable bus. (My oled has developed a new problem, brightness going from 0 to 100 in a second and back, but probably not related to the bus itself)
The things I’ve learned is that when something is off with the i2c bus its hard to trace and you have to debug step by step what component is causing the issue. And you need an actual engineer to develop it so it will work in all circumstances. I can understand that i2c was never meant for consumers but here we are just tinkering till it works 
If your OLED display regularly/randomly stops updating, then it is my opinion that it’s highly likely an I2C bus issue. The I2C bus needs pull-ups, but as I’ve detailed, there are 2 sets of pull-ups – one set to 5V and one to 3.3V and there is no way to make either one of those sets work because of the device voltage max/min specifications. The only way is to move the SHT to 3.3V and use just one set of pull-ups.
Even if you don’t see these symptoms, you cannot have pull-ups to two separate power rails. Removing the 5V pull-ups is the best way to solve this, but you will not be able to meet the SHT sensor’s Vih min = 0.7xVdd requirement. Still, it may work if there is enough engineering margin built into the part. Again, moving the SHT to 3.3V is the best way to fulfill the Vih min requirement.
I assume your responding to me. The issue with the oled is not bus related, it fully works except brightness pulsates. Feels more like a capacitor misbehaving but no time to debug now.
And yes go for 3.3v as I already said. Everything is working with the tweaks I described in the other topic.