Some initial thoughts
Here's a brain dump of the state of things, since this is the first post.
General architecture and motivation
I'm normally not one to let a particular piece of hardware (microcontroller, temperature sensor, etc.) be the driving force behind the project; it's a little backwards from a traditional engineering point of view. However, the idea for this particular project came about because of a confluence of two things:
- I have some fans cooling my entertainment center that I want to control to minimize noise and dust accumulation
- When I first looked at the ESP32, it has very nice 8-way PWMs and pulse counters
Thus, the idea of a fully-connected, 8-way fan controller based on the ESP32 was born. Most of the driving and speed sensing can be done right on the ESP32 itself; the PWMs and the pulse counters take care of most of the standard fan control stuff, and it can handle SD cards natively. An external temperature controller, an analog MUX and a GPIO expander can take care of the rest.
Feature set
Now that we've put the cart well in front of the horse, here's the overall feature set I'm driving towards.
- Control of 8 fans
- Support grouping fans for a targeted speed, optionally synchronizing rotations and/or applying spread spectrum techniques to reduce audible noise
- Support control of non-PWM fans via optional power switches by buffering tachometer pulses (more on that later)
- Support non-tachometer fans via open-loop control
- Measure average fan current and report to user/detect stalls
- 8 temperature sensors
- Apply weighted averages of individual sensors to create specific temperature groups to control fan speeds
- Allow multiple temperature groups for multi-zone fan control
- Support simple home-made temperature probes (2N3904 on two wires)
- Connect via WiFi and Ethernet
- Connect via Bluetooth Low Energy (BLE, now also called Bluetooth Smart) for easy smartphone control
- Log data in RAM, optionally providing long-term logging via microSD card
All of these objectives can be accomplished with the ESP32 with a small handful of external support chips (and some discretes, in the case of the power switching/tachometer buffering).
Where I am now
I'm currently chewing through the pinouts of the ESP32 and its pre-made modules (e.g. ESP32-WROOM) to come up with the most efficient assignment matrix. Unfortunately, because of the way the ESP32 modules are pinned out (both the WROOM and the WROVER), prototypes based on the modules will have to be scaled back. The following features are modified:
- Only support 6 fans
- GPIOs 37 and 38 are not pinned out on the modules because they are used solely for the touch sensor cap negative end on the modules
- Only support 3.3v SD cards
- The VDD_SDIO rail is not pinned out on the modules, and the WROOM modules only have 3.3v flash anyway.
Fun challenges for the future
- The only way to fit all these things on the ESP32 is to heavily use multiple functions on some pins
- The SPI flash, the SD card and any external SPI devices must all share the same pins
- This means that internal SPI (source of the program) needs to be shut off while dumping to SD/performing SPI transactions, because there's no nice means of sharing access
- This may have adverse effects on WiFi/Ethernet/BLE stacks and will involve quite a bit of work
- The I2C and MDIO buses need to share pins
- This is somewhat easier, but requires some rework of the MDIO accesses to switch back and forth
- On the other hand, it just might be possible to safely share the lines without switching, but I need to double-check that
- Ultimately, the external SPI bus (currently envisioned for peripherals like OLED display) may have to go because there's just one pin too few
- The SPI flash, the SD card and any external SPI devices must all share the same pins
That's the brain dump for now. More to come once I've actually done some more research!
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.