Introduction
Aiming to develop an advanced Linux server for a private network, with reduced size and a relatively small payload, the choice has been focused on the Gizmo2 board hosting a Debian Linux distribution:
- A reliable board at a reasonable cost with good performances
- Availability of 1Gb network connection
- Availability of 2 USB3 ports
- Internal SSD connector
- Good power consumption optimization
- Open source hardware
- Availability of accessible GPIO ports and possibility to control the hardware behavior
Main features
The Gizmo2 server hardware features should include:
- Linux boot and root filesystem on 120 Gb SSD
- N.2 x 2.5" 500 Gb HD configured in RAID1 (full mirroring) connected to the two USB3 ports
- Headless configuration with SSH remote access
The services distributed over the network will include:
- Apache2 web server
- Php 5
- MySQL server + PhpMyAdmin
- NFS services
The role of the controller board
An independent controller board to control and continuously monitor the system health status of a device.
Must-have features
- Power status
- Server running status
- External power to the two HDD
- Power On/Off the server mainboard
- Server mainboard reset
- Temperature control
- Extra fan powering
- Alarming
Future features
- Power supply redundancy (two power supplies switched alternatively on failure)
- Power status and power drain
- Power battery backup status
- Programmable system boot and shutdown
- Network physical connectivity checkup
- Other sensors for health status control
From idea to design
As mentioned above the controller board should act as an independent unit. The solution is a microcontroller managing the system including - as shown in the scheme - the user power on/off and reset commands.
This Microcontroller Health Status Controller Board works fine with the Raspberry PI and Arduino, ChipKit and Gizmo2 and almost any circuit board that may need a supervision controller.
MCU choice
There is a wide range of option choosing an MCU for the controller board but in my opinion for this case there are two possible options: a slow and cheap microcontroller available in DIL package (due to the limitations of my prototyping capabilities) or a PSOC device. The idea of using a SOC (i.e. the PSOC5 prototyping kit) is really attracting but unfortunately it is not possible to adopt this solution - that probably remain the best and cheaper - due my limited time resources for the development.
As I have already developed several project with the Atmel AVR microcontrollers series and the AVR Studio development environment, the obliged choice for the first version of the controller has been the use of the AVR328p MCU.
The following image shows the schematic of the board.
While the next images shows the PCB layout and the prototype PCB.
A note on the circuit
As you can see in the schematics the board only includes the microcontroller IC and the circuitry control components + discrete components. As it is expected to it the board as an accessory inside a box including also the rest of the circuits (e.g. the electronics that should be controlled) all the components - LCD, FAN, Temperature Sensor, Vibration Sensor, User control buttons etc. are wired separately to fit in any kind of container depending on space and the most useful position.
Board and external components
The images above sows the finished board with the actually used connectors and the external components that can be connected to the board.
The external components used to populate the board.
Logging and external feedback
All where possible the UART connector can used to easily wire the board with the controlled device (e.g. Arduino based project, Raspberry PI, PIC based project etc.) using just the Tx and Rx cables and a serial connection. The same UART can be connected to any device, included a laptop or desktop with a Serial to USB adapter (e.g. the cheap ones based on the FTDI 232 IC) This optional features gives further options to the user for a more complete feedback, data collection or to instruct the controlled board to assume specific behaviour depending on the feedback of the controller.
NON-PWM Fan
In the images of this example a small 12 V cooler fan has been used provided with just the two power supply cables. Also using a bigger device in general the PWM-controlled FANs are a lot expensive than the three-wires only devices that does not include this option; the third wire when present is the tachometer for the fan speed control. A PWM Fan (4 wires, 12 V, 20-40 mm diameter) can cost up to 100$ while a simple FAN (2 or three wires) has an average cot of about 5-12$
The temperature control via PWM frequency is managed to a non-PWM fan with s simple circuit based on a sufficient powerful transistor (less than 0,5$) and a couple of discrete components. The details of this part from the schematic are shown in the image below:
Pushbutton simulation (aka Button Output)
Another detail it is the worth to analyse is the way the output buttons has been created in the circuit. In theory it is sufficient to put to low a GPIO Pin normally high to create (almost) the same effect of a physical pushbutton connected to the controlled device. I have verified experimentally that not always this method works properly; in some cases the simple Pin status change is not sufficient to recreate the same conditions of a mechanical pushbutton when pressed. The simulation of the Power and Reset pushbuttons (anyway, two configurable buttons) is strategical to control the behaviour of the external device in many conditions:
- When the user ask for a manual power-On / power-Off cycle
- When the user needs a physical reset
- When the board detect an alarm condition that require the system powered down via a power on/of pushbutton switch
- When the board detect a condition that requires the system powered on (awaken from a standby status, to be precise)
To solve this problem a simple and already tested solution is setting the GPIO Pin to control a transistor (PN2222 is more than sufficient) acting just like a relays of a physical switch. The image below shows in detail this part of the circuit
The board in action
The video above shows the firmware approach of the board monitoring at different frequencies the sensors input and checking the user interaction (via the two pushbuttons). In the example shown in the video the temperature sensor is preset to start the fan as a temperature of 30C is detected, increasing the fan rotation speed proportionally to the temperature level. 90C is considered the highest acceptable (in risk area) temperature then an alarm action can be activated, eventually acting directly on the controlled board.
The firmware
The firmware has been developed in C/C++ with AVR Studio 6 but the attached sources has been converted in Arduino sketch format for a better readability by the users. The included classes of the source package (attached to this post) can be used in an AVR Studio project as well.
Top Comments
-
shabaz
-
Cancel
-
Vote Up
0
Vote Down
-
-
Sign in to reply
-
More
-
Cancel
Comment-
shabaz
-
Cancel
-
Vote Up
0
Vote Down
-
-
Sign in to reply
-
More
-
Cancel
Children