The declining costs of single-board computers has made serious computing power available for even the most trivial of tasks. It’s easy enough to slap a Raspberry Pi onto almost anything for nearly the same cost as a powerful 32-bit microcontroller platform, but this takes some of the fun out of projects for a few of us. Looking to get into the weeds can be a challenge as well, as [Michal Zalewski] demonstrates in this audio playback device he built from a simple 8-bit microcontroller.
The small toy takes audio input from a microphone through an op-amp and feeds this signal to an ADC within the AVR128DA28 microcontroller. The data is then stored on a separate memory chip ready to be played back through another op-amp paired with a speaker. This is where being familiar with the inner workings of the microcontroller comes in handy. By manipulating the interrupt routines in specific ways, the audio stored in memory can be played back at various speeds.
[Michal] intended this build to be a toy for one of his younger relatives, and for the price of a few ICs and buttons it does a pretty good job of turning a regular voice into a chipmunk voice like some commercial children’s toys some of us might remember. If the design aesthetics of this gadget look familiar, you may be thinking of his minimalist gaming device which we recently featured.
What do you get when you throw all accepted bicycle designs out the window and start fresh? Well, it might look a bit like [Saukki’s] velomobile.
Most bikes come in a fairly standard, instantly-recognizable shape which has been popular for over a century now. While it’s a vast improvement over its predecessor, the penny-farthing bicycle, there’s no reason that a bike needs to have this two-triangle frame shape other than that a pretentious bicycle racing standards group says they have to. If you want to throw their completely arbitrary rulebook out of the window, though, you can build much more efficient, faster bikes like recumbents or even full-fairing velomobiles. And if you want to go even faster than that, you can always add a standard ebike motor kit to one.
This is a lot harder than putting a motor on a normal bicycle. Bicycles tend to have standardized parts and sizes, and [Saukki]’s velomobile is far from the standard bike. First, he needed custom mounts for the display and also for the battery, which he needed to make extra wide so its weight wouldn’t rip through the carbon fiber body. The emergency brake lever motor cutoff needed to be dismantled to work with his control system too, and finally the mid-drive motor needed a custom mount as well. It’s a TSDZ2 motor that comes with torque-sensing pedal assist.
The changes didn’t stop there. The velomobile max speed is much higher than a standard bike. This called for some gear ratio changes, in the form of a monster 60-tooth chain ring.
This leads to the one major problem with this build which is that the velomobile can achieve such high speeds on its own that the electric assist cuts out for most of the ride. There is a legal requirement over much of Europe that e-bikes only have pedal assist (without a throttle) and that they stop assisting above a specific speed. But if you want to build an e-bike that pushes the boundary of the law instead of strictly adhering to it, take a look at this one which uses a motor from a washing machine.
Drums are an exciting instrument to learn to play, but often prohibitive if there are housemates or close neighbors involved. For that problem there are still electronic drums which can be played much more quietly, but then the problem becomes one of price. To solve at least part of that one, [Jeremy] turned to using an Arduino to build a drum module on his own, but he still had to solve yet a third problem: how to make the Arduino fast enough for the drums to sound natural.
Playing music in real life requires precise timing, so the choice of C++ as a language poses some problems as it’s not typically as fast as lower-level languages. It is much easier to work with though, and [Jeremy] explains this in great detail over a series of blog posts detailing his drum kit’s design. Some of the solutions to the software timing are made up for with the hardware on the specific Arduino he chose to use, including an even system, a speedy EEPROM, hardware timers, and an ADC that can sample at 150k samples per second.
With that being said, the hardware isn’t the only thing standing out on this build. [Jeremy] has released the source code on his GitHub page for those curious about the build, and is planning on releasing several more blog posts about the drum kit build in the near future as well. This isn’t the only path to electronic drums, though, as we’ve seen with this build which converts an analog drumset into a digital one.
For a quick file transfer between two computers, SCP is a fine program to use. For more complex, large, or regular backups, however, the go-to tool is rsync. It’s faster, more efficient, and usable in a wider range of circumstances. For all its perks, [Michael Stapelberg] felt that it had one major weakness: it is a tool written in C. [Michael] is philosophically opposed to programs written in C, so he set out to implement rsync from scratch in Go instead.
[Michael]’s path to deciding to tackle this project is a complicated one. His ISP upgraded his internet connection to 25 Gbit/s recently, which means that his custom router was the bottleneck in his network. To solve that problem he migrated his router to a PC with several 25 Gbit/s network cards. To take full advantage of the speed now theoretically available, he began using a tool called gokrazy, which turns applications written in Go into their own appliance. That means that instead of installing a full Linux distribution to handle specific tasks (like a router, for example), the only thing loaded on the computer is essentially the Linux kernel, the Go compiler and libraries, and then the Go application itself.
With a new router with hardware capable of supporting these fast speeds and only running software written in Go, the last step was finally to build rsync to support his tasks on his network. This meant that rsync itself needed to be built from scratch in Go. Once [Michael] completed this final task, he found that his implementation of rsync is actually much faster than the version built in C, thanks to the modernization found in the Go language and the fact that his router isn’t running all of the cruft associated with a standard Linux distribution.
For a software project of this scope, we find [Michael]’s step-by-step process worth taking note of for any problem any of us attempt to tackle. Not only that, refactoring a foundational tool like rsync is an involved task on its own, let alone its creation simply to increase network speeds beyond what most of us would already consider blazingly fast. We’re leaving out a ton of details on this build so we definitely recommend checking out his talk in the video below.
In prior centuries, it was common practice to tie the operation of a program to a computer’s clock speed. As computers got faster and faster, the programs tied to that slower clock speed sometimes had trouble running. To patch the issue temporarily, some computers in the early 90s included a “TURBO” button which actually slowed the computer’s clock speed down in order to help older software run without breaking in often unpredictable ways. [Ted Fried] decided that he would turn this idea on its head, though, by essentially building a TURBO button into the hardware of old computers which would greatly increase the execution speed of these computers without causing software mayhem.
To accomplish this, he is running CPU emulators on Teensys (Teensies?), but they are configured to be a drop-in replacement for the physical CPU of several retro computers such as the Apple II, VIC-20, and Commodore 64 rather than an emulator for an entire system. It can be configured to run either in cycle-accurate mode, making it essentially identical to the computer’s original hardware, or it can be placed into an accelerated mode to take advantage of the Teensy 4.1’s 800 MHz processor, which is orders of magnitude faster than the original hardware. This allows (most of) the original hardware to still be used while running programs at wildly faster speeds without needing to worry about any programming hiccups due to the increased clock speed.
The video below demonstrates [Ted]’s creation running in an Apple II but he has several other cores for other retro computers. It’s certainly a unique way to squeeze more computing power out of these antique machines. Some Apple II computers had a 4 MHz clock which seems incredibly slow by modern standards, so the 800 MHz Teensy would have been considered wizardry by the standards of the time, but believe it or not, it’s actually necessary to go the other direction for some applications and slow this computer down to a 1 MHz crawl.
Getting into e-biking is a great hobby. It can get people on bikes who might otherwise not be physically able to ride, it can speed up commute times, and it can even make hauling lots of stuff possible and easy, not to mention it’s also fun and rewarding. That being said, there are a wide array of conflicting laws around what your e-bike can and can’t do on the road and if you don’t want to run afoul of the rules you may need a programmable device that ensures your e-bike is restricted in the appropriate way.
This build is specifically for Bafang mid drives, which can be up to 1000 W and easily power a bike beyond the speed limit where [Tomblarom] lives. A small microcontroller is housed in a waterproof box on the bike and wired between the motor’s display and controller. A small hall effect sensor and magnet sit by this microcontroller, and if the magnet is removed then the microcontroller reprograms the bike’s controller to limit the speed and also to disable the throttle, another feature that is illegal in some jurisdictions but not others. As an added bonus, the microcontroller also handles brake lights, turn signals, and automatic headlights for the bike as well.
While the project page mentions removing the magnet while getting pulled over to avoid fines and other punishments, that’s on you. We imagine this could still be useful for someone who wants to comply with local laws when riding on the road, but still wants to remove the restrictions when riding on private property or off-road where the wattage and speed restrictions might not apply.
Most of us have probably seen a video of a sand drawing table at work, in which a steel ball — magnetically-coupled to a gantry under a layer of sand — lazily draws geometric patterns with utter precision and zen-like calmness. That’s all well and good, but [Mark Rehorst] thinks it can also be interesting to crank up the speed and watch the ball plow through sand just as physics intended. There’s a deeper reason [Mark] is working at this, however. Faster drawing leads to less crisp results, but by how much, exactly? To answer this, [Mark] simply ran his table (which is named The Spice Must Flow) at both fast and slow speeds and documented the results.
These two images show the difference between running the table at 100 mm/s versus 500 mm/s. The slower speed is noticeably crisper, but on the other hand the faster speed completed the pattern in about a fifth of the time. [Mark] says that as the ball aggressively accelerates to reach target speeds, more sand is thrown around over existing lines, which leads to a loss of detail.
Crisper detail, or a faster draw? Which is “better” depends on many things, but it’s pretty clear that [Mark]’s cat finds the fast version more exciting. You can see [Mark]’s table at high speed and the cat’s reaction in the video, embedded below.