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.
Imagine, if you will, the perfect electronics lab. Exactly how it looks in your mind will depend a lot upon personal preferences and brand loyalty, but chances are good it’ll be stocked to the gills with at least one every conceivable type of high-precision, laboratory-grade instrument you can think of. It’ll have oscilloscopes with ridiculously high bandwidths, multimeters with digits galore, logic analyzers, waveform generators, programmable power supplies, spectrum analyzers — pretty much anything and everything that can make chasing down problems and developing new circuits easier.
Alas, the dream of a lab like this crashes hard into realities like being able to afford so many instruments and actually finding a place to put them all. And so while we may covet the wall of instruments that people like Marco Reps or Kerry Wong enjoy, most of us settle for a small but targeted suite of instruments, tailored to our particular needs and budgets.
It doesn’t necessarily need to be that way, though, and with software-defined instrumentation, you can pack a lab full of virtual instruments into a single small box. Software-defined instrumentation has the potential to make an engineering lab portable enough for field-service teams, flexible enough for tactical engineering projects, and affordable for students and hobbyists alike.
Ben Nizette is Product Manager at Liquid Instruments, the leader in precision software-defined instrumentation. He’s the engineer behind Moku:Go, the company’s first consumer product, which squeezes eleven instruments into one slim, easily transported, affordable package. He’s been in the thick of software-defined instrumentation, and he’ll drop by the Hack Chat to talk about the pros and cons of the virtual engineering lab, what it means for engineering education, and how we as hobbyists can put it to work on our benches.
Wait, what? Is it possible that a tech company just killed off a product with a huge installed base of hardware and a community of dedicated users, and it wasn’t Google? Apparently not, if the stories of the sudden demise of Insteon are to be believed. The cloud-based home automation concern seems to have just disappeared — users report the service went offline at the end of last week, and hasn’t been back since. What’s more, the company’s executives removed Insteon from their LinkedIn profiles, and the CEO himself went so far as to remove his entire page from LinkedIn. The reasons behind the sudden disappearance remained a mystery until today, when The Register reported that Smartlabs, Inc., the parent company of Insteon, had become financially insolvent after an expected sale of the company failed in March. The fact that the company apparently knew this was going to happen weeks ago and never bothered to give the community a heads up before pulling the switches has led to a lot of hard feelings among the estimated 100,000 Insteonhub users.
Then again, with a comet the size of Rhode Island heading our way, a bunch of bricked smart bulbs might just be a moot point. The comet, known as C/2014 UN271, has a nucleus that is far larger than any previously discovered comet, which makes it a bit of an oddball and an exciting object to study. For those not familiar with the United States, Rhode Island is said to be a state wedged between Connecticut and Massachusetts, but even having lived in both those states, we couldn’t vouch for that. For scale, it’s about 80 miles (128 km) across, or a little bit bigger than Luxembourg, which we’re pretty sure is mythical, too. The comet is a couple of billion miles away at this point; it may never get closer than a billion miles from the Sun, and that in 2031. But given the way things have been going these last few years, we’re not banking on anything.
From the “Answering the Important Questions” file, news this week of the Massachusetts Institute of Technology’s breakthrough development of the “Oreometer,” a device to characterize the physical properties of Oreo cookies. The 3D printed device is capable of clamping onto the wafer parts of the popular sandwich cookie while applying axial torque. The yield strength of the tasty goop gluing the two wafers together can be analyzed, with particular emphasis on elucidating why it always seems to stay primarily on one wafer. Thoughtfully, the MIT folks made the Oreometer models available to one and all, so you can print one up and start your own line of cookie-related research. As a starting point, maybe take a look at the shear strength of the different flavors of Oreo, which might answer why the world needs Carrot Cake Oreos.
And finally, since we mentioned the word “skiving” last week in this space, it seems like the all-knowing algorithm has taken it upon itself to throw this fascinating look at bookbinding into our feed. We’re not complaining, mind you; the look inside Dublin’s J.E. Newman and Sons bookbinding shop, circa 1981, was worth every second of the 23-minute video. Absolutely everything was done by hand back then, and we’d imagine that very little has changed in the shop over the ensuing decades. The detail work is incredible, especially considering that very few jigs or fixtures are used to ensure that everything lines up. By the way, “skiving” in this case refers to the process of thinning out leather using a razor-sharp knife held on a bias to the material. It’s similar to the just-as-fascinating process used to make heat sinks that we happened upon last week.
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()”→
Ben Nizette is Product Manager at Liquid Instruments, the leader in precision software-defined instrumentation. He’s the engineer behind Moku:Go, the company’s first consumer product, which squeezes eleven instruments into one slim, easily transported, affordable package. He’s been in the thick of software-defined instrumentation, and he’ll drop by the Hack Chat to talk about the pros and cons of the virtual engineering lab, what it means for engineering education, and how we as hobbyists can put it to work on our benches.
