OpenWSN与目前热吵的ZigBee有什么关系吗？
首先，需要明确OpenWSN的用途，该开源项目的提出，一是为了满足科研人员对高性能WSN平台的需要（包括我自己），二是附带的为工业应用提供一个可靠的基础开发平台，毕竟，研究的成果应该到实际应用中去检验。
由此，可以理解OpenWSN与ZigBee的不同：
- OpenWSN为Open Source，强调公益性；ZigBee强调商业利益，几乎所有ZigBee解决方案都存在某种程序的封闭性，比如说Chipcon的方案绑定在Atmega MCU，Freescale的方案绑定在自己的MCU，且源代码一般不开放，如果需要获得源码，就要付出高昂的费用。
- OpenWSN重点关注的内容之一就是ZigBee中被封闭的部分，且其覆盖范围更宽。比如说，MAC和Routing, Location, Time Synchronization等，ZigBee毕竟只规定了很小一部分。
- OpenWSN关注底层，放开应用层(Application Layer)，因为OpenWSN相信，应该赋予使用者最大的自由，而应用层又是变化最多的，因此，OpenWSN不限定应用层，只提供若干规范的开发接口。而ZigBee则一直规定到应用层。
- OpenWSN目标中包括了mobile sink和mobile node情形，而ZigBee可以说只考虑了固定结点情形；
- 如果说ZigBee主要是满足当前实际需要，那么OpenWSN更强调未来。
- OpenWSN与ZigBee都强调互联互通，规范化，标准化
由此可见，OpenWSN更学术化一些，更适合在研究和原型化阶段采用。
那么，OpenWSN和ZigBee有什么关联吗？
OpenWSN首选了ZigBee Compatible Transceiver CC2420作为通信芯片，这使得OpenWSN平台可以被用来开发ZigBee应用，OpenWSN平台资源丰富，可以在一定程度上方便开发。
.
Beyond ZigBee!
Developed by OpenWSN/OpenM2M Group
Led by Dr. Wei Zhang, SEE, TongJi University
http://code.google.com/p/openwsn/
Wednesday, February 28, 2007
Tuesday, February 27, 2007
声明：openwsn.com is NOT me!
郑重声明：openwsn.com is NOT me!——都是重名惹得祸！
本人并未注册openwsn.com的域名！openwsn.com与OpenWSN Project/Group没有任何关系，尽管它的简介中也出现了open wireless sensor networks字样。事实上，该域名从注册之日起，其网站就从未运行过。今后，该网站若有任何活动，也与OpenWSN Project/Group无关。
也许，应该考虑起一个更好的名称！大家有更好的建议吗？
Sunday, February 11, 2007
OpenWSN Frame/Packet Summary (draft 20070210)
OpenWSN Frame/Packet Summary (draft 20070210)
this document describes the format of frames/packets in the OpenWSN system.
attention: this design may be different from what we have done now. we will adjust our system to the following. however, some detail are still in discussion.
IEEE 802.15.4 PPDU format
[4B Preamble][1B SFD][7b Framelength, 1b Reserved][nB PSDU/Payload]
QQQ: whether the higher 7 bit or lower 7 bit represent framelength? can any one answer me?
Note that the preamble byte and SFD (start of eliminator) will be processed by hardware chips. so the software only need care about the data from frame length byte. so the real OpenWSN PHY frame defined in OpenWSN software is as the following:
OpenWSN PHY format (TOpenFrame type defined in hal_openframe.h):
[7b Framelength, 1b Reserved][nB PSDU/Payload]
here, PSDU(or namely the payload of PPDU)
is essentially the MAC frame.
attention that OpenWSN MAC format may use the reserved values in IEEE 802.15.4 MAC in the future.
OpenWSN MAC/IEEE 802.15.4 MAC DATA (the payload of PHY frame)
Beacon Frame
[2B Frame Control] [1B Sequence Number][4 or 10 Address][2 Superframe Specification] [k GTS fields][m Padding address fields] [n Beacon payload][2 FCS]
Data Frame
[2B Frame Control] [1B Sequence Number][4 or 20 Address][n Data Payload][2 FCS]
ACK Frame
[2B Frame Control] [1B Sequence Number][2 FCS]
MAC Control Frame
[2B Frame Control] [1B Sequence Number][4 or 20 ADdress][1 Command Type][n Command Payload][2 FCS]
Frame Control
b2b1b0 frame type 000 beacon, 001 data 010 ACK 011 command 100-111 reserved
b12b13 reserved.
One problem puzzled the developer is the format of MAC address. the MAC address varies from 4 byte to even 20 bytes in 802.15.4. The type of address can be decided by the bit settings in Frame Control word in MAC frame.
In the current implementation of OpenWSN, it uses the short address of 802.15.4 MAC only. That is to say, the PAN id, source node id, and destination node id are all 16 bits.
In 802.15.4, the address(unique id) of a device/node, can be 16 bit/2 bytes (short address) or 64 bit/8 bytes (long address). The long 64 bits address is unique in the world. It should be allocated to the device before the device joins the network. While, the short 16 bit address is unique in a specific PAN. So the short address is only meaning full when combining with PAN id together.
However, there's some difference between OpenMAC and 802.15.4.
OpenMAC does more simplifications than 802.15.4 and also add some new features.
- OpenMAC doesn't provide Beacon Frame
- OpenMAC introduce RTS/CTS frame (not implemented till 20070130 in its simple MAC version, but the full version MAC will implement this mechanism)
- OpenMAC adopts the 802.15.4 MAC control frame and extend it to support RTS / CTS frame.
- OpenMAC adopts the 802.15.4 ACK frame. But the software implementation doesn't care this because the ACK frame is processed by cc2420 transceiver chip.
attention:
there's a macro defined in the OpenWSN software: MAC_HEADER_SIZE. this value is 7(???) = 2 frame control + 1 sequence + 4 address bytes (according to the DATA frame only).
OpenNET packet is essentially the payload of the OpenMAC frame.
NET layer also has its address. The NET layer address and MAC layer address are not same. In OpenNET design, every node is assigned a 16 bit unique id (node id) and 16 bit network id (the same as PAN id). So the design can be simplified ---- OpenMAC and OpenNET share the same address fields.
The OpenNET packet:
[4-20B Address] [1B packet control] [1B Command Type] [nB Data]
attention here the "type" byte is the network layer command/packet type. Don't confuse it with MAC layer command. The MAC layer command is used in MAC layer only.
[4-20B Address]
the 4-20B address is shared by OpenMAC frame and OpenNET packet. Due to the complexity address assignment mechanism of MAC address in full version 802.15.4, OpenNET may introduce self-owned address field in the future. But i think it isn't necessary now. So i still let OpenMAC and OpenNET share the same address field.
[1B packet control] = [b7,...b0]
the packet control byte are reserved for future use.
b0 REQUEST flag, default 0
b0 = 0, means this is a RESPONSE packet. the destination node does nothing when it received the packet. this type is usually sent from the sink node to all the other sensor nodes.
b0 = 1 means this is a REQUEST packet. the destination node is required to reply a RESPONSE type packet. this type is often sent from the sensor nodes to the sink nodes.
b1 BROADCASR flag, default 0
b1 = 0, not broadcast
b1 = 1, the current node should broadcast this packet out.
the above attributes can help to implement NET layer protocols such as SPIN.
[1B Command Type] = [b7,...b0]
b7 is used to distinguish whether the command is a OpenWSN system command or user command (namely, application defined command). b7 is 0 for openwsn system command and 1 for application command.
/* system used data types */
#define ODA_TYPE_DEBUG 0x00
#define ODA_TYPE_CONFIGURE 0x01
#define ODA_TYPE_DATA 0x02
#define ODA_TYPE_LOCATION 0x06
#define ODA_TYPE_UPGRADE 0x07
#define ODA_TYPE_PROBE 0x08 // probing neighbor nodes
/* user defined data type
* the developer can add more TYPE defines if necessary. */
#define ODA_TYPE_USER 0x80
#define ODA_TYPE_TEMPSENSOR (ODA_TYPE_USER + 5)
#define ODA_TYPE_VIBSENSOR (ODA_TYPE_USER + 6)
#define ODA_TYPE_STRAINSENSOR (ODA_TYPE_USER + 7)
#define ODA_TYPE_LIGHTSENSOR (ODA_TYPE_USER + 8)
#define ODA_TYPE_OTHER_USER_DEFINED (ODA_TYPE_USER + 100)
attention the values may be adjusted in the near future. however, i'll try my best to make they are stable.
UART frame is quite similar to the wireless PHY frame.
[1B SFD] [1B Length] [nB Payload]
in UART frame, a special byte is used to indicate the start of the frame. attention here OpenWSN uses the technique of ESCAPE character idea to avoid data confilications. The SFD (start of eliminator) byte is used to represent the start of the frame. if there are SFD characters in Length and Payload, then the UART driver will insert another SFD as ESCAPE character.
(??? i have forgot the detail of UART/SIO driver, so this idea need confirmation)
attention that the Payload of the frame is essentially anything. But in our reference implementation of OpenWSN, we makes the "TOpenFrame" describe above as the payload. So the host application can got all the information of the hardware wireless communications. This feature facilitate the developing of host GUI applications.
.
this document describes the format of frames/packets in the OpenWSN system.
attention: this design may be different from what we have done now. we will adjust our system to the following. however, some detail are still in discussion.
- OpenWSN PHY Frame (in wireless communication)
IEEE 802.15.4 PPDU format
[4B Preamble][1B SFD][7b Framelength, 1b Reserved][nB PSDU/Payload]
QQQ: whether the higher 7 bit or lower 7 bit represent framelength? can any one answer me?
Note that the preamble byte and SFD (start of eliminator) will be processed by hardware chips. so the software only need care about the data from frame length byte. so the real OpenWSN PHY frame defined in OpenWSN software is as the following:
OpenWSN PHY format (TOpenFrame type defined in hal_openframe.h):
[7b Framelength, 1b Reserved][nB PSDU/Payload]
here, PSDU(or namely the payload of PPDU)
is essentially the MAC frame.
- OpenWSN MAC Frame (in wireless communication)
attention that OpenWSN MAC format may use the reserved values in IEEE 802.15.4 MAC in the future.
OpenWSN MAC/IEEE 802.15.4 MAC DATA (the payload of PHY frame)
Beacon Frame
[2B Frame Control] [1B Sequence Number][4 or 10 Address][2 Superframe Specification] [k GTS fields][m Padding address fields] [n Beacon payload][2 FCS]
Data Frame
[2B Frame Control] [1B Sequence Number][4 or 20 Address][n Data Payload][2 FCS]
ACK Frame
[2B Frame Control] [1B Sequence Number][2 FCS]
MAC Control Frame
[2B Frame Control] [1B Sequence Number][4 or 20 ADdress][1 Command Type][n Command Payload][2 FCS]
Frame Control
b2b1b0 frame type 000 beacon, 001 data 010 ACK 011 command 100-111 reserved
b12b13 reserved.
One problem puzzled the developer is the format of MAC address. the MAC address varies from 4 byte to even 20 bytes in 802.15.4. The type of address can be decided by the bit settings in Frame Control word in MAC frame.
In the current implementation of OpenWSN, it uses the short address of 802.15.4 MAC only. That is to say, the PAN id, source node id, and destination node id are all 16 bits.
In 802.15.4, the address(unique id) of a device/node, can be 16 bit/2 bytes (short address) or 64 bit/8 bytes (long address). The long 64 bits address is unique in the world. It should be allocated to the device before the device joins the network. While, the short 16 bit address is unique in a specific PAN. So the short address is only meaning full when combining with PAN id together.
However, there's some difference between OpenMAC and 802.15.4.
OpenMAC does more simplifications than 802.15.4 and also add some new features.
- OpenMAC doesn't provide Beacon Frame
- OpenMAC introduce RTS/CTS frame (not implemented till 20070130 in its simple MAC version, but the full version MAC will implement this mechanism)
- OpenMAC adopts the 802.15.4 MAC control frame and extend it to support RTS / CTS frame.
- OpenMAC adopts the 802.15.4 ACK frame. But the software implementation doesn't care this because the ACK frame is processed by cc2420 transceiver chip.
attention:
there's a macro defined in the OpenWSN software: MAC_HEADER_SIZE. this value is 7(???) = 2 frame control + 1 sequence + 4 address bytes (according to the DATA frame only).
- OpenNET Packet (in wireless communication)
OpenNET packet is essentially the payload of the OpenMAC frame.
NET layer also has its address. The NET layer address and MAC layer address are not same. In OpenNET design, every node is assigned a 16 bit unique id (node id) and 16 bit network id (the same as PAN id). So the design can be simplified ---- OpenMAC and OpenNET share the same address fields.
The OpenNET packet:
[4-20B Address] [1B packet control] [1B Command Type] [nB Data]
attention here the "type" byte is the network layer command/packet type. Don't confuse it with MAC layer command. The MAC layer command is used in MAC layer only.
[4-20B Address]
the 4-20B address is shared by OpenMAC frame and OpenNET packet. Due to the complexity address assignment mechanism of MAC address in full version 802.15.4, OpenNET may introduce self-owned address field in the future. But i think it isn't necessary now. So i still let OpenMAC and OpenNET share the same address field.
[1B packet control] = [b7,...b0]
the packet control byte are reserved for future use.
b0 REQUEST flag, default 0
b0 = 0, means this is a RESPONSE packet. the destination node does nothing when it received the packet. this type is usually sent from the sink node to all the other sensor nodes.
b0 = 1 means this is a REQUEST packet. the destination node is required to reply a RESPONSE type packet. this type is often sent from the sensor nodes to the sink nodes.
b1 BROADCASR flag, default 0
b1 = 0, not broadcast
b1 = 1, the current node should broadcast this packet out.
the above attributes can help to implement NET layer protocols such as SPIN.
[1B Command Type] = [b7,...b0]
b7 is used to distinguish whether the command is a OpenWSN system command or user command (namely, application defined command). b7 is 0 for openwsn system command and 1 for application command.
/* system used data types */
#define ODA_TYPE_DEBUG 0x00
#define ODA_TYPE_CONFIGURE 0x01
#define ODA_TYPE_DATA 0x02
#define ODA_TYPE_LOCATION 0x06
#define ODA_TYPE_UPGRADE 0x07
#define ODA_TYPE_PROBE 0x08 // probing neighbor nodes
/* user defined data type
* the developer can add more TYPE defines if necessary. */
#define ODA_TYPE_USER 0x80
#define ODA_TYPE_TEMPSENSOR (ODA_TYPE_USER + 5)
#define ODA_TYPE_VIBSENSOR (ODA_TYPE_USER + 6)
#define ODA_TYPE_STRAINSENSOR (ODA_TYPE_USER + 7)
#define ODA_TYPE_LIGHTSENSOR (ODA_TYPE_USER + 8)
#define ODA_TYPE_OTHER_USER_DEFINED (ODA_TYPE_USER + 100)
attention the values may be adjusted in the near future. however, i'll try my best to make they are stable.
- OpenWSN UART/SIO Frame (in serial communication)
UART frame is quite similar to the wireless PHY frame.
[1B SFD] [1B Length] [nB Payload]
in UART frame, a special byte is used to indicate the start of the frame. attention here OpenWSN uses the technique of ESCAPE character idea to avoid data confilications. The SFD (start of eliminator) byte is used to represent the start of the frame. if there are SFD characters in Length and Payload, then the UART driver will insert another SFD as ESCAPE character.
(??? i have forgot the detail of UART/SIO driver, so this idea need confirmation)
attention that the Payload of the frame is essentially anything. But in our reference implementation of OpenWSN, we makes the "TOpenFrame" describe above as the payload. So the host application can got all the information of the hardware wireless communications. This feature facilitate the developing of host GUI applications.
.
Friday, February 09, 2007
The Future of Things 推荐,可能影响WSN的一些具体应用
Nanobatteries – Away with Exploding Batteries
http://www.tfot.info/content/view/111/61/
Blood Test Lab-on-a-Chip
http://www.tfot.info/content/view/98/60/
BioPen Senses BioThreats
http://www.tfot.info/content/view/96/56/
TFOT Top 2006 Stories in Science, Medicine, and Space
http://www.tfot.info/content/view/108/57/
TFOT Top 2006 Stories in Technology
http://www.tfot.info/content/view/109/58/
.
http://www.tfot.info/content/view/111/61/
Blood Test Lab-on-a-Chip
http://www.tfot.info/content/view/98/60/
BioPen Senses BioThreats
http://www.tfot.info/content/view/96/56/
TFOT Top 2006 Stories in Science, Medicine, and Space
http://www.tfot.info/content/view/108/57/
TFOT Top 2006 Stories in Technology
http://www.tfot.info/content/view/109/58/
.
Nokia发布了新的NFC无线标准Wibree, 替代Bluetooth?
速率比802.15.4/ZigBee高，可达1M，但距离也更近，较Bluetooth 2.0速率要低，但成本也更低
据说Nokia已经联合了CSR，Nodic等一批公司，样片在2007第二季度发布。
基本上可以说是ZigBee的有力竞争对手。看来，欧洲人还是很喜欢和美国对着干！
有关背景材料
Welcome to the No.1 online source of technical design information for Wibree
By Nodic
http://www.wibree.nordicsemi.no/
The Future of Things网站上的简介
这个网站很有意思，是一个了解趋势培养兴趣的好地方
http://www.tfot.info/content/view/97/59/
不知道这个网站怎么回事，和Nokia什么关系?
http://www.wibree.com/
http://www.wibree.org.uk/
业界的一些评论
Wibree Will Kill ZigBee, Long Live Bluetooth
http://www.theinquirer.net/default.aspx?article=34919
.
据说Nokia已经联合了CSR，Nodic等一批公司，样片在2007第二季度发布。
基本上可以说是ZigBee的有力竞争对手。看来，欧洲人还是很喜欢和美国对着干！
有关背景材料
Welcome to the No.1 online source of technical design information for Wibree
By Nodic
http://www.wibree.nordicsemi.no/
The Future of Things网站上的简介
这个网站很有意思，是一个了解趋势培养兴趣的好地方
http://www.tfot.info/content/view/97/59/
不知道这个网站怎么回事，和Nokia什么关系?
http://www.wibree.com/
http://www.wibree.org.uk/
业界的一些评论
Wibree Will Kill ZigBee, Long Live Bluetooth
http://www.theinquirer.net/default.aspx?article=34919
.
最新无线联网协议RuBee渐热 IEEE 1902.1
NFC的标准现在真是越来越多， 看IEEE又发布了新标准 IEEE 1902.1
特点和评价：低频长波，应该适用于有障碍物甚至金属物阻挡的场合；由此推断其通信速率无疑应该是很低的，似乎是主动RFID的合适选择，但不适合移动类应用，除非移动速率很低。
最新无线联网协议RuBee渐热
技术分类： 通信与网络 发表时间：2007-02-09
您已经熟悉了ZigBee，正在寻求WiBree的用途，现在要开始熟悉另一个无线联网协议RuBee，也称为IEEE 1902.1。零售商和制造商可以在RFID之外选择这个新标准，用于许多应用。
开发RuBee的IEEE工作组将于2月20日在美国麻省波士顿召开第一次会议。RuBee的支持方表示RuBee网络可在10到50英尺范围内采用长波长工作，并可使用低成本无线标签。网络中可包括成千上万的无线标签，工作频率低于450kHz，适用于恶劣环境下的实时库存应用，甚至可以在金属和水的附近以及存在电磁噪音的环境中工作。这种恶劣环境是RuBee吸引用户的关键，也是RFID进入广泛、高性价比实施的主要障碍。
使用RuBee的产品具有的另一项优势是能够直接将数据传到因特网，而RuBee的低速特性使它不适于跟踪许多仓库中的大量的运动中的产品。
但是，RuBee标准的支持各方并没有将其看作RFID的替代技术，而是适用于特定应用的另一种方案。RuBee无线标签可以采用有源标签或者无源标签，使用低廉的锂电池的标签的寿命可达10年以上。使用长波长技术也使其成本低，厚度不到1.5毫米，
可使用4位处理器进行编程。
RuBee标准的制定方认为RuBee网络填补了没有联网、不可编程的RFID标签与采用本地网(802.11)和个人网(802.15)的高带宽的辐射系统之间的空白。这种可搜索标签的实时协议使用IPv4地址，使用这种协议的产品有望在12到18个月内面世。
RuBee的最初支持方包括：大型零售公司，如英国的Tesco集团、德国的Metro连锁店、法国的家乐福和美国的BestBuy；芯片供应商、网络设备厂家和系统开发商，如惠普、IBM、索尼、松下、摩托罗拉和NCR。
1902.1标准将根据现有的RuBee协议，在物理层和数据连路层工作，支持不同制造商推出的标签、芯片、网络路由器和其他设备之间的互操作。
RuBee网络已经在商业应用中使用，包括：医院和手术室中的高价值医疗设备的智能货架；用于库存跟踪的智能商店和仓库货架以及用于牲畜、麋鹿和其他进口动物的农用网络。
Ref: EDN China
http://article.ednchina.com/Communinet/20070208094914.htm
特点和评价：低频长波，应该适用于有障碍物甚至金属物阻挡的场合；由此推断其通信速率无疑应该是很低的，似乎是主动RFID的合适选择，但不适合移动类应用，除非移动速率很低。
最新无线联网协议RuBee渐热
技术分类： 通信与网络 发表时间：2007-02-09
您已经熟悉了ZigBee，正在寻求WiBree的用途，现在要开始熟悉另一个无线联网协议RuBee，也称为IEEE 1902.1。零售商和制造商可以在RFID之外选择这个新标准，用于许多应用。
开发RuBee的IEEE工作组将于2月20日在美国麻省波士顿召开第一次会议。RuBee的支持方表示RuBee网络可在10到50英尺范围内采用长波长工作，并可使用低成本无线标签。网络中可包括成千上万的无线标签，工作频率低于450kHz，适用于恶劣环境下的实时库存应用，甚至可以在金属和水的附近以及存在电磁噪音的环境中工作。这种恶劣环境是RuBee吸引用户的关键，也是RFID进入广泛、高性价比实施的主要障碍。
使用RuBee的产品具有的另一项优势是能够直接将数据传到因特网，而RuBee的低速特性使它不适于跟踪许多仓库中的大量的运动中的产品。
但是，RuBee标准的支持各方并没有将其看作RFID的替代技术，而是适用于特定应用的另一种方案。RuBee无线标签可以采用有源标签或者无源标签，使用低廉的锂电池的标签的寿命可达10年以上。使用长波长技术也使其成本低，厚度不到1.5毫米，
可使用4位处理器进行编程。
RuBee标准的制定方认为RuBee网络填补了没有联网、不可编程的RFID标签与采用本地网(802.11)和个人网(802.15)的高带宽的辐射系统之间的空白。这种可搜索标签的实时协议使用IPv4地址，使用这种协议的产品有望在12到18个月内面世。
RuBee的最初支持方包括：大型零售公司，如英国的Tesco集团、德国的Metro连锁店、法国的家乐福和美国的BestBuy；芯片供应商、网络设备厂家和系统开发商，如惠普、IBM、索尼、松下、摩托罗拉和NCR。
1902.1标准将根据现有的RuBee协议，在物理层和数据连路层工作，支持不同制造商推出的标签、芯片、网络路由器和其他设备之间的互操作。
RuBee网络已经在商业应用中使用，包括：医院和手术室中的高价值医疗设备的智能货架；用于库存跟踪的智能商店和仓库货架以及用于牲畜、麋鹿和其他进口动物的农用网络。
Ref: EDN China
http://article.ednchina.com/Communinet/20070208094914.htm
Sunday, February 04, 2007
启用新的项目管理网站和系统
经过一个多星期的内部测试和使用,决定放弃原先的GForge平台,谢谢OSDN提供的服务, 凭心而论,GForge还是一套相当不错的平台,可以提供我想要得很多工具,特别是项目管理
切换到googlecode是因为看中了Google, 且它的SVN服务更稳定, 而Wiki服务也免除了我发布和修改文档的不便(不过相比较专业Wiki而言还是差不少). 而googlepages也能提供一个方便的网站. 只能说google确实强. 目前source code已经发布在googlecode中,请在Project Hosting中查找OpenWSN项目
美中不足的是googlecode在项目管理方面没有GForge那么强,对大项目多人管理还是存在严重不足.
http://openwsn.googlepages.com
OpenWSN root site. Provide links to other resources.
http://code.google.com/p/openwsn/
OpenWSN on Google Code
you can download source code from his site.
切换到googlecode是因为看中了Google, 且它的SVN服务更稳定, 而Wiki服务也免除了我发布和修改文档的不便(不过相比较专业Wiki而言还是差不少). 而googlepages也能提供一个方便的网站. 只能说google确实强. 目前source code已经发布在googlecode中,请在Project Hosting中查找OpenWSN项目
美中不足的是googlecode在项目管理方面没有GForge那么强,对大项目多人管理还是存在严重不足.
http://openwsn.googlepages.com
OpenWSN root site. Provide links to other resources.
http://code.google.com/p/openwsn/
OpenWSN on Google Code
you can download source code from his site.