Should I Automate This?

May 15, 2021 by Elliot Williams 65 Comments

The short answer to the question posed in the headline: yes.

For the long answer, you have to do a little math. How much total time you will save by automating, over some reasonable horizon? It’s a simple product of how much time per occurrence, times how many times per day it happens, times the number of days in your horizon. Or skip out on the math because there’s an XKCD for that.

What’s fun about this table is that it’s kind of a Rorschach test that gives you insight into how much you suffer from automatitis. I always thought that Randall was trying to convince himself not to undertake (fun) automation projects, because that was my condition at the time. Looking at it from my current perspective, it’s a little bit shocking that something that’ll save you five seconds, five times a day, is worth spending twelve hours on. I’ve got some automating to do.

To whit: I use pass as my password manager because it’s ultimately flexible, simple, and failsafe. It stores passwords on my hard drive, and my backup server, encrypted with a GPG key that I have printed out on paper in a fireproof safe. Because I practice good cookie hygiene, I end up re-entering my passwords daily. Because I keep my passwords separate from my browser, that means entering username and password by cut-and-paste. There’s your five seconds, five times per day. Maybe two seconds, ten times, but it’s all the same. It shouldn’t take me even as long as twenty minutes to whip up a script that puts username and password into selection and clipboard for one-click pasting. Why haven’t I done this yet? I’m going to get on it as soon as I’m done with this newsletter.

But the this begs the question. If you spend up to twelve hours on every possible 25-second-per-day savings, when will you ever get your real work done? Again, math gives us the answer. One eight-hour workday * 25 seconds * 12 hours (pessimistically) of labor = 1.58 years before everything that needs automating will be. Next week’s newsletter might be a little bit delayed.

What do you see in the XKCD “Is it worth the time” table? Automate more, or step back from the cliff edge?

Reinventing The Wheel

May 8, 2021 by Elliot Williams 62 Comments

You’ve got a perfectly working software library to do just exactly what you want. Why aren’t you using it? Some of you are already yelling something about NIH syndrome or reinventing the wheel — I hear you. But at least sometimes, there’s a good enough reason to reinvent the wheel: let’s say you want to learn something.

Mike and I were talking about a cool hack on the podcast: a library that makes a floppy drive work with an Arduino, and even builds out a minimalistic DOS for it. The one thing that [David Hansel] didn’t do by himself was write the FAT library; he used the ever-popular FatFS by [Elm-ChaN]. Mike casually noted that he’s always wanted to write his own FAT library from scratch, just to learn how it works at the fundamental level, and I didn’t even bat an eyelash. Heck, if I had the time, I’d want to do that too!

Look around on Hackaday, and you’ll see tons of hacks where people reinvent the wheel. In this superb soundbar hack, [Michal] spends a while working on the IR protocol by hand until succumbing to the call of IRMP, a library that has it all done for you. But if you read his writeup, he’s not sad; he learned something about IR protocols. This I2C paper tape reader is nothing if not a reinvention of the I2C wheel, but isn’t that the best way to learn?

Yes it is. Think back to the last class you took. The teacher or professor certainly explained something to you in reasonable detail — that’s the job after all. And then you got some homework to do by yourself, and you did it, even though you were probably just going over the same stuff that the prof and countless others have gone through. But by doing it yourself, even though it was “reinventing the wheel”, you learned the material. And I’d wager that you wouldn’t have learned it without.

Of course, when the chips are down and the deadline is breathing hot down your neck, that might be the right time to just include that tried-and-true library. But if you really want to learn something yourself, you have every right to reinvent the wheel.

If You Can Measure It, You Must Display It

May 1, 2021 by Elliot Williams 16 Comments

When can you be sure that you’re logging enough data? When you’re logging all of the data! Of course there are exceptions to the above tongue-in-cheek maxim, but it’s certainly a good start. Especially since data storage on, for instance, an SD card is so easy and cheap these days, there’s almost no reason to not record most every little bit of data that your project can produce. Even without an SD card, many microcontrollers have enough onboard flash, or heck even RAM, to handle whatever you throw at them. The trick, then, is to make sense out of that data, and for me at least, that often means drawing pretty pictures.

I was impressed this week by a simple but elegant stepper motor diagnosis tool hacked together by [Zapta]. Essentially, it’s a simple device: it’s a “Black Pill” dev board, two current sensors, an EEPROM for storing settings, and a touchscreen. Given that most of us with 3D printers rely on stepper motors to get the job done, it’s certainly interesting to do some diagnostics.

By logging voltage and current measurement on each phase of a stepper motor, you can learn a lot about what’s going on, at least if you can visualize all that data. And that’s where [Zapta]’s tool shines. It plots current vs motor speed to detect impedance problems. Tuning the current in the first place is a snap with Lissajous patterns, and it’ll track your extruder’s progress or look out for skipped steps for you across an entire print job. It does all this with many carefully targeted graphs.

I was talking to [Niklas Roy] about this, and he said “oh check out my hoverboard battery logger“. Here we go again! It sits inline with the battery and logs current and voltage, charging or discharging. Graphs let you visualize power usage over time, and a real-time-clock lets you sync it with video of using the hoverboard to help make even more sense of the data.

So what are you waiting for? Sensors are cheap, storage is cheap, and utilities to graph your data after the fact are plentiful. If you’re not logging all the relevant data, you’re missing out on some valuable insights. And if you are, we’d love to see your projects! (Hint, hint.)

Hack The Cloud!

April 24, 2021 by Elliot Williams 33 Comments

The obvious rants against software or services “in the cloud” are that you don’t own it, your data isn’t on your own hard drive, or that, when the interwebs are down, you just can’t get your work done. But the one that really grinds my gears is that, at least for many cloud services, you just can’t play around with them. Why does that matter? Well, as a hacker type, of course, I like to fool around, but more deeply, I feel that this invitation to play around is what’s going to grow up the next generation of hackers. Openness matters not just for now, but also for the future.

Of course, it’s unfair to pin all of this on the cloud. There are plenty of services with nice open APIs that let you play around with their systems as much as you want — witness the abundance of amusing things you can do with Twitter or Twitch. Still, every day seems to bring another formerly-open API that gets bought up by some wealthy company and shut down. I built a nice “is it going to rain today” display out of a meter-long WS2812 strip and an ESP8266, but Dark Sky API got bought up by Apple and is going dark soon (tee-hee!) leaving me thinking of how I’m going to get easy weather data in the next few months.

Or take my e-mail annunciator. I wrote a little script that, when I have new mail that’s work related or from my wife (read: important), it displays the subject line on a VFD that I have perched on my monitor. This works with Gmail, which I have to use for work, because they support IMAP so at least I can do cool things with the mail once it reaches my server. But can I do anything with Google Groups, which we use for the Hackaday Tip Line? Fat chance!

So there’s good “cloud” and there’s bad “cloud”. Good cloud is open cloud. Good cloud invites you to play, to innovate, and to come up with the right solutions for yourself. Good cloud gives you access to your data. Good cloud is hackable cloud. Let’s see more of that.

The Last Days Of The Wild West

April 10, 2021 by Elliot Williams 21 Comments

We loved it a few weeks ago when an international team of hackers managed to record and decode telemetry and images from SpaceX launches. And now it looks like SpaceX has started encrypting it all in response. Booo!

Decoding satellite and other space ship transmissions has been a great hacker pastime. Most recently, we’ve seen a group working on listening in to the Chinese Tianwen-1 Mars probe shortly after its launch, but listening to the Deep Space Network or even just decoding weather satellite broadcasts can give folks a reason to stretch their radio muscles.

We understand that SpaceX runs some contract missions for US gov’t agencies that don’t appreciate leaking info about their satellite’s whereabouts, but for non-secret missions, we don’t see the harm in letting the amateurs listen in over their shoulder. Maybe they’re doing it for PR reasons if/when something goes badly wrong?

Whatever the reasons, it’s a shame. Space has been open to hackers for a long time, knowingly in the case of amateur satellites, and unknowingly in the case of many other satellites which until the mid-90s had command channels that were unencrypted. (I’ll have to stick with “unnamed sources” on this one, but I do know a person who has rotated a satellite that he or she didn’t own.) There’s a lot to be learned by listening to signals from above, and while you can still decode weather satellite data yourself, it’s not quite as sexy as downloading images straight from a Falcon 9.

The cool hand for SpaceX to have played would have been to say “of course — we broadcast unencrypted as PR to our biggest fans” but it looks instead like they simply didn’t think that anyone would be listening in, and this caught them by surprise and they panicked. In 2021, with something as complicated as a space mission, that’s a little bit embarrassing. Anyway, to those of you who managed to get in before encryption, kudos!

When The Right Tool Is Wrong

April 3, 2021 by Elliot Williams 76 Comments

I’m a firm believer in using the right tool for the job. And one of the most fantastic things about open-source software tools is that nothing stops you from trying them all. For instance, I’ve been going back and forth between a couple, maybe three, CAD/CAM tools over the past few weeks. They each have their strengths and weaknesses, and so if I’m doing a simpler job, I use the simpler software, because it’s quicker and, well, simpler. But I’ve got to cut it out, at least for a while, and I’ll tell you why.

The first of the packages is FreeCAD, and it’s an extremely capable piece of CAD/CAM software. It can do everything, or so it seems. But it’s got a long shallow learning curve, and I’m only about halfway up. I’m at the stage where I should be hammering out simple “hello world” parts for practice. I say, I should be.

Fortunately/unfortunately, some Hackaday readers introduced me to KrabzCAM through the comments. It’s significantly less feature-full than FreeCAD, but it gets the job of turning your wife’s sketches of bunnies into Easter decorations done in a jiffy. For simple stuff like that, it’s a nice simple tool, and is the perfect fit for 2D CAM jobs. It’s got some other nice features, and it handles laser engraving nicely as well. And that’s the problem.

Doing the simple stuff with KrabzCAM means that when I do finally turn back to FreeCAD, I’m working on a more challenging project — using techniques that I’m not necessarily up to speed on. So I’ll put the time in, but find myself still stumbling over the introductory “hello world” stuff like navigation and project setup.

I know — #first-world-hacker-problems. “Poor Elliot has access to too many useful tools, with strengths that make them fit different jobs!” And honestly, I’m stoked to have so many good options — that wasn’t the case five years ago. But in this case, using the right tool for the job is wrong for me learning the other tool.

On reflection, this is related to the never-try-anything-new-because-your-current-tools-work-just-fine problem. And the solution to that one is to simply bite the bullet and stick it out with FreeCAD until I get proficient. But KrabzCAM works so well for those small 2D jobs…

A hacker’s life is hard.