Now before you start asking yourself “best for what purpose?”, just have a look at the quality of the DIY PCB in the image above. [ForOurGood] is getting higher resolution on the silkscreen than we’ve seen in production boards. Heck, he’s got silkscreen and soldermask at all on a DIY board, so it’s definitely better than what we’re producing at home.

The cost here is mostly time and complexity. This video demonstrating the method is almost three hours long, so you’re absolutely going to want to skip around, and we’ve got some relevant timestamps for you. The main tools required are a cheap 3018-style CNC mill with both a drill and a diode laser head, and a number of UV curing resins, a heat plate, and some etchant.

[ForOurGood] first cleans and covers the entire board with soldermask. A clever recurring theme here is the use of silkscreens and a squeegee to spread the layer uniformly. After that, a laser removes the mask and he etches the board. He then applies another layer of UV soldermask and a UV-curing silkscreen ink. This is baked, selectively exposed with the laser head again, and then he cleans the unexposed bits off.

In the last steps, the laser clears out the copper of the second soldermask layer, and the holes are drilled. An alignment jig makes sure that the drill holes go in exactly the right place when swapping between laser and drill toolheads – it’s been all laser up to now. He does a final swap back to the laser to etch additional informational layers on the back of the board, and creates a solder stencil to boot.

This is hands-down the most complete DIY PCB manufacturing process we’ve seen, and the results speak for themselves. We would cut about half of the corners here ourselves. Heck, if you do single-sided SMT boards, you could probably get away with just the first soldermask, laser clearing, and etching step, which would remove most of the heavy registration requirements and about 2/3 of the time. But if it really needs to look more professional than the professionals, this video demonstrates how you can get there in your own home, on a surprisingly reasonable budget.

This puts even our best toner transfer attempts to shame. We’re ordering UV cure soldermask right now.

[Simon B] enters our 2024 Business Card Challenge with BAUDI/O, a genuinely useful audio output device. The device is based around the PCM2706 DAC, which handles all the USB interfacing and audio stack for you, needing only a reference crystal and the usual sprinkling of passives. This isn’t just a DAC board, though; it’s more of an audio experimentation tool with two microcontrollers to play with.

The first ATTiny AT1614 is hooked up to a simple LED vu-meter, and the second is connected to the onboard AD5252 digipot, which together allows one to custom program the response to the digital inputs to suit the user. The power supply is taken from the USB connection. A pair of ganged LM2663 charge-pump inverters allow inversion of the 5V rail to provide the necessary -5 V for the output amplifiers.  This is then fed to the LM4562-based CMoy-type headphone amplifier.  This design has a few extra stages, so with a bit of soldering, you can adjust the output filtering to suit. An LM1117 derives 3.3 V from the USB input to provide another power rail,  mostly for the DAC.

There’s not much more to say other than this is a nice, clean audio design, with everything broken out so you can tinker with it and get exactly the audio experience you want.

In Terminator 2: Judgment Day it’s revealed that Skynet becomes self-aware in August of 1997, and promptly launches a nuclear attack against Russia to draw humanity into a war which ultimately leaves the door open for the robots to take over. But as you might have noticed, we’re not currently engaged in a rebellion against advanced combat robots.

The later movies had to do some fiddling with the timeline to explain this discrepancy, but looking at this 2024 Business Card Challenge entry from [M. Bindhammer] we think there’s another explanation for the Judgement Day holdup — so long as the terminators are rocking 555 timers in their chrome skulls, we should be safe.

While the classic timer chip might not be any good for plotting world domination, it sure does make for a great way to illuminate this slick piece of PCB art when it’s plugged into a USB port. Exposed copper and red paint are used to recreate the T-800’s “Brain Chip” as it appeared in Terminator 2, so even when the board isn’t powered up, it looks fantastic on display. The handful of components are around the back side, which is a natural place to put some info about the designer. Remember, this is technically supposed to be a Business Card, after all.

This build is a great example of several badge art techniques, which we think is worthy of a closer look even if you’re not personally into the Terminator franchise. While it’s far from the most technologically advanced of the entries we’ve seen so far, it does deliver on a design element which is particularly tricky to nail down — it’s actually cheap enough that you could conceivably hand it out as a real business card without softly weeping afterwards.

Remember, you’ve still got until July 2nd to enter your own creation into the 2024 Business Card Challenge. So long as the gadget is about the same size and shape as a traditional card, it’s fair game. Bonus points if you remember to put your name and contact info on there someplace…

Our PCBs greatly benefit from cases – what’s with all the pins that can be accidentally shorted, connectors that stick out of the outline, and cables pulling the board into different directions. Designing a case for your PCB might feel like a fair bit of effort – but it likely isn’t, thanks to projects like turbocase from [Martijn Braam].

This script generates simple and elegant OpenSCAD cases for your KiCad PCBs – you only need to draw a few extra lines in the PCB Editor, that’s it. It makes connector openings, too – add a “Height” property to your connector footprints to have them be handled automatically. Oh, and there’s a few quality-of-life features – if your project has mounting holes, the script will add threaded-insert-friendly standoffs to the case; yet another argument for adding mounting holes to your boards, in case you needed more.

Installing the script is a single line, running it is merely another, and that will cover an overwhelming majority of boards out there; the code is all open too, of course. Want some more customization? Here’s some general project enclosure tutorials for OpenSCAD, and a KiCad-friendly StepUp tutorial. Oh, and of course, there’s many more ways to enclose PCBs – our own [Bob Baddeley] has written a guide to project enclosures that you are bound to learn new things from.

We thank [adistuder] for sharing this with us!

[Carl Bugeja] finds the engineering behind the Las Vegas Sphere fascinating, and made a video all about the experience of designing and building a micro-sized desktop version. [Carl]’s version is about the size of a baseball and crams nearly a thousand RGB pixels across the surface.

Putting that many addressable LEDs — even tiny 1 mm x 1 mm ones — across a rounded surface isn’t exactly trivial. [Carl]’s favored approach ended up relying on a flexible four-layer PCB and using clever design and math to lay out an unusual panel shape which covers a small 3D printed geodesic dome.

Much easier said that done, by the way. All kinds of things can and do go wrong, from an un-fixable short in the first version to adhesive and durability issues in later prototypes. In the end, however, it’s a success. Powered over USB-C, his mini “sphere” can display a variety of patterns and reactive emojis.

As elegant and impressive as the engineering is in this dense little display, [Carl] has some mixed feelings about the results. 945 individual pixels on such a small object is a lot, but it also ends up being fairly low-resolution in the end. It isn’t very good at displaying sharp lines or borders, so any familiar shapes (like circles or eyes) come out kind of ragged. It’s also expensive. The tiny LEDs may be only about 5 cents each, but when one needs nearly a thousand of them for one prototype that adds up quickly. The whole bill of materials comes out to roughly $250 USD after adding up the components, PCB, controller, and mechanical parts. It’s certainly a wildly different build than its distant cousin, the RGB cube.

Still, it’s an awfully slick little build. [Carl] doubts there’s much value in pursuing the idea further, but there are plenty of great images and clips from the build. Check out the video, embedded below.

Today is another board from a friend, [treble], who wants to convert a Yaesu FRG7700 radio to USB-C PD power. It’s yet another review that I’ve done privately, and then realized I’ve made more than enough changes to it, to the point that others could learn from this review quite a bit. With our hacker’s consent, I’m now sharing these things with you all, so that we can improve our boards further and further.

This board’s idea is thought-out and executed well – it replaces a bespoke barrel jack assembly, and is mechanically designed to fit the screw holes and the free space inside the chassis. For USB-PD, it uses a CH32V003 coupled with FUSB302 – I definitely did help pick the latter! For mechanical reasons, this board is split into two parts – one has the USB-C port, whereas the other has the MCU and the PD PHY.

In short, this board is a PD trigger. Unlike the usual PD triggers, however, this one is fully configurable, since it has a 32-bit MCU with good software support, plus, the PD PHY is also well known and easily controllable. So, if you want special behavior like charger-power-dependent profile selection for powering a static resistance load, you can implement it easily – or, say, you can do PPS for variable voltage or even lithium ion battery charging! With a bit of extra code, you could even do EPR (28 V = 140 W power) with this board, instantly making it into a pretty advanced PD trigger, beyond the ones available on the market.

Also, the board has some PCB art, and a very handy filter to get some of the USB-C charger noise out. Let’s take a look at all of these!

Current Flow Improvements

First of all, the back of the PCB has art. This is a problem. Specifically, the art has to be bigger. See, fabs might struggle drawing thin silkscreen lines. So, I will take the liberty of enlarging it. This board is 25×25 mm in size, after all. Due to the way KiCad works, I’ve had to ask for the original .svg file from [treble] for that. Here’s a tip that I myself should follow more, if you’re adding PCB art, storing its sources alongside the board is pretty valuable for whenever it might need to be regenerated or modified!

This board is seriously nice. It has thick traces for power, and, it makes liberal use of filled zones for higher-current tracks, too! It’s not often that I see these fills used, even for higher-power areas, and truth be told, I get lazy to draw them, but they are possibly the cleanest choice for a board that fulfills a power-related purpose. Also, as usual, it’s just two layers, something dear to my heart.

Now, let’s take a good look at the two layers we have. This is a board that current is supposed to flow through, and if you have an eye for it, you might notice that it will be impeded more than you’d want it to be, in ways that are easy to fix.

Take a look at the board’s bottom layer. It has a ground plane, yes, but there are also tracks going all across it. If you try and visualize the way that ground return current could flow across the board, you might realize that it has to go through a few small slivers of copper; this is despite the ground fill being present on both sides. Let’s fix this.

Here are three spots where you could straightforwardly add ground connectivity purely by moving vias. I usually look out for such spots as part of my after-design cleanup routine – something I might spend a good half an hour on; just, idly glancing at the board in the 3D viewer, looking here and there, trying to notice any things I could improve upon. Here, if you wanted a high return on your investment, you could move these vias and gain whole two new paths for ground return current to flow through.

Moving tracks around will yield way bigger returns for freeing up some ground area. For a start, the SWIO pin, wittily wired up to an SBU pin on the USB-C connector with the trace snaking between the 2.54 mm header pads, doesn’t have to go on B.Cu at all. The VBUS connection of the FUSB302 could also be moved to the left edge, all around the 2.54 mm connector, so that it doesn’t have to cut the ground polygon in half. Furthermore, we could improve upon USB diffpair routing by rotating the CH32V003 90 degrees clockwise, and having the pairs go back onto the front layer again at the top. Part of the 3.3 V track could be routed on the top if you rotate a resistor 180 degrees, and voila, we now have a healthy and plentiful ground polygon.

“Route as much of your board on a single layer as humanly possible” is still a great guideline, and it helps here, too. It also helps if you look at your board and visualize the way that ground return current will flow, from one side to the other, all along the signals.

Only a few small details are left. The ICs don’t have decoupling caps on their 3.3 V inputs, and we could easily add them – cleaner power is always a plus. Oh, and the linear regulator could use a couple more vias from its GND pin – purely for the heat dissipation potential. There’s a 1.5 K resistor used for a USB pull-up, and I2C uses 3.3 K pullups in the same package – I’ve changed them to use 1.5 K too, just as a BOM optimization reminder; should work wonders for I2C.

Implementation Details And Polish

Something I don’t expect hackers to know but is nice to keep in mind – the VBUS pin of the FUSB302 is fault-prone and PSU noise on it can cause the FUSB to die in a way that short-circuits the 3.3 V rail, to the point that the Pinecil soldering iron eventually disconnected it in a new hardware revision, and the community has developed guides to disconnect the VBUS pin. Furthermore, the VBUS connection on the FUSB is not even needed for any part of the PD process; essentially, it’s not even a nice-to-have, all you get is an interrupt that doesn’t carry any meaning in our “bus-powered” arrangement. Let’s disconnect it – that frees up quite a bit of ground and routing space around the FUSB302.

Now, adding a 1:10 resistor divider to an ADC-capable CH32V003 pin would be worthwhile – this lets us measure the voltage we get, checking that it’s indeed the voltage we need. FUSB has provisions to measure voltage on its VBUS pin, but they’re bothersome to use, using an on-MCU ADC is way easier. I’ve also added a 3.6 V Zener diode in 0805 package, clamping the voltage that reaches the GPIO – I don’t expect it to actually be needed, but we do have space for it, and it protects the MCU’s GPIO in case of any assembly errors or voltage spikes; I have previously mis-placed a resistor at a voltage divider, and now I’m worried about others doing it. Worst case, the Zener doesn’t have to be placed at all, and you can just add a capacitor there, smoothing the divided voltage before it reaches the ADC.

What else? Here’s something to consider – the radio might not be happy with 5 volts on its power input, which is an inevitability given how the USB-C negotiation process works. Remember, first, you get 5 V, and then you have to negotiate further up. This is why PD trigger ICs tend have a PG pin, that you can connect to a P-FET gate, and that pin is only driven after a successful negotiation. In our case, we have MCU GPIOs we can use instead!

For that to work, let’s rewire the VBUS on this board. The MCU and its 3.3 V linear regulator can be powered from the raw USB-C input, we won’t gate them with the FET, of course, that’d lead to a chicken and egg problem. It makes sense to power the Pi filter through the FET, though – mostly because we have some board space between the USB-C input and the Pi filter, where a SOT-23 FET could very nicely fit. The radio could consume as much as 3 A at 12 V; at least, that’d be the maximum capability of a typical USB-C PSU you could use with this board. My FET of choice, then, is AO3401 – a classic FET that works at 30 V 4 A, and will even let this board be a pretty generic trigger board if needed, and; higher current, you can stack one more SOT23 FET on top.

With an NPN driver and a provisional 3:1 divider for the gate voltage, the “power good” circuit fits into the board space wonderfully. If it’s not needed, it can be easily jumpered with a 0 R resistor across the FET pads, but adding this circuit retrospectively would be bothersome – it helps that we have the footprints for it. Remember, traces and footprints are free to add, fundamentally – just like silkscreen markings.

How Will You Use Your Board?

Another great thing to visualize is – after you assemble your board, how will you interact with it? Here, [treble] still has to write the USB-PD firmware – in C++, no less, my MicroPython stack won’t be directly applicable, as much as I will help, but [Ralim]’s open-source PD stack used in the Pinecil could work wonderfully! While integrating that, she will have to debug things. Possibly, might even have to debug it some more later on, with the board installed into the radio chassis. It’s a project one hacker could pull off without a doubt, and, there’s things you could add to your board that will help.

The SWIO pin of the CH32V003 goes to an SBU pin on the USB-C socket. This is a great decision, because you can easily reflash the MCU without disassembling the entire radio – just have a USB-C plug with SBU exposed and that’s enough. Also, when I’m thinking about it, it might be troublesome during active development, because [treble] will have to constantly unplug and plug the PSU and the programming plug while debugging the in-progress firmware. Now, she could solder to the 2.54 mm pin headers, sure – alternatively, you could add an extra SWIO header at the edge and make her job a bit easier. I can’t find much space for it, sadly, so I suppose a female header with longer male pins (Arduino and Wemos shield style) can do just as well, also allowing to probe CC pins as a bonus.

I feel like there’s a good few more things you can add to improve development and usage comfort. Will there be a failure mode where the board has to signal to the user that something’s gone wrong – say, with a 5 V USB-C PSU inserted? Let’s add two LEDs on one pin – could even do WS2812 sometime later. What about I2C communications, what if tapping them would be useful during the board’s development? Let’s add a QWIIC socket and pull the I2C lines onto it – not for expansions, but rather, so that you have a socket you can easily wire up to a logic analyzer, plug it in and unplug it at any point.

There’s some arguments to be made for breaking out as many CH32V003 pins as possible. I will refrain from it, as much as it’s tempting – at this point, there isn’t a lot of board space in the spots where it matters. It would be cool to have them on testpoints though! Speaking about that, I’ve just realized – you could add a tiny SMD three-position DIP switch onto the back of the board reasonably easily, so that you can have “profiles” for the trigger board, CH224 PD trigger board style. I’ve found the tiniest three-position SMD DIP switch that LCSC has, then added it to the back of the board, trying to still have the ground fill as intact as possible – the idea is that this is a nice feature for whenever the board might be used as a more general-purpose trigger board. When not populated, it serves as a breakout for three ADC-capable GPIOs, GND, and 3.3 V!

Now, I’d like to emphasize: the DIP switch is not exactly necessary in this project. It falls into “something that’d be cool to fit in space left over, if the board is to be used in an entirely different setting”. Overall, I try not to push features this remote onto people while doing design review – plus, it does clash with the silkscreen. So, this addition is easily removable from the PCB files, and it doesn’t have to be populated either. Also, I’ll stop the additions here, to avoid feature creep.

That about wraps it up for things I feel like this board needs. Let’s talk about an aspect where I’d like your opinion.

Questions For The Audience

Now, here’s a question for the audience, on two things I’m not well-versed on. First one is – here’s a Pi filter. The purpose is filtering out 300 KHz USB-C charger switching frequency that [treble] has noticed being produced by a USB-C charger she’s picked. Having simulated this filter in LTSpice, it appears to be good for filtering out 200 KHz and above. Does that look correct? And, any things she should look out for when it comes to component choices?

Another question is – the ground cutout under the Pi filter. My understanding is – the more ground, all over the board, the better. [treble] decided to remove ground under the Pi filter, as far as I recall, due to a gut feeling that it’d decrease noise imposed by the inductor. Does that make sense? I’m tempted to say “no”, but I can’t formulate a good enough explanation on the specific downsides and how it might need, which is why I’m asking you.

Another board reviewed, and due to the way it’s built, I can easily imagine ordering a dozen for use in my own projects – thanks to [treble] for sharing this, and I hope this feedback helps! As usual, if you would like a design review for your board, submit a tip to us with [design review] in the title, linking to your board files. KiCad design files strongly preferred, both repository-stored files (GitHub/GitLab/etc) and shady Google Drive/Dropbox/etc .zip links are accepted.

I thank [Julianna] for helping me check the the CH32V003 circuit!

What’s solder for, anyway? It’s just the stuff that sticks the parts to the PCB. If you’re rapid prototyping, possibly with expensive components, and want to be able to remove chips from the board easily when you spin up the next iteration, it would be great if you didn’t have to de-solder them to move on. If only you could hold the parts without the solder…

That’s exactly the goal behind [Zeyu Yan] et al’s SolderlessPCB, which uses custom 3D printed plastic covers to do the holding. And it has the knock-on benefit of serving as a simple case.

In their paper, they document some clever topologies to make sure that the parts are held down firmly to the board, with the majority of the force coming from screws. We especially like the little hold-down wings for use with SMD capacitors or resistors, although we could absolutely see saving the technique exclusively for the more high value components to simplify design work on the 3DP frame. Still, with the ability to automatically generate 3D models of the board, parts included, this should be something that can be automated away.

The group is doing this with SLA 3D printing, and we imagine that the resolution is important. You could try it with an FDM printer, though. Let us know if you do!

This is the same research group that is responsible for the laser-cut sheet-PCB origami. There’s clearly some creative thinking going on over there.

Publishing your boards on GitHub or GitLab is a must, and leads to wonderful outcomes in the hacker world. On their own, however, your board files might have the repo look a bit barren; having a picture or two in the README is the best. Making them yourself takes time – what if you could have it happen automatically? Enter [kicad-render], a GitHub&GitLab integration for rendering your KiCad projects by [linalinn].

This integration makes your board pictures, top and bottom view, generated on every push into the repo – just embed two image links into your README.md. This integration is made possible thanks to the new option in KiCad 8’s kicad-cli – board image generation, and [linalinn]’s code makes KiCad run on GitHub/GitLab servers.

For even more bling, you can enable an option to generate a GIF that rotates your board, in the style of that one [arturo182] demo – in fact, this integration’s GIF code was borrowed from that script! Got a repository with many boards in one? There’s an option you could make work for yourself, too.

All you need to do is to follow a couple of simple steps; [linalinn] has documented both the GitHub and GitLab integration. We’ve recently talked about KiCad integrations in more detail, if you’re wondering what else your repository could be doing!