Hackaday Prize Entry: Cheap Visible Light Communication

[Jovan] is very excited about the possibilities presented by Visible Light Communication, or VLC. It’s exciting and new. His opening paragraphs is filled with so many networking acronyms that VLC could be used for, our browser search history now looks like we’re trying to learn english without any vowels.

In lots of ways he has good reason to be excited. We all know that IR can communicate quite a bit, but when you’re clever about frequency and color and throw in some polarizers with a mix of clever algorithms for good measure you can get some very high bandwidth communication with anything in line of site. You can do it for low power, and best of all, there are no pesky regulations to stand in your way.

He wants to build a system that could be used for a PAN (Personal Area Network). To do this he’ll have to figure out a way to build the system inexpensively and using less than a watt of power. The project page is full of interesting experiments and quite a few thesis on the subject of LEDs.

For example, he’s done work on how LEDs respond to polarization. He’s tested how fast an LED can actually turn on and off while still being able to detect the change. He’s also done a lot of work characterizing the kind of light that an LED emits. We don’t know if he’ll succeed yet, but we like the interesting work he’s doing to get there.

MIT Thinks It Can One-Up TOR With New Anonymity Network: Riffle

Tor is the household name in anonymous networks but the system has vulnerabilities, especially when it comes to an attacker finding out who is sending and receiving messages. Researchers at MIT and the École Polytechnique Fédérale de Lausanne think they have found a better way in a system called Riffle. You can dig into the whitepaper but the MIT news article does a great job of providing an overview.

The strength at the core of Tor is the Onion Routing that makes up the last two letters the network’s name. Riffle keeps that aspect, building upon it in a novel way. The onion analogy has to do with layers of skins — a sending computer encrypts the message multiple times and as it passes through each server, one layer of encryption is removed.

Riffle starts by sending the message to every server in the network. It then uses Mix Networking to route the message to its final destination in an unpredictable way. As long as at least one of the servers in the network is uncompromised, tampering will be discovered when verifying that initial message (or through subsequent authenticated encryption checks as the message passes each server).

The combination of Mix Networking with the message verification are what is novel here. The message was already safe because of the encryption used, but Riffle will also protect the anonymity of the sender and receiver.

[via Engadget]

The Terrible Devices Of The Internet Of Wrongs

Last week was Bsides London, and [Steve Lord] was able to give a talk about the devices that could pass for either a terrible, poorly planned, ill-conceived Internet of Things Kickstarter, or something straight out of the NSA toolkit. [Steve] built the Internet of Wrongs, devices that shouldn’t exist, but thanks to all this electronic stuff, does.

Continue reading “The Terrible Devices Of The Internet Of Wrongs”

OpenThread, A Solution To The WiFi Of Things

The term ‘Internet of Things’ was coined in 1999, long before every laptop had WiFi and every Starbucks provided Internet for the latte-sucking masses. Over time, the Internet of Things meant all these devices would connect over WiFi. Why, no one has any idea. WiFi is terrible for a network of Things – it requires too much power, the range isn’t great, it’s beyond overkill, and there’s already too many machines and routers on WiFi networks, anyway.

There have been a number of solutions to this problem of a WiFi of Things over the years, but none have caught on. Now, finally, there may be a solution. Nest, in cooperation with ARM, Atmel, dialog, Qualcomm, and TI have released OpenThread, an Open Source implementation of the Thread networking protocol.

The physical layer for OpenThread is 802.15.4, the same layer ZigBee is based on. Unlike ZigBee, the fourth, fifth, and sixth layers of OpenThread look much more like the rest of the Internet. OpenThread features IPv6 and 6LoWPAN, true mesh networking, and requires only a software update to existing 802.15.4 radios.

OpenThread is OS and platform agnostic, and interfacing different radios should be relatively easy with an abstraction layer. Radios and networking were always the problem with the Internet of Things, and with OpenThread – and especially the companies supporting it – these problems might not be much longer.

Find The Source: WiFi Triangulation

[Michael] was playing with his ESP8266. Occasionally he would notice a WiFi access point come up with, what he described as, “a nasty name”. Perhaps curious about the kind of person who would have this sort of access point, or furious about the tarnishing of his formerly pure airspace, he decided to see if he could locate the router in question.

[Michael] built himself a warwalking machine. His ESP8266 went in along with a GPS module interfaced with a PIC micro controller. It was all housed in an off the shelf case with a keypad and OLED screen. He took his construction for a nice calming war walk around the neighborhood and came home with a nice pile of data to sort through. To save time, he placed the data in a SQL database and did the math using queries. After that it was a quick kludge to put together a website with the Google Maps API and some JavaScript to triangulate the computed results.

Sure enough, the person with the questionable WiFi access point shows up on the map.

Minimal MQTT: Control And Clients

So you’ve built a central server and filled your house with WiFi-connected nodes all speaking to each other using the MQTT protocol. In short, you’ve got the machine-to-machine side of things entirely squared away. Now it’s time to bring the humans into the loop! We’re going to explore a couple graphical user interfaces.

You could build a physical knob and/or LED display for every little aspect of your entire system, but honestly, this is where GUIs really shine. In this installment of Minimal MQTT, we’re going to look at human-friendly ways of consuming and producing data to interact with your connected sensors, switches, and displays. There are a ton of frameworks out there that use MQTT to build something like this, but we’re going to cut out the middle-man and go straight for some GUI MQTT clients.

Continue reading “Minimal MQTT: Control And Clients”

Minimal MQTT: Building A Broker

In this short series, we’re going to get you set up with a completely DIY home automation system using MQTT. Why? Because it’s just about the easiest thing under the sun, and it’s something that many of you out there will be able to do with material on-hand: a Raspberry Pi as a server and an ESP8266 node as a sensor client. Expanding out to something more complicated is left as an exercise to the motivated reader, or can be simply left to mission creep.

We’ll do this in four baby steps. Each one should take you only fifteen minutes and is completely self-contained. There’s a bunch more that you can learn and explore, but we’re going to get you a taste of the power with the absolute minimal hassle.

In this installment, we’re going to build a broker on a Raspberry Pi, which is the hub of your MQTT network. Next time, we’ll get an ESP8266 up and running and start logging some data. After that, we’ll do some back-end scripting in Python to make the data speak, and in the last installment, we’ll explore some of the useful frills and fancy bits. Let’s get started!

Continue reading “Minimal MQTT: Building A Broker”