Skip to content

Project Updates

Oh No, Not That Kind of Oscillation

OK, so maybe things are not happy in switched mode land. In addition to the issues identified in the previous post, things are, to be fair, not good. The first issue is, I think, a minor one. I accidentally misread the datasheet and the P part doesn't have a soft-start pin, but a power good pin. This didn't turn out to be a major issue, but more an annoyance.

The more substantial issue is this ...

A horrifying scope trace

That is, to use a technical term, not good. Not good at all.

Channel 1 (yellow) is the (attempted) 5V output. Channel 2 (cyan) is the 11V input. As you can see from the squiggly nature of the traces, things are unwell in the land. Just a few of the horrors:

  1. The output is swinging 3 volts, mostly around 5V, at least? This is not a good thing, and is what we might call "excessive ripple". Also, the ripple has ripple, which, if you're not Xzibit, is probably not a good thing.
  2. The "ripple" is at 3.7kHz, which is a strange frequency that I can't seem to figure out the origin of.
  3. The input is ... well, I wouldn't expect it to be swinging a full 0.5V in either direction from the 11V setting that it was at.

Further digging into it, just doesn't lead to any rational understanding of the situation. All the capacitors measure reasonably with an LCR meter (in circuit, so accuracy isn't great). Putting it under load, when you get above 2A, the ripple shrinks suddenly to approximately 150mV, which, while still high, is much more sane.

I'm honestly flummoxed.

First Oscillation

One of the things that this project is doing is pushing my skills designing hardware. An area I had largely avoided until now was switch mode power supplies (SMPS). For this project, I am planning to use +12V as the base power rail, +5V as the main distribution rail on the backplane for all the cards, and then local regulation down to +3.3V. The +5V to +3.3V is totally doable (and maybe even preferrably done) with a low dropout (LDO) linear regulator. But the +12V to +5V is a bit more as we're talking about 5-6A of current needed.

SMPS are typically very efficient, and I was hoping to use that to my advantage. It's not that I really need the efficiency, but it's like with machining, you always work to tight tolerances so when you need them, you know how. TI has an amazing tool for building out power circuits, and with some knob twiddling, it spit out a design based around the TPS566238, a wee little QFN package (3mm) that would have a target efficiency of 95%. Perfect!

In this post, I'm hoping to dive into a bit of the design and some logic around it all.

The Centerpiece

Before digging into the specific implementation, let's talk about the chip that it is built around. The TPS566238 is a quite modern regulator for an SMPS. On the surface, the implementation is pretty simple:

Typical application for TPS566238 with the IC, an inductor, and some

That's it, right? Well, almost, but not quite as we'll see in a bit.

As I said earlier, part of the driver is the efficiency of the design, which you can see here:

Efficiency v load chart for

The part can support up to 6A of output current, which makes it perfect for the use case. In addition, it has something like a 50µA quiescent current. Quiescent current being, very roughly, the "overhead" of the chip, or the power that's used that isn't contributing to the switching and outputs. It's more than that, but that's a close enough definition for these purposes.

The Beginning and the End

Schematic of a DIN connector with links to power

It all starts with power coming in at +12V, and going out at +5V. Since the project is built around a DIN 41612-based backplane, we need to tie all that together. As you can see from the schematic to the right, we are using quite a few pins for power. The typical DIN 41612 connector is rated at 2A per contact, so with 8 pins (4 at the "top", and 4 at the "bottom"), that gives us a capacity of 16A, and while we'll need to derate the capacity, we won't need to do so more than 15-20%, leaving us plenty of excess current-carrying capacity.

Additionally, there are quite a few ground pins spread out through the connector. I think it's Rick Hartley that recommends almost 50% grounds, I figured that since I was not doing anything truly high-speed, that about 25% would be more than enough.

Now that we have both a source and sink for current, let's dig into the meat of the design.

Theory to Reality

The "typical application" shown in many data sheets is a highly simplified version of the reality, but it's not misleadingly so. What I ended up with, in the first round at least, was this:

Schematic of the main switch mode

You'll see along the schematic, that there's a lot of text boxes with various specs in them. These exist because, quite honestly, I wanted to keep my thought process and decisions localized to the schematic for future me to use. A few things to call out:

  1. I upped the inductor from 1.5 to 2.2uH, while keeping the DC resistance (DCR) and saturation current (IDC) roughly the same. The part I chose was Pulse BMQ part. This is a shielded inductor with an DCR of 8.5mΩ and an IDC of 12.5A. The additional inductance allows for a lower minimum input voltage.
  2. I used a similar mix of capacitor packages as recommended, although slightly fewer 0402 packages. Smaller packages reduce the loop inductance of the circuit. I also tried to streamline the bill of materials (BOM) a bit by using multiple of certain capacitors rather than one large one. Everything on the board is either Murata or TDK X7R, with the exception of one X5R composition.
  3. The feedback (FB) circuit is built with 1% Vishay CRCW thick-film resistors. They're about $0.01, or less, in any quantity.
  4. I didn't do anything with the enable (EN) pin. The datasheet is clear that if left unconnected, the internal pull-up resistor will activate the chip.

That's it. Other than the tiny passives, it's not a super complicated circuit.

Blinking (or not) Lights

Everything needs more lights, although in this case, they shouldn't be blinking. The last little bit of the circuit was a test point and some LEDs:

Schematic with LEDs

Again, as before, all the math and calculations around current-limiting resistors is included in the schematic. The LTST-C190KGKT are small 0603 LEDs. While I could have gone bigger, I'm trying to push myself to work with smaller components, as that's just the direction the industry is going in.

The Result

I shipped the designs off to JLCPCB, which is the contract manufacturer I use almost exclusively, and after getting the boards back, I did a janky job of soldering up everything, and identified a few design issues:

  1. The QFN package is stupidly small. Like, just insane. But, I did manage to get it soldered the first time by applying a tiny bit of solder to the pads and then using a hot air reflow station.
  2. The default footprint for the inductor is just barely too small, and required some finessing to get it to actually solder to the PCB.
  3. I put an 0402 right up against the inductor, and that was just stupidly hard to solder. I went through 3-4 of them (cheap!) before I finally got something kinda not terrible.

Multiple probes attached to a vertical

On first power up on a bench power supply with 12V and current heavily limited, there was no smoke, which, given my inexperience here, and my lousy soldering, is quite surprising. It even generated 5V.

It also generated not great output (about 500mV ripple) at around 3kHz and a rather annoying 17kHz audible squeal which I could never quite identify the source of. I think it was some kind of reverse microphonics with the inductor because I could press on it and get the volume to change. Fun! I think the output ripple might be related to not having much load on it, as I couldn't find my programmable load in the basement. SMPS don't really like being unloaded, and a 2W resistor didn't help much there.

One final area I was worried about was whether or not temperature would be an issue, so I let it run with what little load I could generate for a while, and watched it on an IR camera.

Infrared snapshot of the board, 2 components identified at

As you can see, both the inductor and the regulator/controller both stayed in a very safe range of 34.4-3.45°C. I'll need to verify this under load to have any confidence in the design, but that means finding my programmable load.

Once I've got that, I need to run down those two issues. But, hey, for a first SMPS ever, using tiny freaking parts, there was, in fact, no smoke in the smoke test. So, for now, I'm happy.

A Modular Base Board

One of the things that really delighted me with the kha project is the use of a common PCB for the rack, and having it designed in such a way as to allow many different applications. I decided I wanted to do the same thing, but obviously with my own spin on it.


The design has the following goals:

  1. A single re-usable PCB that can be used for 90% of the use cases.
  2. Flexibility in programming and debugging
  3. Local power regulation that leverages the +5V rail on the backplane.
  4. Easy ability to change the run-time configuration.


I am using the term "subsystem" quite loosely here. Let's think of it more as just different distinct parts of the base PCB that can be populated as needed, and used as needed. Obviously some, like power, will be there all the time, but others may only be present in a small number of situations.

Power Regulation

The main power rails of the backplane are +12V and +5V, as is tradition. But that's not what "modern" microcontrollers run on. They run on, at most, 3.3V (typically spelled "3v3"), and most can run on much lower voltage. The STM32H5 series, for example, can run on anything from 1.71 to 3.6V. To simplify things (noise gets even more fun to deal with as the potential drops), we'll run the board's main rail on 3.3V.

To get from 5V to 3.3V there are two options. First, we can use a linear regulator in the form of a low-dropout (LDO) regulator. We could also use a local switched mode power supply (SMPS). To choose, I think it's worth thinking about two factor: what's the voltage drop, and what's the power requirements.

Since we're going from 5 → 3.3V, that's only 1.7V, which isn't a huge drop, and well within the capabilities of either type of power supply. For power, let's look at what the worst case might be for that 3.3V rail:

Component Qty mA/ea Total Note
STM32H503 1 200 200 ∑IVVDD
ATA6561 1 0.35 0.35 CAN transceiver
LED 16 20 320 Typical If
ESP32-C3-MINI-1 1 350 350 TX 802.11b @ 20.5dBm

That gets us a total of around 520.35mA for most situations, but 870.35 with an ESP32 with its WiFi radio lit up. Let's call that 900mA. Note, this doesn't include the 5V drive for the CAN transceiver, for example, which is typically 50mA when dominant, but is taken directly from the backplane rail. Most other STM32 CPU are actually lower ∑IVVDD (the maximum current present across all VDD pins) by 50-80mA.

Schematic for a very simple LDO circuit with the

Since there's not a massive amount of current, the plan is to use an AP2114-3.3 fixed-output LDO regulator. This is a super simple device that requires a very simple circuit to implement, as shown to the right, which can deliver 1,000mA (1A). The only addition is a tiny voltage divider to drive the EN (enable) pin high from the +5V rail. The total cost for the circuit, assuming 10 instances of it, is:

Component Qty Unit Total
AP2114H-3.3 1 $0.332 $0.332
4.7uF MLCC 0805 capacitor 2 $0.104 $0.208
0603 100mW ±1% SMD resistor 2 $0.01 $0.02

That gets us to a whopping $0.56USD for the regulator circuit.

We do need to think about junction temperature, so let's do a quick calculation of the "worst case" of a full 1A of power.

\[\begin{align} P &= (V_{in} - V_{out}) \times I_{out} + (V_{in} \times I_{Q}) \\ &= (5 - 3.3)\times 1 + (5\times 0.065) \\ &= 1.7 + 0.325 \\ &= 2.025\textrm{W} \end{align} \]

So the most we might dissipate is 2W at full load. So, what does that do to the junction temperature? Let's assume a 40C wost-case ambient temperature (TA) and a TO-252-2 (that's what the H in the part number refers to) package.

\[\begin{align} T_J &= T_A + (\theta_{JA}\times P) \\ &= 40 + (35 * 2.025) \\ &= 110.875\textrm{C} \end{align} \]

The device has a thermal shutdown (TOTSD) of 160C, so we are safely within the margins of the device. This is before we take into account the use of the ground plane as a heat sink off the package tab.


Samtec FTSH-107-01-L-DV-K-A connector

Every board needs the ability to be programmed and debugged. The standard in the STM32 ecosystem is the STDC connector, which provides multiple functions simultaneously, and is typically exposed via a 0.500" pitch 14-pin connector like the one shown here.

The pin-out according to UM2448 is:

Pin Function Pin Function
1 NC 2 NC
11 GND Detect 12 NRST

The pins are for JTAG (J pins) or SWD (SW pins), along with the virtual communications port (serial port) on the VCP pins.

Tag-Connect TC2070 connector and cable showing the spring-loaded pins

Unfortunately, those Samtec connectors aren't cheap, running close to $4USD each. Instead, I'm planning to leverage the Tag-Connect system, which uses a set of spring-loaded pins to touch contacts on the board that don't require a dedicated header to be installed. The TC2060-IDC-050 model fits the STDC use case perfectly.

For this situation, it's just a special footprint on the PCB. That footprint looks something like this:

PCB footprint with 14 small circles and 3

They're, effectively, free. And, if you use ENIG finish, very durable.

Serial Console (maybe?)

This is one I'm not completely sure of. There's a "serial port" on the VCP part of the STDC header shown above, and this is probably all that's needed. Still, I keep thinking maybe I should expose a dedicated serial port for ... reasons that I cannot explain, other than "more ports better".

USB Connector (maybe?)

This is also a maybe for me. It's not really clear what the use for the connector would be, and it's also unclear if it would make sense for it to be either a host or peripheral connector as well. I can imagine there being the possibility of an interesting use case of attaching devices to the USB bus, however, so I'll likely include one. Whether it'll be a USB micro or a USB-C is yet-to-be-determined.

MicroSD Socket

One thing that I do want to include is a micro SD card connector. This will allow for future expansion of both memory, but also potentially allowing the SD card to contain the configuration for the board, which might allow every board to be flashed with identical firmware.

This will likely be done with a CUI MSD-1-A connector.

Connector Tree

JST PH 4-pin connector

This is the pièce de résistance that I am lifting from the original design. The basic gist of it is that you pull GPIO/I2C/SPI signals out to something like an 8-pin connector, then you fan it out to 2 smaller connectors, and then potentially fan it out further to even smaller connectors. This allows you to pick and choose what you need. You don't even need to put all the connectors on the board unless you need them, saving money further.

For a connector, I'm using the ubiquitous JST PH that you see everywhere. For example, in one variant, it's used for Adafruit's STEMMA connectors. It's widely used, distributed, and a very durable connector.

Power Connectors

One of the things that I was thinking of doing is providing a bank of power connectors. These could be used to provide 3.3V, 5V, or 12V to front-panel devices directly from the board. They don't need to carry a lot of current and I want to use a small connector, so I'm thinking of using the same JST PH connectors as the signal tree, but in different sizes so that hopefully I won't accidentally plug a signal into a 12V power source.

This is an area that I just haven't fully thought through yet. For example, the ubiquitous OLED screens need, typically a 5-12V input that is then used locally to boost to the drive voltage. EPD (e-ink) screens typically leverage 3.3V to feed the driver circuit. I'm not even sure there's a real use-case for 12V here, which could simplify things.

ESP32 Footprint

ESP32 module with castellated

There are a few use cases where I can imagine wanting to have a WiFi "modem" available. To do that, I'm intending to place the necessary pads on the PCB for an ESP32-C3-WROOM-1 module. This is a RISC-V-based module. The package is only 16x13mm, and includes a PCB antenna. This will likely be against the upper edge of the card so that the copper exclusion zone necessary for the antenna doesn't interfere with the main function of the board.

This will be hung off one of the UART channels of the STM32 microcontroller, and programmed with the ESP32 AT firmware, which presents a full TCP/IP stack, with TLS, HTTP, and even MQTT support, over a crazy modified Hayes AT command set. I believe it maxes out (or maybe just defaults to) 115,200bps, which should be fine for most any real application like checking network time or web APIs. If that ends up being not enough, there is an SPI interface option that can run 10x faster.

Status LEDs

Every computer needs blinking lights. This much is indisputable. So every board will have a few selection of lights for power rail status, MCU status, and maybe CAN bus status. These will likely just be 0603 or 0805 surface mount LEDs on the PCB itself. There may, however, be a front-panel LED that is just a "power good" LED. That would be connected to a dedicated connector on the PCB.

Reset Switch

Panasonic EVQ-P7A01P tactile SMD

Finally, every computer needs a physical reset switch. In this case, tied to the NRST pin on the controller. When this gets pulled low, the processor goes into system reset. The plan is to use these small surface-mount tactile switches at the very front of the PCB that will be able to be pressed via a small rod (paperclip, naturally) through a small hole in the front panel.

Next Steps

I have a first prototype of the connector tree part of the board I've done, but I'm not happy with it. I'm planning to go back to the drawing board once I pick a specific MCU so that I can optimize the design to maximize the flexibility of alternate functions on various pins. In addition, the initial design didn't have any power on the connectors, so you had to depend on the MCU to source power, which isn't a great way to drive a lot of things.

CAN on 8p8c Connectors

8p8c is not RJ45

Pedantic Warning You will often hear people call the modular connectors that are used for Ethernet "RJ45", but that standard is a very specific thing that is not actually what you're using. The correct term is an 8p8c connector, which refers to the 8 positions and 8 contacts.

I have often done this myself, but for the purposes of being technically correct, I will try my best to stick to the proper designation.

For the project, I want to connect the string of devices over CANbus. To do that, I intend to leverage the ubiquitous 8p8c that you see all over the place in Ethernet.


There were a few goals in mind:

  1. Use existing standards and easily available connectors and cables
  2. Deliver power over the same cable as the signal
  3. Provide reasonable noise immunity

The noise immunity is pretty easy given this is a differential signal and we are going to use twisted pairs to twist the high and low signal together. Looking at an oscilloscope trace of the CAN signal from this TI application note, you can see the differential nature:

An oscilloscope plot showing a single-ended signal converted to
differential signal

Connector Signal Mapping

For the ends, I chose to use a rather boring layout, but I wanted to make sure CAN was twisted together, and that each of the +12V wires was also twisted with a ground.


Cable Wiring

The wiring is standard Ethernet wiring, following the T568A standard. The reality is that it doesn't matter whether you use T568A or T568B, quite honestly, but I just picked A because it's the most common and what the typical patch cable is wired for.

Category 5/5e is more than adequate for the signalling that CAN or CAN FD use. The general rating for Category 5 is 100MHz, and if we look at a quality cable, like the Belden 1224, we can see that it has the following characteristics:

Max DCR Max DCR Imbalance Max Capacitance Insertion Loss(100MHz) Fitted Impedence
89Ω/km 3% 33pF/100m 21dB/100m 100±15Ω

And it is, in fact, rated to 350MHz, far in excess of what's needed.

The makes the overall wiring looks like this:

%3X1X18p8cplug8-pinCAN_H1CAN_L2GND3+12V4+12V5GND6GND7+12V8W1W1cat5e8x24 AWG (0.25 mm²) X1:1:CAN_H     1:WHGN    X2:1:CAN_HX1:2:CAN_L     2:GN    X2:2:CAN_LX1:3:GND     3:WHOG    X2:3:GNDX1:4:+12V     4:BU    X2:4:+12VX1:5:+12V     5:WHBU    X2:5:+12VX1:6:GND     6:OG    X2:6:GNDX1:7:GND     7:WHBN    X2:7:GNDX1:8:+12V     8:BN    X2:8:+12V X1:e--W1:wX1:e--W1:wX1:e--W1:wX1:e--W1:wX1:e--W1:wX1:e--W1:wX1:e--W1:wX1:e--W1:wX2X28p8cplug8-pin1CAN_H2CAN_L3GND4+12V5+12V6GND7GND8+12VW1:e--X2:wW1:e--X2:wW1:e--X2:wW1:e--X2:wW1:e--X2:wW1:e--X2:wW1:e--X2:wW1:e--X2:w

Power Handling

Voltage Smoltage

I haven't actually settled on the voltage to use on the cabling. For now, I am using +12V, but moving up to +48V would (basically) quadruple the available power without requiring any additional copper. It does, however, somewhat complicate the individual device power supplies.

At this point, I'm planning to run +12V across the cable to allow for most things to be powered off the central device. Given I use solid rather than stranded cables, we can the standard AWG wire gauge ratings of 3.5A on a 24 AWG single-core wire.

Now we can't do the math quite yet, as we need to derate the wire based on two different factors, according to the NEC:

  1. Ambient operating temperature
  2. More than 3 wires in a cable

So, if we do the math for operating at 40C (104F), and with the 3 power carrying conductors in the cable, we get derating factors of 0.88 and 0.80 respectively. So...

\[\begin{align} P &= 3 (3.5A \times 0.88 \times 0.80) \\ &= 3 (2.464) \\ &= 7.392A \end{align} \]

So that means we can do 7.392 * 12 = 88.7W of power on the cable. But there's a catch. The current most advanced power-over-ethernet (PoE) standard, IEEE 802.3bt-2018, says that each pair of conductors is designed to handle 960mA, which would actually put us at (generously!) 960 × 2 or 1.92A, or 23W at 12V.

This is the reason I'm thinking of switching to driving the cable with 48V, which would let me move up to 92W, which is about what the standard allows. So, perhaps I will change to a 48V distribution, which will require something like an LM5576.

We'll burn that bridge when we come to it.

Quick Note About Diagrams

The diagrams above were done with an amazing tool called Wireviz, and embedded into the MkDocs site you're reading using a little hacky Markdown extension I wrote.

A Bus is a Bus, Of Course, Of Course

One of the defining features of the project is using a modular backplane in a subrack enclosure. I figured we can dive into some of the details so far.

Design Principles

When I was looking at how kha structured the bus, I decided to pull a few ideas from what they did:

  1. Leverage DIN 41612 for the physical format of the bus. This is a very well understood and documented specification, and it has been battle-tested over many decades.
  2. Simplify the backplane routing requirement.
  3. Carry both +12V and +5V. Can be locally regulated down to the needed voltage.

Physical Connector

I decided to use the DIN 41612 connector because it is an absolute tank. It has been used, at least, since the late 1980s in dozens and dozens of critical systems. It's also relatively inexpensive and not very finicky to work with.

View of the connector

Diagram showing a straight receptacle and a right-angle

While kha used a 32-pin connector (2 rows of 16 pins), I've decided to use a 64-pin connector. The reason is that this allows me to run many more ground lines across the connector, and also double up the power. I am using the DIN 41612 connector in it's type B configuration. This means it has 2 rows of pins/contacts, labeled "a" and "b". The numbering scheme is basically A1/B1-A32/B32.

There are many other arrangements that are used in other systems, and many have 3 or 4 rows, but this is far more than enough for this setup. It also keeps it from even starting to look like VMEbus, which uses a 3 row 96-pin version.

Pin numbering on a DIN 41612

In the type B configuration, the receptacle (female) connector is on the backplane and the plug (male) is on the card at a right angle. While you can get connectors reversed, I didn't see any reason to deviate from this arrangement.

The connectors also have 2.8mm holes for M2.5 screws that allow them to be very securely attached to the PCBs, without needing to put any strain on the solder joints.

Signal Assignment

To simplify the routing enormously, I've decided to keep the "a" and "b" rows identical. This allows for the bus to be routed straight across the backplane. The "signals" can be broken down into a few groups:

  • Ground
  • Power rails, both +12V and +5V
  • CAN bus (differential encoding)
  • User-defined signals (BUS_*)

This breaks down to this layout, where ground is heavily interspersed with the signals to help ensure reasonable signal integrity.

Pin # Row A Row B
2 +12 +12
3 +12 +12
4 +5 +5
5 +5 +5
11 BUS_00 BUS_00
12 BUS_01 BUS_01
14 BUS_02 BUS_02
15 BUS_03 BUS_03
17 BUS_04 BUS_04
18 BUS_05 BUS_05
20 BUS_06 BUS_06
21 BUS_07 BUS_07
23 BUS_08 BUS_08
24 BUS_09 BUS_09
28 +5 +5
29 +5 +5
30 +12 +12
31 +12 +12

Power Capacity and Derating

One of the things I wanted to do is be able to carry 6-8A of current on both the +12V and +5V rails. The standard for the connector specifies 2A per pin, but you also need to derate this number for use in the real-world. If we look at Harting's derating curve, we get this:

A derating curve for DIN 41612 connectors from

Most standards talk about "room temperature" at 20C, but it's typically necessary to actually use a higher temperature in the real world. The resistance of the copper along with all the other components will raise the ambient temperature. If we assume 35C (95F), then we can see on the curve that we can expect about 1.8A. As I showed above, we are using 8 pins per rail, which gives us a safe load capacity of 14.4A, well above what we are targeting.

We are actually safe, for this definition of safe at least, up to 98C (208F), which is a temperature unlikely to occur in my house, even without air conditioning in Seattle.

PCB Layout

The layout is actually pretty simple, and only needed 2 layers for the initial run. Depending on what signal integrity looks like, I may convert to 4 layers, but because I was able to keep the entire back as a ground, basically, I have reasonable confidence. The top of the board looks like this:

Top of PCB showing 7 slots

Cliff  FCR7350 connector

You can see in the design how everything goes across horizontally, which means there's no need to really "route" anything creatively. The ground is tied together on both sides as the plated through holes connect the two sides.

It has a 8C8P connector for CAN, two Cliff FCR7350 4mm safety banana jacks for +12V and test points that can be used to check power and signals. I also put all the signals on the silkscreen.

All mechanicals are in alignment with Eurocard and VMEbus standards.

You can find the KiCad files in GitHub.

Willkommen. Bienvenue. Welcome. C'mon in.

I'm going to try and do something new with this project, and that's to document the messy convoluted process that my brain goes through to do anything. Historically, I've largely kept that all to myself, and not surfaced anything until the end, if even then.


The inspiration for this project was a post on Hackaday, which I can no longer find, which pointed to this project, which was a wildly over-engineered home automation project based around 19" subrack and a custom protocol built on top of RS-485. You can find the full project on GitHub, and there's even an amazing deep dive YouTube video

The absurd over-engineering really appealed to me as a project to tackle, and a way to push my embedded hardware and software skills way further than I have historically. I cannot emphasize enough just how much I've been inspired by their work. Some things I've lifted nearly wholesale are:

  • Leveraging a subrack. This gives a physical structure to the system, but also lets me build a backplane-based system as well.
  • Eurocard sized modules, and use of the DIN 41612-style connectors.
  • Doubling up the connector pins to simplify the backplane routing. This means that both the a and b rows are the same signal, allowing for a straight line bus.
  • Leveraging 8P8C for connectors on the network.
  • Designing a main Eurocard base for a vast majority of the work. The idea of having a single PCB that can be adapted to a bunch of different uses is very appealing
  • Putting power for the backplane into a slot.
  • Leaning into a specific "vibe" for everything that has a bit of an alternate timeline feel to it.

There's also this project that applies SCADA to the situation, but this just didn't "vibe" with me as an approach.


When it comes down to it, I have absolutely no need for this project. It doesn't solve a gap in my life, as I have HomeKit for a lot of things. Instead, I have a few goals with the project:

  1. Learn. This is the #1 goal by a wide margin. So what do I want to learn?
  2. Designing with modern surface-mount technology, and that includes working with fine-pitch packages, tiny (0402) passives, and various leadless packages.
    • Build some understanding of modern power supply systems, such as switch mode power supplies.
    • Dig into modern embedded frameworks.
    • Push my ability to do the full integration from top to bottom of a project.
    • How to design seriously resource constrained protocols.
  3. Build something silly and a bit absurd. Nobody needs this, so lets have some fun.

In addition, there's some stretch goals/features I hope to (eventually) explore:

  • A mechanism to do updates across all the nodes with a single experience. Thinking about how I might use CAN to update the firmware on everything, perhaps when a USB drive with the proper data in the proper structure is inserted. This will be non-trivial, but also I'm going to skip the insane security complexity because this is not a thing on the Internet. If that ever changes, then that consideration will have to change. mcuboot offers some capabilities here that I hope to leverage.
  • Integrating WiFi for a needlessly complicated time source. This will likely be done using an ESP32 series module as an co-processor.
  • Integrate self-monitoring/analysis into the designs. This would allow the MCU to also check everything about itself. Perhaps using an analog switch like the 74HC4067 connected to the ADC within the MCU, and a digital power monitor, like the INA series from TI. This is inspired by how a lot of test equipment can verify its own function.

Decisions So Far

Part of the process of getting started for me is doing a ton of research and then making some critical decisions that shape the project's overall strategy.

Eurocard/Subrack/Backplane Structure

A Rant About Standards

One of the most exhausting parts of doing this project has been trying to find the international standards that I've mentioned. I've been fortunate through some search-fu to find copies of the PDFs that are typically very expensive. Go support Carl Malamud and the fundamental work he's doing to make law and standards more accessible.

I really like this decision in the inspiration project. I had been thinking about building a modular sensor system in this format, and this gave me a better idea to work with in this case. I'm intending to use a 3U (133mm, 5.3") subrack, and am exploring a couple of different widths. The standard width (19", but also called 84HP) is the easiest to get, but it's a bit large for what I'm trying to do. I'm also planning to use a 175mm (6.89") standardized depth because this isn't that deep for home use, and doesn't necessarily require it to be put into a physical rack (which I don't have space for).

Fortunately, subrack products aren't particularly expensive, and I've been 3d printing mock-ups to explore the physical form factor better.

For the cards themselves, I'm intending to use the base Eurocard specification, which is 100x160mm. I'm trying to figure out if it's possible to move to the 100mm depth, which would both result in a smaller footprint, but also fit within the "cheap" sizes for most of the Chinese PCB manufacturers, which would reduce the cost overall.

A DIN 41612 rectangular backplane connector with 2 rows of 32 contacts

For the backplane, I'm using VMEbus for mechanical inspiration, but have designed my own signaling assignments because I'm not building a general purpose bus, but one designed for very specific purposes that benefits from decades of changes in the microcontroller ecosystem. The connectors will be type B DIN 41612 with 64 contacts in 2 rows. The Harting part is shown to the right. The connectors also have a 2A per contact current carrying capacity, which means they can be used to cary a decent amount of power.

STM32 Microcontrollers

kha is built on the AVR microcontroller ecosystem. This is a very well regarded 8-bit MCU platform that has been around for quite some time. It's widely used in hobbyist and embedded projects. That would be a great choice, but I decided to go with the ubiquitous STM32 series of ARM-based microcontrollers. You might know them from the Blue Pill and Black Pill boards. ST has a bewilderingly broad product set to work from, and have a competitive price point for something with wildly more capability.

I've settled on exploring 3 different chips:

Chip Core Flash RAM CAN Price (25 unit)
STM32G0B1RE M0+ @ 64Mhz 256Kb 144Kb 2 x CAN-FD $5.5140
STM32F072RB M0 @ 48MHz 128Kb 16Kb 1 x CAN $4.8544
STM32H503RB M33 @ 250MHz 128Kb 32Kb 1 x CAN-FD $3.3728

As you can see they're all over the place. The H5 series is by far the fastest one, and the cheapest, which is curious. I've picked up Nucleo dev boards to start exploring.

While I'm going to be designing my own boards, I intend to leverage the Nucleo board schematics as a starting point for best-practices. This is a good thing.


The first area where I've deviated from my inspiration is I intend to use CAN (and potentially CAN-FD). I've been working with CAN some in the robotics space, and it has a lot of nice capabilities. The inspiration used RS-485 (which is another great choice), but this also required them to implement a lot of low-level protocol capabilities that come for free with CAN.

One of the open questions is whether to use another abstraction on top of CAN. If I use "regular" CAN, there's only 8 bytes available in each packet. That may be plenty. CAN-FD allows 64 bytes. But there are other options that can extend that to nearly limitless. Some options are:

These come with higher-level abstractions, but I think they might just be too much for this specific case. I think, given the use case, 8 bytes is probably plenty.


I struggled with the framework to build all the software in. I've done a bunch of things, quite successfully, with Arduino, but I felt like I needed to stretch my skills, and work in something a bit more robust. I initially thought about using FreeRTOS along with ST's STM32Cube software, but I'll be honest... Eclipse gives me hives.

So, after looking at ThreadX, and a few others, I decided to build on top of Zephyr for a couple reasons:

  1. Huge board and chip support, and it's well supported by the vendors as well, and not just hobbyists.
  2. Gigantic (although nowhere near Arduino scale) ecosystem of modules and code.
  3. Excellent high-level primitives to build on top of, such as robust threading and IPC support, network stacks, sensor framework, and numerous other modern components.
  4. Even comes with things like a built in robust shell capability.

I have had a bit of a challenge wrapping my head around the workspace concept they use, but I've, I think, gotten past that now. I still don't have development working on my Windows machine, and I'd like to be able to use any platform to develop.

Where I Am Today

I am very early. I have:

  • Acquired a few test boards and CAN transceivers to work with before I commit to any specific PCB design.
  • Designed a breakout board for the Nucleo format to get IO onto JST PH connectors.
  • Designed an initial 7-slot backplane to work with. This is subject to change in the future, and I'll need a bigger one for the full size project, but this is a good start.
  • Designed a bunch of reusable schematic components that will show up all over the place.
  • Built a few toy applications in Zephyr to try and better understand both the APIs, but also the odd build infrastructure that they use. I still haven't gotten it working with my Windows 11 desktop, but it works fine on my MacBook.
  • Designed an initial switch mode power supply around the TPS566238 controller chip. Simulations say this should hit 95% efficiency, if not a bit above that. But, it's a dumb package, a 3x2mm VQFN. I have a backup design I've worked out built around the TPS566242, which comes in a marginally "better" SOT-53 package, with efficiency targeted around 92%. Fortunately, the passives are all the same between the two, just arranged slightly differently. This will be used to regulate the 12V backplane voltage to 5V for distribution along side. The individual boards will regulate down to their 3.3V as needed, leveraging an AP2113K-3.3 low dropout (LDO) linear regulator.
  • Figured out a bunch of initial connector pin outs.
  • Figured out an initial minimal protocol for communications.

Right now, these aren't in the repository, but over the next few days, I'll be moving them into here.

So, there's the big messy start to this adventure.