无线充电技术渐近商用，900MHz频段承担传输重任
在消费电子展(CES)上，Powercast LLC公司所设计的针对消费电子设备的无线电池技术有望今年由Philips Electronics N.V.公司发布。
Philips公司“将是我们在2007年实现批量交货的第一客户，”Powercast公司(Ligonier, Pa.)的副总裁Keith Kressin表示。该公司宣称，其Powercaster和Powerharvester模块可以利用RF广播在最多几米之外对小于蜂窝电话的消费电子设备的电池进行充电。
利用900MHz频段，Powercast把RF能量发送到一个外形大约为AAA电池一半的接收机上。在对美国匹兹堡动物园对无线传感器网络进行BETA测试的过程中，Powerharvester接收机模块被翻新到由Intellisensor公司制造的无线传感器的电池盒中，从而把电池使用时间从120天扩展到几年。这些模块“一直通过无线方式保持对动物园的温度和湿度传感器进行100%的充电，尽管与无线传感器相距30英尺的能量束时常中断，”Kressin表示。
利用该模块的神秘的Philips消费电子设备包含一个全向能量信标，通过它可以在大约1米的范围内对设备进行充电。在BETA测试中，要采用方向性天线，以便能量束能够被定位于30英尺之外的某一点。
Kressin表示，Powercast的技术不依赖于任何特殊的射频技术，可以采用几乎任何900MHz发射机或接收机。
RF能量传输通常用最大4V的电压就可以把几个毫瓦的功率传输给设备，使之成为对遥控和诸如iPod之类的小电池进行充电的理想方案。Powercast公司表示，今年医疗植入也将开始采用这种无线能量传输技术。蜂窝电话也是潜在的应用对象，但是，目前Powerharvester仅仅能够把常见蜂窝电话的电池电量充电到一半左右。
Powercaster公司表示，该技术已经获得了FCC的批准，其中，包括一系列能量信标发射机和接收机。开发工作早在2003年就开始了。Powercaster公司的技术不同于马萨诸塞州科技学院所开发的能量信标，后者采用了专用的信标和谐振天线方案。
Ref: 电子工程专辑 2007
http://www.eetchina.com/ART_8800451000_628868_NT_be319147.HTM
Showing posts with label 介绍. Show all posts
Showing posts with label 介绍. Show all posts
Wednesday, December 12, 2007
Thursday, September 06, 2007
Tuesday, August 28, 2007
New wiki system start
tedious with the googlecode wiki, i find this one more professional. and the community wiki will move to wetpaint soon. welcome to join it.
http://openwsn.wetpaint.com/
.
http://openwsn.wetpaint.com/
.
Thursday, July 12, 2007
Tuesday, June 05, 2007
美国打造全球首个全城无线传感网 4年后面世
评注：是个点子,但其用途依然不明确
美国打造全球首个全城无线传感网 4年后面世
作者：陈欢欢 来源：科学时报 发布时间：2007-4-12 0:9:6 小号字 中号字 大号字
在美国马萨诸塞州剑桥城，研究人员计划2011年以前在路灯上装置100个无线传感器。每个节点都将含有一个内置PC机、一个无限局域网界面和各种用于监测气候状况和空气污染物的传感器。4月5日，据哈佛大学工程与应用科学学院新闻网报道，哈佛大学、BBN公司和剑桥城将会联手进行一项为期4年的项目——CitySense，打造世界上第一个全城无线传感器网络。该项目由美国国家自然科学基金会（NSF）资助。
据悉，CitySense可以报告整个城市的实时监测数据，并且其收集数据的规模之大是前所未有的。哈佛大学工程与应用科学学院计算机科学系副教授Matt Welsh说：“无线传感网络有潜力对环境、道路，甚至动物栖息地的实时监测进行革命性的改革。”CitySense的第一项任务是为哈佛公共健康学院副教授Majid Ezzati监测城市中的环境污染。就目前而言，数据只能从当地的一个监测中心获得，而CitySense可以从城市的多个地点收集数据，因此可以更全面地了解城市环境的污染情况。不过，这只是第一步，Welsh表示：“我们相信这个网络可以为其他想安装全球无线网络的城市提供一个基础。”
目前，Welsh研究小组的这个项目还处在原型试验阶段，但他们希望可以在两年内安置 20个传感器，到第三年达到50个，最后一年完成剩下的部分。小组采用一个聪明的方法解决了过去电池寿命对无线网络的限制——他们把节点装在市政街灯上，因此可以利用城市电力系统提供电能。该方法使得传感器的使用增加了很多新的途径，如进行实时环境监测这样的长期实验、研究小气候和人口健康之间的关系、跟踪生化制剂的扩散等。
Welsh已经在自己的实验室装备了大约190个单元，同时在厄瓜多尔的活火山上装置了无线传感器。在不受控的室外环境中进行实验，可以帮助研究人员了解实验室模拟环境中运作的传感器网络是否具有代表性。
一个更大的挑战是如何让分散在城市各处的远程节点和位于哈佛大学的中心服务器连接。 Josh Bers是Welsh在BBN公司的合作者，他设计了一个多反射的无线网络软件，可以让每个节点同相邻的节点相连，形成网络。使用一个1英里射程的小无线电装置，任何一个节点就可以从远程服务器中心下载软件或上传传感器数据。Welsh已经在实验室里用一个网络模型运行5个节点。Welsh说：“它就像一个会传染所有节点的‘病毒’。每个节点都可以和相邻的节点‘对话’，传递数据，最终可以使用所有节点运行程序。”
此前，也有人尝试建立一个小规模的类似网络，但其目的是为私人服务，或者为美国威斯康星州麦迪逊、伊利诺伊州香槟市这样的城镇提供无线网络连接。而据CitySense网站报道，CitySense是一个开放的、资源公开的测试平台。从收集气候数据、监测交通状况到噪音污染，全世界的研究人员都可以使用CitySense。Welsh表示：“CitySense将是这类项目中最大的一个，由 100个传感器组成的系统将最终向所有网民开放。这意味着，美国塔尔萨市的大气科学研究人员或者旧金山的高中老师只要预定一个时间，就可以在 CitySense上运行自己设计的实验。”
据《华盛顿邮报》网站4月8日报道，作为交换，服务器把数据库的信息张贴在网络上。在4 月5日的一份声明中，微软公司表示可以使用Virtual Earth和SensorMap技术将数据覆盖到地图上。这样的话，科学家足不出户就可以追踪污染物扩散情况，获得更好的解决方案和更长的监测时间。而现在，研究人员获得这些数据的惟一办法就是背着装满传感器、电池和GPS追踪器的背包满城跑。
据悉， CitySense网络最初将用于监测环境变量，如温度、风速、降雨量、大气压和空气质量等，但未来传感器的用途将会呈现多种可能性，从计算大气污染物的传感器到用于测量噪音污染的麦克风，甚至可以通过轿车和公交车上的移动传感器收集信息。
相关链接：传感器网络
传感器网络是由一组传感器构成的有线或无线网络，其目的是协作的感知、采集和处理网络覆盖区域中感知对象的信息，并发布给观察者。它综合了传感器技术、嵌入式计算技术、分布式信息处理技术和无线通讯技术。
美国麻省理工学院主办的《MIT技术评论》杂志将传感器网络总结为改变未来世界的10种新兴技术之一。美国《商业周刊》将传感器网络列为掀起新的产业浪潮的未来四大高新技术之一。
美国打造全球首个全城无线传感网 4年后面世
作者：陈欢欢 来源：科学时报 发布时间：2007-4-12 0:9:6 小号字 中号字 大号字
在美国马萨诸塞州剑桥城，研究人员计划2011年以前在路灯上装置100个无线传感器。每个节点都将含有一个内置PC机、一个无限局域网界面和各种用于监测气候状况和空气污染物的传感器。4月5日，据哈佛大学工程与应用科学学院新闻网报道，哈佛大学、BBN公司和剑桥城将会联手进行一项为期4年的项目——CitySense，打造世界上第一个全城无线传感器网络。该项目由美国国家自然科学基金会（NSF）资助。
据悉，CitySense可以报告整个城市的实时监测数据，并且其收集数据的规模之大是前所未有的。哈佛大学工程与应用科学学院计算机科学系副教授Matt Welsh说：“无线传感网络有潜力对环境、道路，甚至动物栖息地的实时监测进行革命性的改革。”CitySense的第一项任务是为哈佛公共健康学院副教授Majid Ezzati监测城市中的环境污染。就目前而言，数据只能从当地的一个监测中心获得，而CitySense可以从城市的多个地点收集数据，因此可以更全面地了解城市环境的污染情况。不过，这只是第一步，Welsh表示：“我们相信这个网络可以为其他想安装全球无线网络的城市提供一个基础。”
目前，Welsh研究小组的这个项目还处在原型试验阶段，但他们希望可以在两年内安置 20个传感器，到第三年达到50个，最后一年完成剩下的部分。小组采用一个聪明的方法解决了过去电池寿命对无线网络的限制——他们把节点装在市政街灯上，因此可以利用城市电力系统提供电能。该方法使得传感器的使用增加了很多新的途径，如进行实时环境监测这样的长期实验、研究小气候和人口健康之间的关系、跟踪生化制剂的扩散等。
Welsh已经在自己的实验室装备了大约190个单元，同时在厄瓜多尔的活火山上装置了无线传感器。在不受控的室外环境中进行实验，可以帮助研究人员了解实验室模拟环境中运作的传感器网络是否具有代表性。
一个更大的挑战是如何让分散在城市各处的远程节点和位于哈佛大学的中心服务器连接。 Josh Bers是Welsh在BBN公司的合作者，他设计了一个多反射的无线网络软件，可以让每个节点同相邻的节点相连，形成网络。使用一个1英里射程的小无线电装置，任何一个节点就可以从远程服务器中心下载软件或上传传感器数据。Welsh已经在实验室里用一个网络模型运行5个节点。Welsh说：“它就像一个会传染所有节点的‘病毒’。每个节点都可以和相邻的节点‘对话’，传递数据，最终可以使用所有节点运行程序。”
此前，也有人尝试建立一个小规模的类似网络，但其目的是为私人服务，或者为美国威斯康星州麦迪逊、伊利诺伊州香槟市这样的城镇提供无线网络连接。而据CitySense网站报道，CitySense是一个开放的、资源公开的测试平台。从收集气候数据、监测交通状况到噪音污染，全世界的研究人员都可以使用CitySense。Welsh表示：“CitySense将是这类项目中最大的一个，由 100个传感器组成的系统将最终向所有网民开放。这意味着，美国塔尔萨市的大气科学研究人员或者旧金山的高中老师只要预定一个时间，就可以在 CitySense上运行自己设计的实验。”
据《华盛顿邮报》网站4月8日报道，作为交换，服务器把数据库的信息张贴在网络上。在4 月5日的一份声明中，微软公司表示可以使用Virtual Earth和SensorMap技术将数据覆盖到地图上。这样的话，科学家足不出户就可以追踪污染物扩散情况，获得更好的解决方案和更长的监测时间。而现在，研究人员获得这些数据的惟一办法就是背着装满传感器、电池和GPS追踪器的背包满城跑。
据悉， CitySense网络最初将用于监测环境变量，如温度、风速、降雨量、大气压和空气质量等，但未来传感器的用途将会呈现多种可能性，从计算大气污染物的传感器到用于测量噪音污染的麦克风，甚至可以通过轿车和公交车上的移动传感器收集信息。
相关链接：传感器网络
传感器网络是由一组传感器构成的有线或无线网络，其目的是协作的感知、采集和处理网络覆盖区域中感知对象的信息，并发布给观察者。它综合了传感器技术、嵌入式计算技术、分布式信息处理技术和无线通讯技术。
美国麻省理工学院主办的《MIT技术评论》杂志将传感器网络总结为改变未来世界的10种新兴技术之一。美国《商业周刊》将传感器网络列为掀起新的产业浪潮的未来四大高新技术之一。
Friday, June 01, 2007
TinyOS2.0的任务和调度----评述
推荐一篇关于TinyOS 2.0任务和调度方面的文章
TinyOS2.0的任务和调度
http://ailexy.blog.hexun.com/7850138_d.html
顺便推荐一个Blog
http://ailexy.blog.hexun.com/
对TinyOS 2.0调度介绍的比较细致，不过，也许是TEP原文带有了明显的赞成性导向，所以我们看不到对TinyOS 2.0调度设计的负面评价。对其中的一些问题，事实上我们可以进一步思考一下
调度算法和调度器的设计应该说是一个相对比较成熟的问题，在任何一本OS课本中都可以找到有关的介绍，当然如果希望做到real time schedule，还是需要多花一点力气，可能要找几篇文章来看看，现有的很多课本在这点上内容还偏向陈旧。
既然有调度，自然也就引出了调度的对象，按TinyOS 2.0的术语，称之为Task任务，在其它嵌入式OS中，也常常干脆称之为thread。遵循Oram'z Razor原则，我们可以思考一下：如果我们自己设计一个调度机制，而且要求简单到极限，你会怎么做？
作为个人的一个观点，任何一个(函数或组件)，都是一个执行体，都应该可以顺理成章的成为被调度的对象，所以极端情况就是：系统中不必存在显示的Task，因为Task而引入的各种接口显然看上去就有些累赘。
需要思考的第二点是，有了调度器和被调度的任务，那自然就有了在动态执行的任务之间提供数据交换机制的必要，在这点上，传统OS已经有了相当成熟的久经考验的机制，这就是临界区/信号量等，当然也可以包括更高级的队列/邮箱/标志/共享内存等，但我想临界区和信号量应该是必要的。由此体会，TinyOS 2.0借Parameter接口来形式上实现上述通信机制，就显得还不够完备和灵活。
也许我对TinyOS 2.0的理解有错误，但我的确认为，TinyOS 2.0更多的是实验新想法的温床，而不是面向成熟可靠的工业应用而设计。
由此也想到OpenWSN调度器的设计。现在的OpenWSN，不过是一堆可重复利用的组件库，或者你也可以简单的把它看作是个函数库方便应用开发。事实上，我一直希望在其中加入一个调度器，现在可以明确这样说，未来的OpenWSN，将让任何一个普通的C函数，都可以成为调度的对象！我始终相信这样一个原则，Simple means efficient, robust, and elegant!
.
补记：
对一个完整的OS调度而言，还应该深入考虑两个额外的但很重要的问题：
一是多个任务之间的协调；二是多个任务之间的数据交换和传递
TinyOS2.0的任务和调度
http://ailexy.blog.hexun.com/7850138_d.html
顺便推荐一个Blog
http://ailexy.blog.hexun.com/
对TinyOS 2.0调度介绍的比较细致，不过，也许是TEP原文带有了明显的赞成性导向，所以我们看不到对TinyOS 2.0调度设计的负面评价。对其中的一些问题，事实上我们可以进一步思考一下
调度算法和调度器的设计应该说是一个相对比较成熟的问题，在任何一本OS课本中都可以找到有关的介绍，当然如果希望做到real time schedule，还是需要多花一点力气，可能要找几篇文章来看看，现有的很多课本在这点上内容还偏向陈旧。
既然有调度，自然也就引出了调度的对象，按TinyOS 2.0的术语，称之为Task任务，在其它嵌入式OS中，也常常干脆称之为thread。遵循Oram'z Razor原则，我们可以思考一下：如果我们自己设计一个调度机制，而且要求简单到极限，你会怎么做？
作为个人的一个观点，任何一个(函数或组件)，都是一个执行体，都应该可以顺理成章的成为被调度的对象，所以极端情况就是：系统中不必存在显示的Task，因为Task而引入的各种接口显然看上去就有些累赘。
需要思考的第二点是，有了调度器和被调度的任务，那自然就有了在动态执行的任务之间提供数据交换机制的必要，在这点上，传统OS已经有了相当成熟的久经考验的机制，这就是临界区/信号量等，当然也可以包括更高级的队列/邮箱/标志/共享内存等，但我想临界区和信号量应该是必要的。由此体会，TinyOS 2.0借Parameter接口来形式上实现上述通信机制，就显得还不够完备和灵活。
也许我对TinyOS 2.0的理解有错误，但我的确认为，TinyOS 2.0更多的是实验新想法的温床，而不是面向成熟可靠的工业应用而设计。
由此也想到OpenWSN调度器的设计。现在的OpenWSN，不过是一堆可重复利用的组件库，或者你也可以简单的把它看作是个函数库方便应用开发。事实上，我一直希望在其中加入一个调度器，现在可以明确这样说，未来的OpenWSN，将让任何一个普通的C函数，都可以成为调度的对象！我始终相信这样一个原则，Simple means efficient, robust, and elegant!
.
补记：
对一个完整的OS调度而言，还应该深入考虑两个额外的但很重要的问题：
一是多个任务之间的协调；二是多个任务之间的数据交换和传递
Wednesday, February 28, 2007
OpenWSN ----- Beyond ZigBee
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平台资源丰富，可以在一定程度上方便开发。
.
首先，需要明确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平台资源丰富，可以在一定程度上方便开发。
.
Wednesday, January 31, 2007
又一个选择
Contiki：从不起眼的业余爱好者操作系统到博士论题
OSNEWS----还记得Contiki操作系统吗? 几年前它用来在非常古老的家用电脑象Commodore 64 和Apple II上运行网络服务器和网络浏览器。今天Contiki已经长大了，并从业余项目走到了严肃的，用于网络嵌入系统和无线传感器网络研究的嵌入式操作系统。它已经完善了，而且它的创始人Adam Dunkels宣布他的博士论题是Contiki及其组件； Protothread和捆绑有TCP/IP堆栈的 uIP。可能这是不起眼的业余操作系统要走的引人注目的方向，但可能这与它首次发布的时人们所期待的Contiki的方向相去甚远。
Ref
http://osfans-cn.blogspot.com/2007/01/contiki.html
http://www.sics.se/contiki/
http://web4.cs.ucl.ac.uk/staff/E.Rondini/Elisa%20Rondini/Home.html
Pyxos嵌入式控制平台以低成本无线传感器网络为目标应用
原文here
通体上我个人并不看好Pyxos，首先，它缺乏一个容易读且容易记住的好名字，hehe
不过，看看LonWorks/Echelon和ZIgBee两方的争论还是很有意思的，毕竟双方都不无道理
以下内容摘自原文
制造和供应链咨询公司ARC Advisory Group的高级分析师Harry Forbes同意这一点。“我们发现把ZigBee 1.0应用到工厂环境时会出现一些问题，”Forbes说。他最近完成了一份关于ZigBee的报告。
Forbes 在他的报告中写道：“ZigBee最显著的缺点是要为每个ZigBee网络选择单个RF通道，而且限制ZigBee协调器才有通道选择权。工业无线应用倾向于采用这样的无线电技术：即在极其嘈杂且充满变化的多径干扰模式的RF环境中，也能继续工作。出于这个原因，大部分工业无线应用采用跳频扩谱无线电技术。Forbes相信ZigBee联盟将做出某些改变以提高这项性能，但目前它仍是一个大问题。
不过，一些业内人士对Echelon公司借助Pyxos介入无线应用的计划表示了怀疑。
ZigBee联盟尤其提防再出现另一种用于嵌入式控制的专有技术。“ZigBee不同于以前创建的任何控制和传感技术。此前，没有一家开放标准机构（如IEEE）创制出一种简单、极其鲁棒同时又非常低成本的无线数据协议，”飞思卡尔半导体公司的无线技术和战略总监Jon Adams说。飞思卡尔是ZigBee联盟的成员，该联盟开发了利用此无线协议的开放性技术规范。
Jennic是一家基于 IEEE 802.15.4标准的无线微控制器的供应商，其首席执行官Jim Lindop持类似的看法。他表示Pyxos的专有形态以及Echelon公司缺乏开发无线协议的经验会带来一些问题。Lindop特意强调Jennic 公司的技术不涉及较高层协议，既不会同Echelon也不会同ZigBee协议栈有直接的竞争。他敦促Echelon以一种类似ZigBee的方式在 802.15.4标准的上层建立其Pyxos协议。
.
OSNEWS----还记得Contiki操作系统吗? 几年前它用来在非常古老的家用电脑象Commodore 64 和Apple II上运行网络服务器和网络浏览器。今天Contiki已经长大了，并从业余项目走到了严肃的，用于网络嵌入系统和无线传感器网络研究的嵌入式操作系统。它已经完善了，而且它的创始人Adam Dunkels宣布他的博士论题是Contiki及其组件； Protothread和捆绑有TCP/IP堆栈的 uIP。可能这是不起眼的业余操作系统要走的引人注目的方向，但可能这与它首次发布的时人们所期待的Contiki的方向相去甚远。
Ref
http://osfans-cn.blogspot.com/2007/01/contiki.html
http://www.sics.se/contiki/
http://web4.cs.ucl.ac.uk/staff/E.Rondini/Elisa%20Rondini/Home.html
Pyxos嵌入式控制平台以低成本无线传感器网络为目标应用
原文here
通体上我个人并不看好Pyxos，首先，它缺乏一个容易读且容易记住的好名字，hehe
不过，看看LonWorks/Echelon和ZIgBee两方的争论还是很有意思的，毕竟双方都不无道理
以下内容摘自原文
制造和供应链咨询公司ARC Advisory Group的高级分析师Harry Forbes同意这一点。“我们发现把ZigBee 1.0应用到工厂环境时会出现一些问题，”Forbes说。他最近完成了一份关于ZigBee的报告。
Forbes 在他的报告中写道：“ZigBee最显著的缺点是要为每个ZigBee网络选择单个RF通道，而且限制ZigBee协调器才有通道选择权。工业无线应用倾向于采用这样的无线电技术：即在极其嘈杂且充满变化的多径干扰模式的RF环境中，也能继续工作。出于这个原因，大部分工业无线应用采用跳频扩谱无线电技术。Forbes相信ZigBee联盟将做出某些改变以提高这项性能，但目前它仍是一个大问题。
不过，一些业内人士对Echelon公司借助Pyxos介入无线应用的计划表示了怀疑。
ZigBee联盟尤其提防再出现另一种用于嵌入式控制的专有技术。“ZigBee不同于以前创建的任何控制和传感技术。此前，没有一家开放标准机构（如IEEE）创制出一种简单、极其鲁棒同时又非常低成本的无线数据协议，”飞思卡尔半导体公司的无线技术和战略总监Jon Adams说。飞思卡尔是ZigBee联盟的成员，该联盟开发了利用此无线协议的开放性技术规范。
Jennic是一家基于 IEEE 802.15.4标准的无线微控制器的供应商，其首席执行官Jim Lindop持类似的看法。他表示Pyxos的专有形态以及Echelon公司缺乏开发无线协议的经验会带来一些问题。Lindop特意强调Jennic 公司的技术不涉及较高层协议，既不会同Echelon也不会同ZigBee协议栈有直接的竞争。他敦促Echelon以一种类似ZigBee的方式在 802.15.4标准的上层建立其Pyxos协议。
.
2006年度ACM Fellow获奖者列表
click here
attention:
Phillip B Gibbons ( Intel公司 ) won this pride because his work on:
并行计算；数据库；传感器网络
.
attention:
Phillip B Gibbons ( Intel公司 ) won this pride because his work on:
并行计算；数据库；传感器网络
.
Sunday, January 21, 2007
Q:为什么Host上的应用开发优先选择Java?
大家注意到很多子项目的开发都优先推荐Java作为首选语言．这引起了很多年轻朋友们的激烈争辩，熟悉Windows开发的人认为选择C#会好一些，而做嵌入式方面的朋友，又不认可Java在自己这个领域的应用．本文希望能对这个问题作一些回答．
尽管相比于业务而言，语言和工具的选择比较次要，曾有人形象的说：一片树叶到了高手手中，也能成为致命的武器．所以我们不应该过度在意语言的选择．
这种观点有其正确的成分，但是，就一个具体的项目而言，是不能在不同开发环境之间摇摆的．更关键的是，我们当中的大多数人，精力有限，Focus到一种工具或者一种平台上，有助于我们积累经验和交流．
下面是我借鉴google搜索的结果，据说这种做法被某咨询公司用作市场占有率调查，准确度非常高 :)
搜索关键字 数量 搜索关键字 数量
Java语言...... 1,030,000 ...........C#语言 ........ 560,000
Java工具 ..... 2,260,000 ...........C#工具 ..........599,000
Java开发工具 1,030,000 ........C#开发工具.... 759,000
Java应用 ......7,820,000 ...........C#应用 ...........644,000
Java开源 ....1,300,000 .............C#开源 ...........974,000
Java........... 285,000,000 ..............C# ...........70,600,000
结论：C#网络资源大约是Java的 1/4 - 1/10．注意到我为了确认国内的情况，大量用中文搜索词．因为国内号称是Microsoft天下．我希望这个搜索对比能引起程序员朋友们的注意．
我想，这个结果应该能够反映这两种语言在现实世界中的地位．
此外，优选Java作为开发语言还有如下原因：
- Java有强大的开源社区支持，可以提供从操作系统／开发工具直至最终应用全系列的产品．而Windows世界中，开源的精神相对要欠缺很多．
- Java的很多资源可以"Free"获得，而Windows C#等却不可以，例如Java世界中的Eclipse可以做开发环境，非常优秀．这对于降低学术界的工作成本是非常必要的．因此，我们不难发现和理解，国外的大学中开源产品和非windows产品应用极为普遍，我们应该思考为什么．过去，盗版在中国的大学中盛行，而未来，license和费用将成为学术界的一个不得不认真对待的问题．毕竟，作研究的不会有很多钱．在这点上，我们应该学习国外大学．
- 国外学术界有使用Java的传统，网上可以找到大量的学术资源，例如各种算法实现，便于与国外同行作对比．
- Microsoft并不是一家技术上容易合作的公司，但愿我对它的这个评价是错的。
- 嵌入式系统领域Microsoft也不占统治地位，特别是在深度嵌入领域
综上，我希望未来Host上的应用开发能够以Java为主，可以选取Eclipse平台，GUI部分可以用Eclipse提供的SWT和JFace，这样我们可以充分利用国际上已有的资源，并且回避掉许多商业软件的license和费用问题．毕竟，我们不能要求我们的每一个位项目参与者都去买一套商业软件．而在一个公开的项目中采用盗版软件将是非常尴尬的事情．
补记：
参考著名杂志《国际电子工程EETimes》2007.03的一篇文章：
Java在嵌入式系统应用中迎来发展的好时光
说明:虽然现有的worldview客户端程序版本是采用C#开发的,但是我还是非常希望能够看到一个基于Eclipse和Java的新平台出现,这将赋予研究者们更多的资源
.
尽管相比于业务而言，语言和工具的选择比较次要，曾有人形象的说：一片树叶到了高手手中，也能成为致命的武器．所以我们不应该过度在意语言的选择．
这种观点有其正确的成分，但是，就一个具体的项目而言，是不能在不同开发环境之间摇摆的．更关键的是，我们当中的大多数人，精力有限，Focus到一种工具或者一种平台上，有助于我们积累经验和交流．
下面是我借鉴google搜索的结果，据说这种做法被某咨询公司用作市场占有率调查，准确度非常高 :)
搜索关键字 数量 搜索关键字 数量
Java语言...... 1,030,000 ...........C#语言 ........ 560,000
Java工具 ..... 2,260,000 ...........C#工具 ..........599,000
Java开发工具 1,030,000 ........C#开发工具.... 759,000
Java应用 ......7,820,000 ...........C#应用 ...........644,000
Java开源 ....1,300,000 .............C#开源 ...........974,000
Java........... 285,000,000 ..............C# ...........70,600,000
结论：C#网络资源大约是Java的 1/4 - 1/10．注意到我为了确认国内的情况，大量用中文搜索词．因为国内号称是Microsoft天下．我希望这个搜索对比能引起程序员朋友们的注意．
我想，这个结果应该能够反映这两种语言在现实世界中的地位．
此外，优选Java作为开发语言还有如下原因：
- Java有强大的开源社区支持，可以提供从操作系统／开发工具直至最终应用全系列的产品．而Windows世界中，开源的精神相对要欠缺很多．
- Java的很多资源可以"Free"获得，而Windows C#等却不可以，例如Java世界中的Eclipse可以做开发环境，非常优秀．这对于降低学术界的工作成本是非常必要的．因此，我们不难发现和理解，国外的大学中开源产品和非windows产品应用极为普遍，我们应该思考为什么．过去，盗版在中国的大学中盛行，而未来，license和费用将成为学术界的一个不得不认真对待的问题．毕竟，作研究的不会有很多钱．在这点上，我们应该学习国外大学．
- 国外学术界有使用Java的传统，网上可以找到大量的学术资源，例如各种算法实现，便于与国外同行作对比．
- Microsoft并不是一家技术上容易合作的公司，但愿我对它的这个评价是错的。
- 嵌入式系统领域Microsoft也不占统治地位，特别是在深度嵌入领域
综上，我希望未来Host上的应用开发能够以Java为主，可以选取Eclipse平台，GUI部分可以用Eclipse提供的SWT和JFace，这样我们可以充分利用国际上已有的资源，并且回避掉许多商业软件的license和费用问题．毕竟，我们不能要求我们的每一个位项目参与者都去买一套商业软件．而在一个公开的项目中采用盗版软件将是非常尴尬的事情．
补记：
参考著名杂志《国际电子工程EETimes》2007.03的一篇文章：
Java在嵌入式系统应用中迎来发展的好时光
说明:虽然现有的worldview客户端程序版本是采用C#开发的,但是我还是非常希望能够看到一个基于Eclipse和Java的新平台出现,这将赋予研究者们更多的资源
.
我的问题：关于规模 Help
回答了这么多问题
我也有一个问题
目前是否有上千个结点以上应用的真实实验？
或者是哪位朋友曾经做过5000个结点以上的网络仿真？包括ad-hoc领域研究也算上，我希望能取得一些测试数据来验证我对网络的一些想法。
.
我也有一个问题
目前是否有上千个结点以上应用的真实实验？
或者是哪位朋友曾经做过5000个结点以上的网络仿真？包括ad-hoc领域研究也算上，我希望能取得一些测试数据来验证我对网络的一些想法。
.
Q: OpenWSN为什么没有采用标准的802.15.4 MAC和ZigBEE协议？
我想首先纠正一个观点，不存在OpenWSN是否采用某一固定标准的说法。OpenWSN是一个开放的标准体系，它以Library的方式提供给开发人员和研究人员一套可灵活组合并且复用的组件。用802.15.4替换OpenMAC，用ZigBEE替换OpenNET没有任何问题，OpenWSN支持多种选择，而最终选择的自由是用户。OpenWSN不希望强加任何特定的约束给高层用户，它只是希望不同Group/Company的产品能够在底层上互通互换，即使做不到Hardware级别的互通，也可以提供自己特有的Software层次的HAL实现软件上的可移植。
为什么OpenWSN最初没有采用标准的802.15.4和ZigBEE，而是自己提出了一个OpenMAC和OpenNET是源于OpenWSN的定位之一，即它要服务于WSN领域的研究，换言之，MAC/NET本身就是研究的对象，将研究者约束在802.15.4和ZigBEE上显然是不合理的。
此外，实际应用的需求千差万别，802.15.4和ZigBEE并不是万能的。比如说，他们的设计都没有考虑移动mobile node/sink的情形，而我们在做的一个课题就遇到了mobile的问题，这时非得去用802.15.4和ZigBEE显然是没有必要的。而且，构建一套完整的ZigBEE开发环境对用户而言也是一笔不小的支出，至少在我们最初开始进入这个领域时，其价格还停留在十多万的级别。（很多报价很便宜的厂商最后能给802.15.4的代码就不错了，不仅如此，ZigBEE一般都是以二进制方式给出，因此无形中也就限制了使用者选择的硬件平台）因此，我们最初在从事无线Modem开发的基础上，选择了自己做一套。OpenMAC采用类似于802.11的Aloha方式，并没有许多人想象的那么复杂，在低负载时表现应该没有问题，高负载时时延会不确定（仅就目前版本而言）。
可以粗略的给出目前一些方案的定位示意，如下表格不严谨，仅供参考：
...........................|.......固定拓扑网络 .... 可变拓扑网络 ... 高速移动网络
低速率高延迟 ..|...802.15.4和ZigBEE ... OpenMAC ..................?
数据传输
高速率高延迟 ..|...........802.11 ................OpenMAC ..................?
数据传输
高速率低延迟 ..|.............. ?.............................. ?........................... ?
数据传输
标记?的表示目前尚没有好的解决方案。而且，上述解决方案的划分也没有考虑energy问题。如果再考虑energy，就会发现有更多的空白区域是15.4和ZigBEE没有覆盖的。
所以我们可以看出，802.15.4和ZigBEE作为鼓吹的WSN事实标准，也不是万能的，还有很大的研究空间。OpenMAC/NET不过是我们自己针对自己的应用设计的一个简单的MAC/NET协议实现而已。
欢迎其他的Group能够发布你们的MAC/NET研究成果，为OpenWSN提供更多的选择！当然，也非常希望有兴趣的开发人员能够为OpenWSN贡献一套802.15.4 MAC代码，这对高校研究人员构建异构层次网络拓宽研究内容是很有意义的。尽管我们可以拿到针对其他硬件平台的15.4 MAC实现，但是限于版权原因，不能将其加入OpenWSN项目，因此，有兴趣的开发者自己尝试一下还是有意义的。
.
为什么OpenWSN最初没有采用标准的802.15.4和ZigBEE，而是自己提出了一个OpenMAC和OpenNET是源于OpenWSN的定位之一，即它要服务于WSN领域的研究，换言之，MAC/NET本身就是研究的对象，将研究者约束在802.15.4和ZigBEE上显然是不合理的。
此外，实际应用的需求千差万别，802.15.4和ZigBEE并不是万能的。比如说，他们的设计都没有考虑移动mobile node/sink的情形，而我们在做的一个课题就遇到了mobile的问题，这时非得去用802.15.4和ZigBEE显然是没有必要的。而且，构建一套完整的ZigBEE开发环境对用户而言也是一笔不小的支出，至少在我们最初开始进入这个领域时，其价格还停留在十多万的级别。（很多报价很便宜的厂商最后能给802.15.4的代码就不错了，不仅如此，ZigBEE一般都是以二进制方式给出，因此无形中也就限制了使用者选择的硬件平台）因此，我们最初在从事无线Modem开发的基础上，选择了自己做一套。OpenMAC采用类似于802.11的Aloha方式，并没有许多人想象的那么复杂，在低负载时表现应该没有问题，高负载时时延会不确定（仅就目前版本而言）。
可以粗略的给出目前一些方案的定位示意，如下表格不严谨，仅供参考：
...........................|.......固定拓扑网络 .... 可变拓扑网络 ... 高速移动网络
低速率高延迟 ..|...802.15.4和ZigBEE ... OpenMAC ..................?
数据传输
高速率高延迟 ..|...........802.11 ................OpenMAC ..................?
数据传输
高速率低延迟 ..|.............. ?.............................. ?........................... ?
数据传输
标记?的表示目前尚没有好的解决方案。而且，上述解决方案的划分也没有考虑energy问题。如果再考虑energy，就会发现有更多的空白区域是15.4和ZigBEE没有覆盖的。
所以我们可以看出，802.15.4和ZigBEE作为鼓吹的WSN事实标准，也不是万能的，还有很大的研究空间。OpenMAC/NET不过是我们自己针对自己的应用设计的一个简单的MAC/NET协议实现而已。
欢迎其他的Group能够发布你们的MAC/NET研究成果，为OpenWSN提供更多的选择！当然，也非常希望有兴趣的开发人员能够为OpenWSN贡献一套802.15.4 MAC代码，这对高校研究人员构建异构层次网络拓宽研究内容是很有意义的。尽管我们可以拿到针对其他硬件平台的15.4 MAC实现，但是限于版权原因，不能将其加入OpenWSN项目，因此，有兴趣的开发者自己尝试一下还是有意义的。
.
Tuesday, January 16, 2007
再论OpenWSN的定位
作为一个OpenSource项目,也是需要思考自己定位的, 如何才能更好的发展?
我们认为,在WSN领域, 目前正处于研究高潮期已过,但实际应用尚未大规模出现的产业准备阶段, 因此, 在这样一个带有不确定性的领域中, 我们探索性的作一些准备工作是可行的.
在未来, 有着大量的应用, 也将会有大量的解决方案, 形成如图所示的鱼尾形, 这在本质上是由这个领域所决定的, 客户对性能/成本/功能的需求决定了产品和解决方案的多样性. 那么,我们缺少什么呢? OpenWSN认为我们在丰富的应用和多样的硬件解决方案之间缺乏一个统一的中间层次. 而这个中间层的选择将只会有少数几种选择. OpenWSN将在这个层次多做一些工作. 至于TinyOS,我们希望将其作为OpenWSN中一个可选的服务组件,与之共存, 从而带给客户更多的选择.
.
我们认为,在WSN领域, 目前正处于研究高潮期已过,但实际应用尚未大规模出现的产业准备阶段, 因此, 在这样一个带有不确定性的领域中, 我们探索性的作一些准备工作是可行的.
在未来, 有着大量的应用, 也将会有大量的解决方案, 形成如图所示的鱼尾形, 这在本质上是由这个领域所决定的, 客户对性能/成本/功能的需求决定了产品和解决方案的多样性. 那么,我们缺少什么呢? OpenWSN认为我们在丰富的应用和多样的硬件解决方案之间缺乏一个统一的中间层次. 而这个中间层的选择将只会有少数几种选择. OpenWSN将在这个层次多做一些工作. 至于TinyOS,我们希望将其作为OpenWSN中一个可选的服务组件,与之共存, 从而带给客户更多的选择.
.
Subscribe to:
Posts (Atom)