Things have been progressing at a steady pace with the ESP32 port. Finally resolved enough of the hardware changes to warrant fabricating a new PCB with all of the functions to date:
Look familiar? It’s easy to mistake it for the ESP8266 based V5 IoTaWatt. That’s because one of the design goals was to put this into the same enclosure, which this will satisfy. The ESP32 devkit is about the same size as the ESP8266 but has 38 pins instead of 30 as in the ESP8266 devkit.
This version is also laid out the same with respect to the common components so that I could use the same PCB stencil (hand worked the extra components). The final version will probably move some of the components around to better utilize space and accommodate a few more components (more about that later).
The major hardware changes are:
SDcard now uses 4 bit data path at 40MHz instead of 1 bit at 20MHz (8x improvement).
ADC power, reference voltage and bias are now supplied by an independent 3.3V supply powered directly from the ~5V raw USB feed. The 3.3V available from the ESP32 devkit was just too variable and noisy. With a dedicated power supply just for measurements, things are rock solid.
The major firmware functions are working: Sampling, datalog, web server, inmflux, emoncms, file manager, message log.
The datalog record size has been increased x4 to 1024 bytes. This allows for more accuracy in measurements like VAR, and opens the door for tracking import/export, additional inputs, and other metrics from other sensors.
The plan is to add a second PCB with an additional 14 power inputs. The concept is to make it field expandable with a ribbon cable to this unit and an enclosure riser that would sit between the two, adding maybe 12 or 13 mm to the height. Still researching the connectors, but should have a prototype with provisional wiring soon to test the sampling with 28 channels.
Amazing how fast I’ve run out of IO pins. Have a few input only remaining. Considering adding a 16 port I2C chip to the expansion board and using one or two of the input pins for interrupts from it.
Currently thinking more about adding drivers to support third party bluetooth data like temp, humidity etc.
Have experimented with using an ESP-WROVER instead of ESP-WROOM-32 as it has a lot of additional memory in the external PSRAM. Have an adapter to run with one, and it works fine, except for two things:
The PSRAM takes away two more GRIO (16 & 17)
The form factor would require a change to a component in the enclosure mold.
So the memory comes at a cost. Right now, there’s still quite a bit of heap using the VROOM, so I’m staying with that. That said, I’m starting to experiment with supporting HTTPS, so heap could disappear quickly. Not sure the PSRAM will solve that, but good to know it’s there.