OpenSPICE: A Portable Python Circuit Simulator

[Roman Parise] and [Georgios Is. Detorakis] have created OpenSPICE a fork of the PySpice project, adding a new simulation engine written entirely in Python. This enables the same PySpice simulations to be executed on any platform that runs python (which we reckon is quite a few!) whilst leveraging the full power of the python infrastructure. Since it is a fork — for supported platforms — you can also run your simulations upon Ngspice as well as Xyce, giving options for scaling up to larger systems when required, but importantly without having to recreate your circuit from scratch.

The OpenSPICE simulator first converts the parsed netlist into a set of data structures that represent the equations describing the various parts of the system. These are then in turn passed along the scipy library “optimize.root” function which solves the system, generating a list of branch currents and node voltages. The output of the simulation is a numpy array, which can be further processed and visualized with the mathplotlib library. All pretty standard stuff in python circles. Since this is based upon PySpice, it’s also possible to use KiCAD netlists, so you have a nice way to enter those schematics. We’ve not dug into this much yet, but support for the vast libraries of spice models out there in circulation would be high up on our wish list if it already can’t handle this. This scribe will most definitely be checking this out, as LTSpice whilst good, is a bit of a pain to use and does lack the power of a Python backend!

Continue reading “OpenSPICE: A Portable Python Circuit Simulator”

Hacking The Python For Loop

In the early days of C, you’d occasionally see someone — probably a former Pascal programmer — write something like this:

#define BEGIN {
#define END }

This would usually initiate complaints about abusing the preprocessor and generally being anti-C. Surely no modern language would permit such things, right? Perhaps not. Consider [Tushar Sadhwani] who wanted to create a classic C-style for loop inside of Python. He did it, and the journey is perhaps more interesting than the result.

First, you can’t just transport straight C for loops into Python. There has to be some concession to Python syntax. The initial attempt was clever but not clever enough. However, the disassembly of the Python code was telling. The second attempt, however, was particularly interesting.

That attempt used an odd feature to examine the interpreter’s tree structure for the code and then modify it. This is sort of like a very painful C preprocessor but more powerful. That version works although it is pretty convoluted.

Ironically, [Tushar] then set up a third attempt after seeing code that tries to replace Python indentation with braces using a codec. In Python-speak, a codec lets you convert different text encodings. However, you can do other things than text encoding conversion. This is closest in spirit to the C preprocessor method. You can wade through the source code ahead of processing and make whichever changes you see fit.

Is any of this really useful? Probably not as it is. But you never know when you might need to do something exotic and one of these techniques could save the day. You probably couldn’t get away with some of this on MicroPython, of course. Your mileage may vary depending on where you find your Python running — like the Web.

Giving An Old Typewriter A Mind Of Its Own With GPT-3

There was an all-too-brief period in history where typewriters went from clunky, purely mechanical beasts to streamlined, portable electromechanical devices. But when the 80s came around and the PC revolution started, the typewriting was on the wall for these machines, and by the 90s everyone had a PC, a printer, and Microsoft Word. And thus the little daisy-wheel typewriters began to populate thrift shops all over the world.

That’s fine with us, because it gave [Arvind Sanjeev] a chance to build “Ghostwriter”, an AI-powered automatic typewriter. The donor machine was a clapped-out Brother electronic typewriter, which needed a bit of TLC to bring it back to working condition. From there, [Arvind] worked out the keyboard matrix and programmed an Arduino to drive the typewriter, both read and write. A Raspberry Pi running the OpenAI Python API for GPT-3 talks to the Arduino over serial, which basically means you can enter a GPT writing prompt with the keyboard and have the machine spit out a dead-tree version of the results.

To mix things up a bit, [Arvind] added a pair of pots to control the creativity and length of the response, plus an OLED screen which seems only to provide some cute animations, which we don’t hate. We also don’t hate the new paint job the typewriter got, but the jury is still out on the “poetry” that it typed up. Eye of the beholder, we suppose.

Whatever you think of GPT’s capabilities, this is still a neat build and a nice reuse of otherwise dead-end electronics. Need a bit more help building natural language AI into your next project? Our own [Donald Papp] will get you up to speed on that.

Continue reading “Giving An Old Typewriter A Mind Of Its Own With GPT-3”

The Whole Thing In Python

[hsgw] built a macropad in Python, and that’s not a strange language to choose to program the firmware in these days. But that’s just the tip of the iceberg. The whole process — from schematic capture, through routing and generating the PCB, and even extending to making the case — was done programmatically, in Python.

The macropad itself isn’t too shabby, sporting an OLED and some nice silkscreen graphics, but the whole point here is demonstrating the workflow. And that starts with defining the schematic using skidl, laying out the board with pcbflow, which uses a bunch of KiCAD footprints, and then doing the CAD design for a case in cadquery, which is kind of like OpenSCAD.

The result is that the whole physical project is essentially code-defined from beginning to end.  We’re not sure how well all the different stages of the workflow play together, but we can imagine that this makes versioning a ton easier.  Coding a PCB is probably overkill for something simple like this — you’d be faster to lay it out by hand for sure — but it doesn’t really scale.  There’s definitely some level of complexity where you don’t want to be clicking an pointing, but rather typing. Think of this as the “hello world” to designing in code.

Some of the tools in the workflow were new to us, but if you’d like an in-depth look at cadquery, we’ve got you covered. [Tim Böscke]’s insane CPU made from 555 timers (yes, really) uses pcbflow. And if you’d like to dig back a bit into the origins of Python PCB design, this post introduces CuFlow, on which pcbflow was based.

GitHub ESP32 OTA Updates, Now In MicroPython Flavor

Wouldn’t it be great if you could keep all of your small Internet-connected hacks up to date with a single codebase? A couple of weeks ago, we wrote up a project that automagically pulls down OTA updates to an ESP32 from GitHub, using the ESP32 C SDK. [Pascal] asked in the comments, “but what about MicroPython?” Gauntlet thrown, [TURFPTAx] wrote ugit.pya simple library that mirrors all of the code from a public GitHub Python repo straight to your gizmo running Micropython.

[Damped] wrote in about Senko, another library that does something very similar, but by then [TURFPTAx] was already done. Bam! Part of the speed is that MicroPython includes everything you need to get the job done – parsing streamed JSON was the hard part with the original hack. MicroPython makes those sorts of things easy.

This is one of those ideas that’s just brilliant for a hacker with a small flock of independent devices to herd. And because ugit.py itself is fairly simple and readable, if you need to customize it to do your own bidding, that’s no problem either. Just be sure that when you’re storing your WiFi authentication info, it’s not publicly displayed. ([TURFPTAx], could I log into your home WiFi?)

What’s [TURFPTAx] going to be using this for? We’re guessing it’s going to be deploying code to his awesome Open Muscle sensing rigs. What will we be using it for? Blinky Christmas decorations for the in-laws, now remotely updatable without them having to even learn what a “repo” is.

Continue reading “GitHub ESP32 OTA Updates, Now In MicroPython Flavor”

Taking (Good) Pictures Of PCBs

Snapping pictures is not technically difficult with modern technology, but taking good photographs is another matter. There are a number of things that a photographer needs to account for in order to get the best possible results, and if the subject matter isn’t particularly photogenic to start with it makes the task just a little more difficult. As anyone who’s posted something for sale online can attest, taking pictures of everyday objects can present its own challenges even to seasoned photographers. [Martijn Braam] has a few tricks up his sleeve for pictures like this in his efforts to photograph various circuit boards.

[Martijn] has been updating the images on Hackerboards, an online image reference for single-board computers and other PCBs, and he demands quality in his uploads. To get good pictures of the PCBs, he starts with ample lighting in the form of two wirelessly-controlled flashes in softboxes. He’s also using a high quality macro lens with low distortion, but the real work goes into making sure the image is sharp and the PCBs have well-defined edges. He’s using a Python script to take two pictures with his camera, and some automation in ImageMagic to composite the two images together.

While we’re not all taking pictures of PCBs, it’s a great way of demonstrating the ways that a workflow can be automated in surprising ways, not to mention the proper ways of lighting a photography subject. There are some other excellent ways of lighting subjects that we’ve seen, too, including using broken LCD monitors, or you can take some of these principles to your workspace with this arch lighting system.

Play DOOM On Seven-Segment Displays

Getting DOOM to run on a computer it was never meant to run on is a fun trope in the world of esoteric retro computers. By now we’ve seen it run on everything from old NES systems to microwaves, treadmills, and basically anything with a computer inside of it. What we don’t often see are the displays themselves being set up specifically to run the classic shooter. This build might run the game itself on ordinary hardware, but the impressive part is that it’s able to be displayed on this seven-segment display.

This build makes extensive use of multiplexers to drive enough seven-segment displays to use as a passable screen. There are 1152 seven segment digits arranged in a 48 by 24 array, powered by a network of daisy-chained MAX7219 chips. A Python script running on a Raspberry Pi correlates actual image data with the digit to be displayed on each of the segments, and the Raspberry Pi sends all of that information out to the screen. The final result is a display that’s fast enough and accurate enough to play DOOM in a truly unique way.

There is much more information available about this project on their project page, and they have made everything open source for those who wish to follow along as well. The project includes more than just the ability to play DOOM, too. There’s a built-in video player and a few arcade programs programmed specifically to make use of this display. Perhaps one day we will also see something like this ported to sixteen-segment displays instead of the more common seven-segment.