With a hardware and software design principles and approaches all in place and the list of standard processors and IC's defined, I can now look more closely at what goes into each of the core boards
The main board
The main board is the heart of the system and will, in line with the v2 board standards, use an ESP 32 Saola-1 along with an optional Raspberry Pi Zero 2W, initially for console only access and simplicity during migration. A local SPI bus and I2C bus will be implemented in line with the principles, along with the relevant additional signals such as bus decoders, reset lines, etc.
A PIC 16F628A microcontroller is used to provide power switching, so that the power to other devices can be turned on and off, allowing me to save power and force a hard reset on connected devices if I need to. This controls both of the above processors and is controllable from either of them. Assuming one device is working then I can reset the other from a remote location. This is simply reproduced from the existing design.
A GPS receiver module (Blox NEO-M8N), with a remote aerial option will provide accurate time and the GPS location, since I'll need these to determine the correct times to open and close the pophole door through the year. The remote aerial option is there in case the GPS signal can't get to the module as they do not generally work inside buildings. This replaces the older I2C DS-1307 real-time-clock (RTC) chip that was shared between the Raspberry Pi and Arduino and used as an alarm clock wakeup for the Pi.
Now that there is time over GPS and via Network Time Protocol (NTP) over WiFi, I have a choice of two reference clocks and the code can select the best source at any time. This means that the system can run without an Internet connection, so in a full power failure scenario, it also means that I can obtain location and therefore sunrise and sunset calculations no longer need a hard coded longitude and latitude, resulting in a cleaner configuration. I can also provide the old alarm clock function to the Raspberry Pi by using the ESP32, since it has power control over the Pi via the PIC and is always on. The only risk is if the ESP32 dies then I can't get to the Pi to fix it, without a pair of wellies.
Considering the number of offload IC's that will be needed on the board along with their placement, its clear that I'll need a 16 channel SPI decode capability, using 5 channels on the ESP32, 4 for decode and one to select the decoded device.
A local I2C bus is implemented as several I2C devices are present, including an I2C multiplexer (NXP PCA9547) that is needed to split off separate I2C busses for each of the 4 remote modules, the isolated busses are driven off the board using a differential line driver (NXP PCA9615), keeping the external interfaces aligned with the v2 board standard and minimising the size of potential fault domains.
The 4 remote modules will be :
- The front panel user interface
- The power sensing module
- Two AI modules, for detecting chickens, rats, eggs and stones (not eggs),
one will be located in the main coop, the other in the conservatory.
This is a future expansion.
External expansion
Connectivity between remote modules will use a standardised 12 pin connector, of which there will be 4 external. The connectors provide:
- Power at a higher voltage, allowing the voltage drop on the connecting cable to be avoided and to allow local regulation and power control in each module.
- A 5V rail and its related ground reference.
- Each rail will be provided on at least two pins to increase current carrying capability.
- A multiplexed (isolatable) I2C bus, with differential drive capabilities
- Two pins on an IO Expander
- One reserved as an interrupt function, allowing the module to request attention from the main board
- One spare, unassigned control pin.
- A reset function, allowing the main board to reset the reset of the system.
- A single IO pin pin to the ESP32, which can be mapped to any internal function as required.
Internal expansion
The two internal expansion connectors have a larger pin count using a 40 pin (2x20) header, this allows for additional signals to be provided. The pinout is :
- Power at various levels, allowing flexibility for what is connected / driven on the board.
- Rails of 12V, 5V and 3V3 and their related ground reference.
- The board has the option to regulate locally if required.
- Each rail will be provided on at least two pins to increase current carrying capability.
- The system SPI bus, with a dedicated chip select (CS) for the module
- The system I2C bus
- An interrupt function, allowing the module to request attention from the main board
- A reset function, allowing the main board to reset the reset of the system.
- Two IO Expander digital IO pins - removing the need for a module to have IO capabilities if it only needs minimal control, or allowing for additional control of the remote module
- Two analogue pins - removing the need for a module to have an ADC if it only needs a small number of channels
- Two IO pin pin to the ESP32, which can be mapped to any internal function as required.
- A UART port with full hardware handshake, allowing serial communication with 6 control pins, or IO functions, or a mix thereof, as required.
The connectivity defined above allows for modules to either be intelligent (with a local processor) or dumb, with simple IO or have one or more I2C devices present. Where intelligent remote modules are required, there will need to be a higher level protocol between the modules and the main unit that utilises the control pins defined above. This will need to be implemented when the front panel is enabled. For dumb modules, the I2C devices will just appear on the normal bus when that module is selected. This may require that the bus runs slower, depending on the performance of the line / type of cabling used.
The standard connector layout allows for a remote module to be easily moved in software to a different slot, should one of the 4 channels fail, since each are identical in function, although the pin function IO function mapping would need to be altered in software to match the new slot and new firmware used. This may be easier than swapping the whole board out, if for example it fails during the winter months.
The PCB layout provides enough board space for two expansion slots that are based on a 40 pin connector and 4x M3 screw in stand-off's to mechanically fix a board down.
Their placement of the boards allows for flexibility in expansion, this includes:
- Two smaller expansion boards, one in each slot
- Or one larger board that uses all the expansion space across both slots and all connected pins.
- One lower card taking half a slot, with a larger board in an umbrella form over the top of it, allowing more space to be used, but keeping all IO local to each board.
- Two larger boards, with one being feed-through on its connector only. No local connections are made on the 2nd connector.
- A combination using vertical stacking of several boards on top of each other, using stacking headers, since power, I2C and SPI etc are parallel busses, the digital IO's can then provide the necessary unique board select signals.
The intent is that any expansion capabilities can be resolved without needing to change the main board, thus keeping the cost low. I really only want to build this board once, since its going to be the most expensive in the project. The risk remains though that, due to its complexity, there is a risk that the main board may require at least one respin if something is significantly wrong with the initial design and that can't be resolved with "bodge wires", these are the work-around manually installed modification wires, used to fix incorrect traces on development boards.
Board features
Now that the basic features on the board are detailed, the specific capabilities can be mapped out, they are :
- Two motor drivers for 12V DC motors, each is bi-directional, has speed control via PWM, current sensing and over current trip capabilities. The software will provide additional features such as soft start and soft stop by ramping the PWM signal, hence reducing electrical noise and currents when starting and stopping the motor. It also makes it look much more controlled when its operating.
- Voltage and current sensing on each power rail on the board, including:
- The nominal 12V rail from the charge controller
- The 5V rail, which is derived from the 12V rail
- The 3.3V rail, which is derived from the 5V rail.
- Temperature sensing at key points on the board, mostly around motor controllers and regulators, so that any abnormal temperatures can lead to the system disabling power hungry devices to ensure a safe shutdown in a fault condition.
- Three LED strip connectors are provided, allowing 12V or 5V LED strips to be connected, these are for internal lighting strips and possibly one around the door, since chickens don't seem to know when to go to bed and the lower ranking ones may end up locked out on occasion, requiring manual intervention.
- Minimal main board switches and LED's are provided for power, reset and manual Pi power control, these will be on the main chassis.
- An internal diagnostic TFT display and rotary encoder, which can be attached during development or fault finding, or attached to the inside of the chassis if required.
Front Panel Board
The main goal for this board is to provide a significantly improved user interface, replacing flashing lights of different colours with a large display that has human readable information on it. Unfortunately, this means the end of the throbbing HAL9000 style status LED in the centre of the panel, but that could be emulated on the TFT if I wanted to.
The new board will provide
- A large 4 inch TFT display makes up much of the front panel, which is protected inside a waterproof box, with a clear front. There is a Touch controller on the TFT display as they generally come with one, but this is not used due to its placement within the box.
- A waterproof rotary encoder provides an input for the user interface, allowing easy interaction with information on the TFT display, whilst only requiring one hole in the chassis.
- Two tricolour LED's replicate the functions in the older design (simplifying cut-over) and still providing an easily visible remote indicator, since the TFT display can't be read from a distance.
- Two buttons and single colour LED's, replicating the left and right buttons from the previous generation.
The buttons and LED's are intended for frequent simple operations such as swapping the state of the the pophole door. Instead of being located in the clear front panel of the box, where they make assembly and waterproofing harder, the switches will be located on the bottom of the unit, where they are better protected from the elements and this simplifies assembly. The LED's will be on the connectors, allowing for flexibility in their placement, with the aim to be that they are easily seen from the coop or the house.
The presence of a large TFT display, means that there must be a local SPI bus to control it, due to the amount of information that must be sent to the TFT, these typically run at 40MHz or higher. However, the only interface to the module is the I2C bus that will run at about 400KHz, or 100 times slower. This is a shared bus that all devices use, so its actual bandwidth will be lower.
To solve this problem, and in line with the design principles, an ESP32 S2-Saola-1 is fitted to the front panel board, it will accept I2C commands from the main unit, decoding those and using a local I2C or SPI interface to communicate via the relevant offload IC to the relevant LED, temperature sensor, encoder or TFT display, returning any requested information in the response.
Power Sensing board
This is a simple board that provides voltage and current sensing for the solar panel and lead acid battery that runs the unit. A standard Solar Charge Controller is used to convert power from the panel to charge on the battery. The same 80W solar panel is re-used from the previous design as is the charge controller.
The board is a passive design, having no local processing capabilities. It will utilise two of I2C Analogue to Digital Converters (ADC's) to measure voltages and currents within the module. One ADC dedicated to each channel to simplify component placement and routing.
The module needs to handle currents up to 8A (fused) on each of its two power channels, although expected loads will be much lower than this in most situations. Battery charging from a low battery is the worst case.
The power sensing needs to handle common negative rail or common positive rail designs that are used in the Solar Charge controllers. The latter having been very problematic in the initial v1 design and preventing that part of the design working properly.
Common negative is very common in electronic circuits, this is where all components share a common ground pin and all voltages are positive (or negative) with respect that common zero voltage rail. The common positive rail uses the opposite approach. All of the positive voltages are tied together and the charge controller handles all the power by switching low side MOSFETS. This is far simpler to design against, than high side switching, which requires level shifting, which in turn requires additional components and increases costs and board space requirements.
To further complicate things, the two solar charge controllers available to the project, each use a different approach and I found this out the hard way when a previous controller failed and I got a replacement from a different manufacturer and things that had never got hot before, started getting very hot. This is not what you want in a dry wooden box that is full of straw and Chickens !!
An impact of the low side switching is that voltage sensing becomes more complex. The voltages within the chicken house controller are in the range of 0V-12V on the various 12V, 5V and 3.3V logic levels. These are all derived from its single incoming 12V supply, that is fed from the charge controller. The lead acid battery will have a voltage of between 10V-15V, depending on its state of charge. The solar panel can be anywhere from 0V to 22V, 0V at night and 22V during the day.
Now, assuming that all the positive rails are connected, everything is negative with respect to 22V (The solar panel has the largest voltage), so the battery ground pin will be 22V - 12.8V (typical battery voltage) = 9.2V. The supply to the main board will be 22V - 12V = 10V and the solar panel will be therefore at -10V with respect to the main module.
However, for the other charge controller type, all voltages will be absolute relative to everyone's 0V reference.
The voltage sensors must therefore be able to sense both positive and negative with respect to the chicken house controller's ground pin. The sensing has to be capable of measuring both extremes of these voltages and must assume that the systems 0V may not be the same as any other components 0V. Care is also required to ensure that unexpected current paths are not caused between these rails during measurement.