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”→
What’s a hacker to do to profess his love for his dearest beloved? [Nitesh Kadyan] built his lady-love this awesome LED pendant – the LED BLE Hearty Necklace Badge.
The hardware is pretty vanilla by today’s hacker standards. An ATMega328p does most of the heavy lifting. An HM-11 BLE module provides connection to an Android mobile app. Two 74HC595 shift registers drive 16 columns of red LEDs and a ULN2803 sinks current from the 8 rows. The power section consists of a charger for the 320mAh LiPo and an LDO for the BLE module. All the parts are SMD with the passives mostly being 0603, including the 128 LEDs.
[Nitesh] didn’t get a stencil made for his first batch of boards, so all the parts were painstakingly soldered manually and not in a reflow oven. And on his first board, he ended up soldering all of the LED’s the wrong way around. Kudos to him for his doggedness and patience.
The Arduino code on the ATmega is also quite straightforward. All characters are stored as eight bytes each in program memory and occupy 8×8 pixels on the matrix. The bytes to be displayed are stored in a buffer and the columns are left shifted fast enough for the marquee text effect. The Android app is built by modifying a demo BLE app provided by Google. The firmware, Android app, and the KiCAD design files are all hosted on his Github repository.
[Nitesh] is now building a larger batch of these badges to bring them to hillhacks – the annual hacker-con for making and hacking in the Himalayas. Scheduled for later this month, you’ll have to sign up on the mailing list for details and if you’d like to snag one of these badges. To make it more interesting, [Nitesh] has added two games to the code – Tetris and Snakes. Hopefully, this will spur others to create more games for the badge, such as Pong.
You might be surprised to find out that it’s actually not a good idea to put all of your credit card information on a little Bluetooth enabled device in your pocket. Oh, what’s that? You knew already? Well in that case you won’t find the following information terribly shocking, but it’s still a fascinating look at how security researchers systematically break down a device in an effort to find the chinks in its armor.
[Mike Ryan] of ICE9 Consulting has recently published an article detailing the work done to examine and ultimately defeat the security on the FUZE Card. From using an x-ray machine to do non-destructive reconnaissance on the device’s internals to methodically discovering all the commands it responds to over Bluetooth, it’s safe to say the FUZE Card is cracked wide open at this point.
To be clear, the attacker must still pair with FUZE, so physical access is required. But as pointed out by [Mike] in the blog post, handing your card over to a merchant is standard operating procedure in many cases. It isn’t as if it would be hard to get a hold of one of these FUZE cards for a minute or two without the owner becoming suspicious. Pairing FUZE to the Linux device to continue to the next step of the attack only takes a few seconds, as demonstrated in the video after the break.
Once paired, the attacker can simply send a BLE command to FUZE which disables the lock screen. It’s really that simple. The attacker can also send commands to dump credit card info over Bluetooth, meaning they could download your information even when the card is “safely” back in your pocket. The inherent failure in the FUZE design is that you don’t need to provide any sort of authentication to pair it to a new Bluetooth device. It makes the (very dangerous) assumption that the person holding it is entitled to do so.
Even if you know better than to ever buy a device like this, the post [Mike] has written up is really a must-read for anyone who’s ever looked at a device and tried to figure out what was going on in its little silicon brain. We especially liked his assertion that reverse engineering a device essentially boils down to: “staring, thinking, a little experimentation, but mostly staring and thinking.” We’re having an internal debate here at Hackaday HQ about making that the site’s tagline.