As we’ve seen time and time again, the word “hacker” takes on a different meaning depending on who you’re talking to. If you ask the type of person who reads this fine digital publication, they’ll probably tell you that a hacker is somebody who likes to learn how things work and who has a penchant for finding creative solutions to problems. But if you ask the average passerby on the street to describe a hacker, they might imagine somebody wearing a balaclava and pounding away at their laptop in a dimly lit abandoned warehouse. Thanks, Hollywood.
Naturally, we don’t prescribe to the idea of hackers being digital villains hell-bent on stealing your identity, but we’ll admit that there’s something of rift between what we call hacking versus what happens in the information security realm. If you see mention of Red Teams and Blue Teams on Hackaday, it’s more likely to be in reference to somebody emulating Pokemon on the ESP32 than anything to do with penetration testing. We’re not entirely sure where this fragmentation of the hacking community came from, but it’s definitely pervasive.
Two of these talks which should particularly resonate with the Hackaday crowd were Charles Sgrillo’s An Introduction to IoT Penetration Testing and Ham Hacks: Breaking into Software Defined Radio by Kelly Albrink. These two presentations dealt with the security implications of many of the technologies we see here at Hackaday on what seems like a daily basis: Bluetooth Low Energy (BLE), Software Defined Radio (SDR), home automation, embedded Linux firmware, etc. Unfortunately, the talks were not recorded for the inaugural WOPR Summit, but both presenters were kind of enough to provide their slides for reference.
There was an endless supply of fantastic projects at Supercon this year, but one whose fit and finish really stood out was [Scott]’s lightsaber. If you were walking around and saw someone with a very bright RGB device with a chromed-out handle hanging off their belt it was probably this, though it may have been hard to look at directly. On the outside, the saber looks like a well-polished cosplay prop, and it is! But when Scott quickly broke down the device into component pieces it was apparent that extra care had been put into the assembly of the electronics.
Like any good lightsaber replica the blade is lit, and wow is it bright. The construction is fairly simple, it’s a triplet of WS2812B LED strips back to back on a triangular core, mounted inside a translucent polycarbonate tube with a diffuser. Not especially unusual. But the blade can be popped off the hilt at a moments notice for easy transport and storage, so the strips can’t be soldered in. Connectors would have worked, but who wants flying wires when they’re disconnecting their lightsaber blade. The answer? Pogo pins! Scott runs the power, ground, and data lines out of the strips and into a small board with slip ring-style plated rings. On the hilt, there is a matching array of pogo pins to pass along power and data. The data lines from all the strips are tied together minimizing the number of connections to make, and the outer two power rings have more than one pin for better current-carrying capacity. A handy side effect is that there is nowhere on the blade where there aren’t LEDs; the strips go down to the very end of the blade where it meets the main board inside the hilt.
The hilt is filled with an assembly of 18650’s and a Teensy mounted with a custom shield, all fit inside a printed midframe. The whole build is all about robust design that’s easy to assemble. The main board is book-ended by perpendicular PCBs mounted to the ends, one at the top to connect to the blade and one at the bottom to connect to a speaker. Towards the bottom there is space for an optional Bluetooth radio to allow remote RGB control.
Scott is selling this as a product but also provides detailed instructions and parts lists for each component. Assembly instructions for the blade are here. The hilt is here. And pogo adapters are on OSH Park here. An overview of the firmware with links to GitHub is here. Check out a walkthrough of the handle assembly and blade attachment after the break!
Back in the early days of Arduino proliferation (and before you ask, yes we realize there was a time before that too), wireless was a strange and foreign beast. IR communication was definitely a thing. And if you had the funds there was this cool technology called ZigBee that was available, often in funny blue house-shaped XBee boards. With even more funds and a stomach for AT commands you could even bolt on a 2G cell radio for unlimited range. WiFi existed too, but connecting it to a hobbyist ecosystem of boards was a little hairier (though maybe not for our readership).
But as cell phones pushed demand for low power wireless forward and the progression of what would become the Internet of marking Terms (the IoT, of course) began, a proliferation of options appeared for wireless communication. Earlier this week we came across a great primer on some of the major wireless technologies which was put together by Digikey earlier in the year. Let’s not bury the lede. This table is the crux of the piece:
There are some neat entries here that are a little less common (and our old friend, the oft-maligned and never market-penetrating ZigBee). It’s actually even missing some entries. Let’s break it down:
Extremely short range: Just NFC. Very useful for transferring small amount of sensitive information slowly, or things with high location-relevance (like between phones that are touching).
Medium/long range: Wifi, Bluetooth, Zigbee, Z-Wave, LoRaWAN: Sometimes stretching for a kilometer or more in open spaces. Useful for everything from emitting tweets to stitching together a mesh network across a forrest, as long as there are enough nodes. Some of these are also useful at shorter range.
Very Long range/rangeless: Sigfox, NB-IoT, LTE Category-0. Connect anywhere, usually with some sort of subscription for network access. Rangeless in the sense that range is so long you use infrastructure instead of hooking a radio up to a Raspberry Pi under your desk. Though LoRa can be a fun exception to that.
You’re unlikely to go from zero to custom wireless solution without getting down into the mud with the available dev boards for a few different common protocols, but which ones? The landscape has changed so rapidly over the years, it’s easy to get stuck in one comfortable technology and miss the appearance of the next big thing (like how LoRaWAN is becoming new cool kid these days). This guide is a good overview to help catch you up and help decide which dev kits are worth a further look. But of course we still want to hear from you below about your favorite wireless gems — past, present, and future — that didn’t make it into the list (we’re looking at you 433 MHz).
We’re living in the world of connected devices. It has never been easier to roll your own and implement the functionality you actually want, rather than live with the lowest common denominator that the manufacture chose.
In a previous article I walked though a small python script to talk to a BLE light and used it to cycle through some colors. Now I want to delve deeper into the world of Internet Connected BLE devices and how to set up a simple Internet-Of-Things light. With this example in hand the sky’s the limit on what you can build and what it will be able to do.
Join me after the break as I demonstrate how to use NodeJS to bridge the digital world with the physical world.
If you’ve visited a McDonald’s recently, you might have noticed something of a tonal shift. Rather than relying on angsty human teenagers to take customer orders, an increasing number of McDonald’s locations are now using self-serve kiosks. You walk up, enter your order on a giant touch screen, and then take an electronic marker with you to an open table. In mere minutes your tray of nutritiousdelicious cheap food is brought to you by… well that’s still probably going to be an angsty teenager.
The Nordic nRF52832 features a 32-bit ARM Cortex M4F processor at 64 MHz with 512 KB flash and 64 KB SRAM. Quite a bit of punch for a table marker. Incidentally, this is the same chip used in the Adafruit Feather nRF52 Pro, so there’s already an easily obtainable development toolchain.
A image of the backside of the PCB shows a wealth of labeled test points, and we imagine figuring out how to get one of these table markers doing your own bidding wouldn’t be too difficult. Not that we condone you swiping one of these things along with your Quarter Pounder with Cheese. Though we are curious to know just why they need so much hardware to indicate which table to take a particular order to; it seems the number printed on the body of the device would be enough to do that.
As has been made abundantly clear by the advertising department of essentially every consumer electronics manufacturer on the planet: everything is improved by the addition of sensors and a smartphone companion app. Doesn’t matter if it’s your thermostat or your toilet, you absolutely must know at all times that it’s operating at peak efficiency. But why stop at household gadgets? What better to induct into the Internet of Things than 600 year old samurai weaponry?
The eKatana is powered by an Adafruit Feather 32u4 Bluefruit LE and LSM9DS0 accelerometer module along with a tiny 110 mAh LiPo battery. Bundled together, it makes for a small and unobtrusive package at the base of the sword’s handle. [Carlos] mentions a 3D printed enclosure of some type would be a logical future improvement, though a practice sword that has a hollow handle to hold the electronics is probably the most ideal solution.
A real-time output of sword rotation, pitch, and heading is sent out by the Adafruit Feather over BLE for analysis by a companion smartphone application. For now he just has a running output of the raw data, but [Carlos] envisions a fully realized application that could provide the user with motions to perform and give feedback on their form.
Successfully connecting things without physical wires has a profound effect on the maker brain. Machines talking to each other without any cables is as amazing today as it was a decade ago. When Bluetooth came out, it was a breakthrough since it offered a wireless way to connect cellphones to a PC. But Bluetooth is a complicated, high-bandwidth power hog, and it didn’t make sense for battery-powered devices with less demanding throughput requirements to pay the energy price. Enter Bluetooth LE (BLE), with power requirements modest enough to enable a multitude of applications including low power sensor nodes and beacons.
Over the years, a number of gadgets with BLE have popped up such as the LightBlue Bean, BLE Beacons as well as quadcopters like the FlexBot that rely on BLE for communication. Android or iOS apps are the predominant method of talking to these wonderful gadgets though there are alternatives.
This is the first in a two part series on building with BLE devices. First, I’ll survey some BLE devices and how to get started with BLE from the Linux command line. Later, we will go into describing the process of making a NodeJS cross-platform app that will leverage the BLE capabilities and connect it to the Internet.
Lets get started. Continue reading “Beginning BLE Experiments And Making Everything Better”→