-
A short demonstration video!
04/02/2025 at 19:35 • 0 commentsUp until now, you've had to simply take my word for it whenever I claim something is working, so I've decided to create a short video (using the v0.2 board) to demonstrate that the design does in fact, most definitely, 100% work and I'm not simply making things up :)
-
Fixes for Version 0.2
02/24/2025 at 23:06 • 0 commentsAs noted previously, a couple of issues with the Version 0.1 PCB meant a slight bodge had to be made to the board for it to function correctly, and using a 12V supply would reach the absolute maximum voltage at the output MOSFET gate.
Fortunately, it appeared the 'missing pulse detector' part of the circuit worked as expected, so it should just be a matter of updating the output stage.
Schematic changes from v0.1 to v0.2 First and foremost, the output MOSFET Q1 has had its drain and source pins switched, so that the body diode acts to block current flowing from VCC (rather than conducting). Additionally, the pull-up and gate resistors have been changed to form a potential divider, so that when the control signal is pulled low, the gate-source voltage reaches ~-10V at VCC=12V, giving a couple of volts of margin from the absolute maximum rating.
I had considered simply using a MOSFET with a larger gate-source voltage limit, as the divider solution would also reduce the drive voltage to ~4.2V when operating from a 5V supply. However, when looking at alternative transistors, most datasheets for common, cheap devices indicated higher on-resistances than the A03401A claimed, even with the reduced gate voltage. Since rearranging the resistors costs essentially nothing, I opted to keep the AO3401A using the potential divider, and just accept the slight (probably unnoticable) increase in on-resistance.
Trace routing to connect the updated output MOSFET and potential divider network Changes to the PCB layout were relatively small. Q1 was rotated 180 degrees since this lined up better with the power traces, and a few signals were shifted around to the updated resistor pads. Finally, some small updates to the silkscreen were made to tidy up the component references, and to help tell them apart from the version 0.1 boards.
Compared to the version 0.1 layout, the trace routing actually looks slightly less convoluted in my opinion, but perhaps I'm just telling myself that to justify having to pay for a second batch of prototypes....
-
Version 0.1 PCB
02/15/2025 at 23:30 • 0 commentsThis should be a fairly brief log covering some features of the PCB layout, with most technical aspects being discussed in the Version 0.1 Schematic log.
Components and copper are only on the front side of the board Quick 3D render to check everything looks right The overall PCB dimensions are 15.5mm by 49.5mm, and is designed to fit in the gap between the Compute Module and M.2 slot on the Compute Module 5 IO board. Two cutouts are placed on the board to provide clearance for the JST-SH fan header on the IO board, and a small SOT23-5 component located a bit below it. A single mounting hole is shared with the IO board.
It is a single layer design, using only 2 1206 jumpers to allow the ground plane to pass beneath the power traces. Keeping the copper on a single layer was done for two reasons. Firstly, as there is no copper on the bottom, and no through hole components, there is no risk of accidentally shorting traces on the IO board should the soldermask be damaged, which allows the PCB to be installed directly onto the IO board. Secondly, it makes it easier for a hobbyist to manufacture the board at home, without needing to worry about alignment of a second layer, or fitting via 'rivets' to the board. Any internal fillet radii of the board outline are at least 0.5mm for milling, and all components are 0603 or larger, so everything can be hand soldered with a bit of care.
The location of the connector to the IO board is placed so that a 50mm long JST-SH cable (such as this one from Adafruit) is approximately the right length to connect to the IO boards fan header, without creating excessive bending of the cable or leaving too much loose wire. The module fan header is then located as closely as possible to the IO board fan header to keep fan wiring consistent.
A second fan connector using a standard surface mount 0.1" pitch pin header can be optionally soldered for connecting desktop PC fans, or to connect jumper wires to some other generic load to be controlled.
Since the single mounting hole shared with the IO board may not provide a secure enough attachment to avoid the module from working its way loose, notches were added to the bottom edge of the board to help combat this. These can either be used as alignment guides with a 3D printed bracket, or to provide additional surface area for silicone adhesive when mounted directly onto the IO board.
A quick look at the actual module, notice Q1 has been rotated with an extra flying wire added to correct the pinout Due to the error in the schematic, a small bodge was required to switch the pinout of the output transistor for the board to function correctly (i.e. actually turn off the fan, rather than just slow it down due to the voltage drop across the body diode!). I also noticed the AO3401A used for the output transistor has an absolute maximum gate-source voltage of 12V (not 20V like I thought!), which will be reached when running the module from a 12V supply. Both these issues should be fixed for version 0.2 of the board, which will hopefully be the only revision required!
I need to get the correct length wire, but otherwise not a bad fit! -
Version 0.1 Schematic
02/15/2025 at 14:12 • 0 commentsFollowing from the previous log, the initial schematic layout for a 'missing pulse detector' based circuit for determining the power state of the Compute Module 5 to enable/disable the fan is shown below:
Schematic layout for first version of CM5 Fan Halt module Note: in the below description, 'tachometer line' is used to refer to the TACH_PI signal, which is the tachometer input to the Raspberry Pi. The TACH_FAN signal is the open collector tachometer output of the fan, which I try to refer to as such (e.g. Fan tachometer output)
The circuit is a fairly simple one, relying on an LM393 comparator to monitor the voltage across capacitor C2. A resistor network slowly charges this capacitor, however it is rapidly discharged by MOSFET Q2 whenever the tachometer line is high. While the Pi is running, the fan produces a square wave on the tachometer line, which regularly discharges C2 so the threshold to disable the fan is never reached.
After shutting the Pi down the tachometer line is no longer being pulled up, and hence Q2 cannot discharge the timing capacitor C2. After reaching a threshold of 60% of VCC (set by R11 and R12), the comparator U1B disables the output MOSFET Q1, turning the fan off.
MOSFET Q3 acts to buffer and invert the fan tachometer output before it is fed back to the Compute Module 5. This is required as some fans may have a built-in pull-up resistor on their tachometer output, which could interfere with measuring whether the tachometer line is being pulled up by the Pi. Since the tachometer signal is a simple square wave and fan speed is measured proportional to its frequency, the fact that Q3 inverts the signal should not matter.
As the fan being controlled is of PWM type, it is possible for the Raspberry Pi to stop the fan completely by driving the PWM signal low, and as a result the tachometer signal produced by the fan becomes a constant voltage. This causes a problem should the fan stop in a position where the tachometer is high, as Q3 would be stuck 'on', driving the tachometer line to ground. With the tachometer signal stuck low, C2 will be allowed to charge up until the module disables the fan, even through the Compute Module hasn't been shutdown.
To solve this, a second timing capacitor and comparator, C1 and U1A are used. C1 is discharged when the fan tachometer output is low (and hence Q3 is 'off') through diode D1. If the fan is stuck with its tachometer output high, C1 will begin to charge up. Once C1 reaches 60% of VCC, comparator U1A disables its open collector output, preventing Q3 from driving the tachometer line low, so that it may be pulled high by the Compute Modules pull-up, should it still be running. This additional timing capacitor is charged at a faster rate than capacitor C2, so should the fan become locked, the tachometer line will be prevented from being driven low before the power to the fan is disabled, ensuring the fan remains powered throughout.
The discharge and gate resistor values of 6.8k were chosen based on the Noctua fan whitepaper, which suggests a maximum pull-up current of 5mA connected to the fan tachometer output for 5V and 12V fans (p.3). In this case, the peak current occurs as a combination of R6 and R10 (6.8k) and R2 and R3 (100k). Assuming the module is being powered at 12V (instead of the 5V provided by the CM5 IO Board), the maximum collector current drawn through the fan tachometer is ~3.77mA.
A couple of additional features in the circuit include diode D2, which acts as a flyback diode if you want to use the module to drive any reactive loads other than a brushless PC fan, such as DC motors, solenoids, or relays; and (unpopulated) pin header J3, which conforms to the common 4-pin desktop fan pinout (Noctua fan whitepaper, p.3), allowing regular PC fan to be used with the module instead.
Finally, if you looked closely at the schematic, you might have noticed a very simple mistake that means this version won't work as expected - The output transistor Q1 is the wrong way around, so even when the fan is 'off', current will still be allowed to flow through the body diode!
-
Design thought process and ideas
02/13/2025 at 23:32 • 0 commentsQuick disclaimer: At the time of writing, I'm currently waiting on the 2nd iteration of the boards to be delivered, so these logs are mostly me trying to recall and write down what went into the design at the time!
Some RequirementsWhile the problem I'm trying to solve is simple enough - automatically turning off a fan when the Pi Compute Module is shutdown, there are a few specifics I want this design to achieve:
- Plug 'n' Play: I want installation of the module to be as simple as plug it into the Pi and the fan and it's good to-go. I don't want the functionality to depend on having software installed upon the Pi itself.
- Reside entirely within the Compute Module 5 IO Case: I would like it such that the add-on can be used with the official Compute Module 5 IO Case (the one included with the Compute Module 5 Development Kit), without impacting its overall geometry or appearance. Practically, it would therefore need to reside within the case with the IO board, and should not require connection to any external connectors, such as the USB ports
- Minimal Impact on compatibility with other hardware: The Compute Module 5 IO board provides connections for M.2 devices, standard Raspberry Pi Hats (including Power Over Ethernet) and there are also several third party cooling solutions for the Compute Module itself. This addon should not interfere electrically or mechanically with any of these components as far as reasonably possible.
- Make use of affordable, common components: In line with the Pi Compute Module 5's decade+ long obsolescence statement, this addon should remain accessible and easy to build so long as it remains useful for, which is essentially until the Pi CM5 becomes obsolete. A key part of ensuring this is avoiding the use of niche ICs that are unlikely to be succeeded by alternative parts after reaching end-of-life status. Plus as this should be a fairly simple circuit, they shouldn't be necessary in the first place.
- Minimal impact on idle current consumption: While the main reason to stop the fan after shutdown is to stop it from making annoying noise, it also reduces the overall power draw of the Pi in this state. This addon should really use less power than the fan (and much less than the idle Pi) so these power savings are not lost.
Mechanical sizing
To ensure mechanical compatibility with other addon hardware and the Compute Module 5 IO Case, it's necessary to determine where would be a suitable location for installation so that upper limits on the PCB size can be set. To this effect, I've had my eye on this particular spot on the IO board, in between the M.2 Socket and the Compute Module:
3D render of Compute Module 5 IO board highlighting potential location for the fan halt addon board This location seems fairly ideal as it's a fairly empty patch of board, with only two conflicting components to work around, it includes one of the IO Boards mounting holes, which could also be used to attach the addon, and it's right next to (well, encompasses) the normal fan header, which help keeps the length of loose wires needed to a minimum when plugging things in.
The downside is that this strip is still fairly narrow, limiting the overall board width to about 15mm to avoid conflicting with the adjacent sockets, which could make it challenging to try and fit everything on the PCB neatly. On the other hand, maybe the extra challenge will make designing the board a bit more 'interesting'? Is 'interesting' a good or a bad thing here?Electrical operation
According to the Fan control section of the Compute Module 5 datasheet, (Section 2.15, p.16):
During CM5 shutdown, power supply shutdown includes Fan_PWM. If the PWM fan is powered from +5V, the fan will start or continue to run. To prevent the fan from running after power supply shutdown, turn off the supply to the fan. For example, you could use the same supply as the external USB ports use which is controlled by VBUS_EN. Alternatively, use an open collector buffer (e.g. 74LVC1G07) powered from +5V. Connect the input to CM5_3.3V. Connect the output in parallel with the PWM line.
The main options for detecting shutdown of the Pi appear to be either by tapping off VBUS from the USB ports, or using the CM5_3.3V rail to control some kind of load switch. I would like to avoid the former, as I don't want to have wires trailing outside the case to access the USB connectors, however neither of these signals appear to be made available on any internal connectors...
Conveniently, the datasheet also states the following (Section 2.15, p.15):
Fan_Tacho is an input with an internal pull-up to CM5_3.3V suitable for Tacho output from many PWM fans.
If the pull-up on the Fan_Tacho pin is driven by CM5_3.3V, then we can determine from the presence of a pull-up whether or not CM5_3.3V is powered or not, and hence whether or not the fan should be on.
This is doubly convenient in that we already need to connect to the fan header to access the power and PWM signals to drive the fan, so no other connection to the IO board is needed.
Knowing this, the next step is to devise a scheme for detecting whether a pull-up is present on Fan_Tacho or not, of which there are 2 main ways I can think of to achieve this:
- Add a small shunt between the Fan_Tacho pin and the open collector output of the fan tachometer, and measure if the voltage at the high side of the shunt is sufficiently above ground
- Construct something similar to a 'missing pulse detector' circuit, which generates a signal if the Fan_Tacho pin remains low for too long, while ignoring the short low pulses produced by the fan tachometers open collector output
After some thought I concluded that method 1. would be subject to too much uncertainty, as the input voltage thresholds (which may or may not be affected by the GPIO_VREF voltage), and pull-up resistance on the Fan_Tacho pin are not documented, and no partial schematic of the Compute Module 5 has been released. This makes selecting a suitable shunt voltage (and hence component, whether resistive or non-linear) difficult without experimentation, and since these parameters are not specified on the datasheet, they could even change between revisions of the CM5 IO Board without notice. I did consider simply using a forward biased Schottky diode for this and setting a low voltage threshold of 50mV or so, however I still would not be able to ensure the forward voltage would still be low enough (on top of the saturation voltage of the fan output) to reliably produce a 'low' signal on the Fan_Tacho input.
As a result I went with method 2. (the 'missing pulse detector') as a basis on which to design the shutdown detection circuit, which will be discussed more in another log describing the schematic layout of the addon.
-
Problem Statement
02/11/2025 at 19:04 • 0 commentsI like the Raspberry Pi Compute Modules. I like coming up with a million and one ways they could be put into projects where they don't necessarily belong. I like procrastinating so much that I never get round to doing anything with them! Following this trend, I liked the announcement of the Raspberry Pi Compute Module 5 so much that I had to ask to get one for Christmas.
However, reading up on the Compute Module 5 and its accompanying IO board, there appeared to be a slight problem. THE FAN.
The Compute Module 5 uses an open collector output to drive the fan PWM signal to control its speed. After being shutdown, the fan remains powered while this output is disabled. As a result, the internal pullup resistor within the fan pulls the PWM line high (which is a common feature in 4-pin desktop fans that allows them to be driven from a 3-pin fan header), and then the fan starts whizzing up to full speed! A definite nuisance, when everything is supposed to be shut down, and the only way to stop the whirring is to unplug the power.
Having to fiddle with the USB-C connector whenever you want to turn the Pi on or off is annoying, especially if you want to have it tucked away in a corner running headless with a dozen other cables snaking around it.
This project will eradicate this especially minor inconvenience once and for all by fixing what should have always been in the first place, and STOP the fan when everything has been shutdown.
Fortunately, there is a more or less unused area right next to the fan header on the Compute Module 5 IO board, sandwiched between the Compute Module 5 itself and the M.2 NVME SSD. This appears to be the perfect place to squeeze in a little extra logic to finally put a stop to the tyranny of unwanted fan noise.