Hack My House: Garage Door Cryptography Meets Raspberry Pi

February 13, 2019 by Jonathan Bennett 57 Comments

Today’s story is one of victory and defeat, of mystery and adventure… It’s time to automate the garage door. Connecting the garage door to the internet was a must on my list of smart home features. Our opener has internet connection capabilities built-in. As you might guess, I’m very skeptical of connecting a device to the internet when I have no control over the software running on it.

The garage door is controlled by a button hung on the garage wall. There is only a pair of wires, so a simple relay should be all that is needed to simulate the button press from a Raspberry Pi. I wired a relay module to a GPIO on the Pi mounted in the garage ceiling, and wrote a quick and dirty test program in Python. Sure enough, the little relay was clicking happily– but the garage door wasn’t budging. Time to troubleshoot. Does the push button still work? *raises the garage door* yep. How about the relay now? *click…click* nope.

You may have figured out by now, but this garage door opener isn’t just a simple momentary contact push button. Yes, that’s a microcontroller, in a garage door button. This sort of scenario calls for forensic equipment more capable than a simple multimeter, and so I turned to Amazon for a USB oscilloscope that could do some limited signal analysis. A device with Linux support was a must, and Pico Technology fit the bill nicely.

Searching for a Secret We Don’t Actually Need

My 2 channel Picotech oscilloscope, the 2204A, finally arrived, and it was time to see what sort of alien technology was in this garage door opener. There are two leads to the button, a ground and a five volt line. When the button is pressed, the microcontroller sends data back over that line by pulling the 5 V line to ground. If this isn’t an implementation of Dallas 1-wire, it’s a very similar concept.

Continue reading “Hack My House: Garage Door Cryptography Meets Raspberry Pi” →

Linux Fu: Easier File Watching

January 31, 2019 by Al Williams 22 Comments

In an earlier installment of Linux Fu, I mentioned how you can use inotifywait to efficiently watch for file system changes. The comments had a lot of alternative ways to do the same job, which is great. But there was one very easy-to-use tool that didn’t show up, so I wanted to talk about it. That tool is entr. It isn’t as versatile, but it is easy to use and covers a lot of common use cases where you want some action to occur when a file changes.

Continue reading “Linux Fu: Easier File Watching” →

AI On Raspberry Pi With The Intel Neural Compute Stick

January 31, 2019 by Sean Boyce 58 Comments

I’ve always been fascinated by AI and machine learning. Google TensorFlow offers tutorials and has been on my ‘to-learn’ list since it was first released, although I always seem to neglect it in favor of the shiniest new embedded platform.

Last July, I took note when Intel released the Neural Compute Stick. It looked like an oversized USB stick, and acted as an accelerator for local AI applications, especially machine vision. I thought it was a pretty neat idea: it allowed me to test out AI applications on embedded systems at a power cost of about 1W. It requires pre-trained models, but there are enough of them available now to do some interesting things.

You can add a few of them in a hub for parallel tasks. Image credit Intel Corporation.

I wasn’t convinced I would get great performance out of it, and forgot about it until last November when they released an improved version. Unambiguously named the ‘Neural Compute Stick 2’ (NCS2), it was reasonably priced and promised a 6-8x performance increase over the last model, so I decided to give it a try to see how well it worked.

I took a few days off work around Christmas to set up Intel’s OpenVino Toolkit on my laptop. The installation script provided by Intel wasn’t particularly user-friendly, but it worked well enough and included several example applications I could use to test performance. I found that face detection was possible with my webcam in near real-time (something like 19 FPS), and pose detection at about 3 FPS. So in accordance with the holiday spirit, it knows when I am sleeping, and knows when I’m awake.

That was promising, but the NCS2 was marketed as allowing AI processing on edge computing devices. I set about installing it on the Raspberry Pi 3 Model B+ and compiling the application samples to see if it worked better than previous methods. This turned out to be more difficult than I expected, and the main goal of this article is to share the process I followed and save some of you a little frustration.

Continue reading “AI On Raspberry Pi With The Intel Neural Compute Stick” →

How To Make Your Own Springs For Extruded Rail T-Nuts

January 30, 2019 by Sonya Vasquez 24 Comments

Open-Source Extruded Profile systems are a mature breed these days. With Openbuilds, Makerslide, and Openbeam, we’ve got plenty of systems to choose from; and Amazon and Alibaba are coming in strong with lots of generic interchangeable parts. These open-source framing systems have borrowed tricks from some decades-old industry players like Rexroth and 80/20. But from all they’ve gleaned, there’s still one trick they haven’t snagged yet: affordable springloaded T-nuts.

I’ve discussed a few tricks when working with these systems before, and Roger Cheng came up with a 3D printed technique for working with T-nuts. But today I’ll take another step and show you how to make our own springs for VSlot rail nuts.

Continue reading “How To Make Your Own Springs For Extruded Rail T-Nuts” →

Circuit VR: Redundant Flip Flops And Voting Logic

January 25, 2019 by Al Williams 8 Comments

We are somewhat spoiled because electronics today are very reliable compared to even a few decades ago. Most modern electronics obey the bathtub curve. If they don’t fail right away, they won’t fail for a very long time, in all likelihood. However, there are a few cases where that’s not a good enough answer. One is when something really important is at stake — the control systems of an airplane, for example. The other is when you are in an environment that might cause failures. In those cases — near a nuclear reactor or space, for example, you often are actually dealing with both problems. In this installment of Circuit VR, I’ll show you a few common ways to make digital logic circuits more robust with some examples you can run in the Falstad simulator in your browser.

Continue reading “Circuit VR: Redundant Flip Flops And Voting Logic” →

Cool Tools: A Little Filesystem That Keeps Your Bits On Lock

January 24, 2019 by Kerry Scharfglass 52 Comments

Filesystems for computers are not the best bet for embedded systems. Even those who know this fragment of truth still fall into the trap and pay for it later on while surrounded by the rubble that once was a functioning project. Here’s how it happens.

The project starts small, with modest storage needs. It’s just a temperature logger and you want to store that data, so you stick on a little EEPROM. That works pretty well! But you need to store a little more data so the EEPROM gets paired with a small blob of NOR flash which is much larger but still pretty easy to work with. Device settings go to EEPROM, data logs go to NOR. That works for a time but then you remember that people on the Internet are all about the Internet of Things so it’s time to add WiFi. You start serving a few static pages with that surprisingly capable processor and bump into storage problems again so the NOR flash gets replaced with an SD card and now the logs go there too. Suddenly you’re dealing with multiple files and want access on a computer so a real filesystem is in order. FAT is easy, so the card grows a FAT filesystem. Everything is great, but you start to notice patches missing from the logs. Then the SD card gets totally corrupted. What’s going on? Let’s take a look at the problem, and how to reach embedded file nirvana.

Continue reading “Cool Tools: A Little Filesystem That Keeps Your Bits On Lock” →

Crash Your Code – Lessons Learned From Debugging Things That Should Never Happen™

January 22, 2019 by Sven Gregori 58 Comments

Let’s be honest, no one likes to see their program crash. It’s a clear sign that something is wrong with our code, and that’s a truth we don’t like to see. We try our best to avoid such a situation, and we’ve seen how compiler warnings and other static code analysis tools can help us to detect and prevent possible flaws in our code, which could otherwise lead to its demise. But what if I told you that crashing your program is actually a great way to improve its overall quality? Now, this obviously sounds a bit counterintuitive, after all we are talking about preventing our code from misbehaving, so why would we want to purposely break it?

Wandering around in an environment of ones and zeroes makes it easy to forget that reality is usually a lot less black and white. Yes, a program crash is bad — it hurts the ego, makes us look bad, and most of all, it is simply annoying. But is it really the worst that could happen? What if, say, some bad pointer handling doesn’t cause an instant segmentation fault, but instead happily introduces some garbage data to the system, widely opening the gates to virtually any outcome imaginable, from minor glitches to severe security vulnerabilities. Is this really a better option? And it doesn’t have to be pointers, or anything of C’s shortcomings in particular, we can end up with invalid data and unforeseen scenarios in virtually any language.

It doesn’t matter how often we hear that every piece of software is too complex to ever fully understand it, or how everything that can go wrong will go wrong. We are fully aware of all the wisdom and cliches, and completely ignore them or weasel our way out of it every time we put a /* this should never happen */ comment in our code.

So today, we are going to look into our options to deal with such unanticipated situations, how we can utilize a deliberate crash to improve our code in the future, and why the average error message is mostly useless.

Continue reading “Crash Your Code – Lessons Learned From Debugging Things That Should Never Happen™” →