We’ve all experienced that magic moment when, after countless frustrating hours of experimentation and racking your brain, the object of our attention starts working. The 3D printer finally produces good output. The hacked up laptop finally boots. The car engine finally purrs. The question is, do we know why it started working?
This is more important than you might think. Knowing the answer lets you confirm that the core problem was solved, otherwise you may have just fixed a symptom. And lack of understanding means fixing one problem may just create another.
The solution is to adopt a methodical troubleshooting method. We’re talking about a structured problem solving technique that when used properly can help us solve a problem at its core without leaving any loose ends. Such methodology will also leave you knowing why any solution did or didn’t work in the end, and will give you reproducible results.
A thermal camera is a tool I have been wanting to add to my workbench for quite a while, so when I learned about the tCam-Mini, a wireless thermal camera by Dan Julio, I placed an order. A thermal imager is a camera whose images represent temperatures, making it easy to see things like hot and cold spots, or read the temperature of any point within the camera’s view. The main (and most expensive) component of the tCam-Mini is the Lepton 3.5 sensor, which sits in a socket in the middle of the board. The sensor is sold separately, but the campaign made it available as an add-on.
Want to see how evenly a 3D printer’s heat bed is warming up, or check whether a hot plate is actually reflowing PCBs at the optimal temperature? How about just seeing how weird your pets would look if you had heat vision instead of normal eyes? A thermal imager like the tCam-mini is the tool for that, but it’s important to understand exactly how the tCam-mini works. While it may look like a webcam, it does not work like one.
If you follow cybersecurity hacker methods — or just watch Mr. Robot — you probably know that the best way to get someone’s password is to ask for it. Sure, you probably can’t just say “Hi, I’m a bad guy. Can I have your password?” But there are all sorts of tricks you can use like pretending to be in the person’s IT department, someone in management, or by making up a crisis to overcome their better judgement with a sense. But of course, as wise computer people, we are immune to such things, right? We also don’t need those kinds of tricks in our arsenal.
Is that true? It is amazing how many subtle things influence what we think are rational decisions, no matter who we are. Consider going to eat in a restaurant. Simple, right? You look at the menu, pick what you want, and order. No one is influencing you. But they are. According to a BBC article, there’s a whole industry of menu “engineering” that figures out how to get you to order pricey food.
You might not think social engineering for menus is a great skill for us. But maybe your new open source project needs collaborators. Maybe your startup company needs investors. Maybe you’d like someone to look at your resume. Maybe the same tricks that work with diners will work in those cases, too.
You need to package up a bunch of files, send them somewhere, and do something with them at the destination. It isn’t an uncommon scenario. The obvious answer is to create an archive — a zip or tar file, maybe — and include a shell script that you have to tell the user to run after unpacking.
That may be obvious, but it assumes a lot on the part of the remote user. They need to know how to unpack the file and they also need to know to run your magic script of commands after the unpack. However, you can easily create a shell script that contains a file — even an archive of many files — and then retrieve the file and act on it at run time. This is much simpler from the remote user’s point of view. You get one file, you execute it, and you are done.
In theory, this isn’t that hard to do, but there are a lot of details. Shell scripts are not compiled — at least, not typically — so the shell only reads what it needs to do the work. That means if your script is careful to exit, you can add as much “garbage” to the end of it as you like. The shell will never look at it, so it’s possible to store the payload there.
Twitch Plays Pokemon burst onto the then nascent livestreaming scene back in 2014, letting Twitch viewers take command of a Game Boy emulator running Pokemon Red via simple chat commands. Since then, the same concept has been applied to everything under the sun. Other video games, installing Linux, and even trading on the New York Stock Exchange have all been gameified through Twitch chat.
You, thirsty reader, are wondering how you can get a slice of this delicious action. Fear not, for with a bit of ramshackle code, you can let Twitch chat take over pretty much anything in, on, or around your computer.
It’s Just IRC
The great thing about Twitch chat is that it runs on vanilla IRC (Internet Relay Chat). The protocol has been around forever, and libraries exist to make interfacing easy. Just like the original streamer behind Twitch Plays Pokemon, we’re going to use Python because it’s great for fun little experiments like these. With that said, any language will do fine — just apply the same techniques in the relevant syntax.
SimpleTwitchCommander, as I’ve named it on Github, assumes some familiarity with basic Python programming. The code will allow you to take commands from chat in two ways. Commands from chat can be tabulated, and only the one with the most votes executed, or every single command can be acted on directly. Actually getting this code to control your robot, video game, or pet viper is up to you. What we’re doing here is interfacing with Twitch chat and pulling out commands so you can make it do whatever you like. With that said, for this example, we’ve set up the code to parse commands for a simple wheeled robot. Let’s dive in.
Measuring temperature turns out to be a fundamental function for a huge number of devices. You furnace’s programmable thermostat and digital clocks are obvious examples. If you just needed to know if a certain temperature is exceeded, you could use a bimetalic coil and a microswitch (or a mercury switch as was the method with old thermostats). But these days we want precision over a range of readings, so there are thermocouples that generate a small voltage, RTDs that change resistance with temperature, thermistors that also change resistance with temperature, infrared sensors, and vibrating wire sensors. The bandgap voltage of a semiconductor junction varies with temperature and that’s predictable and measurable, too. There are probably other methods too, some of which are probably pretty creative.
You can often think of creative ways to do any measurement. There’s an old joke about the smart-alec student in physics class. The question was how do you find the height of a building using a barometer. One answer was to drop the barometer from the top of the building and time how long it takes to hit the ground. Another answer — doubtlessly an engineering student — wanted to find the building engineer and offer to give them the barometer in exchange for the height of the building. By the same token, you could find the temperature by monitoring a standard thermometer with a camera or even a level sensor which is a topic for another post.
The point is, there are plenty of ways to measure anything, but in every case, you are converting what you want to know (temperature) into something you know how to measure like voltage, current, or physical position. Let’s take a look at how some of the most interesting temperature sensors accomplish this.
Serial ports used to be everywhere. In a way, they still are since many things that appear to plug in as a USB device actually look like a serial port. The problem is that today, the world runs on the network. Sure, you can buy a terminal server that converts a serial port to an Ethernet port, but what fun is that? In this article, I’m going to show you how to stream serial ports over the network using some available Linux tools. It isn’t perfect, and it won’t work for every case, but when it works it works well.
Everything is a File, Until it Isn’t
At some point in the past, Unix — the progenitor of Linux — treated virtually everything as a file, and all files were created more or less equal. Programs didn’t care if a file was local, on the network, from a tape drive, or arriving over a named pipe.
But things started to change. Even though a serial port is just a file under Linux, it has some special attributes that let you set, for example, baud rates. Worse, some programs “know” too much about files and insist on certain naming conventions. So, in theory, you should be able to create a network socket, connect one end to a serial port and the other end to a program, and be done with it. In theory.