It’s a build that’s remarkably accessible for even the inexperienced builder. Paper templates are used to cut out the plywood parts for the cabinet, and the electronic components are all off-the-shelf items. Assembly is readily achievable with high-school level woodworking and soldering skills. Like most similar builds, it relies on the Raspberry Pi running RetroPie, meaning you’ll never run out of games to play.
Where this project really shines, however, is the graphics. Cribbed from Mortal Kombat II and looking resplendent in purple, they’re key to making this cabinet a truly stunning piece. The attention to detail is excellent, too, with the marquee and screen getting acrylic overlays for that classic shine, as well as proper T-moulding being used to finish the edges.
Software-defined radios or SDRs have provided a step-change in the way we use radio. From your FM broadcast receiver which very likely now has single-application SDR technology embedded in a chip through to the all-singing-all-dancing general purpose SDR you’d find on an experimenter’s bench, control over signal processing has moved from the analogue domain into the digital. The possibilities are limitless, and some of the old ways of building a radio now seem antiquated.
[Pete Juliano N6QW] is an expert radio home-brewer of very long standing, and he’s proved there’s plenty of scope for old-fashioned radio homebrewing in an SDR with his RADIG project. It’s an SDR transceiver for HF which does all the work of quadrature splitting and mixing with homebrewed modules rather than the more usual technique of hiding it in an SDR chip. It’s a very long read in a diary format from the bottom up, and what’s remarkable is that he’s gone from idea to working SDR over the space of about three weeks.
So what goes into a homebrew SDR? Both RF preamplifier, filters, and PA are conventional as you might expect, switched between transmit and receive with relays. A common transmit and receive signal path is split into two and fed to a pair of ADE-1 mixers where they are mixed with quadrature local oscillator signals to produce I and Q that is fed to (or from in the case of transmit) a StarTech sound card. The local oscillator is an Si5351 synthesiser chip in the form of an SDR-Kits USB-driven module, and the 90 degree phased quadrature signals are generated with a set of 74AC74 flip-flops as a divider.
Running the show is a Raspberry Pi running Quisk, and though he mentions using a Teensy to control the Si5351 at the start of his diary it seems from the pictures of the final radio that the Pi has taken on that work. It’s clear that this is very much an experimental radio as it stands with wired-together modules on a wooden board, so we look forward to whatever refinements will come. This has the feel of a design that could eventually be built by many other radio amateurs, so it’s fascinating to be in at the start.
For [Turbo Conquering Mega Eagle], the question was simple: Do I spend 20 minutes slaving away in front of a bandsaw to cut a bunch of short brass rods into even shorter pieces of brass rod? Or do I spend days designing and building an automatic cutoff saw to do the same job? The answer is obvious.
It’s only at the end of the video below that [TCME] reveals the need for these brass bits: they’re for riveting together the handles of knives he makes and sells. That makes the effort that went into his “Auto Mega Cut-O-Matic” a little easier to swallow, although we still think he ran afoul of this relevant XKCD. The saw is built out of scraps and odd bits using angle iron as a base and an electric die grinder to spin a cut-off wheel. A small gear motor feeds the brass rod down a guide tube until it hits a microswitch stop, which starts the cut cycle. Another motor swivels the saw to make the cut then moves it out of the way so the stock can advance. The impressive thing is that the only control mechanism is a series of microswitches, cams, levers, and springs – no Arduino needed. Heck, there’s not even a 555, which we find a refreshing change.
Yes, it’s overkill, but he had fun and made something pretty ingenious. [Turbo Conquering Mega Eagle] always has something interesting going on in the shop, and we couldn’t help but notice him using his aluminum-melting tea kettle to make some parts for this build.
For a hundred years or thereabouts, if you made something out of plastic, you used a mold. Your part would come out of the mold with sprues and flash that had to be removed. Somewhere along the way, someone realized you could use these sprues to hold parts in a frame, and a while later the plastic model was invented. Brilliant. Fast forward a few decades and you have 3D printing. There’s still plastic waste in 3D printing, but it’s in the form of wasteful supports. What if someone designed a 3D printable object like a flat-pack plastic model? That’s what you get when you make a Fully 3D-printable wind up car, just as [Brian Brocken] did. It’s his entry for the Hackaday Prize this year, and it prints out as completely flat parts that snap together into a 3D model.
This 3D model is a fairly standard wind-up car with a plastic spring, escapement, and gear train to drive the rear wheels. Mechanically, there’s nothing too interesting here apart from some nice gears and wheels designed in Fusion 360. Where this build gets serious is how everything is placed on the printer. Every part is contained in one of two frames, laid out to resemble the panels of parts in a traditional plastic model.
These frames, or sprue trees, or whatever we’re calling this technique in the land of 3D printing, form a system of supports that keep all the parts contained until this kit is ready to be assembled. It’s effectively a 3D printable gift card, flat packed for your convenience and ease of shipping. A great project, and one that proves there’s still some innovation left in the world of 3D printing.
There’s something magical about a laser light show. Watching that intense beam of light flit back and forth to make shapes and patterns, some of them even animated, is pretty neat. It leaves those of us with a technical bent wondering just exactly how the beam is manipulated that fast.
Wonder no more as [Zenodilodon], a working concert laser tech with a deep junk bin, dives into the innards of closed-loop galvanometers, which lie at the heart of laser light shows. Galvos are closely related to moving-coil analog meters, which use the magnetic field of a coil to deflect a needle against spring force to measure current. Laser galvos, on the other hand, are optimized to move a lightweight mirror back and forth, by tiny amounts but very rapidly, to achieve the deflection needed to trace out shapes.
As [Zeno] explains in his teardown of some galvos that have seen better days, this means using a very low-mass permanent magnet armature surrounded by coils. The armature is connected to the mirror on one end, and a sensor on the other to provide positional feedback. We found this part fascinating; it hadn’t occurred to us that laser galvos would benefit from closed-loop control. And the fact that a tiny wiggling vane can modulate light from an IR LED enough to generate a control signal is pretty cool too.
The video below may be a bit long, but it’s an interesting glimpse into the day-to-day life of a lighting tech. It puts a little perspective on some of the laser projection projects we’ve seen, like this giant Asteroids game.
We’ll all be familiar with Tic-Tac-Toe, or Noughts and Crosses, a childhood pencil-and-paper diversion which has formed the basis of many a coding exercise. It’s an easy enough task to implement in software, but how many of us have seen it done in hardware alone? That’s just what [Warren Toomey] has done using TTL chips, and his method makes for a surprisingly simple circuit.
At its heart is an 8 kB ROM that contains precomputed move sequences that are selected via an address composed of the game states for both player and machine. A series of flip-flops control and buttons to make the board, and a 555 provides a clock.
The technique of using a ROM to replace complex logic is a very powerful one that is facilitated by the low price of relatively large devices that would once have been unaffordable. We’ve seen the technique used elsewhere, including as an ALU in a TTL CPU, and even for an entire CPU in its own right.
You can see the result in operation in the video below the break, and should you wish to have a go for yourself all the relevant information can be found in a GitHub repository.
Due to the limited resources available, it’s not a direct port of Doom. [David] instead took some sprites and map data from the original game, and built a raycasting engine similar to that of Wolfenstein 3D. Despite the limited memory and CPU cycles, the basic game can run at between 8-11 FPS. There are fancy dithering tricks to help improve the sense of depth, a simplified enemy AI, and even a custom text library for generating the UI.