I plan to finish my Ph.D. study at the end of this year (2009), so I decide to pause the updating of this blog.

On the one hand, I am required to publish 1~2 more papers on relevant issues presented in my thesis proposal. Due to some reason, our lab has abandoned the research on WSN. Besides, I may be required to do some coding work for some disgusting projects, which make things worse.

On the other hand, I need to prepare for the upcoming job hunting. Due to the economical crisis, it is hard to find a job now. However, I must try my best.

I need time to do the above things, and have little time to write blogs now. Whether to continue the blogging depends on what I will do after the graduation.

My CV is at http://sites.google.com/site/fangvv. All job recommendations (researcher/teacher/postdoc in industry/academia) are welcomed!

See you!

For more, click this link

1. NS2 UAN Simulator

2. Aqua-Sim

3. Underwater Channel/PHY/MAC for NS-MIRACLE && NS2

注: 工业界和学术界各玩各的...乱ing...总的来看,是好事.

http://edageek.com/2009/01/19/cymbet-enerchip-msp430/

As wireless network systems designers look to alternative energy sources, Texas Instruments Incorporated (TI) (NYSE: TXN) announced a solar energy harvesting (SEH) development kit that converts ambient light into power for industrial, transportation, agricultural and commercial applications. The credit card-sized eZ430-RF2500-SEH kit combines Cymbet Corporation’s EnerChip[tm] thin-film battery technology with TI’s MSP430 microcontrollers (MCU), CC2500 radio frequency (RF) transceivers and the eZ430-RF2500 development tool. Developers can now build self powered solar-based wireless sensor networks, eliminating system batteries, which cost time and money to periodically replace, especially in remote locations. The $149 eZ430-RF2500-SEH kit is sampling now and is available via the TI e-store or authorized distributors.

In remote or hard-to access environments, wireless sensors are becoming increasingly integrated and miniaturized. Until now, designers typically power wireless devices via storage components such as coin cell or AA batteries. However, these storage technologies do not supply the right mix of charging, storage, discharge and physical size characteristics to provide permanent power for wireless devices. Now, the combination of Cymbet’s EnerChip batteries with TI’s MSP430 MCU and CC2500 RF technology allows energy harvesters to achieve more efficient storage, processing and transmission in both bright and low light environments.

eZ430-RF2500-SEH key features and benefits

• A high efficiency solar panel connected through the EnerChip energy harvesting module delivers enough power to run the wireless application even under low ambient light.
• Based on Cymbet’s EnerChip solid-state lithium thin-film battery technology, which increases conversion efficiencies when storing and starting power in energy harvesting modules.
• Cymbet EnerChips are environmentally friendly, rechargeable and so efficient they can send up to 400 transmissions from a single charge when no ambient light is available.
• TI’s USB-based eZ430-RF2500 tool provides hardware and software to program an MSP430 MCU and low power wireless transceiver on a postage stamp-sized target board.
• MSP430 MCU’s ultra-low power, fast wake-up time and system-on-chip (SoC) peripheral integration saves board space while enabling maintenance-free, self-powered sensors.
• CC2500 RF transceivers operate in the 2.4-GHz range, making them ideally suited for reliable, low-cost digital wireless applications.

Find out more about TI’s eZ430-RF2500-SEH demonstration kit by visiting the links below:

• eZ430-RF2500-SEH: www.ti.com/ez430-RF2500-SEH
• MSP430 tools page: www.ti.com/msp430tools
• eZ430-RF2500 development tool: www.ti.com/ez430
• Tools videos: https://community.ti.com/media/g/microcontrollers/default.aspx
• TI’s microcontrollers: www.ti.com/mcu
• TI’s low power RF: www.ti.com/lprf
• TI energy blog: http://TInergy.ti.com
• TI E2E Community and support: https://community.ti.com/forums/35.aspx

About Texas Instruments
Texas Instruments (NYSE: TXN) helps customers solve problems and develop new electronics that make the world smarter, healthier, safer, greener and more fun. A global semiconductor company, TI innovates through manufacturing, design and sales operations in more than 25 countries.

About Cymbet
Cymbet Corporation—a green technology company—is a leader in thin-film, solid-state storage devices and energy harvesting technology. The company is the first to market a surface mount packaged energy storage solution that designers can use to realize new embedded systems capabilities. Cymbet’s EnerChip[tm] thin-film devices enable innovative energy storage applications for integrated circuits and new products for process control, medical, wireless, sensors, RFID, communications, consumer, portable electronics and energy harvesting.

EnerChip is a trademark of Cymbet Corporation.

http://www.ed-china.com/ARTP_8800030671_400011_500009_TS.HTM

太阳能采集套件实现自供电无线传感器网络
上网时间：2009-02-04
清洁太阳能的利用近几年来一直是市场热点，太阳能手机、太阳能路灯、太阳能公交车、太阳能电动自行车等一直是很多开发人员的目标应用，可是他们一直找不到一个快速的中间件解决方案来帮助他们发挥其创造力。幸运的是，TI今天帮他们解决了这一难题。 德州仪器(TI)最近宣布针对工业、交通、农业以及商业等多领域应用推出一款可将太阳光转换为电源的太阳能采集(SEH)开发套件，从而充分满足了无线网络系统设计人员对可替代能源的需求。尺寸仅为信用卡大小的eZ430-RF2500-SHE套件将Cymbet公司的EnerChip薄膜电池技术与TI MSP430 微处理器 (MCU)、CC2500 射频 (RF) 收发器和 eZ430-RF2500 开发工具完美结合在一起。现在，开发人员可以构建基于太阳能的自供电无线传感器网 络，从而无需采用需要定期花费时间与金钱进行更换的系统电池，这对于偏远地区尤为实用。eZ430-RF2500-SEH 套件现已开始提供样片，目前可通过TI电子商城或授权分销商进行订购（更多详情，敬请访问：www.ti.com/ez430-RF2500- SEHpr）。 Cymbet 公司是一家绿色科技公司，同时也是固态薄膜存储设备与能量采集技术的领先者。该公司率先推出了使设计人员能够实现新的嵌入式系统功能的表面贴装能量存储解 决方案。Cymbet的 EnerChip薄膜设备为工艺控制、医疗、无线、传感器、RFID、通信、消费类电子、便携电子与能量采集等领域的集成电路与新产品开启了全新的能量存 储应用。如欲了解有关Cymbet的详情，敬请访问：www.cymbet.com。 在 偏远或交通不便的地区，无线传感器的集成度正日益提高，体积也日趋小型化。到目前为止，设计人员通常还是采用纽扣电池或五号电池等存储组件为无线设备提供 核心电力。但是，该类型存储技术无法实现充电、存储、放电以及小尺寸特性等的最佳组合，因而难以满足无线设备对永续供电的需求。现在，通过将 Cymbet 的 EnerChip 技术与 TI 的 MSP430 微处理器和 CC2500 RF 技术完美集成在一起，能量采集器无论在强光还是弱光环境中都能实现更高效的存储、处理及传输。 eZ430-RF2500-SEH 的主要特性与优势包括：1）由 EnerChip 能量采集模块连接的高效太阳能电池板即便在较弱的环境光照条件下也能提供足够的电力以驱动无线应用；2）采用 Cymbet 的 EnerChip 固态薄膜锂电池技术，在使用能量采集模块存储并供电时提高能量转换效率；3）Cymbet EnerChips 是可重复充电的高效环境友好型电池。单次充电后可在无环境光照条件下支持多达 400 次的信号传输；4）TI 基于 USB 的 eZ430-RF2500 开发工具可为邮票大小的目标板上的 MSP430 微处理器与低功耗无线收发器提供编程所需的软硬件；5）MSP430 微处理器具有超低功耗、快速唤醒以及片上系统 (SoC) 外设集成等优异特性，可在缩减板级空间的同时支持免维护、自供电的传感器。6）CC2500 RF 收发器可运行于 2.4GHz 频段上，非常适用于低成本的高可靠性数字无线应用。 编辑：Jake Chen 《电子系统设计》

注: 对研究中国特色国情下,技术的运营和发展具有很好的借鉴意义.

来源: http://labs.chinamobile.com/community/my_blog/660/12003

媒体发布了消息，小灵通要在3年之内让出可能对TD有干扰的20M频率。且不说这20M是当年预留给3G，而非新浪所说留给小灵通的，就小灵通的发 展历程和轨迹，我真希望大家能凑一凑，知情的提供一些材料和信息，让我们共同将小灵通这十多年走完的从生到死的轨迹画出来，至少能为未来提供良好的案例 吧。

　　1998年，“小灵通之父”徐福新在浙江余杭电信局首先推出无线市话业务。2000年6月，信产部下文确认小灵通的身份是“市话的延伸和补充”，暂时允许其使用预留3G频段的20M作为无线频率。后来，又陆续出台一些政策，将小灵通纳入电信管理的范围内，算是认可了小灵通的存在。

　　熟悉那段历史的人应该记得，从98年开始，对小灵通的讨论就一直进行着，其中的焦点有很多，突出的是以下几点：

　　合理性：正方认为，存在即合理；反方认为，小灵通的建设属于先斩后奏，不符合常规流程，不应予以认可。

　　技术先进性：正方（以UT为首）认为，小灵通可以满足基本通信要求，并且可以平滑升级，与其他国际标准在更高阶段实现融合；反方认为，小灵通属于过时产品，现在最多就是过渡，将来会被淘汰。

　　存在价值：正反认为，小灵通将平滑演进到3G，用户也可伴随系统升级；反方认为，PHS难以演进到未来，只能是阶段性产物，投资难以得到保护，用户的利益将来也会受损。

　　也许还有其他的争论，期待大家补充。正因为众说纷纭，所以当年信产部对小灵通的态度应该是“不鼓励不干涉”，而是否上小灵通的决定权在于当年的固网运营商，而非政府。

　　经历过移动公司成立之初的人应该还记得，最早政府对资费的管制是非常严格的，移动和联通不能轻易降价，资费要信产部批准，甚至信产部和电管局还 要组织检查组巡视调查运营商有无“违规降价”的行为，而这时对小灵通的管理却是网开一面的，原因很简单——小灵通不属于信产部批准的项目，因此不纳入管理 对象。在这种现在看来奇怪，当时却很正常的管制情况下，小灵通的“资费优势”当然很突出了，由于缺乏漫游等功能，因此即使是2000年信产部开始对小灵通 的资费进行管理时，批准的资费是每分钟0.20元，不得低于0.10元。这与移动电话每分钟0.40元的资费标准相比，自然差了一大截。所以说，小灵通能 发展起来，在很大程度上缘自当年政府对移动通信资费的管制政策。

　　再看固网运营商，听话的不上小灵通的，和其他地方相比，业务发展情况和业绩自然差了一大截；政府的态度又是“不干涉”，于是各地纷纷建设小灵 通，顺便火了UT。这个时候，小灵通的负面声音渐渐弱了，挺小灵通的人胸脯挺得老高，固网运营商依靠小灵通的发展给业绩增添了亮丽。但仍有人认为，小灵通 的辉煌并不能掩盖问题，小灵通未来的路并不好走，固网运营商在获得收益的同时，也为自己未来埋下了隐患。尽管这些观点扔出来就会遭到一大堆板砖的回应，但 是还有如阚凯力等还在直白、执着地坚持自己的观点。

　　后来的发展大家就很熟悉了，政府对资费的干预越来越少，移动电话开始降价，小灵通价格方面的优势越来越弱，虽然与小灵通有关的技术研发还在不断 演进，虽然在竞争策略上还有新的卖点，但不可否认的是，在移动用户总数快速攀升的时代，小灵通用户却在06年到达最高点之后呈现下滑的趋势。这个时候的运 营商心里都明白这个网络的结局。

　　小灵通从98年开始，根据政府规定要走到2011年；相比较而言，当年的模拟移动电话从87年开通，到2001年退网，也是十几年。记得当年模 拟退网，我们希望政府下文分担企业压力，但是未果。而今，退网本来是给小灵通的建设单位出的难题，但却有了充分的理由——政府要运营商退频率，而频率是让 给TD的，中国移动是获益者。轻轻松松，退网的责任和祸首自觉不自觉地转嫁给了政府甚至毫不相干的移动，我不得不佩服记者们手中的笔。移动财大气粗，被冤 枉惯了，再背上个黑锅和包袱也不算啥，对移动的敌视心态如此之大，把矛头指向他是最没有风险的作法。作为移动的员工，我不能再说啥，只是希望大家思考以下 这些问题：

　　回顾整个生命周期之后，我们来看，小灵通到底是不是正确的选择？

　　是谁决策了建设小灵通，政府还是运营商？决策的理由是什么？

　　小灵通是合理合法的网络么？

　　政府对小灵通的态度是一如既往，还是被逼无奈，还是朝令夕改？

　　小灵通使用的20M频段早就明确是3G频段，现在退出是否合理合法？

　　小灵通政策上打擦边球，频率临时占用频段，未来存在风险，这些情况运营商是否在用户入网前，如实告诉了用户？这里面是否存在欺诈？

　　是谁应该为小灵通用户的退网负责，是政府还是小灵通的运营商？

　　前事不忘后事之师，我不在固网运营商，无法了解小灵通的投资是否已经收回，这笔买卖到底是亏是赚。我觉得，如果是亏，就要总结经验教训，避免今 后犯类似的错误。如果是赚，那么就不要站着说话不腰疼，白天外面哭穷，晚上回家数钱。最后说一句，政府部门大可以挥着大棒，在法律许可范围之内，根据管理 办法，强令要求运营商年底前让出非法占用的频率资源；政府不这么做，正是对用户负责，给电信和联通空间的表现。

A presentation from Phillip Gibbons on SenSys 2008.

The pdf file is here.

从工业界的角度在审视现在的WSN研究,非常好.其中9~10页的看法竟然和我原来的看法不谋而合,哈哈.

http://sites.google.com/site/ettx2009/


The TinyOS Technology Exchange (TTX) is a yearly venue where developers, users, and companies involved in low-power wireless sensing get together to talk about recent developments and future directions of the TinyOS platform and the related technologies.

The TTX has been traditionally held in the USA. To foster a broader European TinyOS community, we are launching a companion event In Europe with the same format.

The First European TinyOS Technology Exchange (ETTX 2009) will take place in Cork, Ireland, on February 10, 2009, collocated with EWSN 2009, the largest sensor networks conference in Europe.

The TinyOS Alliance Steering Committee encourages anyone who is interested in, using, exploring or advancing TinyOS-based technologies to attend.

Program Highlights

• TinyOS 2.x overview and tutorial by Phil Levis (Stanford)
• Reports from the TinyOS Working Groups
• Community Contributions Session
• Keynote talk by David Culler (UCB/Arch Rock)
• Open Floor Discussion on the future of TinyOS
• Poster and Demo Session

More details on the Program page...

http://mygogou.com/mm-652/

凯特·格林尼”无线传输媲美光纤速度“, 人们总是需求更快捷的无线传输技术，但目前传输速度最快的几种技术手段，如Wi-Fi（注2）、3G无线网络（注3），甚至即将出现的 WiMax（注4），其最大传输能力也不过每秒数十兆或数百兆比特。迄今为止，还没有一种商用无线传输系统的原始速度比光纤快，光纤每秒可传数十千兆比特 数据。

提高无线传输速度的一个方法是提高频谱中毫米波段的利用率，但产生这样的极高频信号，通常需要昂贵而复杂的设备。现在，美国俄亥俄州哥伦布市的一 家技术研发公司Battelle，发现了一个更简易的毫米波无线传输技术。今年初，Battelle公司的研发组对一个点对点毫米波无线传输系统原型进行 了现场实验，该系统可以通过相隔800米的天线每秒传输10.6千兆比特的数据。最近，Battelle研发组又在实验室示范了每秒传输20千兆比特数 据。

Battelle公司的高级研究员理查德·里奇韦（Richard Ridgway）说，这种技术能应用在校园内传输超大文件、灾后迅速建立紧急应变网络等方面，甚至可实现用一台计算机或机顶盒无线广播不经压缩的高清视频。

鉴于Wi-Fi和无线蜂窝网(即无线广播网络)的工作频率是2.4到5.0千兆赫，毫米波技术利用的频段位于60 到100千兆赫之间，这种电磁波振荡得更快，故而能传送更多数据。大部分毫米波的频段是不受管制的，可任意使用，只是因为生成毫米波信号，把信息调制其上 再在接受端进行解码，整个过程既困难又昂贵，毫米波技术才一直不受重视。产生毫米波信号的常用方法是，先生成10千兆赫左右的低频微波（厘米波），对信息 数据进行编码，再转换成频率较高的信号。这么做的缺点是，在10千兆赫左右电波上每秒只能携带大约1千兆比特的数据。

Battelle公司的研发人员用现有的光通信组件把毫米波传输能力提高了十倍。他们在两条低频激光束上调制数据，再加以合成，就形成一个干涉图样，相当于100千兆的信号。里奇韦说：“这好比我们有了一条频率达100千兆赫的激光束。”

前几年，美国乔治亚理工学院、麻省理工学院、英特尔公司等的研究人员在研发毫米波设备上已取得了很大进展。像英特尔这样的公司，甚至开始推行相关 标准，促进开发在60千兆赫频段可兼容的技术。Gigabeam公司（一家专门从事毫米波无线通讯的公司，成立于2004年，位于美国北卡罗来纳州达拉谟 市）推出的产品，在几百米间通过点对点连接，每秒能传输1千兆比特左右的数据。

里奇韦解释，利用激光通讯有两大优点。第一，激光功率大，产生的毫米波功率也较大；第二，现在的激光技术在工业应用中已很稳定可靠，与标准毫米波信号源相比，激光信号不会大幅振荡，因而抗干扰能力更强。

英特尔通讯技术实验室（the Communications Technology Lab at Intel）的主管艾伦·克劳奇（Alan Crouch）说，Battelle公司的成果进一步证明毫米波技术会日益重要。“无线快捷传输大量数据，这方面需要越来越多的解决方案，有广泛的行业应 用前景。”

不过，要把Battelle公司的研究成果应用到产品上也许仍需数年。里奇韦解释道，用毫米波传输数据首先需要精细的设备，但一般的无线传输系统 是由现有的组件装配而成的，体积过大。另外，毫米波数据传输数字信号利用到电磁波的偏振现象，即在波传播方向的垂直面产生的振动现象，比如，立体电影的原 理就是光的偏振现象。这种偏振波在长距离传输过程中容易发生相位漂移，也就是产生“噪音”。不过里奇韦希望，通过技术方面的改进能解决这些问题。他说：“ 我们想做到让这项技术付诸实用。”

注1：毫米波，millimeter-wave，波长从10毫米至1毫米、频率从30至300GHz的电磁波称为毫米波，是微波的一种，称为极高 频。利用 毫米波进行通信的方法叫毫米波通信。毫米波通信分毫米波波导通信和毫米波无线电通信两大类。毫米波通信的优点是：1、可用频带极宽。毫米波段频带宽度为 270GHz，为整个短波波段的一万倍；2、方向性强，保密性好；3、干扰很小，几乎不受大气干扰、宇宙干扰和工业干扰的影响，因而通信稳定。

注2：Wi-Fi，即无线保真技术，属于在办公室和家庭中使用的短距离无线技术。

注3：3G是英文3rd Generation的缩写，指第三代移动通信技术，能把无线通信与国际互联网等多媒体通信相结合，可处理图像、音乐、视频等多种形式，提供包括网页浏览、电话会议、电子商务等多种信息服务。

注4：WiMax，全名是“微波存取全球互通”Worldwide Interoperability for Microwave Access，又称为802·16“无线城域网”，是一种为企业和家庭用户提供“最后一英里”的宽带无线连接方案。因在数据通信领域覆盖范围大，达 25～30英里，而且成本较低，将扩大宽带无线应用范围，甚至可能对3G构成的威胁，使WiMAX在最近一段时间备受业界关注。

–

http://sensorbase.org/

Sensor Data — Slog. Share. Use.

http://freaklabs.org/index.php/Articles/Zigbee/IEEE-802.15.4-in-the-Context-of-Zigbee-Part-2-MAC-Layer.html

When the economic news is too unbearably depressing to allow me to even write software, I turn to the few things that I know I can count on: my Groove Salad streaming MP3 radio station (legal, of course), a glass of wine, and the tutorial series on 802.15.4 and Zigbee that I have yet to finish.

When we left off last time, Jan was sleeping with Jim, the transsexual who goes by the name of….wait…no, we left off at the 802.15.4 PHY layer. Well, the PHY layer is pretty straightforward unless you're an RF IC engineer, so now we're going to get into the real meat of things…the MAC layer.

The MAC layer is where all the fun is in terms of a software protocol stack. Actually, the 802.15.4 MAC is fairly complicated and feature-packed, which is why I named this series "802.15.4 in the Context of Zigbee". As the title implies, I'm only going to cover enough of 802.15.4 to understand how it fits into a protocol like Zigbee. Luckily, Zigbee eschewed a good portion of 802.15.4 in the name of simplicity and getting a spec out quick, so you won't need to know a whole bunch about 802.15.4. Unfortunately, this has also become a weakness of Zigbee.

Beacon Modes

One of the most glaring omissions of the Zigbee spec is that it doesn't use the 802.15.4 MAC in beacon mode (except for tree-only routing implementations which are impractical as I'll explain in some later article).

The MAC layer defines two basic modes of operation: beacon mode and non-beacon mode. Beacon mode is timing dependent, where a beacon frame is sent out at some set interval defined by the implementation. The beacon defines the start of a superframe which is basically the interval between the beacons, and is used as a way for the devices on the network to synchronize with each other. The superframe is divided into two parts: the active part where data transfers occur, and the inactive part where the device can go to sleep. For very low power operation, you can define the ratio of the active time to the inactive time to be very low so that the device spends most of its time sleeping.

In non-beacon mode, there is no concept of a superframe and the beacons are only used to discover what networks exist within a channel. In other words, beacons are only used when a device is first turned on and it scans for networks to join. Non-beacon mode is completely asynchronous so the upper layer protocol needs to treat each node as completely independent. This has certain implications, especially to power consumption. One of the biggest complaints about Zigbee is that the routers are not allowed to sleep due to the asynchronous nature of non-beacon mode. Since the routers never know if an end device is sleeping or not, it needs to always be on to receive and buffer frames for its children. The children will poll the router periodically to see if there are any messages buffered for that device. The fact that the routers are always on means that certain types of applications are non-feasible for Zigbee, such as applications where the routers do not have access to a MAINS supply.  

Media Access Control

The main purpose of the MAC layer is to provide access control to the shared channel and reliable data delivery. In layman's terms, that means that it controls the channel so that only one device is transmitting at a time and it also defines the handshaking acknowledgement when a frame is received successfully.

So let's get started with one of the main functions of the MAC. That is to provide access control to the wireless medium. To accomplish this, it uses a simple algorithm called CSMA/CA which stands for Carrier Sense Multiple Access/Collision Avoidance. It sounds complicated, but it's really rather simple:

Think of the street that you live on. When you pull your car out of your driveway in the morning, you need to implement CSMA/CA. As you inch your car out of the driveway, you're constantly checking your right and left rear sides to make sure no cars are coming. That's the carrier sense, where the street is the carrier. The fact that you're checking for a car other than yours coming down the street is the multiple access. You're making sure that no other cars are trying to access the road that you want to get on. If you see another car coming as you're trying to get on the road, you stop, possibly inch your car back up the driveway, and wait some unspecified amount of time for the car to pass. That's called collision avoidance. Yes, that's the genius algorithm that engineers devised for the 802.15.4 media access. It's actually slightly more complicated if you use beacon mode, however since we're only focusing on Zigbee, then we don't need to worry about that.

So now that we have the cheesy analogy out of the way, let's see how it really works. When you want to transmit a frame, the first thing you need to do is a CCA, or clear channel assessment. That means that you instruct the radio to check the receive channel and see if there is any data being transmitted, either to you or some other device on the channel that you're on. If it's clear, then you can transmit the frame. Voila!

If it's not, then you have to go into collision avoidance mode. If the channel is not clear, then you wait for a random amount of time and check the channel again. If it's still not clear, you do the same thing. To avoid ending up in an infinite loop, the implementor sets a maximum amount of CSMA backoffs that can be performed. If that amount is exceeded, then the transmit attempt is failed. This usually means you have a serious problem with the channel that you're on so your software better do something to handle it. This gets into frequency (channel) agility which we can discuss more about in the Zigbee section.

802.15.4 Device Types

There are two devices types defined by the 802.15.4 spec:

• Full Function Device (FFD):
• Full function devices are allowed to start a network and assume the role of coordinator. They are also able to allow other FFDs or reduced function devices (RFDs) to join them. For Zigbee, FFDs are known as Zigbee Routers and are the only devices that can forward frames. They must have sufficient RAM to buffer frames for the devices that are joined to it and hold all the tables including the routing and neighbor tables. These devices usually have large flash memory footprints as well since they handle the bulk of the logic in a Zigbee network.

• Reduced Function Device (RFD):
• These devices are only allowed to join FFDs and cannot have other devices join them. They cannot start a network or become a coordinator and are also not allowed to do any routing. In Zigbee, they are known as Zigbee End Devices (ZEDs). The advantage of a Zigbee End Device is that the code and RAM footprint are much smaller resulting in a lower cost device. They are also allowed to sleep so they can reduce their power consumption and survive for long periods of time on a battery.

802.15.4 MAC Topologies

802.15.4 defines two main topologies: point-to-point and star networks. A point-to-point topology is the simplest and isn't even a network. This is just a serial cable replacement where one device can transmit to another device. It's nothing too fancy so I won't spend too much time on it.

A star network is perhaps the simplest real networking topology supported by 802.15.4. It defines a central coordinator and multiple satellite devices that have joined to the coordinator. Unlike an actual star network where the data needs to pass through the center of the star before going to another satellite, an 802.15.4 star network can send data to any device within listening range. However the topology exists because the coordinator always needs to exist to start the network and the devices need to join the coordinator before they can start transmitting on the network.

The MAC layer also defines the services required for a peer-to-peer network where any device can transmit to any other device on the network. However if the receiving device is outside the listening range of the transmitting device, then the frame needs to be somehow forwarded until it reaches the destination. This forwarding mechanism is where the boundary lies between 802.15.4 and Zigbee, since Zigbee defines the mechanism and rules for forwarding frames across a network.

Incidentally, although Zigbee is touted as supporting a mesh network, the actual Zigbee network topology is called a clustered star network. The reason that it follows this topology is because the Zigbee End Devices (ZEDs) are not allowed to perform any routing. Hence the ZEDs are just satellites to their parents. In this type of topology, only the Zigbee Routers (ZRs) are allowed to route frames to each other. A true mesh network would allow routing from any device to any other device, which implies that all devices need to have routing capabilities.

802.15.4 Frame Formats

An generic 802.15.4 frame consists of the PHY header, MAC header, MAC data payload, and the frame checksum. There are four specific types of frames that are defined by the 802.15.4 specification and the frame type is defined in the Frame Control Field, located in the first two bytes of the MAC header. After the general frame format diagram, I'll cover each individual frame type.

• Beacon:
• The beacon frame is a special frame that is used to transmit network information and also synchronize devices on the network and can only be transmitted by full function devices. In Zigbee, the beacon is used to transmit network information and is only used for network discovery.

• Data:
• The data frame is the basic and most common frame. It's used to transmit data and can be sent as a unicast or broadcast frame. A unicast frame means that it will only go to the device specified in the destination address. A broadcast frame means that it will go out to all devices within listening range on the network.

• Command:
• Command frames are used for network management and control and have a command ID associated with them. The command ID will identify the type of command that is being requested and the command frame recipient will respond accordingly.

• Acknowledge:
• If a frame is received with its ack_request flag set, then that means that the frame requires an ACK to inform the transmitter that it was received properly. The receiver will then transmit an ACK frame which basically consists of the frame's unique identifier (DSN) and a frame ID that identifies it as an ACK.

Addressing

There are two types of addresses in 802.15.4:

• Extended address
• This is an 8-byte address that is used as a universal, unique identifier for the device and will differentiate it from all other devices in the world. It is similar to the MAC address of an Ethernet device. The IEEE 64 bit address is known as the extended unique identifier (EUI) and consists of the 24-bit organizationally unique identifier (OUI) a.k.a. company ID, and a 40-bit unique identifier assigned by the company that owns the OUI. The address range needs to be purchased from the IEEE.

• Short address
• This is a 2-byte address that is unique only on the network that the device has joined to. It is the main addressing method used in a Zigbee network to identify a device and also serves the purpose of determining the position of the device within the Zigbee tree routing hierarchy.

Indirect Data Transfers

Indirect transfers are used to send data to an RFD (Zigbee end device). Since it is not possible for a parent to know when a child RFD is sleeping, it cannot simply send a frame to it at any time. Hence it will buffer all frames destined to the child device. The child device will poll the parent at a set interval determined by the implementation and retrieve any pending frames for it.

In order to poll the parent, the child sends a special frame called the data request command frame to the parent. If the parent has data for the child, the parent will indicate it in the "frame pending" field of the ACK. That will let the child know that it should keep its receiver on for the incoming data frame. Otherwise, if the ACK indicates no frames, the child will turn off its transceiver and go back to sleep.

Network and Energy Scanning

802.15.4 defines a generic scan mechanism that allows the device to perform different types of scans. The ones most often used by Zigbee are the energy scan and the network scan. The network scan is used for Zigbee network discovery and the energy scan is used in conjunction with the network scan for Zigbee network formation.

An energy scan is a relatively simple operation where a device turns on its receiver and samples the energy level for a certain amount of time. The scan is performed on all channels that are allowed to the device, and the results of the energy scan will tell the device how much noise or interference exists on a channel. This will be useful for the device in determining an optimal channel to form a network on.

A network scan consists of a device broadcasting a beacon request command frame. This is a command frame with an ID of "beacon request" and it will be received by all devices on the network. If an FFD receives a beacon request command frame, it must respond with a beacon frame containing information about itself and the network. The scanning device will then collect all the beacons and compile a list of FFDs within listening range as well as the different networks that exist on that channel.

Association

Association is the process of a device joining to a parent node. Association is very dependent on the upper layer for many of the decisions on joining criteria, so in this sense, it's basically a service that is used by the upper layer, Zigbee in this case, to join devices to the network. That being said, let's take a closer look at the association sequence.

The association process occurs after a device finishes its network scan and chooses a suitable parent to join. The choice of a suitable parent is determined by the Zigbee stack. Once a parent is chosen, the device will issue an association request command frame to the potential parent. When the parent receives the request, it will determine if it has the capacity to add another device and is permitting other devices to join it. This is also determined by the Zigbee layer. The potential parent will then issue an association response command frame telling the device whether the join was successful or not. If it was successful, the response frame will also contain the short address that will be used to identify the node on the network. It might be kind of hard to follow so I tried to illustrate the data flow in the following sequence diagram.

You might notice that there's a slight complication where the association response is sent via indirect data transfer. This is because the parent can't send the response directly to the child in the case that the child is asleep so it uses an indirect transfer instead.

Well, I guess that covers the major areas that I wanted to hit for the MAC layer in this part. The next part will get into the data and management services descriptions and some of the minutiae of the MAC layer, and hopefully wrap things up so I can get started on the Zigbee portion.

http://freaklabs.org/index.php/Articles/Zigbee/IEEE-802.15.4-in-the-Context-of-Zigbee-Part-3-MAC-Layer.html

I'm back once again to excite you with the details of the IEEE 802.15.4 spec. Actually, it's not so boring if you know what you're looking for. But if you were like me, wading through the endless SDL diagrams and trying to make sense of the bizarre acronyms, then yeah, it's a real snoozer. This will be the last in the three-part 802.15.4 series and should be quick. It's just going to be a quick summary of the MAC layer service functions defined in the spec. As I mentioned before, this will only explain the service functions as it applies to Zigbee.

In this part, I'm going to be going over the 802.15.4 service interfaces, since the spec can make it rather cryptic; especially if you see something like MCPS-DATA.indication. Instead, I'm going to try and explain what the data and management services are, how they're used, and try my best to avoid the spec formality so that it's easier to get an implementation view of things.

If you look at the MAC layer block diagram in the 802.15.4 spec, you're going to see a lot of weird terms and acronyms. An example would be the entry ports to the layer. These ports are called "MCPS-SAP" and "MLME-SAP" respectively. Ugh. Technically, that stands for the "MAC Common Part Sublayer - Service Access Point" and the "MAC Layer Management Entity - Service Access Point". Unfortunately, I've never seen any use for those ports. When I designed the MAC layer of the FreakZ stack, I found it easier to call the functions directly. In other stacks that I've seen, they either call the functions directly or use function pointers that serve as the API for the layer. Going through a level of abstraction like ports would just add overhead and make a stack bigger.

Before I get too distracted, let me get into the real meat of this post. The MAC layer is actually divided into two functional partitions: Data handling and Device/Network management. The data handling portion can be thought of as the data path and the management portion can be thought of as the control path. The data path is pretty straightforward but should be optimized since it will be accessed the majority of the time. The management (control) path is not accessed very frequently, but can be complex and must be implemented. At least part of it anyways. With no further ado...

MAC Data Service

Data Request	This is for outgoing data frames and can be more appropriately called mac_tx. The Zigbee network layer will call this function once it has decided where a frame needs to go (based on its routing tables, etc). All of the required info will be provided such as the source and destination addresses, PAN ID, and the transmit options so this function basically just needs to format all that data into the relevant MAC header and slap it on to the front of the Zigbee network frame. Once the header is assembled, the final touch will be to add the frame length to the front of the frame (ie: the PHY header). Once the frame is assembled, there are actually two ways to send it. If its going to another router or an end device whose receiver is always on, the frame will be sent directly via the radio. Otherwise, if the destination is a sleepy end device, the frame will need to be sent as an indirect transfer. The frame will go to the indirect queue until the destination device wakes up and polls the parent. Once the poll comes in, the frame will get sent to the destination.
Data Confirm	This is a separate function than the data request and usually runs asynchronously to it. Its purpose is to communicate the status of the transmitted data. If no response was received and the maximum number of transmission retries was exceeded, it will send a failure status. Otherwise, it will send a success status or some other code expressing any issues that occurred during transmission.
Data Indication	This is for incoming data and can be more appropriately called mac_rx. Usually an indicator will be set in the Rx ISR that a frame came in and will trigger the call of this function. The MAC code will then start to process the inbound frame and send it up the stack.
Purge	Not required for Zigbee.

MAC Management Service

Association	The association function is used to join a node to a parent. Before a node is allowed to communicate on the network, it must go through the association process and join a parent that is in the network. Zigbee uses the association service in its NWK_JOIN service.
Disassociation	This would normally be used to remove a node from its parent on the network. However Zigbee doesn't use this service and instead defines its own command frame called NWK_LEAVE which is sent as a data frame.
Beacon Notify	This service is used to inform the Zigbee layer that a beacon has arrived and requires processing. Zigbee uses information in the beacon to communicate router/end device capacity and whether or not they are allowing joining.
MAC PIB Get/Set	I have a hard time seeing how these should exist as services since they basically just manipulate a data structure that holds the MAC settings. In my implementation, I just manipulate the table directly via pointer.
GTS	Used for reserving guaranteed timeslots in beacon mode. Not used by Zigbee.
Orphan Notification	When a device loses its parent, it's considered an orphaned device. There are a couple ways that this can happen, but normally, it occurs through a failure on the parent or if the end device is mobile and it moves out of range. If a device is orphaned, then it will do an orphan scan by broadcasting an "orphan notification" command frame in the hopes of finding its parent. If the parent gets the notification, it will inform the device that it's still there and the orphan can rejoin that parent.
Reset	Resets the MAC layer and sets all values to their defaults in the PIB.
Rx Enable	Not used for Zigbee. Zigbee doesn't specify transceiver control except for routers which must always have their receivers on. End device power handling is dependent on stack architecture and requirements. Transceiver control is also usually implemented at the driver level.
Scan	There are three types of scans that are used in Zigbee: energy scan, network (active) scan, and orphan scan. The energy scan is used during network formation to select a channel with low noise on it. The network scan is used during network formation and network discovery. During network formation, the channel is selected based on the noise level and the amount of other networks on the channel. For network discovery, the scan active scan is used to find other networks to join. The orphan scan, as mentioned above, is used for an orphaned device. It consists of broadcasting an orphan notification frame and waiting to see if the parent responds.
Comm Status Indication	This is mostly used to inform the Zigbee network layer that an event occurred in the indirect transaction queue. Indirect transactions are transactions that are buffered and require the destination device to poll the parent to retrieve the frame. If a buffered frame is sent to its destination successfully, a comm status indication is sent with a success code. Otherwise, if a frame times out and is purged, then a comm status indication is also sent out with the relevant code.
Start	This is used to start the MAC layer and initialize the device. It is also used to change certain settings in the MAC layer such as the superframe configuration. In Zigbee, it's just used to start the device and is normally called after a MAC reset.
Sync	Not used in Zigbee unless on a beacon enabled network.
Sync Loss Indication	Not used in Zigbee unless on a beacon enabled network.
Poll	Used by the Zigbee nwk_sync request to poll the parent for any pending data buffered for the device. Calling the poll function will generate a data_request command frame and set off the indirect transaction sequence.

That should wrap it up for this series on IEEE 802.15.4 in the Context of Zigbee. From here, I'll probably be starting up the next series which is a detailed look at the Zigbee layers and how it's implemented.

http://freaklabs.org/index.php/Articles/Zigbee/IEEE-802.15.4-in-the-Context-of-Zigbee-Part-1-PHY-Layer.html

Introduction

IEEE 802.15.4 is a wireless communications protocol that runs at the seemingly unimpressive maximum speed of 250 kb/sec. That's bits, not bytes. Most people that have heard of wireless communications usually think of IEEE 802.11 or Bluetooth , since those are the most mass-market consumer protocols available. So why in the world would we need another wireless protocol that runs at a turtle's pace?

The reasons behind 802.15.4 lie in its application domain: short range wireless networking. One of the biggest obstacles to using wireless devices is power consumption, since there is usually no power cable available to a mobile wireless device. 802.11 was designed for large data transfers with a tethered device like a wireless router spewing out gobs of RF power. On the receiving end, the laptops with Wi-Fi connections usually have a large (ie: big-ass by consumer mobile standards) battery that can run an 802.11 transceiver for hours at a time.

Bluetooth was also not developed to be a power conserving protocol. The main focus is on multi-media communications and you can see that the largest market for Bluetooth is in those annoying little ear-pieces people wear when they look like they're talking to themselves. There is currently a movement for a modified Bluetooth protocol that is more power-aware and less of a drain on a battery and it will be interesting to see how that progresses.

The reason I mentioned 802.11 and Bluetooth is because it serves as an interesting contrast to 802.15.4. In December of 2000, the IEEE-SA officially sanctioned the creation of a new project to develop a low-rate wireless protocol that eventually became the IEEE 802.15.4 TG. The focus of the protocol was for applications that had relaxed throughput requirements but needed low-power and low-cost.

The low power goal was to achieve at least 2 years of activity per node on a single coin cell. That goal can be reached depending on the duty cycle of the node. The duty cycle is the ratio of time the node is active compared with the time that it is sleeping. So if a node only transmits data once per hour and sleeps the rest of the time, then the duty cycle is very low and it can achieve a long battery life. However it wouldn't be very useful except in data logging applications with slowly changing data (ie: weather).

The cost issue is still being worked out. From my experience, Bluetooth transceivers are still slightly cheaper than the 802.15.4 transceivers due to the large volumes that go into cell phone applications. However now that there is a fairly large uptake of 802.15.4 for a large variety of protocols, it looks like the cost of the transceivers is shrinking.

802.15.4 in the Context of Zigbee

But anyways, you didn't want to hear a bunch of marketing mumbo-jumbo from me, did you? The main purpose of this article is to discuss 802.15.4 in the context of Zigbee. What does this mean, you say? 802.15.4 is a large protocol and is somewhat complex, especially when you start getting into the different beacon modes and synchronization features. However if you're only interested in 802.15.4 from the point of view of Zigbee, then things become much easier. You just need to understand some of the basic PHY aspects and a small subset of the MAC layer.  

Physical Layer

It's probably best to start off with an explanation of the physical (PHY) layer of the 802.15.4 protocol. To understand the PHY, it will probably require some terminology that may be unfamiliar unless you've studied digital communications or your hobby happens to be HAM radio operation.

The 802.15.4 spec defines three frequency ranges that it's allowed to play in:

1. 868 MHz
2. 915 MHz
3. 2400 MHz (2.4 GHz)

Of those frequency ranges, the 2.4 GHz is the most common frequency range because it's a worldwide standard frequency for industrial, scientific, and medical equipment. In other words, it's open and doesn't require a license to use. 868 MHz is an open band in most of the EU and 915 MHz is an open band in North America and some Asian countries. Zigbee is only defined for the 2.4 GHz bands so you technically don't need to understand the 868/915 MHz bands, however radios are starting to come out that address these lower bands. Since there is almost no software change to use these lower bands, and you get added benefits, I though it would be worthwhile to add them into this discussion.

One of the main differences between the 802.15.4-2003 spec and 802.15.4-2006 spec is how the PHYs are defined. In the 2003 spec, the bit-rate was directly tied to the frequency range of the PHY. For 868 MHz, the bitrate was a meager 20 kbps. 915 MHz got you 40 kbps, and 2.4 GHz had the highest bitrate at 250 kbps. That, coupled with the fact that 2.4 GHz is almost a worldwide standard frequency for the free ISM band, is one of the principal reasons why you see that most of the PHYs available now are at 2.4 GHz.

Frequency (MHz)	Modulation	Bit Rate (kbps)
868	BPSK	20
915	BPSK	40
2400	O-QPSK	250

When the 802.15.4-2006 revision came around, one of the main changes they made was to the PHY definitions since there was such a low uptake of radios in the 868 and 915 bands. They modified the PHYs so that it was possible to use the same modulation (O-QPSK) and spread spectrum (DSSS) scheme in all bands. They also modified the bitrates so they were higher in the 868 and 915 bands. If using an O-QPSK DSSS transceiver, you could then get 250 kbps in either the 2.4 GHz or 915 MHz bands and up to 100 kbps in the 868 MHz band.

Frequency (MHz)	Modulation	Bit Rate (kbps)
868	BPSK	20
915	BPSK	40
868	ASK	250
915	ASK	250
868	O-QPSK	100
915	O-QPSK	250
2400	O-QPSK	250

There were also modulation and spread spectrum schemes defined for other PHYs, but it's not likely that they'll catch on. Once a company develops the technology for one PHY (ie: a 2.4 GHz radio using O-QPSK and DSSS ), then supporting the other frequencies that use O-QPSK and DSSS is almost just a matter of changing the center frequency of the radio. Some 868/915 MHz radios are already on the market. According to early tests from the manufacturer, they are getting a significant boost in range at the lower frequencies than at the 2.4 GHz frequency due to the longer wavelengths.

Another reason that the lower bands are interesting is because there is an ongoing debate about using the 2.4 GHz band for wireless sensors due to the issue of coexistence. The 2.4 GHz band is noisy and everyone and their grandma's RF circuits use it for communications. The big monster in this band is 802.11 wireless networks which have a strong radio that can overpower the signals from an 802.15.4 radio.

Along with Wi-Fi, this band is also shared with cordless phones, Bluetooth, proprietary protocols, and microwave ovens. Yep, you heard it. There's a chance you can drop a connection by heating up that day-old coffee. Actually, the research into coexistence finds that the noise from microwave ovens is negligible, but hey, you never know.

Anyways, on the hardware side, the important information to know aside from the band of operation is probably the number of channels and the frequency of operation. Aside from that, the other important parameters that I normally keep track of is the Tx power, Rx sensitivity, and the power consumption of the chip. You can check out my 802.15.4 chip comparison sheet here .


802.15.4 PHY Services

The 802.15.4 spec defines a PHY interface that consists of two types of services: a data service and a management service. In reality, this interface is basically useless to software writers because the PHY interface will be defined by the radio that you are using. Hence it basically just ends up being taken care of by the hardware or in the very low, low, low level driver. In any case, I still think that it might be beneficial to add some verbiage on the basics of the PHY interface. s

The PHY data service consists of :

• Data Request:
• This is usually just a transmit function. Basically, you take the data that you want to transmit and you stuff it into the outgoing FIFO of your radio.

• Data Confirm:
• Most radios will give you some type of status indication after you transmit the data. The status information will tell you if the data was transmitted successfully, if you were jammed due to interference, or if some catastrophic failure occurred that rendered transmission impossible (ie: your transceiver blew up).

• Data Indication:
• This is going to be signaled from your Rx Data ISR. When data arrives into your radio's inbound FIFO, then it will trigger an interrupt. From your ISR, you will normally signal to the MAC layer that data was received and needs processing.

On the PHY management service side, there are just a few services that need to be taken care of:

• Clear Channel Assessment :
• Before sending a frame, the PHY needs to perform a clear channel assessment (CCA). This is part of the collision management protocol (CSMA/CA) and prevents sending a frame while another frame is in the process of being transmitted and thus corrupting it.

• Energy Detection:
• Energy detection (ED) should return the amount of noise detected over the media. It is principally used in the initial network scan if the device is starting its own network. When you do a network scan, you go through two phases of scanning. The first phase is the energy scan where you check the amount of energy on each channel. This is where the ED scan is used. The second phase of the network scan is where you count the number of networks on each channel and will be discussed in the MAC section.

• Set Tx/Rx State:
• This service allows the PHY transceiver to be enabled, disabled, set in Rx mode, or set in Tx mode.

• Get/Set Phy PIB:
• The PHY Pan Information Base (PIB) contains information related to the PHY configuration. Normally most of these will be either constants or the information will be held in the transceiver. I haven't seen too many stacks that actually discretely implement this structure since the information is usually redundant. The types of info that this structure defines are things like:
• Current channel
• Channels supported
• Transmit Power

802.15.4 PHY Frame Format

This is going to be a quick section. The PHY frame format just consists of a synchronization header to mark the start of the frame and a PHY header. The sync header is usually added by the hardware to mark the start of the frame so there's no need to worry about it. The PHY header consists of a single byte which holds the size of the frame. Told you it'd be quick.

Want to sense your social network in real-time? Want to know what your friends are doing right now - sitting, walking, running, dancing? Want to know their social setting or fav hangouts - gym, café, meeting, party?

Ready for the next step in Web presence? CenceMe uses iPhone™ sensors to automatically discern your activity and more, and shares it with your Facebook™ buddies while respecting your privacy needs.

CenceMe - Your Seventh Sense on the iPhone™ and iPod touch now!

Thanks for your interest in CenceMe, your Seventh Sense! CenceMe helps you to remain connected to your Facebook™ friends running CenceMe on their iPhone on the move. Using advanced machine learning techniques, CenceMe software infers human presence information based on iPhone™ sensors, for example, activity, location. Soon, CenceMe will even be able to determine if a person is busy in a conversation, or dancing at a party, and will automatically learn your buddies' favorite hang outs! This presence can be gathered and shared with your social circle via Facebook™ without any extra effort. CenceMe presence can be viewed on the iPhone™ as well. Beyond detection and sharing, CenceMe software also allows you to customize how your presence information is displayed, by allowing you to assign personalized presenceIcons and text to your presence. (Hey MySpace™ users, we have not forgotten about you - we are currently working on making it possible to share CenceMe presence on MySpace™ profiles too.)

CenceMe is easy to install and fun to play with. Give it a try today!

CenceMe website

注:制作山寨节点的必备材料:-)

from:freaklabs.org

Zigbee/802.15.4 Chip Comparison Guide

Written by Akiba

Tuesday, 18 March 2008

I put together a Zigbee/802.15.4 chip comparison guide. There is another one up on the web , but it hasn't been updated since 2004. I thought I would put together the 2008 version since a lot of the info on the 2004 chart is a bit obsolete. Such as: The AT86RF210 is EOL'd CompXS was purchased by Integrated Ember's EM2420 was a re-marked CC2420 which disappeared after TI purchased Chipcon ZMD no longer makes their Zigbee chip. I think they cut some deal with Renesas which gave them the IP So I figured it was time for an update. I don't guarantee the accuracy of the tables, although I took all of the information from the datasheets on the vendors' websites. Also, I initially tried to do it in HTML tables, but HTML tables suck. So I put the tables together in an external program and then exported it as a JPG. Hopefully, you can read it. The first table is a comparison guide for transceivers only. You can click on it to get the full JPG. All values are "typical" unless stated otherwise. The font is a bit small due to the size of the table so I've included a PDF document at the end of the post in case it's difficult to read. The second comparison table is for integrated MCUs + Transceivers. The integrated category is quite complex and I might expand this one later. Integrating an MCU and a radio is difficult because many features come into play: ADC, ADC Resolution, number of timers, types of timers, GPIO, development tools, architecture, etc... I might need to make a more comprehensive list, but here is the first stab at it. Regarding the power consumption values, in cases where a multi-chip module are used (they just stuck an MCU and a radio die on the same substrate), the power values are given as separate MCU and RF numbers since I couldn't get the actual total consumption value. If anyone can correct me on these, please let me know... In case these images are too small, I've made the PDF available here as well as an easy pdf download link at the bottom of this page. If you find any mistakes or if I left out anything significant, please feel free to drop me an email or leave a comment or send me a private message (see, there is some benefit to being registered) or post on the discussion forum or instant message me. Just kidding. I don't like instant messaging much. Click Here to download the PDF

Updated 2008-12-05: Added AT86RF231 and MC13224 chips to the chip comparison guide.
Updated 2008-12-12: Fixed to include the Microchip MRF24J40 and the Radiopulse MG2400. These were cut off by the margins on the PDF utility.

虽然感觉有些不妥,但还是想推荐一下这个视频,因为很符合自己最近的心境.

2009年到了,祝福来到这个博客的所有朋友新年快乐:-)

根据CodeProject上某篇文章代码修改而成,启动后进入系统托盘.

使用:

Alt键 + 鼠标滚轮 --> 滚轮滚动调节系统音量大小
Alt键 + 鼠标左键 --> 当前音量和最小音量间切换

鼠标左右键点击托盘图标显示菜单项:退出(Exit),关于(About).

Windows XP Pro & Visual C++ 6.0下编译链接通过.

下载

CodeProject基本源代码