If we had to make a guess at the single piece of electronic bench equipment owned by the highest proportion of Hackaday readers, it would not be a budget oscilloscope from Rigol, nor would it be a popular portable soldering iron like the TS100. Instead we’re guessing that it’s a multimeter, and not even the most accomplished one.
The DT830 is a genericised Chinese-manufactured 3.5 digit digital multimeter that can be had for an astonishingly low price. Less than a decent hamburger gets you an instantly recognisable plastic case with a chunky rotary range selector switch, and maybe a socket for some kind of transistor or component tester. Make sure that there is a 9 volt battery installed, plug in the pair of test leads, and you’re in business for almost any day-to-day electrical or electronic measurement. They’ve been available in one form or another for decades and have been the subject of innumerable give-aways and loss-leader offers, so it’s a reasonsble guess that you’ll have one somewhere. I have three as far as I know, they make great on-the-go instruments and have proved themselves surprisingly reliable for what they are. Continue reading “In Praise Of The DT830, The Phenomenal Instrument You Probably Don’t Recognise For What It Is”→
Mike and I were talking about two very similar clock projects we’d both built recently: they both use ESP8266 modules to get the time over WiFi and NTP, and they both failed. Mike’s failed because he was visiting relatives in a different timezone with different WiFi credentials, and mine failed because daylight savings time caught me off-guard. In both cases, we hard-coded stuff that could obviously change, but we drew vastly different conclusions.
Mike thought he’d solve his WiFi problem with a fallback to a captive portal, and maybe would have to figure out some web interface for configuring the timezone. A very clean, professional solution. Me? I’ve got good comments in the code, can find the UTC offset (or the WiFi creds) in a few minutes, and flash the new version up simply by fetching a USB cable, for something that happens twice a year. It’s hardly worth the trouble to cobble together a web interface.
There’s an XKCD for everything.
We’ve accidentally embodied a quandary that spans both the hardware and software worlds: should flexibility be exposed to the end-user or to the hacker who can peer under the hood or open up the source code? (And what if the end-user is the hacker?) What are the tradeoffs, in project complexity and in ease of use?
And in this, Mike is on the side of right and good, and I’m the heretic. I don’t always write my code to be extensible or re-usable. I sometimes write it to be quickly re-edited and patched whenever I need to. Is it full of magic numbers? Sure! But I know just where they are and how to change them. Heck, most are even well documented in their own header file. You could probably figure it out just about as fast. Would my father-in-law be able to tweak the timezone? Nope! But this ain’t his project anyway.
Dare to code for hackers! Don’t over-generalize or over-abstract. Less is more. Don’t be afraid to edit code. Tweak, compile, and re-flash when the situation changes. After all, that’s how you got the code there in the first place.
And although I’m on the wrong end of history, in this case I was right. You see, before daylight savings time could come around again, and I could have made use of that captive portal that I didn’t bother coding up anyway, my son entered first grade. Everything needs to be changed, from the hardware to the software. Will I code up the next version with flexible time regimes? As flexible as I need it to be, but not more.
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!
Last week, I wrote about two recent projects of mine that serve as cautionary tales in keeping projects simple — you probably can’t simplify everything, so it’s worth the time to find out which simplifications have the most bang for the buck. This week, I’d like to share a tale of lack of design focus.
German has the eierlegende Wollmilchsau: a mystical animal that lays eggs, while producing wool, milk, and meat to boot. It’s a little bit like the English “jack of all trades, master of none” except that the eierlegende Wollmilchsau doesn’t do each job badly, it plainly can’t exist. This is obviously a bad way to start a design.
The first surfboard that I made by myself was supposed to be an eierlegende Wollmilchsau. It was going to be a longboard, because we had months with smaller waves that just weren’t all that suitable for shortboarding, but it was also going to turn sharply off the rails like a shortboard. To help it turn, it was going to have tons of camber (bend like a banana), and small fins. And along the way, I thought I’d make it thin to cut through the water.
Of course what I ended up with, not helped by my heavy fiberglassing hand, was a plow that dug into the water, would turn unexpectedly when you managed to get it onto the rails, and couldn’t pick up a small wave to save its life due to the camber and aforementioned plowing. I surfed it anyway, as a matter of pride, but I had no illusions of it being anything but the the worst board I owned. And that’s comparing it to the $30 used rasta-graphic plank that had been taking on water for at least five years, unrepaired, and was rotting out from the inside. At least it had design focus.
My surfboard didn’t suffer from feature creep, where you start piling on features until the project crumbles from overload, but rather from wanting to have my cake and eat it too. Or from failing to realize that certain design goals were necessarily tradeoffs. The “raily” behavior that I wanted when it was in bigger waves was necessarily “diggy” in small waves. Good boards trade off these features, and getting the balance between them is the art of shaping a board.
So when you start up a new project, think about which facets of your design are jointly achievable, and which are necessarily tradeoffs. Ignoring tradeoffs is a recipe for disaster, designing an eierlegende Wollmilchsau. But viewed constructively, it’s exactly these nuanced decisions that separates the simply possible from the truly marvelous. May you identify your trades, and make them well!
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!
“Keep it simple” sounds like such good advice, but what exactly is the “it”; what parts of a project should you try to keep simple? You can’t always make everything simple, can you? Are all kinds of “simplicity” equally valuable, or are there aspects of a design where simplicity has multiplier effects on the rest of the project?
I ran into two seemingly different, but surprisingly similar, design problems in the last couple weeks, and I realized that focusing on keeping one aspect of the project simple had a multiplier effect on the rest — simplifying the right part of the problem made everything drastically easier.
The first example was a scratch-built airplane design. I’d made a few planes over the summer, focusing on plans on the Interwebs that emphasize simplicity of the actual build. Consequently, the planes were a bit heavy, maybe not entirely aerodynamic, and probably underpowered. And this is because the effort you expend building the plane doesn’t fundamentally have anything to do with flight. Keeping the build simple doesn’t necessarily get you a good plane.
Weight, on the other hand, is central. Wings produce lift, whether measured in grams or ounces, and anything heavier just isn’t gonna fly. But reducing weight has a multiplier effect. Less weight means smaller and lighter motors and batteries. Structures don’t need to be as stiff if they’re not subject to heavier bending forces. And, important to the noob pilot, planes with less weight per wing area fly slower, giving me (ahem, the noob pilot) more reaction time when something goes sideways. Trying to simplify the design by trimming weight has knock-on effects all around.
My latest fully-DIY design threw out anything that brought weight along with it, including some parts I thought were necessary for stiffness or crash resistance. But with the significantly lowered weight, these problems evaporated without needing me to solve them — in a way, the complexity of design was creating the problems that the complexity of design was supposed to solve. Ditching it meant that I had a slow plane, with simple-to-build wings, that’s capable of carrying a lightweight FPV camera. Done and done! Simply.
Nope. Too complex.
At the same time, I’m building a four-axis CNC foam cutter. I’ve built many 3D printers, and played around with other folks’ DIY CNC machines, so I had a few design ideas in my head starting out. My first iteration of an XY axis for the machine runs on metal angle stock with a whopping eight skate bearings per axis. It’s strong and rigid, and clumsy and overkill, in a bad way for this machine.
3D printers want to move a relatively light tool head around a small volume, but relatively quickly. CNC mills need to be extremely rigid and shoulder heavy side loads, subject to some speed constraints. A foam cutter has none of these needs. The hot wire melts the foam by radiation, so there are no loads on the machine because it doesn’t even contact the workpiece. And because it cuts by melting, it has to go slow. These are the places in the design where simplification will bear the most fruit.
I write this in retrospect, or at least from the perspective of a second prototype. I wanted the first design to hold the cutting filament taut, hence the rigid frame. But separating the tension from the motion, by using a lightweight external bow to keep the filament tight, meant that the machine could be dead simple. I could use smaller plastic sliders instead of complex bearings, on thin rods instead of bulky rails. In a day after having this realization, I got twice as far as I had on the previous machine design in a week, and it takes up a lot less space in my basement.
So take your KISS to the next level. Brainstorm a while about the binding constraints on your design, and what relaxing any of them can do. Do any particular simplifications enable further simplifications? Those are the ones that you want to start with. Keep it simple, smartly. And because it’s not always easy to find these multiplier effects, tell your friends!
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!
This week our own [Donald Papp] wrote a thought-provoking piece on buying and selling 3D-printer models. His basic point: if you don’t know what you’re getting until you’ve purchased it, and there’s no refund policy, how can you tell if your money is being well spent? It’s a serious problem for these nascent markets, because when customers aren’t satisfied they won’t come back.
It got me thinking about my own experience, albeit with all of the free 3D models out there. They are a supremely mixed bag, and even though you’re not paying for the model, you’re paying in printing time, filament, and effort. It pays to be choosy, and all of [Donald]’s suggestions hold in the “free” market as well.
Only download models that have been printed at least once, have decent documentation about things like layer height, filament type, and support, and to the best of your abilities, be critical about the ability to fabricate the part at all. Fused-deposition printers can only print on top of previous layers, and have a distinct grain, so you need to watch out for overhangs and print orientation. With resin printers, you need to be careful about trapped volumes of uncured resin. You want to be sure that the modeler at least took these considerations into account.
But when your parts have strength requirements, fits, and tolerances, it gets even worse. There’s almost no way a designer can know if you’re overextruding on your first layers or not. Different slicers handle corners differently, making inner surfaces shrink to varying degrees. How can the designer work around your particular situation?
My personal answer is open-source. Whenever possible, I prefer models in OpenSCAD. If you download an STL with ten M8 bolt holes, you could widen them all in a modeling program, but if you’ve got the source code, it’s as easy as changing a single variable. Using the source plays to the customizability of 3D printing, which is perhaps its strongest suit, in my mind. Nobody knows exactly how thick your desk is but you, after all. Making a headphone hook that’s customizable is key.
So even if the markets for 3D prints can solve the reliability problems, through customer reviews or requirements of extensive documentation, they’ll never be able to solve the one-size-fits-nobody issue. Open source fixes this easily. Sell me the source, not the STL!
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!
The OpenStreetMap project is an excellent example of how powerful crowdsourced data can be, but that’s not to say the system is perfect. Invalid data, added intentionally or otherwise, can sometimes slip through the cracks and lead to some interesting problems. A fact that developers Asobo Studio are becoming keenly aware of as players explore their recently released Microsoft Flight Simulator 2020.
Like a Wiki, users can update OpenStreetMap and about a year ago, user nathanwright120 marked a 2 story building near Melbourne, Australia as having an incredible 212 floors (we think it’s this commit). The rest of his edits seem legitimate enough, so it’s a safe bet that it was simply a typo made in haste. The sort of thing that could happen to anyone. Not long after, thanks to the beauty of open source, another user picked up on the error and got it fixed up.
But not before some script written by Asobo Studio went through sucked up the OpenStreetMap data for Australia and implemented it into their virtual recreation of the planet. The result is that the hotly anticipated flight simulator now features a majestic structure in the Melbourne skyline that rises far above…everything.
The whole thing is great fun, and honestly, players probably wouldn’t even mind if it got left in as a Easter egg. It’s certainly providing them with some free publicity; in the video below you can see a player by the name of Conor O’Kane land his aircraft on the dizzying edifice, a feat which has earned him nearly 100,000 views in just a few days.
But it does have us thinking about filtering crowdsourced data. If you ask random people to, say, identify flying saucers in NASA footage, how do you filter that? You probably don’t want to take one person’s input as authoritative. What about 10 people? Or a hundred?
People sometimes say “when you have a hammer, everything looks like a nail” as if that were a bad thing. Hitting up Wikipedia, they’re calling it the Law of the Instrument or Maslow’s Hammer and calling it a cognitive bias. But I like hammers…
I’m working on a new tool, a four-axis hot-wire foam cutter based roughly on this design, but built out of stuff in my basement so far. I want it primarily to turn out wings for RC airplanes so that I can play around with airfoils and construction methods and so on. But halfway through building this new “hammer”, I’m already getting funny ideas of other projects that could be built with it. Classic nail-seeking behavior.
And some of these thoughts are making me reconsider the design of my hammer. I originally wanted to build it low, because it’s not likely that I’ll ever want to cut wing sections taller than 50 mm or so. But as soon as cutting out giant letters to decorate my son’s room, or maybe parts for a boat hull enter my mind, that means a significantly taller cutter, with ensuing complications.
So here I am suffering simultaneously from Maslow’s Hammer and scope creep, but I’m not sad about either of these “ills”. Playing with a couple manual prototypes for the CNC hot-wire cutter has expanded my design vocabulary; I’ve thought of a couple cool projects that I simply wouldn’t have had the mental map for before. Having tools expands the possible ways you can build, cognitive bias or not.
One person’s scope creep is another’s “fully realizing the potential of a project”. I’m pretty sure that I’ll build a version two of this machine anyway, so maybe it’s not a big deal if the first draft were height-limited, but the process of thinking through the height problem has actually lead me to a better design even for the short cutter. (Tension provided by an external bow instead of born by the vertical CNC towers. I’ll write the project up when I’m done. But that’s not the point.)
Maybe instead of lamenting Maslow’s cognitive bias, we should be celebrating the other side of the same coin: that nails are tremendously useful, and that the simple fact of having a hammer can lead you to fully appreciate them, and in turn expand what you’re capable of. As for scope creep? As long as I get the project done over my vacation next week, all’s well, right?
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!