This form is intended to assist in optioneering to derive low level hardware & software specification from the Validated
High Level Requirements Capture Form [1]requirements_capture.md.
Its scope can be adapted to suit projects of varying complexity
Space to work through different options before deciding on specific low level requirements & system specification for hardware & software It is useful to highlight situations where one design decision is dependent on other decisions, or where a design decision will have known, or forseeable impacts on other decisions later.
Introduction to the design approach if required
Flowcharts can be used to explore the relationships between different options, and display graphically how making specific design decisions will affect the other available options.
Flowchart showing the different communications standards and methods that could be used to connect the user interface and the microcontroller, dependent on
low level hardware choices
This is an example of the options that may wish to be explored for this project, however there may be alternative ways of displaying this information that are more suitable
| Requirement | Function | Options | Sub-Options | Hirarchy | Notes |
|---|---|---|---|---|---|
| HL:(4,5,6) | Controller for Current Sensing | Integrated MCU on PCB | CH340 Driver for USB comms to Raspi | 3 | |
| " | " | " | ublox Wifi module & remote database server | 2 | |
| " | " | " | ESP32 performs as MCU controller And/Or Wifi Module | 1 | requires 3.3v logic if used as MCU |
| " | " | Arduino Nano 33 IoT | Local Raspberry Pi | 4 | will require 8 port switch to accomidate extra RasPi in ISO Container |
| " | " | " | Remote Raspberry Pi | 3 | Will Require external WiFi Antenna to ensure robust Connection |
| HL:(4) | Power Switching | N-Channel Low Side MOSFET | 3 | ||
| " | " | P-Channel High Side MOSFET | 1 | Difficult to source suitable MOSFET | |
| " | " | Relay | Normally Closed | 2 | Expense |
| " | " | " | Latching | 4 | Expense, Reliability |
| HL:(1,2,3) | Power Supply DC/DC Conversion | COTS Modules | 1 | ||
| " | " | ReEngineer & Integrate w/ PCB | 4 | ||
| " | |||||
| HL:(7) | Power Input Connector | Screw Terminals | 4 | ||
| " | " | XT60 - 60A Connector | 1 | Quick Disconnect Compared to screw terminals, easy to solder, easier PCB mounting | |
| HL:(7) | 12v Power Output Connectors | 2.1mm Barrel Jacks | 4 | Hard to find with range of options, easy to damage | |
| " | " | XT30 - 30A Connector | 1 | Easy to source, many differnt options, well defined specifications | |
| HL:(5) | Voltage Sensing | Voltage Divider on 12 bus | 1 | Can't be used for 5v bus as MCU would share Vcc ref. Must protect MCU from voltage spikes | |
| " | " | Voltage sense IC | 2 | Cant find suitable option, open for reccomendations, could be used for both 12v and 5v bus |
Exploration of circuit elements & Hardware that might be used to meet design objectives
The aim of overvoltage protection for the 5v bus, is to protect the raspberry pis in the event +12v power is accidently applied to this bus, pulling all the outputs to 12v and causing damage. Several possible approaches will be discussed below
5.1v zener diode reverse biased between the USB outputs 5v rail, and GND. A 100ohm resistor must be between the potential source of over voltage and the zener diode.1
Problems with this approach
If the source of the overvoltage is also on the USB bus, this does not nessissarily solve the problem, as the current will flow unimpeded through the zener diode, causing overheating and component failure. If it fails open circuit (likely) then the protection is no longer active and the 5v bus will be pulled to 12v.
As the likely source of the overvoltage would be the other USB inputs, each V+ rail would need a 100ohm resistor, with a zener diode on the supply side of the resistor.
As the USB channel is already designed to be switched off via a logic high signal (+5v) from a microcontroller, could that same MOSTFET also be triggered with logic high if a fault condition is detected? This solution would have to be passive, i.e not be reliant on the MCU to trigger, as this would delay response and would not stop damage from occuring.
A logical OR gate could be used to provide a buffer between the logic HIGH/LOW pin on the microcontroller, and the other system for providing a logical HIGH in the case the 5v bus moves out of tolerance. 1 logical OR gate would be required for each USB output, The output of each logic gate, feeds the gate of each MOSFET
OverVoltage Detection
Voltage Supivisor/detection ICs:
TL431 Voltage Reference, Adjustable Shunt
Voltage is monitored on 5v rail, and IC outputs a logic high if voltage goes outside of set nominal band.Use Case TI TL431 for Under & Overvoltage Detection2 In this case, the V(high) and V(low) thresholds are set via 4 resistors. Calculations outlined below3
TL431 has a minimum cathode current of 1mA, so resistor selection must be checked to meet this requirement.
Resistor Values Estimated: R1: 470r
R2: 560r
Vhigh ~ 5.47v
R3: 560r
R4: 470r
Vlow ~ 4.8vR5 = 220r
Using these values &
I = (Vcc - Vref)/R3 (High edge) & I = (Vcc - Vref)/R5 (Low edge) [No sure if correct best guess given forum posts & datasheet]
ere Ika ~ 4mA for high edge & 11mA for low edge
Implementing This Solution
Requires:
5 * OR Gates
To make these gates from common gates, it would require:
15 * NAND Gates. (3 req for OR gate)
OR
10 * NOR Gates. (2 req for OR gate)
Suggest:
3 * MC74HC02ADG SMD Quad Input NOR Gate
The aim of this requirement is to provide additional information to engineers testing, maintaining and debugging the system. For this reason it should be independent of all other systems, and simplified as much as possible.
I much prefer the idea of independent indication for each bus, rather than a traffic light with "All Nominal" "Something Off Nominal" "Everything Off Nominal" indication, as I believe this is;
1: less useful than say "A Okay" "B Okay" "C Okay" indications and
2: it may also be harder to design if we take a passive approach, i.e: This system should work independently of any microcontrollers.
A window comparator circuit4 could be used to display whether each bus is falling within a predefined "nominal" window, however this circuit would be reliant on stable Vcc, so is not useful for detecting if Vcc is off nominal. An independent linear or LDO regulator could provide independent reference voltages to solve this problem, but increase in cost & complexity.
Led VU Meter, Options detailed 5 LM3916 Dot/Bar Display Driver Monitors analog voltage level and lights up to 10 LEDs sequentially Supply Voltage from 3v to 25v - Suggest it runs from 12v rail for each use case. Input can handle from 0 to 35v
Assessment This option did not work well, as the window for the "okay" LED was far too wide, I managed to get it to indicate high voltage at 5.5v, however getting it to register low voltage at anything >4v seemed to fail. It also did not perform well with off nominal supply voltage.
Use the features of the DC/DC supplies6
DC/DC supply can indicate an off nominal voltage rail by pulling a logic HIGH to ground. This can be monitored by the MCU and set error LEDs. This will also enable easy reporting & monitoring of power status.
The best options for MCU seem to be either;
AtMega328p combined with CH340 for USB comms & programming, ISP header for programming bootloaders, and an WiFi transcever as a peripheral device, or
ESP32-WROOM-32U, with the same USB interface and ISP header, but without the need for an additional WiFi transcever. This has a number of advantages and disadvantages.
The major disadvantage is the ESP's requirement for 3.3v logic, this will likely require additional drivers for actuation of the MOSFET switches, as well as voltage dividers and additional scaling on ADC inputs from the ACS712 Hall Effect Linear Current Sensor For this reason, using the AtMega328p as the main MCU seems like it will cause less issues with the rest of the circuit design.
However the selection of the peripheral WiFi adaptor throws up an ironic aside, it seems much cheaper to use ESP32 as a WiFi device than sourcing dedicated WiFi transceiver modules like the ublox nina. The ESP32 is available with the option to connect an external antenna, which makes the system more adaptable for use in areas that may not have adiquate WiFi signal with the antenna obscured inside a metal box.
Conclusion
The board will use both AtMega328p to act as the hardware controller, and ESP32 to act as wifi & higher level control. This will also act as a proving ground for using mixed controller boards, interfacing ESP32 with other MCUs, and potentually offering up the ability to expand the scope of the power supply module later with more advanced software run on the ESP32, with the AtMega handling the lower level hardware monitoring.
Info on using ESP32 as WiFi adaptor for AtMega328p7
Exploration of software, firmware and development tools that might be used to meet design objectives and test system performance
- Arduino running state machine framework
- websocket server responds to HTTP GET requests for control of power channels
- concurrently taking analogRead() of 2 ADC inputs, and sending to external database with HTTP POST requests over wifi
- Data is pulled from database using graphing tool, like Grafana, which is built around a web accessable user interface.
- Arduino running state machine framework
- websocket server responds to HTTP GET requests
- concurrently taking analogRead() of 2 ADC inputs, and sending to Raspberry Pi over USB communication.
- Raspberry pi requires script to place data received over COM port into web accessable format.
Info On Requirements Matrix & Link to: Requirements Matrix Document
- Rugged Circuits: 10 Ways to Destroy an Arduino
- High Side vs Low Side Switch
- Important Stuff: MOSFET Specs You Need to Know
- Using the Atmel ATmega328P Analog to Digital Conversion Module
VGS & Rds Explanation
Assuming That
| Attribute | Value | Max Current Flow |
|---|---|---|
| Source Voltage | 5v | |
| Rds(on) @ Vgs -4.5v | 0.0133 ohm | 5/0.0133 = 376A |
| Rds(on) @ Vgs -10v | 0.0083 ohm | 5/0.0093 = 537A |
<!-- -  -->
Footnotes
-
Voltage Window Calculations:
- Vh=(1+(R2/R)1)*Vref
- Vl=(1+(R4/R3))*Vref ↩ -
Gate-Source Threshold Voltage
- Datasheet shows that Vgs must be >-2.0V to turn off device
- i.e. Id = -250 uA @ Vds (Maximum Drain - Source voltage differential)
- Therefore if VCC is 12v, Gate Voltage must be driven to >10v to turn off MOSFET
↩
