Multitasker Or Many Monotaskers?

In Al Williams’s marvelous rant he points out a number of the problems with speaking to computers. Obvious problems with voice control include things like multiple people talking over each other, discerning commands from background conversations, and so on. Somehow, unlike on the bridge in Star Trek, where the computer seems to understand everyone just fine, Al sometimes can’t even get the darn thing to play his going-to-sleep playlist, which should be well within the device’s capabilities.

In the comments, [rclark] suggests making a single button that plays his playlist, no voice interaction required, and we have to admit that it’s a great solution to this one particular problem. Heck, the “bedtime button” would make fun project in and of itself, and it’s such a limited scope that it could probably only be an weekend’s work for anyone who has touched the internals of their home automation system, like Al certainly has. We love the simplicity of the idea.

But it ignores the biggest potential benefit of a voice control system: that it’s a one-size-fits-all solution for everything. Imagine how many other use cases Al would need to make a single button device for, and how many coin cell batteries he’d be signing himself up to change out over the course of the year. The trade-off is that the general purpose solution tends not to be as robust as a single-tasker like the button, but also that it can potentially simplify the overall system.

I suffer this in my own home. It’s much more a loosely-coupled web of individual hacks than an overall system, and that has pros and cons. Each individual part is easier to maintain and hack on, but the overall system is less coordinated than it could be. If we change the WiFi password on the home automation router, for instance, I’m going to have to individually log into about eight ESP8266s and change their credentials. Yuck!

It’s probably a matter of preference, but I’ll still take the loose, MQTT-based system that I’ve got now over an all-in-one. Like [rclark], I value individual device simplicity and reliability above the overall system’s simplicity, but because our stereo isn’t even hooked up to the network, I can’t play myself to sleep like Al can. Or at least like he can when the voice recognition is working.

A Guide To Making The Right Microcontroller Choice

Starting a new microcontroller project can be pretty daunting. While you have at least a rough idea of where you want to end up, there are so many ways to get there that you can get locked into “analysis paralysis” and never get the project off the ground. Or arguably worse, you just throw whatever dev board you have in the junk bin and deal with the consequences.

While it’s hard to go wrong with relying on a familiar MCU and toolchain, [lcamtuf] argues in this recent guide to choosing microcontrollers that it’s actually not too much of a chore to make the right choice. Breaking the microcontroller universe down into three broad categories makes the job a little easier: simple process control, computationally intensive tasks, and IoT products. Figuring out where your project falls on that spectrum narrows your choices considerably.

For example, if you just need to read some sensors and run a few servos or solenoids, using something like a Raspberry Pi is probably overkill. On the other hand, a Pi or other SBC might be fine for something that you need wireless connectivity. We also appreciate that [lcamtuf] acknowledges that intangible considerations sometimes factor in, such as favoring a new-to-you MCU because you’ll get experience with technology you haven’t used before. It might not override technical considerations by itself, but you can’t ignore the need to stretch your wings once in a while.

There’s nothing earth-shattering here, but we enjoy think pieces like this. It’s a bit like [lcamtuf]’s recent piece on rethinking your jellybean op-amps.

Hacker Olympics

The opening ceremony of the Summer Olympics is going on today. It’s an over-the-top presentation meant to draw people into sport. And for the next few weeks, we’ll be seeing people from all across the world competing in their chosen physical activities. There will be triumph and defeat, front-runners who nonetheless lag behind on that day, and underdogs who sneak ahead. In short, a lot of ado about sport, and I don’t necessarily think that’s a bad thing. Sports are fun.

But where is the Hacker Olympics? Or even more broadly the Science Olympics or Engineering Olympics? Why don’t we celebrate the achievements of great thinkers, planners, and builders the same way that we celebrate fast runners or steady shooters? With all the pomp and showmanship and so on?

Here at Hackaday, we try our best! When we see a cool hack, we celebrate it. But we’re one little blog, with about a millionth the budget of the International Olympic Commission. However, we have you all as our biggest multiplier. It would be awesome if we could take over the entire city of Paris in celebration of science and engineering, but until then, if you see something smart, share it with us. And if you see something on Hackaday that you think was awesome, share it with your friends.

Sometimes It’s Not The Solution

Watching a video about a scratch-built ultra-precise switch for metrology last week reminded me that it’s not always the projects that are the most elegant solutions that I enjoy reading about the most. Sometimes I like reading about hackers’ projects more for the description of the problem they’re facing.

A good problem invites you to brainstorm along. In the case of [Marco Reps]’s switches, for instance, they need to be extraordinarily temperature stable, which means being made out of a single type of metal to avoid unintentional thermocouple joints. And ideally, they should be as cheap as possible. Once you see one good solution, you can’t help but think of others – just reading the comments on that article shows you how inspiring a good problem can be. I’m not worried about these issues in any of my work, but it would be cool to have to.

Similarly, this week, I really liked [Michael Prasthofer]’s deep dive into converting a normal camera into a spectrometer. His solutions were all very elegant, but what was most interesting were the various problems he faced along the way. Things that you just wouldn’t expect end up mattering, like diffraction gratings being differently sensitive across the spectrum when light comes in from different angles. You can learn a lot from other people’s problems.

So, hackers everywhere, please share your problems with us! You think that your application is “too niche” to be of general interest? Maybe it’s another example of a problem that’s unique enough to be interesting just on its own. Let’s see what your up against. A cool problem is at least as interesting as a clever solution.

Institutional Memory, On Paper

Our own Dan Maloney has been on a Voyager kick for the past couple of years. Voyager, the space probe. As a long-term project, he has been trying to figure out the computer systems on board. He got far enough to write up a great overview piece, and it’s a pretty good summary of what we know these days. But along the way, he stumbled on a couple old documents that would answer a lot of questions.

Dan asked JPL if they had them, and the answer was “no”. Oddly enough, the very people who are involved in the epic save a couple weeks ago would also like a copy. So when Dan tracked the document down to a paper-only collection at Wichita State University, he thought he had won, but the whole box is stashed away as the library undergoes construction.

That box, and a couple of its neighbors, appear to have a treasure trove of documentation about the Voyagers, and it may even be one-of-a-kind. So in the comments, a number of people have volunteered to help the effort, but I think we’re all just going to have to wait until the library is open for business again. In this age of everything-online, everything-scanned-in, it’s amazing to believe that documents about the world’s furthest-flown space probe wouldn’t be available, but so it is!

It makes you wonder how many other similar documents – products of serious work by the people responsible for designing the systems and machines that shaped our world – are out there in the dark somewhere. History can’t capture everything, and it’s down to our collective good judgement in the end. So if you find yourself in a position to shed light on, or scan, such old papers, please do! And then contact some nerd institution like the Internet Archive or the Computer History Museum.

Microsoft Killed My Favorite Keyboard, And I’m Mad About It

As a professional writer, I rack up thousands of words a day. Too many in fact, to the point where it hurts my brain. To ease this burden, I choose my tools carefully to minimize obstructions as the words pour from my mind, spilling through my fingers on their way to the screen.

That’s a long-winded way of saying I’m pretty persnickety about my keyboard. Now, I’ve found out my favorite model has been discontinued, and I’ll never again know the pleasure of typing on its delicate keys. And I’m mad about it. Real mad. Because I shouldn’t be in this position to begin with!

Continue reading “Microsoft Killed My Favorite Keyboard, And I’m Mad About It”

Wireless All The Things!

Neither Tom Nardi nor I are exactly young anymore, and we can both remember a time when joysticks were actually connected with wires to the computer or console, for instance. Back then, even though wireless options were on the market, you’d still want the wired version if it was a reaction-speed game, because wireless links just used to be too slow.

Somehow, in the intervening years, and although we never even really noticed the transition as such, everything has become wireless. And that includes our own hacker projects. Sure, the ESP8266 and other WiFi-capable chips made a big difference, but I still have a soft spot in my heart for the nRF24 chipset, which made at least point-to-point wireless affordable and easy. Others will feel the same about ZigBee, but the point stands: nothing has wires anymore, except to charge back up.

The reason? As this experiment comparing the latency of many different wireless connections bears out, wireless data links have just gotten that good, to the point that the latency in the radio is on par with what you’d get over USB. And the relevant software ecosystems have made it easier to go wireless as well. Except for the extra power requirement, and for cases where you need to move a lot of data, there’s almost no reason that any of your devices need wires anymore.

Are you with us? Will you throw down your chains and go wireless?