This excellent content from the Hackaday writing crew highlights recurring topics and popular series like Linux-Fu, 3D-Printering, Hackaday Links, This Week in Security, Inputs of Interest, Profiles in Science, Retrotechtacular, Ask Hackaday, Teardowns, Reviews, and many more.
This week, Jonathan Bennett, Randal Schwartz, and Aaron Newcomb chat about Linux, the challenges with using system modules like the Raspberry Pi, challenges with funding development, and more!
Continue reading “FLOSS Weekly Episode 810: Pi4J – Stable And Boring On The Raspberry Pi”
At this point, we’ve learned about man-made byproducts and nature-made byproducts. But how about one that’s a little of both? I’m talking about calthemites, which are secondary deposits that form in those man-made caves such as parking garages, mines, and tunnels.
Calthemites grow both on and under these structures in forms that mimic natural cave speleothems like stalactites, stalagmites, flowstone, and so on. They are often the result of an hyperalkalinic solution of pH 9-14 seeping through a concrete structure to the point of coming into contact with the air on the underside. Here, carbon dioxide in the air facilitates the necessary reactions to secondarily deposit calcium carbonate.
These calcium carbonate deposits are usually white, but can be colored red, orange, or yellow thanks to iron oxide. If copper pipes are around, copper oxide can cause calthemites to be blue or green. As pretty as all that sounds, I didn’t find any evidence of these parking garage growths having been turned into jewelry. So there’s your million-dollar idea.
Continue reading “Boss Byproducts: Calthemites Are Man-Made Cave Dwellers”
Last week I completed the SAO flower badge redrawing task, making a complete KiCad project. Most of the SAO petals are already released as KiCad projects, except for the Petal Matrix. The design features 56 LEDs arranged in eight spiral arms radiating from the center. What it does not feature are straight lines, right angles, nor parts placed on a regular grid.
I first wanted to only read the data from the LEDs for analysis, and I didn’t need the full Kicad + Python scripting for that. Using grep on the PCB file, you get a text file that can be easily parsed to get the numbers. I confirmed that the LED placements were truly as irregular as they looked.
My biggest worry was how obtain and re-apply the positions and angles of the LEDs, given the irregular layout of the spiral arms. Just like the random angles of six SAO connector on the badge board, [Voja] doesn’t disappoint on this board, either. I fired up Python and used Matplotlib to get a visual perspective of the randomness of the placements, as one does. Due to the overall shape of the arms, there is a general trend to the numbers. But no obvious equation is discernable.
It was obvious that I needed a script of some sort to locate 56 new KiCad LED footprints onto the board. (Spoiler: I was wrong.) Theoretically I could have processed the PCB text file with bash or Python, creating a modified file. Since I only needed to change a few numbers, this wasn’t completely out of the question. But that is inelegant. It was time to get familiar with the KiCad + Python scripting capabilities. I dug in with gusto, but came away baffled.
This being a one-time task for one specific PCB, writing a KiCad plugin didn’t seem appropriate. Instead, hacking around in the KiCad Python console looked like the way to go. But I didn’t work well for quick experimenting. You open the KiCad PCB console within the PCB editor. But when the console boots up, it doesn’t know anything about the currently loaded PCB. You need to import the Kicad Python interface library, and then open the PCB file. Also, the current state of the Python REPL and the command history are not maintained between restarts of KiCad. I don’t see any advantages of using the built-in Python console over just running a script in your usual Python environment.
Clearly there is a use case for this console. By all appearances, a lot of effort has gone into building up this capability. It appears to be full of features that must be valuable to some users and/or developers. Perhaps I should have stuck with it longer and figured it out.
This seemed like the perfect solution. The buzz in the community is that modern KiCad versions interface very well with Python. I’ve also been impressed with the improved KiCad project documentation on recent years. “This is going to be easy”, I thought.
First thing to note, the KiCad v8 interface library works only with Python 3.9. I run pyenv on my computers and already have 3.9 installed — check. However, you cannot just do a pip install kicad-something-or-other... to get the KiCad python interface library. These libraries come bundled within the KiCad distribution. Furthermore, they only work with a custom built version of Python 3.9 that is also included in the bundle. While I haven’t encountered this situation before, I figured out you can make pyenv point to a Python that has been installed outside of pyenv. But before I got that working, I made another discovery.
The Python API is not “officially” supported. KiCad has announced that the current Simplified Wrapper and Interface Generator-based Python interface bindings are slated to be deprecated. They are to be replaced by Inter-Process Communication-based bindings in Feb 2026. This tidbit of news coincided with learning of a similar 3rd party library.
Many people were asking questions about including external pip-installed modules from within the KiCad Python console. This confounded my search results, until I hit upon someone using the KiUtils package to solve the same problem I was having. Armed with this tool, I was up and running in no time. To be fair, I susepct KiUtils may also break when KiCad switched from SWIG to IPC interface, but KiUtils was so much easier to get up and running, I stuck with it.
I wrote a Python script to extract all the information I needed for the LEDs. The next step was to apply those values to the 56 new KiCad LED footprints to place each one in the correct position and orientation. As I searched for an example of writing a PCB file from KiUtils, I saw issue #113, “Broken as of KiCAD 8?”, on the KiUtils GitHub repository. Looks like KiUtils is already broken for v8 files. While I was able to read data from my v8 PCB file, it is reported that KiCad v8 cannot read files written by KiUtils.
At a dead end, I was about to hand place all the LEDs manually when I realized I could do it from inside KiCad. My excursions into KiCad and Python scripting were all for naught. The LED footprints had been imported from Altium Circuit Maker as one single footprint per LED (as opposed to some parts which convert as one footprint per pad). This single realization made the problem trivial. I just needed to update footprints from the library. While this did require a few attempts to get the cathode and anodes sorted out, it was basically solved with a single mouse click.
The imported traces on this PCB were harder to cleanup than those on the badge board. There were a lot of disconinuities in track segments. These artifacts would work fine if you made a real PCB, but because some segment endpoints don’t precisely line up, KiCad doesn’t know they belong to the same net. Here is how these were fixed:
Applying these rules over and over again, I finaly cleared all the discontinuities. Frustratingly, the algorithm to do this task already exists in a KiCad function: Tools -> Cleanup Graphics... -> Fix Discontinuities in Board Outline, and an accompanying tolerance field specified as a length in millimeters. But this operation, as noted in the its name, is restricted to lines on the Edge.Cuts layer.
When I was all done, I noticed a detail in the photo of the Petal Matrix PCB assembly from the Hackaday reveal article. That board (sitting on a rock) has six debugging / expansion test points connected to the six pins of the SAO connector. But in the Altium Circuit Maker PCB design, there are only two pads, A and B. These connect to the two auxiliary input pins of the AS1115 chip. I don’t know which is correct. (Editor’s note: they were just there for debugging.) If you use this project to build one of these boards, edit it according to your needs.
The SAO Petal Matrix redrawn KiCad project can be found over at this GitHub repository. It isn’t easy to work backwards using KiCad from the PCB to the schematic. I certainly wouldn’t want to reverse engineer a 9U VME board this way. But for many smaller projects, it isn’t an unreasonable task, either. You can also use much simpler tools to get the job done. Earlier this year over on Hackaday.io, user [Skyhawkson] did a gread job backing out schematics from an Apollo-era PCB with Microsoft Paint 3D — a tool released in 2017 and just discontinued last week.
Ceci n’est pas une keyboard, sure. But it’s keyboard-adjacent, and how. [Joshua Bemenderfer]’s wrists are tired of moving off the keyboard in order to mouse, and he decided to create a trackball that can sit just below the Space bar. The idea is to get rid of the regular mouse entirely if this works out.
Starting with an off-the-shelf trackball, the first BOM came in around $25 if you throw in $5 for the 3D printing of the case. [Joshua] added some cheap ceramic bearings to make it better. Since this was still too high, he turned to the internals of cheap mice.
Trial and error has resulted in a 99-cent special from Ali being the idea candidate. There are even cheaper mice to be had, but this one has an ideal layout for doing a bit of surgery. It also requires remapping since [Joshua] is flipping the sensor upside down and using a POM ball on top of it. Now he just needs to figure out how to add buttons and make them split keyboard-friendly.
Continue reading “Keebin’ With Kristina: The One With The Typo”
A couple of weeks back, we covered an interesting method for prototyping PCBs using a modified CNC mill to 3D print solder onto a blank FR4 substrate. The video showing this process generated a lot of interest and no fewer than 20 tips to the Hackaday tips line, which continued to come in dribs and drabs this week. In a world where low-cost, fast-turn PCB fabs exist, the amount of effort that went into this method makes little sense, and readers certainly made that known in the comments section. Given that the blokes who pulled this off are gearheads with no hobby electronics background, it kind of made their approach a little more understandable, but it still left a ton of practical questions about how they pulled it off. And now a new video from the aptly named Bad Obsession Motorsports attempts to explain what went on behind the scenes.
Last week, we ran a post about a slightly controversial video that claimed that a particular 3D-printing slicing strategy was tied up by a patent troll. We’re absolutely not lawyers here at Hackaday, but we’ve been in the amateur 3D printing revolution since the very beginning, and surprisingly patents have played a role all along.
Modern fused-deposition modelling (FDM) 3D printing began with Stratasys’ patent US5121329A, “Apparatus and method for creating three-dimensional objects”, and the machines they manufactured and sold based on the technology. Go read the patent, it’s an absolute beauty and has 44 different claims that cover just about everything in FDM printing. This was the watershed invention, and today, everything claimed in the patent is free.
Stratasys’ patent on the fundamental FDM method kept anyone else from commercializing it until the patent expired in 2009. Not coincidentally, the first available home-gamer 3D printer, the Makerbot Cupcake, also went on sale in 2009.
The Stratasys machines were also one of the big inspirations for Adrian Bowyer to start the RepRap project, the open-source movement that basically lead to us all having cheap and cheerful 3D printers today, and he didn’t let the patent stop him from innovating before it lapsed. Indeed, the documentation for the RepRap Darwin dates back to 2007. Zach [Hoeken] Smith delivered our hackerspace the acrylic parts to make one just around that time, and we had it running a year or two before the Cupcake came out of the company that he, Bre, and Adam shortly thereafter founded.
The story of hackers and 3D printers is longer than the commercial version of the same story would imply, and a lot of important innovations have come out of our community since then too. For instance, have a look at Stratasys’ patent on heated bed technology. At first read, it seems to cover removable heated beds, but have a look at the cutout at the end of claim 1: “wherein the polymer coating is not a polymer tape”. This cutout is presumably in response to the at-the-time common practice of buying Kapton, PEI, or PET tape and applying that to removable heated bed surfaces. I know I was doing that in 2012, because I read about it on IRC or something, long before the Stratasys patent was filed in 2014. They could only get a patent for sprayed-on coatings.
As [Helge] points out, it’s also easily verifiable that the current patent on “brick layers” that we’re worrying about, filed in 2020, comes later than this feature request to Prusa Slicer that covers essentially the same thing in 2019. We assume that the patent examiner simply missed that obvious prior art – they are human after all. But I certainly wouldn’t hesitate to implement this feature given the documented timing.
I would even be so bold as to say that most of the post-2010 innovation in 3D printing has been made by hobbyists. While the RepRap movement was certainly inspired by Stratasys’ invention in the beginning, our community is where the innovation is happening now, and maybe even more starkly on the software side of things than the hardware. Either way, as long as you’re just doing it for fun, let the suits worry about the patents. Hackers gotta hack.
In this episode you’ll get to hear not one, not two, but three Hackaday Editors! Now that the dust has mostly settled from the 2024 Hackaday Supercon, Al Williams joins Elliot and Tom to compare notes and pick out a few highlights from the event. But before that, the week’s discussion will cover the questionable patents holding back a promising feature for desktop 3D printers, a new digital book from NODE, and the surprisingly limited history of welding in space. You’ll also hear about the challenge of commercializing free and open source software, the finicky optics of the James Web Space Telescope, and the once exciting prospect of distributing software via pages of printed barcodes.
Direct MP3 download for offline, “easy” listening.
