cchs-melbourne / esplant Goto Github PK

The readme.md is missing

git clone https://github.com/CCHS-Melbourne/ESPlant

before the 'git submodule init' command and you can't get download the zip file from github as you don't get the .git folder and 'git submodule init' fails

Strangely, it appears as two devices in the device manager and even after pretending it was a STM virtual com port, upload was not successful.

On the page https://github.com/CCHS-Melbourne/ESPlant/wiki/Internal-Sensors the link to the BME280 is dead. It should be http://www.bosch-sensortec.com/en/bst/products/all_products/bme280

Robyn

Using rev 3bc7665:

1. When the STM32 first powers on and then goes into low power sleep mode, with ESP also in deep sleep, total board current is approx 12.5mA - too high, implies it's not going into STOP mode.

2. If you then press and release "STM Reset" and the STM32 resets and then returns itself to sleep mode, total board current drops to approx 1.1mA - about right for properly configured STOP mode.

3. If the ESP then wakes up, uses the i2c ADC (which wakes the STM), and everything goes back to sleep, the total board current becomes approx 2.5mA - implies STOP mode is working, but some peripherals are not being powered back down correctly.

Symptom (3) Seems to be caused by enabling ADC channels 3 & 4, even if we don't run an ADC conversion. If I skip setting these channels then the current consumption drops. Not clear why these channels in particular though.

Symptom (1) must be some weird difference between Power-On-Reset and the reset button being pressed, but I don't understand what it could be.

In dim light, the solar panel voltage droops to consistently match the battery voltage (the point at which the power switch changes and the battery starts supplying current as well). Rather than being a transient, this is the steady-state if the light level is low (the current drawn from the panel constantly varies to maintain VSOLAR=VBAT.)

Unfortunately in this state (VSOLAR==VBAT), the op amp output floats at approx VOUT/2, which means neither FET saturates on - they both turn on a bit, but still in the linear region. Most current to the load appears to be supplied via the FET body diodes.

This means there's suddenly a big voltage drop between VBAT and the input to the 3.3V regulator. The drop is enough that with common battery voltage of ~3.7V, the 3.3V rail can droop to 3.0V-3.1V unnecessarily. With the battery below 3.7V it can droop enough to cause boot loops on the ESP.

Despite being a flaw, this is working "as intended" in one way - there's no way that the solar panel can back-power the battery in the circumstance where the voltages are approximately equal. However it's still not the intended behaviour.

On my board I've tried adding a 100K pullup between GBAT and VOUT (gate/source on Q203) and a 100K pulldown between GIN and ground (gate on G202 and ground.) This acts as a "tie breaker" so when the op amp output is floating in the deadband it will prefer turning on the solar panel input over the battery.

This seems to fix the problem, and doesn't seem to cause battery backpowering in my limited tests (VBAT is always held a bit higher than VSOLAR). But I'd like to experiment more.

Will allow us to do some checking of light levels when there is not sufficient power to charge. This would allow light detection inside for example, when the UV sensor would not work.

#10
shows that neopixel LED updates get dropped for about 0.5sec from time to time, and cause my GPIO commands to the LED string to be lost. It then self recovers.
It's as if the wifi chip or some other background task is causing GPIO output to get lost or corrupted, causing an LED update or two, to be lost.
The amount of time this happens seems to depend on the the pattern at which I send neopixel updates.

We've already run in to a few occurrences were having a 5v pin would be an advantage.

It might be possible to extend this to having level shitted connections that can be switched on and off as we currently do with the 3.3v rail.

In the 'Onboarding to Wifi' section there needs to be a note:

May need to press ESP FLASH button to get esptool.py to work.

I am running the erase command as sudo on Linux Mint but I don't know if that is always required.

Robyn

As per this guide http://randomnerdtutorials.com/modifying-cheap-pir-motion-sensor-to-work-at-3-3v/

The SR-HC501 PIR sensor can in fact (unofficially) use 3.3V as its using a (5V - 3.3V) Voltage Regulator anyway, simply moving the VCC Source from the VCC IN to any header past the Voltage Regulator enables the Sensor to work.

(Here is the position of the header that 3.3V IN can be attached to)

Please note this is untested as I had no Jumper cables on me, but has worked in previous projects.