If you try to sew leather on a standard consumer-grade machine, more often than not you’ll quickly learn its limits. Most machines are built for speed, and trying to get them to punch through heavy material at the low motor speeds often needed for leather work is a lesson in frustration.
How frustrating? Enough so that [Joseph Eoff] expended considerable effort to create this sewing machine speed controller for his nearly century-old Adler sewing machine. The machine was once powered by a foot treadle, which is probably why the project is dubbed “Bigfoot,” but now uses a 230 V universal motor. Such motors don’t deliver much torque when run at low speeds with the standard foot-pedal rheostat control, so [Joseph] worked up an Arduino-based controller with a tachometer for feedback and a high-power PWM driver for the motor.
There are a ton of details in [Joseph]’s post and even more in the original blog article, which is well worth a read, but a couple really stand out. The first is with the tachometer, which uses an off-the-shelf photointerrupter and slotted disc. [Joseph] was displeased with the sensor’s asymmetrical and unreliable output, so he made some modifications to the onboard comparator to square up the signal. Also interesting is the PID loop auto-tuning function he programmed into Bigfoot; press a button and the controller automatically ramps the motor speed up and down and stores the coefficients in memory. Nice!
The short video below shows Bigfoot in action with varying thicknesses of faux leather; there are also some clips in the original article that show the machine dealing with a triple thickness of leather at slow speed and not even breaking a sweat. Hats off to [Joseph] on a solid build that keeps a classic machine in the game. And if you want to get into the textile arts but don’t know where to start, we’ve got you covered.
It’s easier than ever to build your own robot, but humans have been building automatons since before anyone had even thought of electronics. One beautiful example is the Silver Swan, built in the 18th century.
The brainchild of [John Joseph Merlin] and silversmith [James Cox], the swan features three separate clockwork drives, appearing to swim in a moving river where it snatches fish in its motorized beak. Mark Twain said the swan had “a living grace about his movements and living intelligence in his eyes” when he saw it at the International Exhibition in Paris in 1867.
The swan has been delighting people for 250 years, and recently received some much-deserved maintenance. In the video below, you can see museum staff disassembling the swan including its 113 neck rings which protect the three different chain drives controlling its lifelike motions. Hopefully, with some maintenance, this automaton will still be going strong in 2273.
The world once ran on hardcopy, and when the digital age started to bring new tools and ways of doing things, documents were ripe for change. Today, word processors and digital documents are so ubiquitous that they are hardly worth a thought, but that didn’t happen all at once. [Cathode Ray Dude] has a soft spot for old word processors and the journey they took over decades, and he walks through the Olivetti ETV 2700.
The ETV 2700 is a monstrous machine; a fusion of old-school word processor, x86-based hardware, and electric 17 inch-wide typewriter.
With it one could boot up a word processor that is nothing like the WYSIWYG of today, write and edit a document, and upon command, the typewriter portion could electronically type out a page. A bit like a printer, but it really is an electric typewriter with a computer interface. Characters were hammered out one at a time with daisy wheel and ink ribbon on a manually-loaded page using all the usual typewriter controls.
While internally the machine has an x86 processor, expects a monitor and even boots MS-DOS, the keyboard had its own layout (and even proprietary keys and functions), did not support graphical output, and in other ways was unusual even by the standards of the oddball decades during which designers and products experimented with figuring out what worked best in terms of functionality and usability.
Have you ever wondered how induction cooking works? A rotating magnetic field — electrically or mechanically — induces eddy currents in aluminum and that generates heat. When [3D Sage] learned this, he decided to try to 3D print some mechanical rigs to spin magnets so he could try cooking with them.
We doubt at all that this is practical, but we have to admit it is fun and there are some pretty impressive 3D prints in the video, too. The cook surface, by the way, is tiny, so you won’t be prepping a holiday meal on it. But there’s something super charming about the tiny breakfast on a plate produced by a printed magnetic “stove.” We would be interested to know how much power this setup consumed and how much heat was produced compared to, say, just using a big resistor to heat things up.
Cathode-Retro is a collection of shaders and sample C++ code for reliving the glorious days when graphics were composite video signals displayed on a CRT screen. How? By faking it in software and providing more configuration options than any authentic setup ever had.
Not satisfied with creating CRT-style color images with optional scanlines and TV picture controls like tint and saturation, Cathode-Retro can emulate more nuanced elements as well.
The tool includes the ability to imitate things like the slight distortion of a period-correct curved screen, the subtle effects of different methods CRT displays used to actually work (such as shadow mask vs aperture grille), and even taking into account the slight distortion of light refracting imperfectly through the glass face of the CRT. There’s even options for adding noise and ghosting, which may spark some artistic ideas.
If all you need is software to recreate an old-school CRT terminal, we have you covered. But if your needs are a bit more low-level, Cathode-Retro might be what you’re missing.
The software for the Supercon badge went down to the wire this year, with user-facing features being coded up as late as Thursday morning. This left “plenty of time” to flash the badges on Thursday afternoon, but they were admittedly still warm as the first attendees filed in on Friday morning. While I’ve always noted that the last minute is the best minute, this was a little close, and frankly there was an uncaught bug that we would have noticed if we had a few more hours to just play with it before showtime.
But we were by no means slacking. On the contrary, a few of us were putting in nights and full weekend days for six or eight weeks beforehand. The problem was hard, and the path to a solution was never clear, and changed depending on the immovability of the roadblocks hit along the way. This is, honestly, a pretty normal hacker development pattern.
What was interesting to me was how similar the process was to simulated annealing. This is an optimization method where you explore more of the solution space in the beginning, when the metaphorical “temperature” is hot. Later, as you’re getting closer to a good solution, you want to refine in smaller and smaller steps – it cools down. This rate of “cooling” is a tremendously important parameter in practice.
And this is exactly the way the badge development felt. We were searching in a very big solution space in the beginning, and many aspects of the firmware infrastructure were in flux. As it got closer and closer to a working solution, more and more of the code settled down, and the changes got smaller. In retrospect, this happened naturally, and you can’t always control or plan for the eureka moments, but I wonder if it’s worth thinking of a project this way. Instead of milestones, temperatures? Instead of a deadline, a freeze date.
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
It is an interesting fact that the most efficient way to generate electricity — at least so far — is to spin the shaft of a generator. The only real question is how you spin it. Falling water works. Heat from a nuclear reaction is another choice. For many decades, the king of the hill was steam. Now, however, gas turbines rule the electric generator landscape, and [Construction Physics] explains why in a recent post.
With a steam turbine, something burns or otherwise generates heat that boils water. The steam spins the blades, which turns the generator. With a gas turbine, the system compresses air and mixes it with gas. The hot gasses then drive the turbine, which is more efficient than using the combustion to produce steam.
Turns out, the idea for the gas turbine is very old, but material science had to catch up to be practical. Inefficient compressors led to low operating pressures, which was good, in a way, because the materials couldn’t stand the heat and pressure. However, low pressures led to inefficient turbines that were not practical.
The post is long and covers a lot of details about Carnot, Brayton, and Rankine cycles. It is a fascinating read, and we learned a few new things. Bet you will, too.
Turbines are a little like jet engines, but they transfer more power to the turbine blade instead of generating thrust. Turbines show up in odd places today. Some odder than others.