Procedural Generation of MegaCastle Castellated Symbols

In the previous post I described how I went about procedurally generating KiCad footprints for modules of different sizes and pin configurations.  That's all working great, but now I'd like the same for schematic symbols.

Like footprints, KiCad has a text-based format for symbols, and that format looks quite similar. The main difference is that while footprints each have their own file, symbols are are stored in a single library.  I'm not quite sure why, but that's how it is.

So where as with the footprints I just had to create the files in the library directory, for the symbols I'll have to read the existing symbol library and then insert them.  To do that I'll probably read the library file, and copy lines to a temporary file until I reach the end, removing the symbol if it's already in there in the process. Then at the end, instead of writing the final line, which is just a ")", I'll insert the new symbol entities. That way we can either insert or update the symbol.

One nice thing once I have this all done, is that I can make the symbols choose the correct footprint by default, to provide a small but welcome convenience.

Okay, it's taken a few hours to get it all right, but it's working now.  

One thing I found out in the process, is that if you corrupt a KiCad symbol library, you can't just re-load it. You have to quit and reload KiCad, before it will actually reload the library.  There are also some odd things with symbol order. It might expect them to be in alphabetical order or something in the file. But it all works okay.

Here's what the symbols look like for all the combinations of whether its the module or the bay to take a module, and whether its for the edge of a PCB and/or has a cut-out to allow a component zone on the rear of the module:

And of course it correctly populates which pins are actually present or not.

So now I really can get back to making the next module.

Procedural Generation of Castellated Footprints

Each of the modules I am creating need a unique module footprint, so that they can't be installed in the wrong bay, or with incorrect orientation.

I've already spent quite a bit of time in the footprint editor making variants, and I've only designed 4 of the perhaps 30 modules I will need -- and then each needs its matching bay.

To save on work going forward, I want to explore writing a program that can generate a unique module footprint that has the required component area and number of pins.

This should be possible, because KiCad uses a text-based format for footprints.

After an hour or so of hacking up some C, I have it well under way, producing footprints like this:

From running a command like this:

./footprint-gen 10 10 10 1 > ../MegaCastle.pretty/test.kicad_mod

The numbers mean the width and height of the cut-out area in the middle, and the minimum number of  pins required. The final number, 1 in this case, is to select the variant (i.e., which pins are missing to make the result unambiguous in terms of rotation or flipping). It will make the module bigger if the number of pins or the cut-out size require it.

I still need to add the no-component zones, and then the logic for working out which pins to remove, when less than the full pin-count is required.

That latter will be fairly simple, if a little fiddly, as we need to consider all possible variants (or at least several) that meet the criteria of:

1. Has the correct number of pins.

2. Has no rotational or translational symmetry to itself, nor to any of the previously identified variants.

It might be that I try to come up with up to unique variants, until we run out of possibilities, or the requested variant number is reached.

This felt like the kind of problem to set ChatGPT against to work out. And it got it mostly right, but forgot to bother flipping, when testing. It probably saved some time overall. And now I can generate variants with any number of pins and any given cut-out size for components. It even works out the name for the variant, and adds the labels, like this:

So now I just need to make it write it out into the correct file name, and we are most of the way there. I will also need to make the module bay version that accepts the corresponding module, and then my life when defining new modules will be super easy.

This will not only save time, but likely help me work faster, as coming up with the footprints for these was a significant psychological drag, especially with the low-level concern that I might have to re-do it a different size or something, if I wasn't 100% sure I had the rest of the circuit done.  It also meant that I was using cut-out areas that weren't optimal, because of the effort of making a new one, instead of just re-using an existing one.

So, onward with making the module bay versions. It was a bit of fiddling again, to get this right, but it now generates all four variants that I could need: Normal, No cutout for components in the middle for modules that don't need it (so that we keep ground planes, routing layers etc intact), Edge-of-board and both edge and no cutout, like this:

I am very happy with this -- as I can now just generate them as I need. I haven't done the same for symbol generation, but the symbols are much quicker and easier to generate by hand. It doesn't mean that I won't tackle it, but I want to get back to making modules using these footprints again first!

MEGAphone 3.5mm Audio Jack Module

This one is a super simple one: It just has the 3.5mm audio jack on it. It's a bit questionable as to whether this even needs to be on a module, vs just be soldered directly onto the carrier board. But I still like the idea of it being on a module to allow easier re-use, as I iterate the main board.  Also, it's about the size project that I can tackle on my lunch break.

1. Key Component Selection

The only component it needs is the connector itself.

We need to support stereo audio plus microphone input, and nothing else. So probably something like one of these should be okay:

https://www.digikey.com.au/en/products/detail/same-sky-formerly-cui-devices/SJ-43515RS-SMT-TR/669722

Trying to find the symbols and footprints for KiCad for this connector, I was a bit surprised that it's not even listed in SnapEDA.com -- but the datasheet actually has links to the files from the vendor directly! It would be nice if all vendors included such links in their datasheets. It just removes that bit of friction for selecting a component, and isn't that hard to do.

Anyway, with that in place, and knowing that I need only 4 pins, it's time to think about the module layout -- in particular that this connector needs to sit on the edge of the board, which the standard castellated modules I have created don't handle explicitly.  That said, the only real chance is the module bay footprint, to remove the furniture at one end of the module.

Meanwhile, I have been annoyed by a problem that I'd encountered before, but forgotten the solution for: KiCad freezes for several seconds when switching between the schematic and PCB windows.  It turns out its a known problem with running KiCad under XWayland, and the solution is to make sure no KiCad window is maximised. The interested reader can go down the rabbit hole to understand why this happens, but I'm just glad I remembered I'd seen the problem before, and could easily deal with it, because it's really annoying, and a big productivity and mood drag.

2. Schematic Layout

Okay, for the schematic, this is super simple: We have 4 pins that need to go to 4 pads on the module. Nothing else. The only other thing I've added is cuttable jumpers for each of the four pins, in case I get the pin order wrong (again).

3. PCB Layout

The PCB layout itself is also super simple. The main thing is to try to keep the size of the module as small as possible. Once I know the dimensions of the active area of the module, I can create a castellated module footprint that will fit it:

Okay, so now we know the size we need. Note that unlike most of the other modules, for this one, the jack has to sit on the flat size of the module, rather than the side that will sit in the cut-out on rear-side. This means that the module can actually be a whisker smaller than it would otherwise be. So let's set this up.

Okay, so a 2x10 is a fair bit longer than we need. 2x7 should be enough, so it's probably worth making that size module, rather than wasting ~7.5mm at the tail-end.

In the process, I have also updated all of the other footprints to fix the castellation hole sizes, and some other minor things that I was having to fix in each derived footprint, so that it should be quicker to make new footprints in future.  I do also wonder if I can't come up with a way to parametrically generate the footprints, as it should be quite possible given KiCad's text format for footprints. I'll have a think about it.

But in the meantime, here is what the module looks like now:

And that's really all there is to this one.

MEGAphone Audio CODEC / Speaker Driver Module

The internal speaker and 3.5mm audio jack require a driver. The easiest solution here is to use what they call an "Audio Codec" IC, that are used in mobile phones. They have drivers for internal and external audio sources, and often also allow termination of an external microphone, e.g., for 3.5mm audio headset.

1. Requirements Analysis

There is only one requirement we have to address here:

Requirement 3.2.1: Audio CODEC or equivalent that has output channels for loud speaker (mono is ok), 3.5mm audio output (stereo) ear piece, and input channel for 3.5mm microphone.

Implied in this, is that it supports I2S or similar audio interface, so that we can have the MEGAphone's FPGA drive it using the existing audio infrastructure that we have there.

2. Key Component Selection

We can use something like this: https://www.ti.com/product/TAC5112

I've previously used the ALC5616, but they seem to be end of life (EOL) now. 

What I'd really like, is one that has a speaker amplifier built in, so that I don't need a separate component for that. The alternative option is to not have a 3.5mm jack, and only support bluetooth for external microphone and headset.

This looks like an option:

https://www.digikey.com.au/en/products/detail/texas-instruments/TLV320AIC3110IRHBR/296-25584-2-ND/2201340

This one has two class-D 1.29W speaker drivers for stereo internal audio, as well as stereo line-drivers for 3.5mm line out jack, and also an analog microphone input line. In short, this can drive both the internal speakers, as well as the 3.5mm audio jack. It also supports I2S for the digital side of the audio.

That's more than enough to get us out of trouble for the current stage -- Bluetooth can wait until the time-critical period is over.  

3. Schematic Layout

Further in the datasheet in sections 8 -- 10 we find a typical schematic:

 

The suggested layout is interesting, too:

Our module system effectively provides a means of separation of the analog and digital grounds, with just a single point of connection.  Pleasingly, this all looks like it needs relatively few passives.

What I am considering, is whether I put the 3.5mm jack on this module, or whether it should be mounted on the main board.  I really want to keep as few components as possible on the main board, partly so that I can easily update it as I go along. 

This does mean that I need a way to have one of my modules that has one edge that can be aligned to the edge of the carrier board.  I'll need this, in any case for various other modules, such as those carrying the SIM card and SD card, or thumb-wheel potentiometers. So I'll need to tackle that anyway -- so we might as well put the 3.5mm audio jack on the module with the audio codec IC.

Okay, so I'm going through the schematic now. One thing I've just noticed that is mildly annoying, is that the device requires a 1.8V supply, as well as whatever the IO voltage is (most likely 3.3V to match the rest of the system), and VBAT for powering the speaker amplifiers.  The 3.3V and VBAT I had counted on, but 1.8V is going to require a 2nd DC:DC converter.  I'm going to see how much current the 1.8V supply needs. It might be simpler and acceptable to use a linear regulator to derive the 1.8V from the 3.3V -- but only if it won't cause too much heat / wasted power.

Also, ideally the power rails should come up in a particular order. We're going to take the minor liberty of powering them up effectively simultaneously. The datasheet does say that it has been designed to be tolerant of power sequencing, so given that our power supplies should come on fairly simultaneously -- with the exception of VBAT which remains on at all times, unless I make that switchable for this module -- we should be okay.

Now, back to that 1.8V power rail, having read through the datasheet I can't find a clear indication of the total power consumption. It talks about the power requirements for various blocks, but doesn't have a convenient "maximum power consumption" line anywhere that I can find. So I'm probably going to have to assume the worst, that it could be ~250mA.  

Probably something like a ADP5301ACBZ-1-R7 is a good option for this. It's a buck converter, so will be much more efficient than a linear regulator. And any noise will be on the digital 3.3V rail, rather than the VBAT analog rail.  It's fairly easy to setup, and can be set to 1.8V using a single resistor:

 

The PWM/Hysteresis mode of this regulator selects between a more efficient (hysteresis) mode, but is limited to 50mA, or a less efficient PWM mode, which can supply up to 500mA. This is a bit annoying, as depending on my reading of the CODEC datasheet, the draw on the 1.8V rail is either about 30mW max, or about 150mW max -- i.e., spanning the two modes ranges. The PWM mode can do both, but is particularly inefficient at lower current draw levels.

I think the best solution here is to connect the SYNC/MODE pin to GPIO1 of the CODEC, and then we can talk to the CODEC, and switch modes based on how we configure it... except that the GPIO1 pin is not, despite it's name, actually a GPIO. DOUT can be configured as a GPIO, though... which sounds a bit odd. Perhaps the datasheet is wrong?

Here's the register description for controlling DOUT:

Nope, looking through the rest of the datasheet, it really looks like GPIO1 is really just a Multi-Purpose Pin, rather than a true GPIO. So all we can do is connect the PWM/Hysteresis pin to either a pad on the module, to allow the board to select it elsewhere, or just strap it to PWM, and accept the efficiency loss. Given that the efficiency at 20mA draw should still be ~70%, that's probably the most sensible option. I'll do that using a 100K pull-up, and expose the mode pin on a pad of the module, so that it can be controlled externally, if desired.

Okay, so with the 1.8V rail solved, I can go back to the rest of the schematic layout...

I've now got it mostly set out, except for the module outline. A quick count suggests that I'll need 20 signals visible on external pads, so a 2x11 with one key pin feels like it should do the trick.  What I don't yet know, is whether the existing format of that module will fit all the components in the available cut-out area.  So it's probably a case of adding the module footprint, and then trying to fit everything into the area. I don't yet have a strong sense of whether this module will need to be 4 layer or not.

Well, the initial scale of the module to the CODEC IC gives me a bit of hope -- but there are a bunch of passives, and also that 1.8V regulator to be added yet:

4. Passive Component Selection

Okay, so to go to the next step, I need all the passives, so that I can work out if it really will all fit in a sensible way.

I can't find any restrictions on capacitor types or particular voltage requirements for the codec. The 1.8V regulator does provide specific guidance in their example layout, which I'll follow.

A quick hunt through Digikey found suitable passives, almost all of which are 0603, which gives me hope.

2.1K 0603 Resistor  - RMCF0603FT2K10

100K 0603 Resistor - ERJ-3EKF1003V

19.6K 0603 Resistor - ERJ-3EKF1962V

0.1uF 0603 Capacitor - 0603B104K500XD (X7R, 50V)

10uF 0603 Capacitor - CL10A106MP8NNNC (X5R, 10V)

22uF 0603 Capacitor - CL10A226MP8NUNE  (X5R, 10V)

47uF 0603 Capacitor - GRM188R60J476ME15D (X5R, 6.3V)

2.2uH 0805 Inductor - WCLA2012V1-222-R

5. PCB Layout

Okay, so I have managed to lay it out with just 2 layers, which is great... except I realised right at the end that I hadn't flipped the module footprint to the rear, which is what you have to do if you want the components to go on in the cut-out in the module recepticle.

It shouldn't be too hard to flip it, but I will have to switch the pin assignments from left to right, and vice-versa -- which means that the pin that is opposite the key pin will have to be re-routed. I hope I won't have to do much to sort that out. It's only the GPIO1 pin, which I can see will be easy to sort out.

Oh, except that I also have to re-route the VBAT and GND pins.  GND is easy, but VBAT might cause me some problems. Well, unexpectedly the routing ended up being simpler.

This is what the board looks like now:

As usual, I've added the values for all parts, so that if field repair is required, it can be done.

6. Requirements Verification

Here's our requirement again:

Requirement 3.2.1: Audio CODEC or equivalent that has output channels for loud speaker (mono is ok), 3.5mm audio output (stereo) ear piece, and input channel for 3.5mm microphone.

We have stereo internal speaker outputs, as well as headset output and input for microphone, so we have everything we need.

7. Milestone Mapping

Together with the blog post detailing the MEMS Microphone module, this satisfies:

2.5.2 Internal microphone and speaker module : Schematic

2.5.3 Internal microphone and speaker module :PCB Layout

 The source is, as usual here: https://github.com/gardners/megaphone-r5-modular/tree/main/modules

MEGAphone Home SMD Assembly Options

While the modularisation of the MEGAphone makes it easier to assemble and test the device, it doesn't completely do away with the need for surface mount (SMD) soldering.

So let's explore some ways that we can help to make that more approachable at home, or in austere environments.

There are five approaches that can be considered (let me know if you think of others in the comments, and I'll update the post):

1. Phone a Friend!

The first option is, quite simply, to find someone else who knows how to do it, and is willing to do it for you!

Pros: No new skills or equipment required.

Cons: They might not be available or willing for all sorts of reasons.

2. Online PCB Assembly service

The next option is to pay some online service to make batches of modules. This is particularly effective if you want to make a bunch of units for yourself or a group.  You could even make a kind of syndicate where each person orders a few types of modules in larger quantity, and have them all arrive at one person's address, who then makes up kits of the sets of modules you need, and distributes them to everyone.

Pros: No new skills or equipment required.

Cons: More expensive. Requires some scales of economy to be cost-effective. Involves logistics and probably international shipping etc to be working in your location.

3. Hand-Soldering

You can of course still hand-solder, but this can be quite fiddly for some component types, and almost impossible for others, e.g., ball-grid arrays. Whether that ends up being a problem is yet to be seen, based on the component choices I am able to make, but there is a significant risk of at least one component somewhere being like that. Currently the high-current DC:DC converter falls in this category.

Pros: Cheap and simple tools.

Cons: Requires considerable skills and increased risk of things going wrong. Also some components are just not feasible to reflow this way.

4. Hot-Air Reflow

Or you can use a hot-air gun or hot-air reflow station. I find this method to be quite fiddly and difficult to accurately control the heat. Also, you can blow components away, or scorch things due to the focused application of heat at very high temperature.

Pros: Relatively cheap equipment.

Cons: Hard to get right. Easy to scorch things.

5. Reflow Oven (Commercial or DIY)

Then there are reflow ovens, such as the cheap T-962 units, that with a little adjustment, perform okay. They are quite physically large, however. Also, if you use a T-962, you probably also want to replace the controller with a sensible after market one, which cost about as much as the T962 unit itself! The combination will cost you about 600 - 800€. Or you can buy one pre-modified for about 1,200€ plus postage, which to Australia is probably another 200€ - 300€. Then also import duties etc.

Also, it looks like the T962C works fine out of the box, but is a bit larger. For me, it also has the advantage that the top stays cool, so if the cat gets into the shed etc, it won't be a big problem. I can probably also stack it under some of my other tools. The trade-off, is that it vents through the bottom, which is not great for whatever bench you have underneath, nor for efficient extraction of fumes from the workshop. These are about 600€, or more like 900€ by the time they get down here to Australia. This is still enough to trigger import duties.

Pros: Does a great job.

Cons: Relative expense and size.

6. Hotplate (Commercial, DIY or improvised)

Finally there are soldering hotplates, varying from quite small commercial units with ~5cm x 5cm plates, through to bigger ones with more like 15x15cm plates. The commercial ones don't tend to do reflow curves, but rather just heat to a constant temperature, which is a bit of an issue. Also, the larger ones especially, have high thermal mass, which means that the time it takes to cycle it cool again ready to handle the next board(s) can be longer than you'd like. Also, the exposed hot top can be a risk for people or animals touching it (our cat tends to find ways into my workshop, for example).

There is an ingenious DIY version of this, which uses copper traces on a custom PCB to provide the heating. It does support temperature curves. What the lifetime of this approach is, is unknown, as it does involve heating the PCB it is made of itself each time, which will likely fail at some point.

Pros: Fairly easy and low-cost. Some are even just USB-C powered!

Cons: Larger ones are a bit more expensive, and hold heat for a long time, without a protective cover, making a bit of a safety issue.

7. Sand in a Fry-Pan

As it sounds, this is just putting some fine sand in a frying pan and heating it on your stove. It's cheap, and if you have fume extraction above your stove, sounds reasonable, provided the people you live with don't mind.  It's not perfect in terms of results, however. You can get a sense of the comparison of this with hot-air and a T962 reflow oven from Great Scott's video here:

Pros: Even cheaper alternative to hotplates. Most people have access to a pan and a heat source.

Cons: Fiddlier, and less reliable.

8. Decision

Okay, so now I need to make a decision -- or at least an initial decision.

I think initially I'm going to get one of the 5x5cm USB-C hotplates, as they are small and cheap, and feel like they would be a good option in an austere environment. Also, it's a technique that I feel that I could easily master, and that I have yet to try. 

Watching this video:

 

I found out about a hotplate that is only US$20 and that still seems to work. The postage to Australia is more than the unit itself!  

Anyway, I've ordered one, so that's that. I'll post again when it arrives, and let you know how it goes, when I have some PCBs arrive. I'll probably put a PCB order in next week or thereabouts, once I have enough of the module PCBs designed for the MEGAphone to make it worth the postage.

I'll work out what to do about low-temperature solder paste at the same time.

MEGAphone MEMS Microphone Module

Next up, I'm looking at the MEMS microphone modules. We want to be able to have more than one, so I'll route out the left-right select line that they usually have. 

1. Requirements Analysis

But first, let's look at the requirements that relate to this module:

Requirement 3.1.1: One or more power-switchable MEMS microphones with power status indication.
 

This should hopefully be a simple module, as I believe it can just have a MEMS microphone, with very few passives.

2. Selection of Key Component(s)

Let's look at a candidate microphone: SPH0690LM4H-1
These are about $2. Digikey's link to the datasheet is broken, though. But I found it here.

Unlike the ones I have used previously, this one is happy with 3.3V VCC, which is convenient.

Like most of these things, they use a simple 2-pin data protocol, with data on either rising or falling edge, based on a SELECT line, which allows 2 microphones to share a pair of lines. 

 

I'll expose that SELECT line, to allow selection to be made by the mainboard, possibly with a 100K pull-up resistor on the module, so that it will default to one or the other, even if the mainboard doesn't select.

Apart from that, I'll just need the decoupling caps (which must not contain type 2 dialectrics) and output resistor on the DATA lines, and optionally also on the CLOCK line, which should be safe to include on each module.

The datasheet includes no guidance on the R_TERM values, nor for the bypass capacitors, which is a bit annoying. Maybe I'll look at a different part, like a IM69D130V01XTSA1, whose datasheet has all the info nicely laid out:

So it looks like Infineon wins out, because their datasheet is better. Note that the actual interface is identical, which is good for allowing future substitution of parts.

3. Schematic

Let's make a schematic for it in KiCad:

I've also made the 2x5 module footprint with the extra pins removed, so that we have only the 5 we need, while still keeping it impossible to mis-orient, and have all the pads line up.

4. Part Selection

The final step is to pick out parts for the passives. The three resistors are simple, but we have that note about the capacitor not being allowed to have type 2 dialectrics. That excludes most 100nF SMD capacitors, leaving just three options with Digikey: the AC1206JKNPO9BN104 which is cheap, but out of stock, or for 10x the price, I can get the CC1206JKNPO9BN104. Both are 1206, so that makes it easy -- I'll just add a 1206 footprint for it.

Using 0603s for the resistors, it looks like we might just be able to get away with the 2x5 small module size, which would be nice:

It's just a whisker out of spec for the resistor pads, but given that the resistors will sit within the pads, rather than right to the edges of them, it should probably be ok... Assuming I can route the nets... which I can.

5. PCB Layout

Oh, it turns out the footprints hadn't updated from 0805s to 0603s. With that done, I can get it to fit properly:

You really do get the idea of just how small this module has ended up. It's only 10x13mm, after all.

6. Bill of Materials

IM69D130V01XTSA1 - MEMS microphone

AC1206JKNPO9BN104 (if available, if not substitute with CC1206JKNPO9BN104) - capacitor

RK73H1JTTD1002F - 100 Ohm 0603 SMD resistor

ERJ-3EKF1003V - 100K Ohm 0603 SMD resistor

7. Review

So I think that's it for the module. Let's double-check with the requirement it has to satisfy:

Requirement 3.1.1: One or more power-switchable MEMS microphones with power status indication.

The only thing not on the module is power status indication, which we will put on the carrier board. 

This also gets us half-way through the schematic and PCB layout milestones for 2.5.1 Internal microphone and Speaker Module.  I'll work on the speaker module next, so that I can close those milestones out.  The actual driver for the speaker will be on a separate module that will use a standard cellular phone "audio codec" IC, and have the pads for the internal speaker. I'll tackle that in a separate post, though.

MEGAphone 2A DC:DC Converter Module Design

Okay, now that we have the overall design of the MEGAphone laid out, we can start drilling down into the individual modules.  We'll start with the first one on the list: 

High-efficiency DC:DC converter

1. Requirements Analysis

But start with the requirement list for this module, which is pretty straight-forward:

Requirement 1.4.1: High-efficiency DC switchable DC power supplies that can support various sub-systems with >=2A @ 3.3V or 5V (externally selectable), with an efficiency of at least 90% in typical conditions when powered from a single cell LiFEPO4 battery (28.V - 3.2V).

So it must be:

1. Switchable (ie we can turn it on and off)

2. >=2A @ 3.3V or 5V

3. Externally selectable between 3.3V and 5V output.

4. Efficiency >= 90% in typical conditions

5. Can be powered from a single LiFEPO4 battery (2.8V -- 3.2V typical range, but can be up to 3.7V fully charged).

2. Selection of Key Component(s)

Looking at my previous blog post, I've suggested to myself that the following part is likely to be a good option, specifically the ISL91127IRAZ, which is adjustable voltage:

https://www.renesas.com/en/document/dst/isl91127ir-datasheet

As the goal here is for an MVP, we are less fussed with whether this will be the absolute best/cheapest/most efficient part, and more concerned about making a working module as quickly as possible.  They are about US$7 each singly, which is not fantastic, but we'll live with it for now.

Here's their typical application schematic for the variable voltage output, which is the one we want:

The efficiency curve with 3.3V input looks good. It will be a bit worse with lower voltage, but overall it looks good, only dropping below 90% for very low or very high current draws, in particular at lower input voltages. But given that we have a working input voltage range of ~2.6V to 3.6V, this keeps us in the >=90% efficiency zone.

It has an EN pin to enable/disable it, which meets sub-requirement 1.

The datasheet indicates 2A output, which meets sub-requirement 2.

The variable-voltage mode supports output voltages from 1V to 5.2V, which meets sub-requirement 3.

The efficiency is >=90% across the working input voltage range, which meets sub-requirement 4.

So the input range is fine, which meets sub-requirement 5.

In short, we are now satisfied that this part meets the requirements.

3. Module Design: Module External Interfaces

A module hosting this unit will require the following external interfaces:

1. GND plane as input.

2. V_BAT as input.

3. EN line as control signal (V_BAT vs 0V).

4. Output voltage select line (tie to GND for 3.3V, leave floating for 5V)

5. V_OUT

So not many pins.  

4 Module Design: Voltage Selection Logic

I'm designing this, so that I can avoid the need to populate a resistor on the carrier board. My goal is to have a common R1 for both voltages, and then an R2 connected to each of the 3.3V and 5V select lines. The carrier board then ties the desired voltage to GND, and leaves the other select pin floating.  The other alternative is to have one of them always connected to GND, and then have a single voltage select pin that connects another resistor in parallel to the other, causing the alternate voltage to be selected.

Having one voltage selection resistor always active should prevent the situation where the feedback line can go open-circuit, which might result in a higher voltage being output.

In terms of resistor selection for this, let's see what the datasheet has to say about the typical resistor values. I'm assuming fairly high values, so that we don't waste too much energy. This is reinforced by their advice here:

When designing a PCB, include a GND guard band around the
feedback resistor network to reduce noise and improve accuracy
and stability. Resistors R1 and R2 should be positioned close to
the FB pin.

This suggests to me that this circuit will be quite high-impedence, and thus prone to noise.

For 5V output, our waste current will be 5V / (R1+R2), so to keep waste current below 1mA, we would need R1+R5 >= 5K. That feels very comfortable. Having them around 50K would get us down to 100 micro Amps, which is even better, without going to crazy impedance levels. But we could even go a decade higher, given the datasheet talks about R1=1Mohm. So let's aim for around there.

Now let's look at the difference in resistor ratio that we need for 3.3V vs 5V, to see if we can't use the same value resistor for everything here, to simplify the BoM.

So the equation to solve for is VOUT = 0.8 * (1 + R1/R2).

To get 3.3V we need 1+R1 / R2 = 4.125 and for 5V we need 6.25. Remove the 1 term, and those reduce to 3.125 and 5.25.  Now, those aren't too crazy fractions, but just annoying enough that having arrays of identical value resistors would be a pain. 

So let's fall back to working out some resistor value ratios that would allow us to have an R2A that is always tied to GND, and an R2B that is tied to GND only when you want 3.3V.

So R2A = R1 / 5.25, which is the easy part. R2B isn't too hard, but we have to use the parallel resistor equation: R2 = 1 / ( 1/R2A + 1/R2B). I could try to solve this numerically, but it's easier to just whack it into a spreadsheet, and fiddle with the numbers until they are right.

Ratios of R1 : R2A : R2B = 29 : 9 : 14 yields output voltages of 3.38V and 5.03V, which feels reasonable.  So let's try putting some real resistor values in for these, and see how close to ideal voltages we can get.

R1 : R2A : R2B  = 291000 : 92000 : 138000  looks pretty good, with output voltages of 3.33V and 5.02V.

What's also nice about this from a failure mode perspective, is if the R2B ground strap fails, then R2 increases, which decreases the R1/R2 the ratio, which in turn decreases the voltage. That is, a dry joint or failure in this manner results in the safer option of the voltage dropping, rather than increasing.

Let's now look at the other passives:

C1 is a fixed 10 uF X5R type, with the recommendation to have two of them.

C2 is a fixed 22uF X5R type, again with the recommendation to have two of them. 

C3 is more interesting: It's recommended at 56pF for R1=1M Ohm. This kind of feedback circuit is not something I'm super familiar with, but some chatting with ChatGPT suggests that C3 should be proportional to the inverse of R1. So if we are going to use R1=291K, then C3 should be 56pF x (1M / 291K) = 192pF, NPO type.

L1 should be 1uH, >=4A saturation current.

5. Module Design: Part Selection

Let's look at some possible part numbers for these:

C1 - CL21A106KOQNNNG. Also massively stocked. 0805 SMD, which is fine. They are plausibly hand-solderable, but given the DC:DC converter IC with its thermal pad on the underside are a bastard to hand-solder, this is one of the modules I'm expecting to get PCBWay or someone to assemble for me.

C2 - CL21A226KOQNNNG. Same series and size, just a different value.

C3 - CC0805JRNPO9BN201. 200pF, because 192pF doesn't seem to be a standard value. NPO temperature curve, 0805 package.

L1 - DFE252012P-1R0M=P2. Stocked by the mega-tonne at Digikey, and ~US$0.30 each, have 4A saturation current, and reasonably low DCR, and acceptable 20% tolerance.

R1 - RN73R1JTTD2913F100. 1% tolerance, which should be enough. It's an 0603, which is a bit fiddlier if you had to hand solder it, but there are no 0805 series in stock at the moment.

R2A - RC0603FR-0791KL. 1% tolerance, but 91K, rather than 92K (turns out 92K is not a real size, after all). This increases the output voltages to 3.36V and 5.05V, which is acceptable.

R3A -  RK73H1JTTD1403F 1% tolerance 140K. This brings the 5V output back to 5.01V.

Okay, so that looks like all the parts.

In terms of planning the module dimensions, the IC is ~3-4mm on each edge, and there will need to be 9 passives on there as well, that are ~2x1.25mm for most of them. So the module itself should be able to be quite small in the end. What's also nice, is that all of the components selected are <1.6mm high, and thus should be able to sit in the cut-out of the castellated module without requiring any extra spacing. I'll have to leave that GND buffer around the resistor network as well, which might push things out a bit.

Also, I'm expecting that this module will need to be 4-layer, so that there can be a good ground pad for thermal conduction, as at ~90% efficiency and 2A @ 5V = 10W implies that the DC:DC converter can be dumping as much as 1W as heat, and that needs somewhere to go.  It's actually the aspect of this module that worries me the most. But with the strong thermal bonding of the castellated module concept, I'm fairly confident that it will be fine: a short 2.5mm track and solder wick jumper is the only interruption between the ground plane of the module and the ground plane of the carrier board, which will have more than enough thermal capacity to dump that heat.

6. Schematic Design

Okey dokey -- we are now all set to actually design the schematic of this thing.

The passives won't be a problem for KiCad, but as is often the case, the main IC that I need isn't in KiCad's default library, so it's off to SnapEDA to find a footprint and symbol.  There is a footprint, but not a symbol, so I'll have to make the symbol. Here's the pinout from the datasheet:

 

And here's my symbol I've cooked up in the KiCad Symbol editor:

 

Looks like I've got all the pins right. Good. So let's hook up the reference circuit, but with our feedback circuit using R2A and R2B, and add in the various other things we need here:

There aren't too many surprises here. The only thing I've gone and added is a jumper to force 5V output, if for some reason someone wanted to have that. 

So now I guess I need to see how small an area I can layout the PCB, so that I know which size castellated module to use. I'll allow a bit of spare space, so that if the IC has to be swapped for another, it's not a disaster.  Here's my first go, without worrying about the GND or VBAT signals that will be routed via internal layers:

So about 13.5 x 23.5mm. But the cut-out in the module can be a bit smaller, as it only needs to allow all the components to fit together. We will need five of these, so I'm inclined to make them as relatively small as I can get away with.

I've just looked at the module footprint sizes I've specified, and they are all too small right now to accommodate this module, so I'll have to make bigger ones.  I actually need to update them anyway, to fix the minor issues / potential improvements I identified in a previous blog post.  So I guess I'll start on that. This means that the DC:DC module will have way more pads than it needs. 

I might purposely under-populate the pins to make soldering/desoldering easier, as well as making it obvious which module goes where -- I fully intend for each module type to have uniquely keyed pin combinations, so that they can't be put in the wrong place without you noticing. This also makes grass-roots assembly much easier, by reducing the number of things you need to look up or know while assembling or repairing.

Most likely it will need to be a 22-pin module to get the necessary length, but not actually any wider than the wide module footprint I have already specified. In fact, they could be a few mm narrower, if necessary. But as mentioned above, we'll keep a bit of spare space, to allow for easier part substitution.

This is what I have so far:

We only need 6 pins, but I've left at least two near each corner, to provide ample strength to hold the module in place.  The marked dimensions of the hole are sufficient. So now I need to make the schematic symbol for this. I'll just do one version with all 22 pins for now, as I think it's possible to use a footprint with missing pins, if none of them are connected.  If not, then I'll make versions of the symbol as well.

As I'm going to have quite a few possible variants of these larger modules by deleting one or more pins, I've made an identification scheme for the footprints, where -M<hex string> indicates that only some pins are present, with 1s in the hex string corresponding to pins present.  For ease of reading the hex, the first hex digits corresponds to pins 1 to 4, with the most significant bit first. So the pattern above is -MA0780C.

Okay, it complains about the missing pads, but still works. Here is what I have so far:

I need to make the board 4-layer and add the VBAT and GND planes, and then in theory, it should be all good. Actually, I think I can keep it 2-layer, with the rear of the board being almost exclusively a GND plane fill, as there is no need for any power planes. 

Going through with that, and I've hit an interesting Design Rule Check violation for the footprint for the IC:

A bit of searching found this post about this issue. It looks like for fine-pitched SMD parts you are basically guaranteed to get this violation, and the remedy is to tell the footprint properties that it's okay.

I'm also seeing DRC violations for the castellated pads.  Apparently the right way to do these is to let the copper go outside the edge cuts.

Okay, after sorting those out, I have it looking nice now:

As I described above, my goal here isn't to make the circuit as dense as (in)humanly possible, but rather leave some space for reworked future versions. I also want to make it possible to hand-solder if you have to. I've also added the values of the passives on the rear, to make it easier to maintain in the field, if you had to. Sure, you can stick a multi-meter on a component and try to figure it out -- but so much the easier if you can just look on the back and see what it should be...

But you can also see that I've put URL info and the name of the module on silk-screen on both sides, as well as the revision of the module. This is to make it easier to pick up the right thing, and know whether you can use it.

And the schematic:

So I think this one's ready for sending off for fabrication as soon as someone can do a quick review of the schematic for me, to make sure I haven't done anything stupid.

The KiCad project is here:

https://github.com/gardners/megaphone-r5-modular/tree/main/modules/high-efficiency_dc-dc_converter

Anyone who has feedback can comment on this post, or better yet, file an issue against the repository, even if the feedback is that you don't see any problems, as that's useful information for me, too.