I’ve been following the development of KiCAD for a number of years now, and using it as my main electronics CAD package daily for a the last six years or thereabouts, so the release of KiCAD 6.0 is quite exciting to an electronics nerd like me. The release date had been pushed out a bit, as this is such a huge update, and has taken a little longer than anticipated. But, it was finally tagged and pushed out to distribution on Christmas day, with some much deserved fanfare in the usual places.
A while back, [Heavydeck] remembered stumbling across the worst CAD package ever, which is a schematic editor whose existence was purely intended for use to make quick circuit sketches for documentation, presentations and the like. All good. But, being based on low quality JPEG graphics, which when blown up to projector size on a big screen, they look really rough. After deciding that the original nasty, clunky interface was just nasty and clunky enough, [Heavydeck] then proceeded to reimplement the idea over the course of an afternoon, and came up with Kludge (possibly the second worst CAD package ever) making an actually useful tool even more useful.
You see, whether you make website content, YouTube tutorials, or just need to write technical reports, if you’re in the electronics business, you’re going to need to make high-quality editable schematic images at some point, and Kludge might well solve some problems for you. Kludge lets you do so many things; you can save a schematic, you can load a schematic, you can even export it to an SVG file. Actually, that’s all you can do, but it is actually just enough. Once you’ve got an image as an SVG, you can whack that into Inkscape to add some more details and you’re done. We demonstrate this with the image above, which was not annoying at all to create.
So here’s to Kludging your way around a problem, and hoping that the somewhat limited symbol library may expand a little more in the future!
When it comes to electronic design, breadboarding a circuit is the fun part — the creative juices flow, parts come and go, jumpers build into a tangled mess, but it’s all worth it when the circuit finally comes to life. Then comes the “What have I done?” phase, where you’ve got to backtrack through the circuit to document exactly how you built it. If only there was a better way.
Thanks to [Nick Bild], there is, in the form of the “Schematic-o-matic”, which aims to automate the breadboard documentation process. The trick is using a breadboard where each bus bar is connected to an IO pin on an Arduino Due. A program runs through each point on the breadboard, running a continuity test to see if there’s a jumper connecting them. A Python program then uses the connection list, along with some basic information about where components are plugged into the board, to generate a KiCad schematic.
[Nick] admits the schematics are crude at this point, and that it’s a bit inconvenient to remove some components, like ICs, from the breadboard first to prevent false readings. But this seems like one of those things where getting 80% of the work done automatically and worrying about the rest later is a big win. Plus, we can see a path forward to automatic IC probing, and even measurement of passive components too. But even as it is, it’s a great tool.
If you’ve ever pushed the needle a bit on your Raspberry Pi, there’s a good chance you’ve been visited by the dreaded lightning bolt icon. When it pops up on the corner of the screen, it’s a warning that the input voltage is dipping into the danger zone. If you see this symbol often, the usual recommendation is to get a higher capacity power supply. But experienced Pi wranglers will know that the board can still be skittish.
Sick of seeing this icon during his MAME sessions, [Majenko] decided to attack the problem directly by taking a close look at the power supply circuitry of the Pi 4. While the official schematics for everyone’s favorite single-board computer are unfortunately incomplete, he was still able to identify a few components that struck him as a bit odd. While we wouldn’t necessarily recommend you rush out and make these same modifications to your own board, the early results are certainly promising.
The first potential culprit [Majenko] found was a 10 ohm resistor on the 5 V line. He figured this part alone would have a greater impact on the system voltage than a dodgy USB cable would. The components aren’t labeled on the Pi’s PCB, but with a little poking of the multimeter he was able to track down the 0402 component and replace it with a tiny piece of wire. He powered up the Pi and ran a few games to test the fix, and while he definitely got fewer low-voltage warnings, there was still the occasional brownout.
Going back to the schematic, he noticed there was a 10 uF capacitor on the same line as the resistor. What if he bumped that up a bit? The USB specifications say that’s the maximum capacitive load for a downstream device, but he reasoned that’s really only a problem for people trying to power the Pi from their computer’s USB port.
Tacking a 470 uF electrolytic capacitor to the existing SMD part might look a little funny, but after the installation, [Majenko] reports there hasn’t been a single low-voltage warning. He wonders if the addition of the larger capacitor might make removing the resistor unnecessary, but since he doesn’t want to mess with a good thing, that determination will be left as an exercise for the reader.
Do you remember drawing your first schematic? Presumably you used a pen or a pencil and some kind of paper. Schematic capture software, though, makes it so much easier to draw schematics. There are many to choose from, but we spent some time checking out FidoCadJ and found it capable. Of course, there are many other options, but we did like that FidoCadJ runs locally and since it uses Java will run on just about any computer. Since it is open-source, you can modify it and you don’t have to worry about licensing it for your many computers or your team.
The program is a JAR file, and our first attempt to run it ran afoul of our older Java version that was the default Java Runtime Environment. But that was easy to fix, especially since a newer version was there, just not the default.
For [Leigh Oliver], there’s something undeniably appealing about the green on black instrumentation of the 2003 Saab 9-3 Gen2. Perhaps it’s because the Infotainment Control Module 2 (ICM2) screen brings a bit of that classic Matrix vibe to the daily commute. Whatever the reason, it seemed the display deserved better than to be stuck showing the nearly 20 year old stock user interface. Luckily, you can control it via I2C.
Though as you might expect, that fact wasn’t obvious at first. [Leigh] had to start by taking the ICM2 apart and reverse engineering the display board. With a multimeter and high resolution photographs of both sides of the PCB, all of the traces were mapped out and recreated in KiCAD. This might not have been strictly necessary, but it did serve as good practice for using KiCAD; a worthwhile tip for anyone else looking to build practical experience creating schematics.
With everything mapped out, [Leigh] was able to connect a BusPirate V3 up to the board and pretty quickly determine it was using I2C to control the display. As far as figuring out how to repurpose existing displays goes, this was perhaps the best possible scenario. It even allowed for creating a display library based on Adafruit_GFX which offers graphical capabilities far beyond what the ICM2 module itself is capable of.
Even with so much progress made, this project is really just getting started. [Leigh] has managed to put some impressive imagery on the black and green Saab display, but the hardware side of things is still being worked on. For example, there’s some hope that an I2C multiplexer would allow the display to easily and quickly be switched between “stock” mode and whatever enhanced version comes about thanks to the new libraries and an ESP8266 hiding behind the dashboard.
The most notable of the home computer and console hardware from the 8-bit golden era didn’t get their impressive sound and graphics from off-the-shelf silicon, instead they relied on secretive custom chipsets to get the edge over their competitors. Unfortunately for vintage gaming aficionados, those chips are now long out of production and in many cases there’s little information to be had about their operation.
That such a useful document is available at all is due to a lucky find in a dumpster following the demise of Atari, when a treasure trove of documents was discarded. It seems that the existence of these schematics has been known within the Atari community for some time, and we expect before long this information will find its way into FPGA implementations of the 7800; especially since the system features nearly complete backwards compatibility with the massively successful Atari 2600.