Now I know what I am trying to achieve, I can think about the board features and design, but the boards should be designed in a consistent in approach and use similar components as that will reduce design risk, ensure consistency across modules and to reduce software development effort, plus it means that I need to keep minimal spare parts to fix things as I move forwards.
Hardware design
I set about working on the design and settled on an approach that uses the same modularity as the v1 design, where there is a main board in the coop, which can run autonomously to anything outside of the house, so in the event of a power cut, the Chickens are still getting in and out of their house at the right times. The modular approach helps to reduce costs when I need to respin a module, since smaller boards are cheaper to make than larger ones. This also meant that I needed to take extra care for the large board in the main unit, since that was going to be relatively complicated, and cost a lot more to make and I really didn't want to have to respin it unless I absolutely had to. I can however reduce the risk of a respin by adding some expansion sockets to the board. Any edits can go into those, which will be cheap, since they are fairly small.
I wanted to re-use components I already had in my collection, where it made sense to do so, since this would reduce the cost of the components needed to build the system. I wanted to clean up the design and remove the need for the Raspberry Pi that existed in the first version, so that I can get the power budget down on the system and make it run for much longer on battery.
Processors
I had been looking a the Espressif ESP32 microcontrollers and their impressive set of features such as WiFi and Over The Air (OTA) firmware upgrade capabilities and the ability to map most functions to nearly any pin on the device - in software. As long as I can resolve things such as getting a reliable console connection into the ESP32, then I don't need the Pi any more. However, for expandability and options, I'll still add in the footprint and expected connectivity, just in case anything changes as my crystal ball is a bit fuzzy at the moment.
Removing the need for the Pi is a key factor in reducing the power required by the system, since as it is a fully functional computer, it requires a relatively high amount of power. The old Pi model A in the original design required a constant 250mA, with peaks well above that during start-up. Although the coop was upgraded to the Zero 2W several years ago, this still needs about 300mA for the peak current need, but the typical running power requirement is around 150mA, the actual value is dependant on what the board is doing at that point in time. The newer Pi 3B needs around 600mA and a Pi 4 is just under 800mA for the same idle workloads, according to external research.
Boards
I settled on a design that has 3 printed circuit boards forming the stand-alone core of the system, but with the ability to add more modules over time. There will be :
- A main board in the coop, using the existing boxes form factor, since I've already got a spare and the mounting holes in the coop will therefore line up. This keeps most of the electronics out of the weather and allows for most of the wiring to be hidden. Given the enclosure size, the board area should be large enough as PCB's generally need less space than prototype boards, although I was using vertical stacking of some add-on boards in the old design.
- A front panel board, that sits outside the coop at the front and forms the main user interface and its easily visible from the house.
- A power sensing board that monitors all the higher voltage and higher currents, keeping these well away from the main (expensive) board. The separation keeps some electrical noise remote from the main unit including any generated by the charge controller.
Logical architecture
There are many ways to design boards, all with different pros and cons. A single integrated device handling everything is attractive and simple to implement, but if you need a capability that is not on the device, or or more pins than the device has, then you have to to utilise a dedicated integrated circuit (IC) and there are literally thousands of different devices that will do virtually anything you might need. A large percentage of these devices will need some supporting connectivity such as a data interface of some form of control lines such as chip selects and interrupt requests. The first thing though is to decide what is going to control all of those devices.
Microcontrollers
The previous board was run by an Atmega 2560, which was a single core 16MHz CPU, a tiny 8K of RAM, yes 8192 bytes), 256K of firmware FLASH, 4K of data EEPROM and it could only run at 5V. Only about half of the total RAM was consumed due to some careful coding and tricks such as bit packing multiple flags into one byte, storing static messages in EEPROM rather than RAM. Clearly this board is past its best and being 5V, no longer meets the need as all current generation devices are 3.3V or lower. Its also lacking modern features such as WiFi, Bluetooth, etc.
The microcontrollers will be replaced with a current generation device. After a bit of looking around and because I had some in stock already, I selected the Espressif ESP32 S2-Saola-1, this is a is a single core Xtensa LX7, 240MHz CPU, with 320K of RAM, 128K of on-board EEPROM, 2M of external SPI EEPROM , 2.4GHz WiFi, with IPv4 network capabilities, low power operation and the ability to matrix many of its internal functions to most of its external pins. It supports common interface protocols such as SPI and I2C, JTAG for debugging and it has two UART's, although one of these is used as the programming interface and already exposed on a USB connector. You may note that Bluetooth is not listed in the spec, but more on this later. The device also uses FreeRTOS, the open source real-time operating system, which is helpful.
Microprocessors
Where a full OS is required, A Raspberry Pi Zero W2 will be used, since its a small form factor and gives me lots of capabilities for IO, networking and local data logging, remote connection over WiFi from my development workstation and the ability to connect to the ESP32's UART port using the USB interface, so I can get a local console / local programming if I need it. It is also the least power hungry Pi in the range at the moment and its in a small form factor.
Larger Pi's may be needed for other roles that are not in the coop, in which case power is not a problem as they can be mains powered.
Data busses
All boards with a microcontroller or microprocessor will use local data busses to simplify other IC placement and allow fast data transfers where required.
The Serial Peripheral Interface (SPI) bus protocol shall be preferred communication method, since its fast and only needs a couple of pins (a clock, a data in and a data out pin, typically termed SCLK, MOSI, MISO). A decoder will be used where more than 2 SPI devices are on a board, since each device requires a unique Chip Select (CS) pin and using an external decoder saves valuable IO pins on the microcontroller. A 74HC138 provides 3 to 8 line decoding and a 74HC154 provides 4 to 16 line decoding. An additional enable pin will be required to select the decoded device, this will be mapped to the microcontrollers default SPI Chip Select (CS) pin.
This bus will not extend beyond the single enclosure since its an on-board bus, not an interconnecting bus. This means it can be used for expansion boards and TFT displays, SD card interfaces, etc within a single chassis as the bus length still remains short. This is necessary as SPI is a medium speed bus running at around 40MHz to 80MHz within this design.
Boards shall also utilise an internal I2C bus that allows lower speed devices to be utilised. I2C requires only two wires, a clock pin and a data pin (SCL and SDA). This bus will not extend beyond a single enclosure, except on the main board, where extension shall occur via a bus multiplexer (NXP PCA9547) this limits the overall bus length, reducing any potential fault domain and reduces bus capacitance, to help ensure that good data rates are achieved due to high bus integrity. Differential line drivers (NXP PCA9615) will be used between enclosures, to further reduce noise and bus capacitance.
This approach allows the main board to ignore any remote board that have a bus problem, which could be caused by issues such as a faulty module, a rat chewing through the cable, a cable becoming pinched, or water ingress to the cable due to damage on its length.
Where an intelligent module is at the remote end of an I2C link from the main unit, this link shall terminate only on the local microcontroller or microprocessor, hence isolating any local resources and ensuring that they are only controllable by the local boards processors. This also allows for different bus speeds to be achieved, optimising throughput and maximising flexibility.
Where other bus protocols are required, they will in general terms be limited to the same principles as above. Specifically being limited to a single enclosure and designed to reduce noise and limit the impact in fault conditions across the system.
Offloading intelligence
The reason for the design goal of placing devices close to the area they are needed in is that it simplifies PCB layout and reduces electrical noise. IO functions will be offloaded to dedicated IC's, that are connected using one of the bus protocols defined above. This also helps preserve IO pins on the microcontrollers or processors to handle any expansion or cater for any special cases that may be required. The following standard devices shall be used in the design.
- Digital IO Expansion for General Purpose Input Output (GPIO)
SPI, use MCP23S17 IO Expanders
I2C, use MCP23017 IO Expanders - Analogue to Digital Converters (ADC)
SPI - TI ADC128S022 or I2C - TI / BB ADS7828
However, use the most appropriate ADC, depending on the function.
These are harder to standardise since they vary a lot on channel count, speed, accuracy, cost, etc. - Pulse Width Modulation (PWM)
Using NXP PCA9685 - Universal Asynchronous Receiver Transmitters (UARTs) for serial communication.
Using NXP SC16IS752IPW - SPI based storage such as EEPROM's or SD Card interfaces
Using appropriate devices. SD Cards just expose an SPI interface.
These devices are then connected via software classes, in line with the software architecture, to provide the facilities that board facilities require, such as motor controllers, voltage and current sensing circuits, temperature sensors, LED strips, etc.
Surface Mount technology
As the board redesign is happening in 2022, all boards shall use surface mount components, since they are the industry standard. However, to ensure that assembly is possible at home and fault finding is possible without specialist tooling. The 0603 form factor for passives shall be used, except where a component explicitly needed a different form factor (diodes and capacitors for example), the 0603's are large enough to be placed by hand during assembly, but small enough to use board space efficiently.
Note that this is the imperial 0603 designation - 0.125inch x 0.060 inch, which is the same as the 1608 metric, 1.6mm long, 0.8mm wide size. It must not be confused with the metric 0603 size, which is 0.6mm x 0.3mm, which are too small to manage at home.
The Integrated Circuit footprint shall be small outline form factors, using two or four sets of parallel pins around their perimeter or leadless pads around their perimeter and possibly a ground thermal pad in their centre, rather than anything in a ball grid array form factor, which is near on impossible to solder or debug in a home setting, without specialist tooling.
Connectors
All connections from a PCB shall be via polarised pluggable connectors, ensuring that boards can be replaced easily and to simplify wiring. This also simplifies the addition of other modules in a non disruptive manner. The current rating of each connector shall exceed the maximum expected current flows.
Care will be taken to ensure that the connector types and pin counts are unique within an enclosure where there is a risk of the wrong device being plugged in. For example, motors and power sources
2.54mm pitch (0.1 inch) pitch shall be used as the default size, since its commonly available and is easy to manufacture to. Smaller pitches can be used where it is sensible to do so, i.e. board interconnects etc. Through hole mounting of connectors shall be used for mechanical strength.
Cabling
Exterior grade low voltage DC power cabling shall be rubber coated to protect it from the elements and placed at least 30cm above the ground, ideally in a protected route, to reduce the risk of it being chewed by rats.
Standard multicore cable will be used between modules where possible, to reduce the cabling costs. Complex cables such as those having multiple different cable types (twisted pair, ordinary cable, coax, different shielded groups, etc) shall only be used by exception. Multiple, separate cable runs between modules will generally offer the same flexibility at a lower cost.