A lot of talk around Beacons and the promise of 'Low Energy', without that much factual data around the amount of power they source from your smartphone battery mostly.
Maybe it's a good time to update some of those figures. Eg, NFC range now goes up to 10cm-12cm or longer. Also, it would be nice to include power consumption from the ucontrollers that are used with those wireless transmitters to be more representative.
This is a few years old and leaves out 6LoWPAN[1], which wasn't yet commercially viable. 6LoWPAN is based on the same 802.15.4 hardware that ZigBee uses, but it has two significant advantages over ZigBee. First, it is TCP/IP that works on microcontrollers, so embedded devices running the protocol become first-class members of the internet with the addition of a very inexpensive router[2] to the network. This means that sensor nodes and embedded devices can seamlessly interoperate with traditional servers in a distributed computing environment and many programming techniques can be directly adapted.
Second, 6LoWPAN can be configured so that all nodes involved can sleep, whereas ZigBee requires always-on routing nodes in order to produce a true mesh. This means it isn't possible to use ZigBee to construct a mesh out of fungible battery-powered devices, which is a big problem for many applications.
If this interests you, there are a couple of very capable chips that have been released recently that are ideal for use with 6LoWPAN, namely TI's CC2538 [3] and Atmel's SAM R21 [4]. They both are supported by Contiki OS[5], which provides network stacks for extremely resource-constrained devices. It has been under development for ~10 years at this point as an open source academic/hobby project but in the last couple of years it has become significantly more professional and it is now used in many commercial applications. In addition, its core architects have launched a company called Thingsquare[6] based on Contiki which aims to be Heroku for low-powered wireless devices.
[1] IPv6 over Low power Wireless Personal Area Networks
DASH7, the alliance, is a failed enterprise, imho. Their spec and OpenTag firmware both look great from a high level but once you attempt to use them you will find huge holes in the implementation of each.
ISO 18000-7, although power hungry compared to most every proprietary wireless protocol, is a well deployed and understood spec with many users. There is an upcoming version of the spec with some new things, get involved in the working group or get a draft copy to find out the details.
If you're looking for 433 MHz band RF, take a look at IEEE 802.15.4 and the "f" and "e" amendments. These will allow you to do 6LoWPAN, if you want, or to simply use the PHY and MAC layer from a international specification. Just be aware of the "fun" you'll have in the 433 MHz band in different parts of the world.
Maybe this will also answer some of the other questions:
6LoWPAN is not an implementation, it's a term used to describe a suite of open standards maintained by the IETF. The Working group is also called 6LoWPAN, IIRC.
The suite primarily provides a standardized packet format and addressing information. This is a good starting point - http://tools.ietf.org/html/rfc4944. This is needed because Regular IPv6 packets are way too large for sensor network purposes. The standardization also allows these devices to interop with regular IPv6 gateways.
AFAIK work on all this started in TinyOS and they still maintain a solid implementation. TinyOS also works on extremely small devices and has a reasonably active community.
Also, from my understanding There's nothing inherent to 6LoWpAN that allows sleep. It's just that the protocol doesn't really care about how nodes operate. Routing protocols are free to build on top of this packet format and work however. Some of them allow nodes to sleep (e.g. RPL in some implementations) and some do not.
10 comments
[ 14.1 ms ] story [ 1478 ms ] threadSecond, 6LoWPAN can be configured so that all nodes involved can sleep, whereas ZigBee requires always-on routing nodes in order to produce a true mesh. This means it isn't possible to use ZigBee to construct a mesh out of fungible battery-powered devices, which is a big problem for many applications.
If this interests you, there are a couple of very capable chips that have been released recently that are ideal for use with 6LoWPAN, namely TI's CC2538 [3] and Atmel's SAM R21 [4]. They both are supported by Contiki OS[5], which provides network stacks for extremely resource-constrained devices. It has been under development for ~10 years at this point as an open source academic/hobby project but in the last couple of years it has become significantly more professional and it is now used in many commercial applications. In addition, its core architects have launched a company called Thingsquare[6] based on Contiki which aims to be Heroku for low-powered wireless devices.
[1] IPv6 over Low power Wireless Personal Area Networks
[2] http://redwire.myshopify.com/collections/frontpage/products/...
[3] http://www.ti.com/product/cc2538
[4] http://www.atmel.com/tools/atsamr21-xpro.aspx?tab=devices
[5] http://contiki-os.org/
[6] http://thingsquare.com/
[7] If you want some CC2538-based open hardware: http://www.openmote.com/
[1] http://en.wikipedia.org/wiki/DASH7
ISO 18000-7, although power hungry compared to most every proprietary wireless protocol, is a well deployed and understood spec with many users. There is an upcoming version of the spec with some new things, get involved in the working group or get a draft copy to find out the details.
If you're looking for 433 MHz band RF, take a look at IEEE 802.15.4 and the "f" and "e" amendments. These will allow you to do 6LoWPAN, if you want, or to simply use the PHY and MAC layer from a international specification. Just be aware of the "fun" you'll have in the 433 MHz band in different parts of the world.
One question: how well does 6LowPAN support low-power(6-12 months on a battery) combined with low-latency(1-2 sec) ?
6LoWPAN is not an implementation, it's a term used to describe a suite of open standards maintained by the IETF. The Working group is also called 6LoWPAN, IIRC.
The suite primarily provides a standardized packet format and addressing information. This is a good starting point - http://tools.ietf.org/html/rfc4944. This is needed because Regular IPv6 packets are way too large for sensor network purposes. The standardization also allows these devices to interop with regular IPv6 gateways.
AFAIK work on all this started in TinyOS and they still maintain a solid implementation. TinyOS also works on extremely small devices and has a reasonably active community.
Also, from my understanding There's nothing inherent to 6LoWpAN that allows sleep. It's just that the protocol doesn't really care about how nodes operate. Routing protocols are free to build on top of this packet format and work however. Some of them allow nodes to sleep (e.g. RPL in some implementations) and some do not.