The v2 design

Now we know what we are trying to do, we can think about the design. This went round and round for several weeks, considering options and what-if's and what else might I want to do on the boards. Its also worth remembering that a printed circuit board (PCB) design costs the same if its got extra footprints on it for things you might want, compared to a board that doesn't. It only costs more when you come to populate those components during assembly, or when you come to respin a board to add on things you forgot the first time around. 

Hardware design

I set about working on the design and settled on a design that has a similar modular approach to 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 you 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 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 also 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 Rasperry Pi that existed in the first version, since I had been using Espressif ESP32 microcontrollers and they have an Over The Air (OTA) firmware upgrade capability, so as long as I can get a console into them, 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.

I settled on a design that has 3 printed circuit boards

• A main one in the coop, using the exising box form factor, since I've already got a box and the mounting holes in the coop and it should be plenty big enough.
• A front panel board, that sits outside the coop at the front,
• A power sensing board that monitors all the higher voltage and higher currents, keeping these well away from the main (expensive) board.

The main board

• An ESP32 S2-Saola-1, replacing the old Atmega 2560, this gave me lots of options, a powerful ESP32 S2-Saola-1 with a single core, 240MHz CPU, 320Kb of RAM, 128KB of ROM, 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 and two UART's, one of which 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.
• A Raspberry Pi Zero W2 (replacing a 1st generation Raspberry Pi model A), 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, so I can get a local console / local programming if I need it.
• A PIC microcontroller 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 if I need to. This controls both of the above processors and is controllable from either of them.
• A GPS receiver module, with a remote aerial option, to provide me with 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. 
• Utilised dedicated SPI or I2C devices to provide I2C bus mutiplexing, Pulse Width Modulation (PWM), Digital IO Expansion, Analogue channel expansion, a dual UART these are in turn connected to several motor controllers, various voltage and current Sensing circuits. The principle is to put the devices local to where they need to provide their functions, and a single SPI bus and a single I2C bus goes around the board, hence freeing up board space. This in turn means that there can be several of one device type 4 digital IO expanders for example. This in turn means that there needs to be some SPI bus decoding and I2C bus decoding. 16 channels of SPI and 8 channels of I2C give sufficient space and the IO pins for the decodes are on the ESP32 for speed and simplicity. 
• Several SPI EEPROM's, for any storage needs
• Connectivity between the modules uses a unified connector, of which there are 6, 4 external, 2 internal. The connectors provide Power at a higher voltage, allowing for local regulation and power control in each module. A long distance differential I2C bus that carries all the commands to and from the modules. It has to be differential, since the runs may be several metres long. There is an interrupt function, a reset function, several digital IO pins, several analogue pins and a control pin to the ESP32. 
  This allows for modules to be either intelligent (with a local processor) or dumb, just some IO pins or an I2C device of some form. In turn, this requires that there is a higher level protocol betwen the modules and the main unit, but thats a challenge for future me.
• Board space allows for two expansion slots that are based on a 40 pin connector and 4 screw in stand-off's, these have the same interface as the external expansion slots and their placement allows for two smaller expansion capabilities or one larger expansion capability, or even a small one sitting above a larger board below 
• Two motor drivers for 12V DC motors, each has current sensing and over current trip capabilities.
• Voltage and current sensing is provided for each of the voltage rails on the board, ~12V in from the charge controller, 5V, 3.3V,
• Temperature sensing is provided at multiple points on the board, mostly around motor controllers and regulators, so that any abnormal operation can be detected and things shut down if requried. 
• 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, requriing manual intervention.
• Minimal main board switches and LED's are provided for power, reset and manual Pi power control, these are on the main chassis. 
• A capability was provided to connect 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. 
• The boards were designed to use surface mount components, given that they are the norm these days. I settled on the 0603 form factor for passives, unless something larger was needed (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.  The Integrated Circuit footprints were mostly of the small outline form factors, using two sets of parallel pins, rather than anything in a ball grid array, which is near on impossible to solder or debug in a home setting.

Front Panel Board

The main goal for this board is to provide a far improved user interface, replacing flashing lights of different colours with a large display that has human readable information on it. 

• A large 4 inch TFT display makes up much of the front panel, which is protected in a waterproof box, with a clear front.
• There is a Touch controller on the TFT display, but this is not used due to its placement in a waterproof box.
• A waterproof rotary encoder provides the user interface
• Two tricolour LED's replicate the functions in the older design (simplifying cut-over)
• Two buttons and LED's are provided, but instead of being on the front panel, where they make assembly and waterproofing harder,  the switches will be at the bottom, better protecting them from the elements and simplifying assembly. These provide the common operations, such as opening and closing the door. The LED's remain in their old position, ensuring that they can be easily seen from the coop or the house.

The presence of a large TFT display, means that it requires an SPI bus to control it, due to the amount of information that must be sent to the TFT, these typically run at 40MHz. However, the only interface to the module is an 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, an  ESP32 S2-Saola-1 is fitted to the board, it will accept I2C commands from the main unit, decoding those to the relevant LED, temperature sensor, encoder or TFT display, returning any requested information in the response. The local ESP can then do any high bandwidth operations on the TFT display. This approach also allows for a second local I2C bus on the board, which can't be accessed from the main unit, hence helping to enforce role separation between the boards and reduce I2C bus lengths.

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, only having a couple of I2C Analogue to Digital Converters (ADC's), but it can handle currents up to 8A (fused) on each of its two power channels. It can also handle the 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, since no level shifting is required in the design, which in turn reduces component count and therefore cost. To further complicate things, my current two solar charge controllers 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 !!

To further complicate matters, the voltage on the chicken house controller is in the range of 0V-12V, the lead acid battery is around 10V-15V and the solar panel can be anywhere from 0V to 24V, meaning that the voltages I need to sense are both positive and negative in respect to the chicken house controller. The sensing therefore has to be capable of sensing both extremes of these voltages. 

Software design

Although my background includes many previous low level project in assembly language and C, the software development on the version 1 Chicken Coop was undertaken in the Arduino IDE using a mix of C and C++, since the main board was a ATMega 2560 and I wanted to be able to leverage several modules that came with Arduino libraries so that I could add some capabilities fairly quickly yo the coop. Further, with both my children nearly in secondary school I didn't want to have a complex environment for them to have to learn early on. However, as time passed any my son started to go down the Electronics route and head off to University, the need to use that framework decreased and became a comedy point at home when he started to dabble in more professional tools.

The Arduino IDE, being targetted at beginners was also well out of its depth for what the V1 project had become and I was struggling with:

• The lack of things like fast download options, since UART downloads have to be used.
• The build process is slow, building far too much that hasn't changed each time.
• No JTAG support, so debugging could be very laborious
• The basic Arduino IDE was not great when you have multiple modules and the tools are fairly basic
• There was no source control integration, which required manual processes to be used to protect the code.
• There was no easy way to flip between development and production settings
• My manual hacks to Arduino scripts to allow programming to the production coop in the garden got broken each time the IDE got updated.   

The revamp of the system therefore provides the opportunity to refresh the software stack, however, the amount of work to do between now, at the design stage and the desire to install in the spring / summer of 2023, only 5 months away, was a difficult challenge to overcome and learning a new development framework on new and fairly complex boards would just complicate the work significantly and this is after all, a fun project, not a day job. I also wanted to re-use the now fairly bug free code that has evolved over the last couple of years as the springboard on this project. 

I started getting involved in 3D printing and using Visual Studio Code (VSCode) and the raft of plug-ins and custom setups to extend it for Marlin (3D printer software), which wanted to use Platform IO, then I found that it could also support Arduino, but VSCode can also ESP-IDF and ESP-IDF is partially exposed in PlatformIO, so things got very complicated and the choice of where to go was not at all clear, since I couldn't see where one thing stopped and the next one starts. I was also doing some work with a friend on another ESP32 based project, so I started reading up on the above tools and learning how they worked and interacted. We migrated the smaller project to it and the penny dropped into place. 

The version 2 Chicken Coop, will therefore use up-to-date development tools.

• Visual Studio Code as the IDE, since its far better for larger projects and has much more advanced feaures, code highlighting, prototype highlighting, Doxygen popups, proper folder structures, faster build times, it can go to code function declarations and implementations, GIT integration, git diffs, etc, 
• A local GIT server for source control (No, this is not an open source project)
• PlatformIO with the Arduino framework, (as a phase 1), since this allows me to use bring the current code base across and start updating it, reducing risk for the spring / summer implementation and simplifying the testing of the new boards. Once that is done, I can start transitioning to ESP-IDF functionality, before dropping the Arduino framework and going native Espressif IDF. This in turn will free up a bunch of space on the ESP32.
• The principle of separating configuration from code will be used, secrets will be stored in the ESP32's Preferences storage and not in source code.  This also allows calibration data to be stored on the ESP32.
• Utilise the features of the ESP32 family, such as FreeRTOS so that you can better use the resources and isolate different tasks.
• Remove any Atmel specific code or code optimisations such as PROGMEM / F() functions that aren't required on ESP32

Now the hard work starts

Once everything was designed and I knew where I was going, parts lists were in baskets, ready to order, circuit diagrams could be firmed up, missing components symbols and footprints were generated or sourced from SnapEDA and circuit diagrams could be made into layouts and then the laborious process of manual routing each of the traces could begin.

This took a long time. Many edits were made, some beer helped the design process progress. Some devices were replaced with smaller footprint ones to gain space and the main board became very tight and complex, ending up as a 230mm x 180mm 6 layer board, providing 2 signal layers and 4 power layers (GND, 12V, 5V and 3V3). 

The same process was undertaken on the front panel and power sensing boards and both of them came out as 140mm x 100mm, 2 layer boards, with flood fills for the power and grounds.

Then all the reiviewing and double checking took place, since you do not want to rush this, only to spot the problem when the boards turn up, or you start trying to bring them up.

• Electrical Rules Checking (ERC) done
• Design Rules Checking (DRC) done 
• No Airwires (unrouted traces)
• Check the footprints match the size of the devices (hard without the devices)
• Double check. Triple check 
• Take a break 
• Re-validate nothing is missed
• Generate the manufacturing files and zip them up 
• Check there are no last minute design changes and that I've not missed something - by double checking my notes

Finally I take the decision to upload the design files to PCBWay, ordering stencils for each board to simplify manufacturing, pay the invoice and wait ...