If the word “train” didn’t grab your attention, you’re probably not the target audience for this project. If it did, then there is no need to explain why [AeroKoi] has come up with a modular 3″ train whistle, available on Thingiverse and well explained in the video embedded below. It’s a train whistle. Who doesn’t want their own train whistle?
The great part of this design– aside from requiring less air than his earlier, larger-diameter iterations–is the modularity. With adjustable bell caps, you can alter the size of the resonant chamber and thus the notes the whistle plays on the fly. That’s the key difference between a train whistle, as used in the steam era, and a train horn as you find on a modern diesel or electric– whistles use a resonant chamber, while a horn uses a diaphragm to create the vibrations we call sound. By using the movable chamber caps to change the resonance, you can go from a Santa Fe 5 chime to a B&O 3 chime whistle by matching the measurements in the handy-dandy spreadsheet [TrainArtisan] provided– and doubling up on a couple of chimes.
One excellent tip he gives in the video is to grease all the mating surfaces of the whistles with petroleum jelly, but it’s worth watching the whole thing on YouTube for both full build and tuning instructions, and to learn more than you ever thought you needed to know about whistles– he gets right into the physics of sound waves to explain exactly the limitations of trying to replicate the sound of brass steam whistles with plastic and compressed air. If you just want to hear a bunch of train whistles to see how well it works, jump to the ten minute mark. The disappointing part comes later, where he explains the airflow requirements: if you don’t have a compressor with a big tank, you can’t expect more than one short toot at a time.
Writing a computer game has always been hard. It is only the nature of the difficulty that changes. A modern game is as much about graphics, sound, and storytelling as it is about programming. But in the early days of computers, writing a game was a challenge because of limited graphics, slow CPUs, and tiny memory capacity. If you wanted to write a game for an early microcomputer, you generally wrote it in assembly language. BASIC was available on many machines, but it was usually too slow for anything requiring fast animation. Assembly language was fast, but it was also difficult to write, debug, and port to another machine.
RCA — in particular [Joseph Weisbecker], the architect of the 1802 — introduced the COSMAC VIP into the primordial 1977 home video game market. In addition to using ready-made games, the idea was that you could create your own. But writing games in 1802 assembly language would be beyond most of RCA’s customers. [Weisbecker] devised CHIP-8, a tiny virtual machine. It wasn’t quite a programming language. Instead, it was a simple instruction set implemented by an interpreter running on a real computer. You wrote programs for the imaginary CHIP-8 processor, and the interpreter made them run on the actual hardware. CHIP-8 is perfect for the kind of games you’d see in those days and still has a following among those who love retro games.
A Different Time: Tiny Interpreters
Today, when we think of interpreters, we often imagine something like Python, where the interpreter reads source code and figures out what to do. However, there’s another approach that was particularly attractive when memory and processor cycles were precious: threaded code.
In a threaded-code interpreter, a program consists of references (like indices into a command table) to routines that perform operations. Instead of decoding complicated instructions, the interpreter follows these references, executing the corresponding routines. There are several variations, including direct threading, indirect threading, and token threading. Forth is probably the best-known example of a language that commonly uses threaded code. In a typical Forth implementation, a program is compiled into a sequence of references to words, and a compact inner interpreter executes them.
Why bother? Because the implementation can be remarkably small. Instead of generating native machine code, a compiler can produce a compact representation that is relatively easy to execute. CHIP-8 belongs to the same general family of ideas, although it is more accurately described as a bytecode interpreter than a conventional threaded-code system. Its instructions are two bytes long, and the interpreter decodes each instruction and executes the corresponding operation. The original implementation was written in RCA 1802 machine code.
History Of CHIP-8
The VIP ([Dave Ruske] CC-BY-SA-2.0)The COSMAC VIP was an interesting machine. A basic system had 2 KB of RAM, a hexadecimal keypad, and a monochrome video display. Programs were generally entered as hexadecimal bytes using the keypad, although expansion options were available. The 1802 CPU inside wasn’t exactly a speed demon. It was an 8-bit processor with sixteen 16-bit registers and an unusual architecture that made it well suited to certain embedded applications. There were versions that were also well-suited for spacecraft, and so the chip is in Magellan, Galileo, and even some parts of the Hubble.
CHIP-8 made programming the VIP considerably easier, especially for games. Rather than dealing with the peculiarities of the 1802 and the VIP’s display hardware, programmers could use a small, consistent instruction set designed around graphics and keypad input.
The CHIP-8 virtual machine provides sixteen 8-bit registers, conventionally named V0 through VF. It also has a 16-bit index register, a program counter, a stack for subroutine calls, and two timers.
The display is 64 pixels wide and 32 pixels high. Pixels are either on or off. There’s no color, no hardware sprites, and no sophisticated graphics processor. There are, however, instructions specifically intended to make games easier to write. You can draw a sprite with a single instruction, test whether a key is pressed, generate a random number, and use timers to control animation.
A sprite is simply a sequence of bytes, with each bit representing a pixel. A typical sprite can be up to eight pixels wide and fifteen pixels high. The instruction set is tiny, with only a few dozen basic operations. Yet it is sufficient to implement games such as Pong, Breakout, and Space Invaders-like shooters.
CHIP-8 subsequently appeared on other systems, and later variants extended its capabilities. The best-known extension is Super-CHIP, which added features including higher-resolution graphics. Today, CHIP-8 survives largely because it is an excellent target for emulator projects. Writing a CHIP-8 interpreter is a manageable exercise, and there are thousands of small programs available to test one. But you don’t need to write an interpreter to experiment with CHIP-8.
Adjustable standing desks have had some ergonomic and health benefits for many people who would otherwise be sitting down all day, but those benefits come at a cost of a bit of usability. They can be more expensive, they make cable management and lighting a bit more difficult, and of course they take up more space than a normal desk. Related to that, they may have limited or no drawer space. [Super Valid Designs] decided to tackle all of these problems, while at the same time addressing the larger problem of a very disorganized workspace.
The idea seems simple on its face. The desk surface would be removed from the legs and a full-sized drawer built that matches the footprint of the desk and attaches to the same points, then the surface can be put back on top of that. But this is where feature creep started to set in, although in this case it was all a net positive for the build. [Super Valid Designs] wanted a front for the drawer but, since this is where his keyboard and mouse would go, wanted it to automatically move aside so it’s not in the way. He built a clever mechanism that pivots the front down when the drawer slides out. Not only that, but the drawer locks into place when it’s halfway out in “keyboard mode” and by lifting the front and pulling the drawer further out he can access a deeper storage space further to the back of the drawer.
Although adding these features in took him longer than he originally thought, the new desk is much more usable than the old while helping him eliminate some of the clutter around his workspace. Like any prototype, though, there were a few issues such as cable management (which is a problem with most standing desks) and the fact that he forgot that some of his peripherals were attached to the desk with clamps, which can’t be used with the drawer cabinet in the way. Overall though it’s a major improvement which we think could only be further improved by making it not just a standing desk, but a walking desk.
Batteries have a habit of quietly getting worse. Anyone who has nursed an old smartphone through its final years knows the routine—it leaves the house at 100% and is begging for a charger by lunchtime. It’s no surprise, then, that one of the most common worries about electric cars is what happens to the pack after a few years and a lot of kilometres. Nobody wants to buy a used EV only to discover it can barely make it across town. Fears around battery degradation and high replacement costs were the catch cry of many EV doomers over the years.
The good news is that we now have a pretty big pile of data on the question. Austrian battery diagnostics company Aviloo has crunched the results of more than 500,000 tests on used EVs covering 20 popular models from the likes of Tesla, Volkswagen, Hyundai and Nissan. The data thus far tells us that EV batteries are holding up far better than the naysayers would have you believe.
It’s become a bit of a platitude to state that products were manufactured better in ‘the olden days’, but as [The Meandrous Engineer] covers in a recent video essay, the truth is a lot more greyscale and nuanced than something so trite.
The very short version is that it is the dominant culture of a nation in which products are manufactured that determines how many shortcuts and potential product life-shortening decisions are made. This same culture works its way down into company culture, including the engagement of the so-called C-suite with the engineers and folk who keep the now mostly automated manufacturing lines running, as well as vice-versa.
Old-school die-cast models and incandescent light bulbs saw their own series of manufacturing shortcuts, including a pre-World War 2 scandal about the artificial limiting of the lifespan of lightbulbs so that customers would buy more of them. This foreshadows what happened as soon as plastics and computer-aided design and manufacturing came on the scene.
Post-WW2, people like W. Edwards Deming were welcome guests in Japan and other rebuilding nations, introducing the Lean method of manufacturing which was at the time not deemed desirable in a post-war USA. For Japan, South Korea and other nations in the region this meant a boom in manufacturing, with a quality level that would ultimately trounce that of their Western equivalents.
Somehow, seeing DOOM on things that were never meant to run DOOM never gets old. It’s probably hard to get further into the “never meant to run DOOM” weeds than a coffee maker, but [Robin M.] has done it, and tells you exactly how in his excellent write-up. It adds a new dimension to hard mode — try and play while you’re waiting for your morning coffee.
Of course [Robin] doesn’t start with just any coffee machine; most sensible percolators won’t have any silicon capable of executing code, much less gaming on. The Spengler PSL50 machine [Robin] is hacking is a smart device with a Linux computer inside, although in this case there’s a point to having the smarts, as it’s meant to be a self-serve, pay-to-drink coffee kiosk. Handling payments and the touchscreen menus seems like justification enough for a microprocessor.
As you might expect, all the ‘smarts’ of this coffee maker are on the touchscreen module which aside from the brains of the operation — i.MX 6 ARM Cortex A9 processor — happens to have a handy a debug port. With just a little probing to find the right pins, he gets a console connection via that debug port to the 2013-era Linux build that runs the device, and then it’s off to the races. To make life even easier for [Robin], there was no uboot password set, nor any protections. So a simple setnv gets him into an sh prompt, and then he’s set. As for DOOM, he’s using fbDOOM, a version that renders directly to the framebuffer, and compiles it as a self-contained binary so he doesn’t have to care that everything on the Linux system is 13 years out of date.
Spengler made hacking this device relatively easy with their almost complete lack of security, and the resulting project is well documented, well executed, and tickles our funny bones the same way seeing DOOM on a toaster did. We haven’t covered DOOM on a refrigerator but it’s only a matter of time before the whole kitchen is killing demons, including the thermostat in the hall.
Although combining electronics and 3D-printed structures is fairly common, this usually entails some level of manual assembly. This contrasts strongly with the Print & Place approach demonstrated by [Oliver Child] et al. in their research article titled Print & Place: Using a 3D printer for Continuous Assembly of Electronic Devices.
An accompanying video is also provided which covers all the basics and showing a few ways in which a regular FDM printer can be used without modifications to embed these components. Rather than requiring a custom tool head the thermoplastic is used as a temporary adhesive to pick up parts that are placed in a printed tray elsewhere on the build plate.
This parts tray is created parametrically before being printed. Following this an operator has to populate this tray with the requisite parts so that the print head can pick them up when they are needed. This is done during the printing of the actual parts, with regular G-code added to move the head over to the needed part before using a bit of extruded plastic to adhere to it and lift it to its new home.
Subsequently these parts can be printed over to fully embed them, with this method supporting a range of parts. In the three demonstrations everything from small pre-populated PCBs to strips of conductive wire and braid were used together with rivets to provide paths between conductive traces.
Of course, with this being an open loop system you can expect many of the typical issues here, ranging from pick failures, placement misalignment and contact inconsistencies, as the authors encountered during their experiments. Here one could conceivably pitch adding a camera system as on typical pick & place machines to add a feedback loop that the firmware could then use for adjustments and to signal the human operator to assist.
Although combining electronics and 3D-printed structures is fairly common, this usually entails some level of manual assembly. This contrasts strongly with the Print & Place approach demonstrated by [Oliver Child] et al. in 
