Say you’ve got a neat gadget you are building. You need to send data to it, but you want to keep it simple. You could add a WiFi interface, but that sucks up power. Bluetooth Low Energy uses less power, but it can get complicated, and it’s overkill if you are just looking to send a small amount of data. If your device has a microphone, there is another way that you might not have considered: ultrasonic communications. Continue reading “Hackaday Dictionary: Ultrasonic Communications”
A problem faced by all collaborative working spaces as they grow is that of access control. How can you give your membership secure access to the space without the cost and inconvenience of having a keyholder on site at all times.
Each door has a client with RFID readers, either a Raspberry Pi or an ESP8266, which connects via WiFi to a Raspberry Pi 2 server running a Django-based REST API. This server has access to a database of paid-up members and their RFID keys, so can issue the command to the client to unlock the door. The system also supports the Telegram messaging service, and so can be queried as to whether the space is open and how many members are in at a particular time.
This is a project that is still in active development, and [Torehc] admits that its security needs more work so is busy implementing HTTPS and better access security. As far as we can see through the fog of machine translation at the moment it relies on the security of its own encrypted WiFi network, so we’d be inclined to agree with him.
This isn’t the first hackerspace access system we’ve featured here. The MakerBarn in Texas has one using the Particle Photon, while the Lansing Makers Network in Michigan have an ingenious mechanism for their door, and the Nesit hackerspace in Connecticut has a very fancy system with video feedback. How does your space solve this problem?
Last time I talked about the internals of how Bluetooth Low Energy (BLE) handles data. I mentioned that the way it is set up is meant to conserve power and also to support common BLE devices like heart rate monitors. On the other hand, I also mentioned that you often didn’t need to deal with that because you’d use an abstraction layer.
This time, I want to show you how I used the Hackaday special edition Tiny BLE (from Seeed Studios) and its mbed library to do a quick simple BLE project. If you didn’t read the first part, don’t worry. The abstraction is so good, you probably won’t have to unless you want to circle back around later and get a more detailed understanding of what’s happening under the covers.
I wanted something simple for an example so you could build on it without having to remove much code. For that reason, I decided to allow my phone to control the state of a three-color LED via BLE. To do that, I’m going to use a virtual UART and some off-the-shelf phone software. The whole thing won’t take much code, but that’s the point: the abstraction makes BLE relatively simple.
If you need an industrial-strength IoT product, you need an industrial-strength WiFi chipset. For our own household hacks, we’re totally happy with the ESP8266 chip. But if you need to connect to the big, scary Internet you’ll probably want state-of-the-art encryption. In particular, Amazon insists on TLS 1.2 for their Web Services (AWS), and we don’t know how to get that working on the ESP.
[Anuj] designed a breakout board called the knit which includes a Marvell MW300 WiFi SOC. This chip has an onboard ARM Cortex M4F running at 200 MHz, which means you’ve got a lot of everything to play with: flash memory, RAM, a floating-point unit, you name it. And Marvell’s got an SDK for using AWS that includes things like an operating system and peripheral support and other niceties. TLS 1.2 is included.
Best of all, a MW300 breakout is reasonably affordable (though more expensive than the mass-produced ESP8266 modules, naturally) and it’s an entirely open design. [Anuj] also seems to be setting up for a production run, if you don’t feel like making it yourself.
The MW300 is in all sorts of commercial IoT designs, and it’s a battle-tested go-to for interfacing with “the cloud” securely. The only hobbyist-friendly board that’s similar is the Adafruit WICED WiFi Feather, but it’s more expensive, less powerful, and out of stock at the moment, which just shows the demand for something like this.
Of course, if you need more integrated peripherals, you could just hack up a “Hello Barbie” toy which has the same chip as well as sweet audio codecs and a nice fat flash ROM.
We think it’s neat that [Anuj] would make and test a breakout for this powerful little WiFi SOC. We don’t need one for our projects right now — we’re running in entirely insecure mode — but it’s good to know what your options are. (We’re also looking into esp-open-rtos for the ESP8266 — we know they’ve been working on TLS 1.2 encryption, but we don’t know what their status is at the moment. Anyone?)
In any motorsport, the more you know about how the engine is performing, the better a driver is likely to do in a race. That holds for bicycles, too, where the driver just happens to also be the engine. There are plenty of cheap bike computers on the market, but the high-end meters that measure power output are a bit pricey. [chiprobot] is looking to change that with a home-brew, low-cost bike power meter.
The project still appears to be in the proof-of-concept phase, but it’s an interesting concept for sure. The stock crank arms are carefully fitted with two pairs of tiny strain gauges. The gauges are wired in a Wheatstone bridge arrangement, with one gauge in each pair mounted perpendicular to the force on the crank to serve as a static reference. Output from the bridge is fed to an HX711 instrumentation amplifier. The demo video below shows how sensitive the bridge and 24-bit amp are.
The goal is to send crank data to a handlebar-mounted UI via WiFi with a pair of ESP8266 modules. We like the idea of a bicycle area network, but [chiprobot] has his work cut out for him in terms of ruggedizing and weatherproofing all this gear. We’ll be sure to keep an eye on this project. In the meantime, there’s plenty to learn from this bike power meter project we covered last year.
It is a good bet that you have at least one Bluetooth device hanging around. Headsets, mice, keyboards, and speakers have become increasingly common. Bluetooth forms a short range wireless network and can also perform file transfers and create virtual serial ports.
If you have ever had to stop listening to music to recharge a Bluetooth headphone, you know Bluetooth won’t run long on batteries. In 2006, Nokia introduced Wibree, which would later become Bluetooth Low Energy (or BLE). These days it’s used in everything and it’s well worth your time to gather a basic understanding of this technology.
Getting back to basics is a great way to teach yourself about a technology. We see it all the time with computers built from NAND gates or even discrete transistors. It’s the same for radio – stripping it back to the 19th century can really let you own the technology. But if an old-school wireless setup still needs a 21st-century twist to light your fire, try this spark gap transmitter and coherer receiver with a Beagle Bone Morse decoder.
At its heart, a spark gap transmitter is just a broadband RF noise generator, and as such is pretty illegal to operate these days. [Ashish Derhgawen]’s version, which lacks an LC tuning circuit, would be especially obnoxious if it had an antenna. But even without one, the 100% electromechanical transmitter is good for a couple of feet – more than enough for experimentation without incurring the wrath of local hams.
The receiver is based on a coherer, a device that conducts electricity only when a passing radio wave disturbs it. [Ashish]’s coherer is a slug of iron filings between two bolts in a plastic tube. To reset the coherer, [Ashish] added a decoherer built from an electromagnetic doorbell ringer to tap the tube and jostle the filings back into the nonconductive state. He also added an optoisolator to condition the receiver’s output for an IO pin on the Beagle, and a Python script to decode the incoming Morse. You can see it in action in the video below.
If this build looks familiar, it’s because we’ve covered [Ashish]’s efforts before. But this project keeps evolving, and it’s nice to see where he’s taken it and what he’s learned – like that MOSFETs don’t like inductive kickback much.