Zen And Glowing Air Bubble Displays

When you work in a medium for long enough, and you learn how it works more and more deeply, you eventually become its master. [Yukio Shinoda] is probably master of the LED bubble display.

She started out with an idea, back in 1994, of a column of water and an array of solenoids to inject air, making patterns in the bubbles. Time passed, and she began to realize these works, first in water and then switching over to glycerine for slower, more predictable, and more spherical bubbles. The latest version realizes her initial vision, after 29 years, with an 8×8 array of nozzles making 3D shapes in the slowly rising columns. Continue reading “Zen And Glowing Air Bubble Displays”

The Crawlspace Crawler

This crawlspace crawler FPV robot is a fairly simple build. [Jeff G] bought a boxy chassis kit with frame, motors, and wheels, mounted lights and camera, and we get to see it in action (video, embedded below).

As always, the details are where it’s at, and his overview covers most of the high points. [Jeff] went for relatively slow 60 RPM motors so that he’d have plenty of grunt. The FPV setup is particularly simple – he bought a cheap Flysky i6 transmitter and receiver, and an Eachine TX05 all-in-one camera and transmitter. An interesting choice was a USB UVC video receiver so he can watch the footage on a computer, tablet, or a cell phone, which means he didn’t have to shell out for expensive FPV goggles. We also love the sticks-and-zip-ties used as feelers, letting him know when he’s about to get stuck, but that also serve as a visual frame for the camera.

The FPV Contest just came to an end, and we’ll be announcing the winners soon! If you find any inspiration there for your own project, [Jeff]’s simple basis here should get you started on the right track.

Continue reading “The Crawlspace Crawler”

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.

In Praise Of “Just Because” Hacks

Sometimes you pick a project because the world needs it to be done. Or maybe you or a friend need it. Or maybe you don’t really need it, but it fulfills a longstanding dream. In my mind, the last stop before you reach “why am I doing this” is the “just because” hack.

The ideal “just because” hack is limited in scope. You don’t want to spend years on a whimsical project, and because of this a “just because” hack isn’t usually motivating enough to keep you going that long anyway, except for the tenacious few. A “just because” doesn’t necessarily have to be an easy win, but it makes sense for you to see your way out before you get in too deep.

I’m not sure if it’s the Baader-Meinhof phenomenon or not, but in the last week or so in the Hackaday universe, a lot of people have been singing the praises of “just because” hacks. (Check out this one discussion, for instance.) Mostly, it’s a combination of them turning out better than initially thought, or it’s about the learning that came along for the ride. Of course, many of them spin off into longer, serious projects even if they didn’t start that way.

Not everything in life can be frivolous, of course. But that makes the “just because” hack that much sweeter, and you should try to make mental room for them if you can. When the stakes are low, creativity can be high. You might still want to impose a deadline, lest you fall into eternal yak shaving, but take it easy. You don’t need a justification all the time: the journey can be the destination.

Decentralized Chaos In Germany

When you’re planning an event with 15,000 hackers in a tight space these days, the COVID logistics can take the wind right out of your sails. And so the Chaos Computer Club decided, for one more year, to put aside plans for the traditional year-end Chaos Communications Congress. In it’s place this year? Everyone is doing their own thing, together but apart, for the “Dezentrale Jahresendveranstaltungen”.

Some local clubs are putting on local events, some of them have talk streams, and it’s all happening everywhere and at once. If you’re not near one of the roughly 30 locations in Europe that are doing something live – check out the streams. But be warned, there’s a lot to process!

Maybe it’s best to start with the schedule, where you can see what’s coming up next. Live streams are going on throughout, until Dec 30. If you missed a talk, you can check out the pre-release versions on Relive, but note that start times and end times are approximate, so you might need to seek around. And once they’re edited and polished up, they’ll show up on the permanent event playlist, which is still just getting started as we write this.

Right now, we’re watching a talk in German about how to program laser shows, but yesterday there were some great talks on subjects as varied as the history of the C language, how perimeter cybersecurity is dead, how to find the Norwegian prime minister in an “anonymous” dataset, and how Hackaday friend [Dave Darko] made his LED dodecahedron that he was showing off at Supercon.

In short, there’s a lot going on. Check it out.

Teensy Twofer Of Plug-In Emulated Retro CPUs

[Ted Fried] wrote in with not one but two (2!) new drop-in replacements for widespread old-school CPUs: the Zilog Z80 and the Intel 8088. Both of the “chips” run in cycle-accurate mode as well as in a super turbo mode, which can run so fast that you’ll need to use the Teensy’s internal RAM just to keep up.

Both of these designs have a hardware and software component. The PCBs basically adapt the pinout of the Teensy to the target CPU, with a bunch of 74VLC latches on board to do the voltage level conversion. The rest is a matter of emulating all of the instructions on the Teensy, which is more than fast enough to keep up. If this sounds familiar to you, it’s basically the same approach that [Ted] used last year to bring us his replacement for the 6502 found in the Apple ][ and Commodore 64.

Why would you want an emulated CPU when the originals are still available? [Ted] inherited a busted Osborne I, an ancient Z80 luggable. By replacing the original Z80 with his emulation, he could diagnose the entire system, which led him to discover some bad DRAM chips and get the old beast running again. Or maybe you just want to play IBM XT games at insane speeds?

And it looks like [Ted] has updated his 6502 emulation to include the undocumented C64 opcodes, so if you’re into that scene, you should be covered as well.

If any of this tickles your fancy, head over to [Ted]’s blog, microcore labs, and follow along. Although now that he’s covered most of the famous retrocomputers, we have to ask ourselves what processor is going to be next?

A Hacker’s Christmas Story

Twas the night before Christmas, and because I decided to make everyone’s presents myself this year, I’m still working like mad to get everything done before the big deadline. Why do I do this to myself? Well, partly because I enjoy the process.

My wife had this idea that we can make the older folks some fun decorative blinky things, and picked some motives. My son then drew them out on paper, and I scanned those drawings in and traced them over in CAD. We then cut the shapes out of wood on the CNC router, which turned out to be incredibly successful. (Now that I’ve done it, I wouldn’t be surprised if all of those “quirky” decorative objects that the Swedish flat-packers sell aren’t initially sketched out by third graders.)

Then my son painted them, and it’s my job to insert the twinkling. I bought some of those three-wire “fairy lights” for the purpose, and they’re really fun to hack on. They’re like WS2812s, only instead of using four pins and shifting the data downstream, they’re on a bus, each with a hard-coded address – they know where they are in the string and each LED only listens for the Nth set of 24 bits. This means sending 200 color codes just to light up the 4 LEDs in Aunt Micki’s decorative tree, but so be it.

Last stop, and still to do as of the 23rd, route out some kind of wooden battery case, wedge in the LiPo and the charging circuits, and solder on an on/off switch. It’s down to the last minute, but isn’t that always the way?

Definitely would have been easier just to order something online. But is that the spirit of giving? No! The DIY way brings the family together, gets me some quality time with the CNC machine, and tones up my FreeCAD skills. My son even looked over my shoulder as we were coding some of the LED animations. And nothing says Christmas like hand-coded blinkies.

Happy Holidays, y’all!