@gsuberland Very neat board, btw. Is the idea to read from all three sensors and do some comparative analysis / "sensor fusion"? I'll be interested to see what you find.
last time we just had the MH-Z19D and SHT35. the readings got skewed a lot by foggers in the nullsector and other areas. we're switching to the SCD40 which is a much better photoaccoustic NDIR design with two internal sensors (one for autocal & deskew, one for the measurements). the SGP30 should hopefully help provide additional insight into TVOCs.
I'll also be adding a PM sensor to a couple that'll be operating in fogged areas.
@projectgus these sensors are intended to have two main functions: to help orgas identify places where airflow is a concern, and to help attendees make informed decisions. all the data will be publicly available via a Grafana dashboard for anyone to check out.
@gsuberland Is it too late to talk you into an ESP32 family devboard instead of 8266?
It'll be fine but switching gives you better firmware options, hardware I2C and PWM, and overall less rough bits. Although if you have a mature ESP8266 firmware stack in mind then that probably trumps any of this.
@projectgus I built this to use the ESP8266 devboards I have in stock, to save costs, but the specific ones I have (Plusivo) are no longer manufactured so I will be building NodeMCU ESP8266 and NodeMCU-32S adapter boards anyway to give me options.
@projectgus I already have the rev1 firmware for these boards so I decided to stick with them for this.
in hindsight it would've been better to build them for ESP32 since I'd forgotten how limited the GPIO was on ESP8266, but I'm committed to this design now. although since it's just I2C for everything except the MH-Z19D (which is UART) it's trivial to make adapter boards.
@gsuberland Also, I assume you are all over this as your depth of MOSFET knowledge trumps mine, but the AO3400 level shifters look like they'll be still in their linear region when 1.8V side pulls low. I don't see a section of graph in the datasheet that covers it, but I assume it'll still be much more conductive than the small current they need to pass to pull down a 10K pullup quick enough?
@projectgus you'd have been right at 1.5V though. the worst-case Vgs(th) is 1.45V and at that point it only sinks about 250uA, which wouldn't be enough to pull the rail down.
(although in practice it might be ok at that low a voltage since Vgs(th) typ is 1.05V)
I'm aware that the 1.8V LED might be very dim due to the low voltage. one solution would be to use a MOSFET to drive it from 3.3V with the gate tied to 1.8V, but that's kinda clunky.
all signal vias should have a z-axis GND reference via close by regardless of expected transition speed; I don't think I missed any.
the heavy via stitching is for both electrical and thermal reasons. keeping the sensors at the same temperature will help keep the measurements as accurate as possible.
the fan output is for periodic operation. these sensors have special guidelines around airflow. the chassis will be designed to produce fairly laminar airflow over an aperture to avoid turbulent air movement over the sensor. every so often (e.g. once every 15 mins) the sensors will stop taking measurements, the fan will operate for a few seconds, then the sensors will resume after some settling time. this way we avoid air stagnating inside the sensor but don't mess up the readings with the fan.
the board cutout is intended to pull double duty. it improves airflow to the sensors under the MH-Z19D, and also aligns with the position of the PCB antenna on the ESP8266 dev board.
it turns out these Plusivo ESP8266 boards from the rev1 design are now no longer made, so I'm intending to build some NodeMCU adapter boards. those will cause the devboard to sit further off the board, so RF attenuation should be less of a problem, but I still intend to align the antenna with the cutout if possible
the pads and via stitching around the edge are intended to make it super easy to mount the ground clip on a scope probe for debugging.
the 0Ω resistors (e.g. GPIO net ties, and those in the 1.8V logic level conversion) are defensive design features to make it easier to separate things and rework them if needed.
the VIN-VUSB jumper (J1) is there for similar reasons. makes it easy to verify I've got the connections right first, then bring up the DC-DC.
Add comment