This excellent content from the Hackaday writing crew highlights recurring topics and popular series like Linux-Fu, 3D-Printering, Hackaday Links, This Week in Security, Inputs of Interest, Profiles in Science, Retrotechtacular, Ask Hackaday, Teardowns, Reviews, and many more.
In everyday life, the largest moving object most people are likely to encounter is probably a train. Watching a train rolling along a track, it’s hard not to be impressed with the vast amount of power needed to put what might be a mile-long string of hopper cars carrying megatons of freight into motion.
But it’s the other side of that coin — the engineering needed to keep that train under control and eventually get it to stop — that’s the subject of this gem from British Transport Films on “The Power to Stop.” On the face of it, stopping a train isn’t exactly high-technology; the technique of pressing cast-iron brake shoes against the wheels was largely unchanged in the 100 years prior to the making of this 1979 film. The interesting thing here is the discovery that the metallurgy of the iron used for brakes has a huge impact on braking efficiency and safety. And given that British Railways was going through about 3.5 million brake shoes a year at the time, anything that could make them last even a little longer could result in significant savings.
It was the safety of railway brakes, though, that led to research into how they can be improved. Noting that cast iron is brittle, prone to rapid wear, and liable to create showers of dangerous sparks, the research arm of British Railways undertook a study of the phosphorus content of the cast iron, to find the best mix for the job. They turned to an impressively energetic brake dynamometer for their tests, where it turned out that increasing the amount of the trace element greatly reduced wear and sparking while reducing braking times.
Although we’re all for safety, we have to admit that some of the rooster-tails of sparks thrown off by the low-phosphorus shoes were pretty spectacular. Still, it’s interesting to see just how much thought and effort went into optimizing something so seemingly simple. Think about that the next time you watch a train go by.
It’s no surprise that the hacking and making community has traditionally had something of a love affair with movie props, especially those of the science fiction variety. Over the years we’ve seen folks put untold hours into incredible recreations of their favorite pieces of fictional gear — and by the time this post goes out, our 2022 Sci-Fi Contest will be entering into the final stretch. So it’s a safe bet that if you make your living by creating the electronics behind all that Hollywood movie magic, you’ll find ours to be an especially welcoming community.
We were fortunate enough to see this in action this week when Ben Eadie stopped by to host the Hack Chat. It’s no exaggeration to say that he’s been living out what most of us would consider a dream, having worked on films from iconic franchises such as Star Trek and Predator. But perhaps his most enviable credit is that of propmaster for 2021’s Ghostbusters: Afterlife, where he got the chance to work on the proton packs and ghost traps; arguably some of the most well-known props in the history of cinema.
Not bad for a guy who only recently got in the game. Ben spent 20 years working as an aerounatical engineer until a friend from his local maker space mentioned they were working on a film and could use a hand. Suddenly he found himself behind the scenes of Star Trek: Beyond in 2015, helping to design and fabricate one of the largest rotating sets ever made. He figures he must have done something right, because Hollywood has been calling ever since.
This anecdote about his first time working on a feature film helped answer what many wanted to know early on in the Chat, which was how one manages to get into the prop and special effects industry. Ben once again confirmed a truth well known to this community: that what you’re capable of is far more important than where you went to school and what you studied. There’s not a lot of formal education out there that can train you to make the impossible possible, and Ben says the majority of his day-to-day knowledge came from a lifetime of fiddling around with electronics. In fact, he attributes much of his professional success with hanging out in maker spaces, reading Hackaday, and watching YouTube. If that’s the recipe, then we should all be in pretty good shape.
Over the last few years, Ben has been trying to pay that forward by documenting some of the tricks of the trade on his own YouTube channel. In a particularly interesting piece of marketing on Sony’s part, some of Ben’s videos have even been featured on the official Ghostbusters YouTube channel as part of a “Maker Monday” series. In fact, we first got in contact with Ben when he left a comment on our coverage of his “PKE Meter” prop build. This is the kind of advertisement we can get behind, and wish more companies would embrace the hacker and maker culture with this kind of interactive content. Ben says the best way to make initiatives like this more popular is to consume it — if Sony sees people watching and sharing this kind of content, hopefully more will follow.
Of course, it wouldn’t be a Hack Chat unless some arcane compartmentalized technical knowledge was dished out. In this case, several of the questions were about the unique challenges posed by operating custom electronics on a movie set. For example, Ben says he always uses addressable LEDs controlled by the APA102 chip as it offers an external clock pin that he can feed with a different frequency to avoid on-screen flickering. The radio spectrum also tends to be pretty noisy on set, so if at all possible, you want to make sure your gear has a wired connection. Otherwise, you’ll need to get intimately acquainted with what other RF signals are being used on set so as not to interfere with the production.
Ben’s creations include the Remote Trap Vehicle (RTV) from Ghostbusters: Afterlife.
But while some of the challenges he has to deal with might seem pretty foreign to us, the technology itself is in some cases more familiar than you might think. It turns out there’s plenty of Sparkfun and Adafruit gear behind the scenes, with Ben specifically mentioning the Feather nRF52 as one of his go-to microcontrollers. Sometimes the graybeards on set grumble about his “consumer grade” tech, but when his gear is up and running in half the time, it’s usually he who gets the last laugh.
Towards the end of the Chat, Ben says the most important thing he’s learned over the years is to always have backups. His motto is “One is None”, and if he can help it, he usually builds four of everything: that gives him two to learn from, and a pair to actually use for whatever the project is. Even if our own projects don’t quite rise to the level of a key prop from a summer blockbuster, there’s no certainly no harm in being prepared.
We want to thank Ben Eadie for taking the time to talk with the community and sharing some of his fascinating stories and tips with us. At the risk of sounding a bit sappy, stories like his are what motivates us here at Hackaday. If we can provide even a small part of the what it takes to help people like Ben achieve their goals, that’s reason enough for us to keep the lights on.
The Hack Chat is a weekly online chat session hosted by leading experts from all corners of the hardware hacking universe. It’s a great way for hackers connect in a fun and informal way, but if you can’t make it live, these overview posts as well as the transcripts posted to Hackaday.io make sure you don’t miss out.
Join Hackaday Editor-in-Chief Elliot Williams and Assignments Editor Kristina Panos as we gab about the most interesting hacks and stories of the previous week. This time, we start off by marveling over everything happening this weekend. Most urgently, it’s your last chance to enter the 2022 Sci-Fi contest, which closes Monday, April 25th at 8:30 AM Pacific Time sharp. Already got your hat in the ring? If you’re anywhere in the neighborhood of New Jersey, don’t miss the VCF’s Vintage Computer Festival East. Don’t want to leave the house? Then check out all the talks that start approximately right now, assuming you get your Hackaday Podcasts hot off the server.
In this episode, we’ll fawn over a KiCAD plug-in that gives your PCBs that old-timey look, discuss ancient telephone exchanges and the finest in 70s-era custom telephones, and dream about building a wall of sound out of Raspberry Pis. Then we’ll talk about awesome old printers and the elegance of RSS feeds, developing your own digital film, and a really cool line follower robot that works without a brain. Stay with us to find out where Kristina likes her taskbar, and we’ll tell you the cool-kid name for the the Commodore key.
Java versions 15, 16, 17, and 18 (and maybe some older versions) have a big problem, ECDSA signature verification is totally broken. The story is a prime example of the dangers of unintended consequences, the pitfall of rolling your own crypto, and why to build a test suite for important code. In Java 15, the ECDSA verification code was re-written, moving the code from C++ to a Java-native implementation. The new code misses an important check, that the initialization and proof values are both non-zero.
If you are a Star Trek fan, you’ll probably remember the phrase “You have to learn why things work on a starship.” The truth is, in most episodes, knowing how to override another ship’s console or make gunpowder didn’t come in very handy, but boy when it did, it really saved the day. Linux is a lot like that. There are a few things you probably don’t need to know very often, but when you do need to know, it makes a huge difference. In this particular post, I want to look at an odd use of the fork system call. For many purposes, you’ll never need to know this particular irregular use. But when you need it, you are really going to need it.
This is actually based on an old client of mine who used Unix to run a massive and very critical report every day. The report had a lot of math since they were trying to optimize something and then generate a lot of reports. In those days, the output of the report was on old green-bar paper on a line printer. The problem was that the report took something like 14 hours to run including the printouts. If someone discovered something wrong, there was no time to run the report again because the next day’s report would have to start before the second run would finish.
The client had a bunch of Windows programmers and — at that time — there wasn’t anything really analogous to a real fork call in Windows. I looked at the code and realized that probably most of the code was spending time waiting to print the output. The computer had multiple CPUs and there were multiple printers, but that one program was hanging on the one printer. There was a lot of data, so writing it to a database and then running different reports against it wasn’t a great option. The answer was to use the power of fork. With a change in the code that took less than 30 minutes, the report ran in five hours. They were very pleased.
So how did I do it? The answer lies in how fork works. Just about every time you see a fork, you see some sort of exec call to start a new program. So if you think about fork at all, you probably think it is part of how you start a new program and, most of the time, that’s true. Continue reading “Linux Fu: An Odd Use For Fork()”→
As you may have noticed, I’ve been working with an STM32 ARM CPU using Mbed. There was a time when Mbed was pretty simple, but a lot has changed since it has morphed into Mbed OS. Unfortunately, that means that a lot of libraries and examples you can find don’t work with the newer system.
I needed a rotary encoder — I pulled a cheap one out of one of those “49 boards for Arduino” kits you see around. Not the finest encoder in the land, I’m sure, but it should do the job. Unfortunately, Mbed OS doesn’t have a driver for an encoder and the first few third-party libraries I found either worked via polling or wouldn’t compile with the latest Mbed. Of course, reading an encoder isn’t a mysterious process. How hard can it be to write the code yourself? How hard, indeed. I thought I’d share my code and the process of how I got there.
There are many ways you can read a rotary encoder. Some are probably better than my method. Also, these cheap mechanical encoders are terrible. If you were trying to do precision work, you should probably be looking at a different technology like an optical encoder. I mention this because it is nearly impossible to read one of these flawlessly.
So my goal was simple: I wanted something interrupt driven. Most of what I found required you to periodically call some function or set up a timer interrupt. Then they built a state machine to track the encoder. That’s fine, but it means you eat up a lot of processor just to check in on the encoder even if it isn’t moving. The STM32 CPU can easily interrupt with a pin changes, so that’s what I wanted.
The Catch
The problem is, of course, that mechanical switches bounce. So you have to filter that bounce either in hardware or software. I really didn’t want to put in any extra hardware more than a capacitor, so the software would have to handle it.
I also didn’t want to use any more interrupts than absolutely necessary. The Mbed system makes it easy to handle interrupts, but there is a bit of latency. Actually, after it was all over, I measured the latency and it isn’t that bad — I’ll talk about that a little later. Regardless, I had decided to try to use only a pair of interrupts.
Yeah, I’ll admit it: I’m a Windows person. Two years ago this summer, I traded in an overworked Windows 7 laptop that was literally screaming in pain for a SFF Windows 10 box as my main machine. But 10 might mean the end for this scribe, who has used Windows since the late 1980s. Admittedly, it’s for a fairly petty reason — Microsoft have gotten rid of alternate-location taskbar support in Windows 11. As in, you can have the taskbar anywhere you want, as long as it’s the bottom of the screen.
Years ago, I switched my taskbar to the top for various reasons. For one, it just made more sense to me to have everything at the top, and nothing at the bottom to interrupt visual flow while reading a web page or a document. Plenty of people move it to one of the sides or hide it when not in use for the same reason. More importantly, I thought moving the taskbar to the top would help with my neck/shoulder strain issues, and I believe that it has. So oddly enough, this one little thing may be the dealbreaker that gets me to switch after thirty-something years to Linux, where top-aligned taskbars are more or less the norm.
