Swift01: Open Source Mesh Networking by Swiftlet Technology
Swift01: Open Source Mesh Networking by Swiftlet Technology
Open Source, Wireless Mesh Networking. Based on IEEE 802.15.5.
Open Source, Wireless Mesh Networking. Based on IEEE 802.15.5. Read more
Have you ever wished that you could simply hook things together wirelessly? Have you ever wanted to automate everything in your house, but didn’t want to spend $35+ on a wireless module for each node in the network? This is exactly what drove me to envision the Swift01.
What is the Swift01?
The Swift is a wireless hardware module with specialized software running on it that enable it to create and join wireless networks which are designed for sensing and control. Let me give you some examples of how you might use the Swift:
Whole-house temperature monitoring
Attach a temperature sensor to a node and place one in each room of your house. Find hot or cold spots and adjust your heating system, or replace your thermostat with another module that can control your house's temperature from more than just one room’s temperature. Imagine a house that heats based on the temperature of your main rooms during the day, but your bedrooms at night!
Remote, distributed weather station
Collect information from the anemometer on your roof, the thermometer on your porch, and the rain gauge in your yard. Then send that information to WeatherUnderground.com or use it to tailor your heating and cooling, turning down the heat on winter days when it’s sunny.
Reconfigure the lighting in your house
Switch the lamps and light fixtures in your house using a PowerswitchTail and control it from a smart switch or from your phone (over your WiFi network).
Control your home theater
Pair a Swift with an Infrared diode in your home A/V cabinet and pause the movie from your smartphone. Take it a step farther and put in a “Movie time” switch that puts your projector screen down, turns on the projector and A/V receiver, and dims the lights.
The Swift wireless module is currently designed to be attached to an existing processor, like an Arduino or a Raspberry Pi. This means that Swift can’t do any of these things out of the box, but rather these scenarios all become much easier by networking with Swift. There’s a couple of key ideas that allow Swift to simplify each of these scenarios:
You can already connect things together using the Bluetooth on your phone or over the WiFi network in your house, what is so different about Swift?
Swift is built on the concept of Mesh Networking. Mesh networks take point-to-point networks like WiFi and Bluetooth (which only send information between two devices) and puts special software on each device that allows it to send and receive information on behalf of the devices it is in range of (also called that device’s neighbors). Basically, this means that a device can join the network if it can see one device in the network, not just if it can see the router (the range of a device is about 10-100m, this depends on things like the materials in your walls). Actually, all devices essentially become routers, which means that in some situations, you don’t even need a separate router, just the devices themselves.
That being said, mesh networks are already starting to gain traction with devices like ZigBee/XBee and other proprietary wireless modules. Here’s the problem, many mesh protocols aren’t specified in the open so that anyone can write software to implement them. This has the unfortunate effect of locking you down to one company’s wireless technology. Even if the specification is available to see, most mesh network protocols come with a license fee in order to build anything that uses that protocol. In the case of ZigBee, this means increased cost to you, the customer.
By building a mesh network based on an open protocol, it means that any company can build a device that talks on this network and it also means that the network can build on those devices the same way that it can on ours.
The open source philosophy is central to what Swiftlet does. We believe that the more people who can contribute to a project, the more successful that project will be. If you are a Maker or a Tinkerer, this means that you can get inside of the hardware and software and learn by figuring out how things work and, if you want to, fix a bug or add a feature that brings even more value to the product. If you are just someone who buys the end product to put into something else, you can rest more easily knowing that the project has had more than just one set of eyes on it: Things are a lot more likely to work and work well.
Now, I’m sure you are thinking, “If a device can join without being able to see the centralized router, what is to prevent my next-door-neighbor from turning my heat all the way up or malicious hackers disabling my security system?” Security is vital in any digital system, especially one that touches the real world like this one; Swiftlet is whole-heartedly committed to security and will be implementing a best-practices packet-signing security scheme in the base version of the software. This security scheme is based on a Pre-Shared Key that you will set up ahead of time and is unique to your network. This will prevent a digital intruder from sending false messages, but won’t keep your temperature and other information private; in the future, Swiftlet will also work to develop a completely encrypted data transfer method that will obscure all of the information on the network.
Who is going to build this?
I had this idea back in college as a way that an urban farm could better monitor and control the environmental conditions in their greenhouse and I gathered a team to build a platform for wireless sensor networks. Well, if you’ve ever been part of an undergraduate independent study project, you know where this is going: our ambitions were much much greater than our abilities. It was a great learning experience, but we made almost no progress toward our goal of making wireless networking simpler.
After graduating with my Bachelor’s degree in Electrical Engineering, I took a job with a wireless company in their telematics department. I thought this would be the perfect company to make my vision a reality, but in reality, I was working on tracking systems for cars to enable stolen vehicles to be recovered more easily; it's not exactly the home automation systems that I had envisioned. I pitched the idea to the company’s innovation team, but there wasn’t a lot of interest in pursuing it as a business.
Even though the company didn’t want to pursue the idea, I still worked there for about 3 and a half years and picked up information on all aspects of the company, from Hardware design (my job) and firmware design (the other half of our team) to manufacturing, testing, and purchasing. With those experiences in hand, I left that company to kickstart this business and now I’m looking for people like you, who believe in this idea, to partner with me to bring this to reality.
What still needs to be done?
Check out the demo video above to see where the project currently stands!
I have already completed the preliminary hardware design. This includes choosing components, deciding on how everything connects together (Schematic) and connecting it together on a PCB (Board Layout). I have built a handful of prototypes, which you can see in the demo video, but there's a couple of tweaks that I would like to make before I ship the full product. There is a lot more detail about the hardware over on my blog (link), but here are some basic specs:
- Board size: 0.7 in x 1.4 in
- Power input: 3.4-5.5V
- 802.15.4-based Atmel System-on-Chip equipped with Cortex-M0+
- On-board, 2.4GHz trace antenna
- 3.3V Serial UART interface
- 10 I/Os including expandable serial interface and analog I/Os
- On-board serial memory for future features (OTA and on-module scripting, anyone?)
There is a huge software component to this module. When you consider the software responsible for handling the mesh networking, it is not a trivial task. That being said, we have put significant effort into mapping out how long the development should take (+ some extra) and this cost of software development is built into the amount of money we are asking for. Here is a breakdown of the software features that will be on the module when it ships to you:
- Serial Bootloader - This will allow the software to be updated using just the connector and a USB-to-Serial adapter
- Full IEEE 802.15.5 network stack - This is the most important part of the software that routes all of the network traffic and keeps track of its "neighbors"
- AT Command interface - Allows you to configure the network stack and send messages
- AES Message signing - an encrypted add-on that allows each module to know if the message is legitimate
This diagram explains how the software will be put together. For more information, please see this recent blog post about software development.
Here is our project timeline:
- Kickstarter campaign ends successfully: Dec. 8th, 2014
- Beta-level hardware build kicked off: Jan. 5th, 2015
- Beta-level hardware ships to Beta backers: Feb. 2nd
- Main hardware build kicked off: Mar. 2nd
- Software is feature-complete: Apr. 13th
All Kickstarter Rewards shipped: May the 4th
This timeline could change, but those changes will definitely be communicated to you.
There are tons of other things that we want to do with this beyond just the basic networking software, but all of these things require more money for development. If you guys are able to help raise more money than I'm asking for, we can achieve greater things!
- $75,000 - Power saving for battery-operated modules!
Thanks for taking the time to learn about my project. If you like the idea, support me! Even if you're not a techie like me, your donation will still help us get to our goal (and we'll still send you something as a thanks!).
Risks and challenges
“It’s called hardware for a reason – It’s hard” – Marc Andreessen
Building something physical is not without its risks or challenges, but we think we’ve done a pretty good job mitigating a lot of the risk. We’ve done things like add buffers for miscellaneous expenses and tax on revenue (one of the reasons we are asking for so much), investigated both using a contract manufacturer for hardware build and building ourselves, and taken into account the unforeseen time it takes to build software.
Ultimately, the largest risk is to our timeline. Things may take longer than anticipated to build a high-quality product, and we want to be sure that the product is ready before we ship it out to you. Any changes in schedule will be communicated to you, the backer!
- (32 days)