Now I know what the physical dimensions and constraints of the consumables module is, I can turn my attention to the PCB its self and how that will interact with the broader Chicken coop controller system.
For cost reasons, the maximum board area is 100mm x 100mm, except that the corners need to be removed to make the square board fit into the round enclosure. I considered using a round PCB, but the diameter would then be larger than 100mm x 100mm and that in turn triggers a much higher board cost, making it less attractive. It looks like I've got plenty of board space anyhow.
The board will be identical between the food and water feeders, except for a couple of configuration parameters that include things such as its hostname, login details and some parameters around the ultrasonic sensors position relative to the top of the container and the size of the food container, these parameters ensure that accurate measurements can be made.
Power will come from a single 18650 Lithium Ion battery, and be recharged with a small solar panel that measures 110mm x 60mm and claims to produce 200mA at 6V and can be on your desk for less than £3. However, lithium battery charging is more complicated that other battery technologies, so care and attention is needed, otherwise the batteries have a reputation for doing nasty things and I don't want that in the chicken coop. The batteries have some some constraints:
- If you discharge a Lithium battery below 3V, it will permanently damage it and the cell can no longer be charged or recovered.
- If you overcharge a Lithium battery, it permanently damages the cell, but it appears to be charging normally, it just never completes.
- If the battery gets too hot, then it turns into a small firework and rapidly sets fire to everything around it.
- Lithium ion batteries have a narrow operating and storage temperature range, they can't be charged below 0C and shouldn't be charged above 44C
Luckily, IC's exist that protect against the above problems. The TP4056 battery charger IC, DW01A over current / under voltage protection IC and a FS8205A dual MOSFET to disconnect the battery completes the solution. These are available in module form for next to nothing on eBay, coming in at around 80p each when purchased in 10 packs. I can't even buy the same / equivalent components from the mainstream suppliers for a similar cost, so I'll just get some disassemble them and re-use most of the components within my board, rather than have a daughter card on top of a PCB.
Lithium batteries produce a voltage of between 3.0V when discharged and 4.2V when full charged. Some modern cell chemistries are able to go down to 2.5V, but I'm not using those since they will be more expensive to procure. Either way, this voltage range is well outside the nominal 3.3V +/- 5% voltage that modern devices such as the ESP32 and other common device expect. A regulator is therefore required to convert whatever the battery voltage is to a stable 3.3V. Luckily, standard of the shelf IC's provide this function with various buck / boost regulator devices, providing a constant 3.3V irrespective of the input voltage.
Processor choice
Since the workload on these modules will be very low and because I have a pile of ESP32 S2 Saola-1 units doing nothing, these can be the controller for the module, they have WiFi and can therefore connect back to the MQTT broker with telemetry information when needed. They do not have any Bluetooth capabilities and as they are in the middle of a muddy Chicken pen, getting a console connection to them could be challenging, but luckily the previous solution to console access will work here too. I also need to be really careful about power consumption.
I decide not to use a footprint for the ESP32-S3 and use my ESP32-S2 to ESP32-S3 adapters, since that will make the stack-up of this board too large when other modules are also considered. With the board cost being low, in this case, it would just be simpler to respin the board should I want to upgrade the main module. I also toy with the idea of dropping the ESP32 directly onto the board and getting rid of the development board profile, but decide to go with what I've got on hand. After all, I'm not making thousands of these.
Power budget
Due to the very limited power budget of the single 18650 battery, which can provide somewhere between 2200mAh and 3500mAh, depending on the battery used and its condition, plus the very limited solar power available over the winter months to recharge the system, I must preserve power as much as possible. A couple of quick measurements with a solar panel, a power resistor and a multimeter on a couple of average cold but bright winters day showed that I could generate somewhere between 10mA and 65mA of power, depending where I am in respect to the sun, so this is a trickle charge current at best. My fall-back position is that the 18650 batteries are easily removeable, so could be swapped with others in the house and recharged inside if required. I would prefer hands-off automatic systems if possible, but that's not always an option, as experience with solar power on the main unit has already taught us.
The solution to conserving power is to consider what actually needs doing. The water and food level does not need millisecond accuracy on the food level, measuring it every half an hour or every hour and perhaps far less is fine when you consider that we generally only need to refill the feeders once within the week, although the rate of consumption does change with food in the winter and with water in the summer months.
In between taking measurements, the system can go into a sleep mode and the power requirements become very low. The ESP32 has a variety of power saving modes that it can be put into, with different features and limitations.
It would be useful for a console be provided over Telnet / SSH or Bluetooth using the HC-05 module. However, neither the Bluetooth nor Ultrasonic module has a low power capability, so additional IC's are required to switch their power, The Microchip MCP1253 charge pump regulators looks to be ideal, simply provide a GPIO pin into their !Shutdown pin and you are done, they can also produce 3.3V or 5V outputs depending on the state of the SELECT pin, which makes them a great option, particularly as the ultrasonic modules I have require a 5V power supply.
The challenge remains though that a system that is asleep can't be communicated with, nor have its firmware updated and both of those are useful features too. Yes, I can remove the module from the coop and take it into the house for an upgrade if necessary, or I can add an SD card slot and a TFT display and let it do a self update. To keep things consistent, I decide to add the options to the board, since as I've said before, adding traces and device footprints does not impact the manufacturing cost of the PCB's, it only impacts your cost if you choose to populate those positions on the board during assembly.
I now have a design that:
- Is cheap to manufacture and uses some parts I already have in stock
- Is consistent with the other modules in the system around areas such as management and firmware upgrades
- Can measure the important things for the consumables, including the height of the food or water and the temperature in the enclosure, which can be adjusted to give a view on the water temperature below.
- Can be charged from solar panel throughout most of the year, but can have the battery swapped easily if required
- Solar charging does not require the ESP32 to be powered up, so it can go from flat to good just with the charge controller IC's
- Protects the lithium battery from common failure modes
- Allows all of the modules to be individually powered down when they are not in use
- Can be contacted from the development workstation when the module is on
- Has an option for a removable 1.8 inch TFT display, so that I can display information on it when developing the board
- Has a JTAG connector to allow debugging, since this is likely to be useful when working on low power configurations.
- Protects the electronics from the environment outside and includes the ability to wrap the battery cell in insulation, further protecting it from low temperatures during the winter months.
- Allows two (and potentially more) 18650 batteries to be installed. On on-board, and one in parallel, somewhere within the enclosure. This is some insurance against any power budget issues. It would need a modification to the enclosure layout though to provide a suitable battery location and there is no charge balancing capability across the cells.
The only remaining problem in the above is how to get to the console, if the device is asleep and the Bluetooth module is powered off as both WiFi and Bluetooth will be unavailable.
Then a lightbulb moment happens. I have a central message broker, so what if I send a message via MQTT to the device in a retained manner, so it will ready, in the queue for when the module powers up. It can then retrieve the messages it missed whilst it was sleeping. A suitable command could be an insomnia mode, where it is prevented from sleeping. This will drain the battery quicker, but allow the Bluetooth and WiFi to be up, OTA firmware is then an option too.
The insomnia mode can be a limited uptime, with a warning when it approaches zero, hence preventing the situation where you turn it on and forget its enabled and end up with a flat battery and an inoperable module.
Last Will and Testament
As MQTT is being used, the option of Last Will and Testament (LWT) is also available, this is a special message that is requested at the point that the client connects to the broker and it instructs the broker what is to be sent (as in a will) to anyone that is subscribing to that topic. This means that unexpected disconnects can now get a useful message. This is really handy if the device runs out of battery for example, although there should be multiple battery low alerts, well before it actually fails, but I digress.
How low power and LWT work will need testing. At this point, an interrupt occurs that makes me want to go and read a Discworld novel again as I think about the Granny Weatherwax statement "I' Aten't dead" from the book Equal Rites, from Sir Terry Pratchett. I must make some more time to read those books again.
Back to the problem.
Power management
Using the blended approach to power management, I can keep the quiescent current on the module right down for much of the time, powering up the ultrasonic measurement module when its needed, using it, then powering it off again. The same can be done for the SD card, although the reader its self will not consume any power if no card is inserted, since its just wires in a plastic and metal slot, so multiple options exist there. The temperature sensor's quiescent current is a couple of microamps, so that's not worth switching. The TFT card will be on a connector, so it can be removed before installation or installed during any fault finding, just like the diagnostic display is in the main unit.
There will need to be some analysis done about picking the right wake-up frequency to balance flexibility on things like remote power on speed. If that's too long, then its simpler to walk to the garden. If its too frequent, then power will be wasted and the battery will go flat more quickly. Similarly, if we have connected WiFi up and logged into MQTT to send one message, then we may as well send all the sensor information updates. Knowing the food and water height is one thing, but knowing the temperature and charge subsystem state is also useful.
Whilst building the schematic for the board, I note that there are some charge state pins on the charge controller that say if the battery is charging or fully charged, with a couple more passive components on the board, the ESP32 now has visibility of that. This is in addition to the usual power monitoring of key lines on the boards, so voltage sensing of the solar panel and battery is added. Current sensing for the charge controller is also available using the current limiting resistor that the charge controller requires. I can now see the state of the charge module and the solar voltage, charge current and battery voltage and I've still got some pins left on the ESP32. Nice. The only thing I can't sense is the power being consumed by the module, but I'll only need that during development and that's easy to fix on the bench.
The charge controller has an inhibit pin, which can disable its operation. This is connected to the ESP32, with a suitable pull-up resistor to default it to enabled if the ESP is not driving the pin. This will allow the temperature sensor in the module to act as a second layer of protection above what the thermistor under the battery can provide. This ensures that the cell is only charged within the cells safe temperature range.
The schematic is then completed and laid out, resulting in a nice clean and logical board layout. The usual PCB validation steps are performed and the PCB's are ordered from PCBWay, hopefully with enough time that they should get to me before Christmas, even though I use the cheap shipping method. Now I can turn my attention to creating an initial code base for that module.