Physical Computing Used To Be A Thing

In the early 2000s, the idea that you could write programs on microcontrollers that did things in the physical world, like run motors or light up LEDs, was kind of new. At the time, most people thought of coding as stuff that stayed on the screen, or in cyberspace. This idea of writing code for physical gadgets was uncommon enough that it had a buzzword of its own: “physical computing”.

You never hear much about “physical computing” these days, but that’s not because the concept went away. Rather, it’s probably because it’s almost become the norm. I realized this as Tom Nardi and I were talking on the podcast about a number of apparently different trends that all point in the same direction.

We started off talking about the early days of the Arduino revolution. Sure, folks have been building hobby projects with microcontrollers built in before Arduino, but the combination of a standardized board, a wide-ranging software library, and abundant examples to learn from brought embedded programming to a much wider audience. And particularly, it brought this to an audience of beginners who were not only blinking an LED for the first time, but maybe even taking their first steps into coding. For many, the Arduino hello world was their coding hello world as well. These folks are “physical computing” natives.

Now, it’s to the point that when Arya goes to visit FOSDEM, an open-source software convention, there is hardware everywhere. Why? Because many successful software projects support open hardware, and many others run on it. People port their favorite programming languages to microcontroller platforms, and as they become more powerful, the lines between the “big” computers and the “micro” ones starts to blur.

And I think this is awesome. For one, it’s somehow more rewarding, when you’re just starting to learn to code, to see the letters you type cause something in the physical world to happen, even if it’s just blinking an LED. At the same time, everything has a microcontroller in it these days, and hacking on these devices is also another flavor of physical computing – there’s code in everything that you might think of as hardware. And with open licenses, everything being under version control, and more openness in open hardware than we’ve ever seen before, the open-source hardware world reflects the open-source software ethos.

Are we getting past the point where the hardware / software distinction is even worth making? And was “physical computing” just the buzzword for the final stages of blurring out those lines?

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”