KiCAD de no Bouken - 2022
I’ve been laying out my circuits in Photoshop and soldering on perfboard for quite some time now. It’s a time consuming process and it’s hard to keep track of which trace connects to what and whether it’s a correct representation of the circuit. Usually there are a few mistakes, though not difficult to correct by adding a wire or two to my one-off prototype.
As Aril turned to May I decided, quite on a whim, to learn KiCAD, design some PCBs and have them manufactured. How hard could it be? Not very hard at all, turns out. Now, KiCAD is a bit of a kludge UI-wise. It looks like a drawing program, but isn’t. Doing very basic graphical stuff can be quite time consuming. Different sub-programs and modes have different UIs, context menus and capabilities. Apparently the UI has been reworked in version 6, but I have to make do with V5.0.2-5 (dated 2018?) as that’s compatible with my El Capitan (10.11.5) Hackintosh.
Still, I find it very relaxing to lay a circuit out and solve it. It’s like a game, figuring out how to snake traces around efficiently, whilst also considering component adjacencies. It’s even more complicated for professionals who are constrained by trace pairs and lengths, signal interference, crosstalk and coupling. I’m not quite there yet.
Each component has a footprint, i.e. how it sits on the PCB, through holes or on the surface. There are a lot of components so finding the footprint design for the stuff you have in stock at home is tricky. Fortunately it’s not that hard to design your own in the footprint editor then add it to your custom library. Owning some calipers is of great help here as you need quite precise measurements.
You can also make your own graphical logos. These are limited to using the mono-tone silkscreen colour (not sure if actually silkscreen print nowadays). I don’t think I’ve seen anyone do dot/dither gradients using it. You can actually get a few more colours by manipulating the solder mask and copper layers, but there are limitations, like silk can’t go on copper, and copper designs will confuse the DRC and Zone fills. The silk layer is also imprecise and a bit blobby. The editor doesn’t quite directly support boolean operations, inverted silk text, or drawing in copper.
On actual PCB. Turns out that all copper gets tinned silver and becomes a little blobby. I might switch white and metal around here for the next revision.
The GUI colours can thankfully be changed by clicking the colours in the layers panel. Default is ZX Spectrum colours on black. I've lowered the contrast a bit. Here's a rotary encoder mouse. Many of the lines here are decorative and not in the functional PCB layer.
I made some custom complex pads for my keyboard. It's worth to note that if they connect to GND (mine don't here) they don’t get thermal relief to a GND plane because the program doesn’t have a way of knowing where to attach to. The workaround is just adding them manually. Thermal relief connection makes soldering stuff which connect to a big ground plane easier. Without, the GND copper mass will act as a heatsink. I found it helpful to use a GND zone fill to handle all of the GND connections, which I leave unconnected ’til last.
Once sort-of finished, a PCB design is converted to Gerber and Drill files which are uploaded to a PCB manufacturer. It’ll probably cost you some 20€ to have five small-ish PCBs made (barren) and shipped, so it’s not that expensive. If you have money but no time, it’s more efficient than hand-wiring or perfboard, especially for more complex designs.
Got the PCBs from JLCPCB. I paid 50€ total. Looked alright at a glance. When I soldered them up I discovered no circuit/logic errors. Having a schematic and design rules checker really helps. When making circuit by hand on perfboard, it's very easy to miss or mirror connections.
I did make one big mistake though. When plotting the gerbers (production files) I left [ ]Plot footprint values unchecked, as those are generally in the Fab layer. But I had moved some to the Silk layer, including all of the key/button names. So, all of my Silk work on e.g. the keyboard was for nought. Still, it's covered up by the key membrane and the silkscreen doesn't affect function.
Ardumite Rev.A
Naked PCBs. These "knoll". The F5 RGB LED pad holes are quite tightly spaced. The LED can sink actually through all the way though, past the "squeezed" bit on the legs, which mean technically I don't need a hole on the top module. The RGB LED needs tuned resistors on each channel. Probably 4K7-68K-10K for this particular model, as green is strong and red is weak. Kinda strange since green can be the weakest on other (older?) LEDs. Messed up the LED jumper header solder mask which should be RGB not BGR. I used green for power as it's more logical than red (error). Blue is kinda annoying to look at if always on. Obviously in an RGB led they mix when blinking so it's not really practical as an indicator, it just looks cool and the header can be tapped into by wires from any MCU pin.
The transistor pad holes suffer from the same issue as the many-legged RGB LED. It might be best to space these out a little in the future. Also, I think I'll replace footprint reference values (e.g. R12) with actual values.
This particular Barrel Jack footprint didn't quite match the one I had in stock, but good enough. The silkscreen expands a bit, eating my inverted text B and 13 on the LED jumper header. Otherwise my silkscreens seemingly worked here, including the tinned ARDUMITE text which I gave some margin that came out as an outline.
My first project was an Arduino type board, that is, a board for the Atmel ATMega328P which is used on the UNO boards. There are a number of reasons why one might not want to use use the UNO. First, the headers are misplaced on all large Arduino boards, so a regular perfboard won't fit on top, making them quite useless for projects beyond plopping a few wires in. Second, the UNO includes FTDI and power regulation, which is handy, but sometimes you don't want it there for various reasons, like power consumptions and drops. Third, on my version I've angled the FTDI,ICSP and reset button out to the side so they're accessible even with a perfboard/module/shield on top. Fourth, My LED is configurable via jumpers, so if you don't want any activity light you can easily disconnect it. I also use larger resistor values which makes it easier on the eye. It's an RGB LED, so blink demo code could be made a bit more fun. Fifth, from what I can tell, the analog side of the UNO might be prone to picking up noice and experience coupling as there's no inductor between VCC and AVCC, dedicated AVCC cap, AREF cap, or AGND plane considerations. I've added these features on my board as I'm probably doing high speed analog stuff. The back of the PCB has SMD cap pads much closer to the pins.
Apparently, ground planes are kinda like a surface which can be distorted. Digital signals aren't that sensitive to it, but if the ground plane has a bulge somewhere due to thumping digital traffic, this can offset nearby analog reads and show up in the decimals so to speak. It's worse if ground is snaking around in a linear fashion, rather than being a big lake. Digital traces and components encroaching on analog zones in general can cause problems. From what I understand, digital ground should be kind of like a second lake but significantly connected to the digital one. Like a suit fly? Digital return signals should not shortcut/trespass on analog ground. Well, I'll just have to see how my design fares.
Test fit on paper model. One can save as PDF, then print out a 1:1 drawing for test-fitting components. It's hard to tell on a zoomed display if something is the right scale.
It is much faster to upload using an USBasp, perhaps because it skips the bootloader. FTDI upload uses a bootloader so that stops working, though serial communication over FTDI will still work. It's possible to use the "Burn Bootloader" menu option to upload a new one over ICSP/USBasp (won't include your program code), and then FTDI uploads work again.
Here I'm using long-pin headers to adapt female to male. I have room for more header rows on the PCB, but they might not be necessary. Sidenote, turnpin sockets don't seem to hold ICs well, so next time I'll use the flat type.
Zakobon Rev.A
This is just a little ATTiny2313 breakout/dev board. I sketched it up a few years ago. I messed up the position of the ICSP header and decoupling cap, which should've been 0.1" aligned with the headers. Probably some missing Silk too.
Amiga Drawbridge & Input Lag Tester
Two projects in one. I mostly just wanted to make a top module/shield for my Ardumite. Note the button, jack, FTDI and ICSP stuff points out to the side and the LED is visible through a gloryhole of sorts. This module board can be either an Amiga Drawbridge or an Input Lag Tester (populating both will break it). The Drawbridge code and schematic was developed by Rob Smith. Basically it allows you to repurpose an old PC floppy drive to work as an Amiga FDD on a PC, with e.g. WinUAE. I didn't want to wire it up by hand so I just tucked it into a PCB for another project. My version has support for twisted cables, if it works that is.
Soldered the low/SMD components first. The 7-segs will work unsoldered if the pins are bent to create some tension against the PCB holes. It can use both Common Anode and Common Cathode displays as I added a 5V-COM-GND jumper. Here I put on a transistor backwards and the wrong caps but later noticed and fixed.
The Input Lag Tester checks the time elapse after joypad button signal, until visual change on screen. It's not immediate typical on modern systems. Modern displays sometimes lose a few frames doing image processing, like scaling. Modern OSes might also drop frames for mysterious reasons and there might be polling pipelines/hick-ups. Then there's the USB protocol which can operate at various speeds.
Back in the CRT days, the lag could be less than a frame if the player hit a button just before the frame redraw and the game updated position and drew the player character perhaps near the top scanlines. In practice though, Amiga games might update at half or a third of 50FPS PAL. However, scrolling (screen offset via pointer) might still update at 50FPS as it was a hardware feature.
The button detect is buffered via a transistor for safety reasons. I'm using an LDR rather than photodiode/transistor. An LDR is slower but I really only need to know when the car has started moving, not when it reached 100, so any value change from the LDR is a valid detection. There's some noice and risk of coupling, but I might have solved that on the PCB level. Benchmarks tell me that I can get a detection within less than 100 microseconds (a tenth of a millisecond), which is pretty good precision. By changing a prescaler, analog reads can go faster than the default 120 micros or so. Mine are 20-25 micros apart with no loss of precision. I ran into some coupling issues on a breadboard variant with long cables and poor decoupling, as well as an issue with the first read being unreliable (solved by discarding it). I'm hoping this has been solved with my PCB. In practice I only really need millisecond accuracy, but it's good learning to optimize designs.
Because the LDR in my code detects an absolute change in brightness, it doesn't matter if the screen goes darker or brighter as long as there's a notable change. This means as soon as the button is pressed, one can make a measurement to use as reference (as the character can't possibly have moved within say 20 micros after the press). At my sample rate, it will be about 1500 samples before a change can be expected. The sample rate is 40000 Hz, which is far greater than a cheap high speed camera. I can also detect the exact moment of the button pressed at even greater precision (perhaps in the MHz range).
As the 7-segs eat MCU pins, I was left with a single one for some UI buttons, which are split via binary voltage dividers, similar to what I did on my handheld thingy. I've added a trace on the back to separate the analog-digital ground planes a bit.
Slightly older version in Pink, as you can set the 3D view render colours... in manufacturing though you're limited to just a few basic colours. Engineers and companies are not that good at picking good colours, me thinks. PCB manufacturers put hobby boards on shared larger boards (which are cut up), so that's why there are so few PCB colours available. Picking exotic colours (if they even support them) can upset the pipeline. Also, green is a well established good colour (and material) for consistency and inspection purposes. Black is kinda awful for inspection.
I first built a breadboard version of the lag tester, then this perfboard one. It’s missing a cap on AREF, but there's an inductor and analog cap under the socket. It's powered via the ICSP header. Without a serial over USB connection, I had to find another way to output the measurement. It features a compact bar-display which I kind of overdid by adding fancy demo "screensaver" effects for. It has a 5ms display granularity, but I later opted to implement 7-seg digits as it's more readable. I tested this device using a USB pad on my Mac and found a 35-75ms lag windowed and even more in full screen (even in native rez with no scaling). The lag value varies quite a bit between measurements, probably for the reasons hinted at earlier.
Keyboard
Operational PCB. I've been working on a lot of keyboard layouts, but it's difficult to try them out when they deviate from established norms, such as is the case with my fantasy Amiga Keyboard, which... I suppose is slightly less of a fantasy now.
The matrix is a 8x4 and 7x4 section, which makes a fairly typical 8x8. The joypads actually sit in the keyboard matrix over convenient buttons, such as the arrow keys. This means joystick will basically "type" when used, which is how things were done on some older computers. The advantage with this is that you basically get free joystick ports. Nowadays this would work poorly because of the limits of the kinda shoddy USB keyboard protocol (6 keys plus 8 modifiers) and typing with a joystick might cause problems in a modern OS. But for this project I'm ignoring conventions, designing the computer as I fancy it.
The PCB can accommodate the flat 6x6 SMD switches, or a rubber membrane, or a PCB film, so it's three on one. I'll be using my sponge membrane. A row membrane presses against the row test pads on the flanks, but row contacts are also included on the PCB. These keys are smaller than those of a normal keyboard in order to minimize hand movement. I've talked about the design points on the other page so I won't go on about it here.
It's fully diode'd. I would've liked to use ISS309 diode arrays, but with the chip shortage prices have risen by a magnitude or two and I can't source them, so THT it is for now.
The rotary encoders of the joys and mouse likely need high speed polling and needs to be outside of the key part of the matrix lest they'd be spamming keys constantly, so I expanded the matrix to 10x8. I'm not sure if I've seen this kind of solution with a matrix extending into peripherals, so I'm curious if it'll work. It actually saves me from using any sort of IC inside the peripherals, whilst getting more buttons than with an 8-bit Mux or SR. Diodes are needed though.
I messed up the gerber plot and some of these silk layer key labels were omitted on the manufactured version. Can’t tell under the membrane tho. I also misplaced a screw hole on the right side.
Joypad
Joypad PCB. I made a custom edge connector to rotate standard mouse wheel rotary encoders 90 degree to the side. I might need to put the pads on the bottom as technically these REs are upside down. I don't have any case or membranes for this so it's just for testing the principle and polling speed limits and cable length effects thereupon. Joy-1 can actually mouse around since it overlaps the mouse-mode toggle key on the keyboard.
In this case I laid out the buttons on a paper model first to test ergonomics, then designed the PCB, then printed out and made additional placement adjustments. Drawing a joypad willy nilly will likely result in some strange scaling and uncomfortable grip.
More on Mice
Ball mouse with an Amiga-Atari switch. These type of mice use rotary encoder wheels with slits. Four sensors (PhotoDiodes/Transistors perhaps) pick up (IR?) LED light, or not. Since the sensor signal is probably quite fuzzy, an IC attempts to turn it into a tidy digital square wave. Sometime a comparator is used, but here a hex inverter with Schmitt triggers has been employed.
Ball mice hold some advantages over optical. Basically, since the ball has some momentum this helps aimlook during mouse lifts, whereas an optical mouse will freeze or jitter. Optical mice also jitter if the surface is confusing. Ball nice don’t have the shining LEDs which can be annoying in some cases. It’s possible to manipulate a ball mouse with a finger for fine adjustments, perhaps X or Y axis only. I wonder if it’s possible to put an optical sensor on top of the ball inside an old ball mouse...
KiCAD can export schematics as PDF. Not sure if this Mouse one is correct. I reverse engineered it from the old Amiga-Atari mouse, omitting the pinout swap switch as I'm only interested in the Amiga part.
NES Multipad
WIP NES joypad PCB, with earlier notes on the Joys page. The price of a PCB doesn’t really change with trace pattern, which is really just an image. What I mean is, making a PCB multipurpose doesn’t necessarily make it more expensive. I suppose making really thin fragile traces might affect reliability, possibly forcing the manufacturer to use a different process. Adding drill holes, vias, a second back layer can add cost, but practically it doesn’t at a hobbyist level. Mostly added functionality just adds to design time, and there’s a chance that it won’t work and has to be remade a few times. A company like Nintendo, SEGA, NEC or Commodore wouldn’t want to support competing products with this kind of work either.
But I hadn’t seen even a hobbyist make something like this, so I tried my hands at it. Only the relevant ICs go on the board, so I don’t think there will be any conflicts (missing ICs will separate connections). While I really like the NES joypad, it has some drawbacks nowadays. It’s less common nowadays. The screwposts tend to break when disassembled as the plastic has gone brittle. Start and Select are not that accessible (would prefer them being shoulder buttons). They are made for smaller hands, which was fine in 1987 but now my beard is gray.
Lie Detector
Lie Detector. This is a kit I assembled in 198X, probably. First thing I soldered. What a nice job. It worked though. It still works. If you show your soldering online the soldering besserweissers will turn up in droves. More flux! Too much solder! Too little there! That’s a cold joint - I can totally tell! Looks like a bridge there! Your heat is all wrong! Apply heat to the pad!
They’re not wrong, but it’s actually quite difficult to solder. You’re constantly one hand short. You shake and twitch. You're getting old and your eyesight is shit too. Things fall out. Plop - it fell on the floor, aaand it’s gone forever. Maybe you only have a cheap iron with a bad tip, and no flux, sucker or wick. You burn a finger on a heated component. You’re working mirrored and make mistakes. Did you fry that LED? No, but it's backwards and you have to desolder and resolder, perhaps frying it after all. Another component is corroded/oxidized and the solder won’t take. Want easier solder to work with? - Use the one with poisonous lead. Fumes are also toxic and extractor fan is doing a bad job, so wearing a mask, and your glasses fog up. The solder iron cable hooks onto a thing and drags it onto the floor. Someone's at the door. Where did you put the thing, you were just holding it, things can't just disapp--ooow it went right into the foot gonna get lead poisoning now. Phew, it's finally done. It doesn't work WHY everything is correct oh all these connections are mirrored because the schematic's pinout is looking INTO the connector not OUT of it.
I decided to reverse engineer it using the Schema editor just to go through the process. Not that complex once untangled. Several stages of amplification of skin/sweat resistance. Trimpot sets threshold value for LED indicator. Transistors are not binary though, so it comes on gradually. An additional IC could make it digital if needed. Unsure what cap does. I rebuilt it on breadboard using modern replacement components. Seemingly works but the characteristics might be different.
New PCB. In cases where you expect the user to solder on loose wires, it’s a good idea to provide two holes, so the wire can pull through one for strain relief. A tiny PCB like this can be fiddly for the manufacturer to handle, so it’s better, and cheaper to panelize (like a chocolate bar with pieces that break off). The pad holes for the transistors is are a bit too tightly spaced in the default footprint, so I think I'll have to alter it for DIY.
Cleaned up the old board and straightened out some legs. Still works. The LED comes on gradually here too (I sometimes forget that transistors are analog amplifiers and not digital switches), but perhaps one could use a comparator and have the LED "pop" on. Though practically it might be difficult to set the right threshold and you only get a binary "verdict" that way.
Pulse Supply
Sometimes it’s handy to have a little 555 on the breadboard. Since I have a bench PSU I don’t really need regulation, so this design just has some smoothing/decoupling caps. I had to make a custom footprint for the volume wheel.
Here an earlier version is driving my breadboarded Larson Scanner. The volume wheel and barrel jack are not perfboard compliant.
Larson/Larne Scanner
This is just a short video of a Cylon / Knight Rider LED effect. Originally in the movie props, the effect was achieved using logic chips and smaller light bulbs. When using modern LEDs the softness of the transitions can be replicated using the PWM capabilities of an MCU. Here I'm using the larger MEGA2560 board which has plenty of PWM pins. If using regular lightbulbs with an MCU a driver IC is necessary because MCU pins can't handle the bulbs directly. A red tinted/filter glass was used on the props. Back then red LEDs existed but they were not very bright. Kitt use 8 bulbs, but I'm not sure what was used in the Cylon helmets which were probably space and heat constrained.
Larson Scanner PCB, using components I have in stock. Not much point in manufacturing though, as an MCU does this cheaper than logic chips. This implementation has ULN2003 drivers for bulbs. Unfortunately I have the 7-pin variant so I needed two for the 8 lights. Though, in actuality, only one light is on at a time. There might be better ways to select and drive only one bulb. Bulbs have a warmup and afterglow that’s very soft and pleasing, contributing to the analog feel of the scan effect.
NE555 circuit here is pretty much the same as on the Pulse Supply. I isolated the power section just to be neat. There are some decoupling caps here and there elsewhere though. Not really critical for this low frequency application, I'd say.
An ULN2003 taking a bulb for a test drive. I think I regulated down to 3.3V on the other (switch) side. The ULN2003 sinks rather than source.
Miscellaneous
Desoldering a supposedly faulty resistor on the blue pill STM board. This technique sort of works. I didn't have the proper SMD resistor at hand so I attached a THT with greenstuff. Various desoldered/scavenged SMDs in the background, none of the correct value as it turned out.
A potentiometer looks like this inside.
And a rotary encoder looks like this inside.
Is it possible to make a rotary encoder that's more like left-right buttons? Well, in theory, but practically there might be mechanical/wear problems.
BubbleBus Software had a pretty great logo.
Camera handheld, with UI controls morel like that of a game.
MP3-player handheld.