您正在查看 "Wsn Related" 分类下的文章
2009-02-12 09:32
2009-02-06 16:56
注: 工业界和学术界各玩各的...乱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
《电子系统设计》
|
|
2009-01-18 21:45
2009-01-12 20:16
http://sensorbase.org/
Sensor Data — Slog. Share. Use.
Why SensorBase?
SensorBase provides you with a way to publish, share, and manage your sensor data much in the same way that you can publish, share, and manage journal entries in a blog. Also, data from many different sensor networks, with SensorBase, are centralized and no longer in the form of scattered text files.
Slog Sensor Data
Similar to blogs, SensorBase provides an easy way to log sensor data, or rather, slog. We can think of sensor data as anything from numeric values to images, audio, and video. SensorBase allows you to slog these types of data both manually and automatically.
Share Sensor Data
Once data is slogged, you can share your data with collaborators or let all SensorBase users take a look. You can also elect to make your data private.
Use Sensor Data
Of course data isn't much good if you just set it aside to collect dust. SensorBase makes it easy to export data via the user interface or SOAP web services.
|
2009-01-11 15:34
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. |
2009-01-11 15:33
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:
- 868 MHz
- 915 MHz
- 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. |
2009-01-09 17:00
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 |
2009-01-06 18:41
注:制作山寨节点的必备材料:-)
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. |
2008-12-14 22:52
2008-12-12 09:40
Intel Looks To Blanket The World With Self-Powered Sensors
The wireless identification and sensing platform, or WISP, could be used for measuring the environment or inserted into the human body to detect medical problems.
By Antone Gonsalves, InformationWeek
Dec. 5, 2008
URL: http://www.informationweek.com/story/showArticle.jhtml?articleID=212202257
Intel is developing self-powered microchips that could be implanted in the human body, a mobile phone, a building, or anyplace else where people wish to gather information.
Called a "wireless identification and sensing platform," or WISP, the devices were among several technologies described Friday by Intel CTO Justin Rattner during a meeting with reporters in San Francisco. Most of the technologies discussed are under development in Intel labs and are unlikely to reach the marketplace in products for at least three to five years.
All of the inventions were designed to be energy-efficient. The WISP sensors would use Intel technology for drawing power from the environment. "These are install-and-forget kind of systems," Rattner said.
The power would come from wireless transmissions, such as a Wi-Fi hotspot, a cellular tower, or a TV broadcast, making it possible for the sensors to continuously gather information in almost any environment, Rattner said.
In an experiment conducted by Intel in San Francisco, sensors implanted in street sweepers were used to monitor air quality throughout the city.
"We could, in fact, litter the planet with these things," he said. "Rather than depend on satellite information, we could literally get instantaneous, near-global indication of the state of the planet."
Self-powered sensors could one day go into the human body to monitor health-related activity, such as the beat of a heart. If researchers could shrink detectors to the molecular level, they could one day be capable of detecting viruses in the environment to determine the potential health risk.
Within the data center, sensors could be used to map the heat levels of the different systems in order to create a "thermally aware load management" system, Rattner said. Systems that are running hot could have some of their workloads shifted to idle systems, thereby lowering the overall temperature, which would lower the demand on cooling systems.
Along with sensors, Intel labs is experimenting with the use of microchips to gather energy from other sources, such as the sun or the movement of a trackball in a smartphone, to recharge a battery in a mobile device.
"Wouldn't it be nice if you could go almost indefinitely without recharging the battery?" Rattner said.
For Intel, sensor technology "might turn into a business opportunity" in the future, Rattner said. But a lot of the other experimental technology is likely to be licensed for use by other companies and not necessarily end up as separate Intel products.
An example of the latter is work Intel is doing with manufacturers of power supplies for computing systems. Today, most power supplies use multiple voltage regulators to take incoming AC power from an outlet and transform it into DC power at different voltage levels to power multiple components within the system, such as hard disk drives and graphics and sound cards.
The problem with the use of multiple voltage regulators is they aren't very power-efficient. As a result, traditional power supplies are from 55% to 70% efficient, Rattner said. Intel is working on technology that would let a microchip regulate power, which would boost the efficiency to 90%.
Intel is building power management within a microchip, so power levels could be adjusted microsecond by microsecond in following the fluctuations in energy needed to power CPUs or modules within a chipset, Rattner said. Today, power levels have to be kept higher than needed during light workloads to make sure enough energy is available to meet sudden demands for processing power.
Moving power management from software to hardware within a computer would improve energy efficiency during light workloads to 70% from 10% today, Rattner said.
中文版本from: http://www.eetchina.com/ART_8800556238_617687_NT_83cc9e56.HTM#
Intel正着手研发多项 节能技术,可利用免费能源对 手机等装置进行 供电以及为电子装置和数据中心节能。
Intel在上周召开了一次聚焦其“Eco-Technology(环保技术)”研发的会议。该公司CTO Justin Rattner公开了一系列有关节能和发电技术的长期研发计划。
如,Rattner 表示Intel已开发出可以植入人体、手机以及建筑物内部并且自行供电的微芯片。
Rattner还表示,会上所讨论的大多数技术目前正在Intel实验室进行开发,但这些产品要真正商业化,至少还需要三到五年的时间。
在无线识别和传感平台(wireless identification and sensing platform ,Wisp)中,传感器将采用Intel技术从周围环境获取能量。“他们是一类安装后即可忽略(install-and-forget)的系统”。
该技术可以将来自无线传输,如Wi-Fi hotspot,蜂窝基站或TV广播的信号转换为电能,这样传感器几乎在所有环境下都可以持续地收集到信号。
传感器可以无线传送信号,通过在充电前发送大量数据至接收器提供对环境的实时报告。
目前已展开一项实验,将Wisps安装在旧金山的道路清洁车上用于监控制空气污染情况。
据Rattner表示,这项技术对数据中心的管理也有着深远影响。置入数据中心的Wisps可以精确地监控散其散热情况,使管理人员可以调整机器的计算负载以降温,节省了成本。
他表示,自行供电的传感器有朝一日将被置入人体以监控人体的健康情况。若研发人员能够研发出分子般大小的检验器,那么它们将可以用于检测人体内的病毒,检查出潜在的健康隐患。
除了传感器之外,Intel还着手研究通过使用微芯片从其它能量源(如太阳能或智能手机中轨迹球的移动)收集能量,对移动装置中的电池进行充电,这项技术目前正处在验证阶段。
对Intel而言,传感技术存在很大商机。但Intel的很多其它正在验证中的新技术极可能以授权的方式提供给其它公司使用,而非直接由Intel以单一产品的形式推出。
如,Intel 和许多计算系统用电源制造商有合作。Intel目前正着手研发一项技术,该项技术采用IC调节电源,可将效率提高到90%。
本文完~~~~~~~~~简而言之,工业界,终于对实际的供电问题下手了,解决问题,而不是指着问题灌水.挺好的! |
2008-12-08 12:54
Wireless Sensor Network Helps School Cut Its Energy Use
|
The City of London School for Girls is employing wireless sensor nodes to manage temperatures in about 130 zones set up in its building, reducing the tendency to overheat certain rooms.
By Claire Swedberg
Dec. 5, 2008— The City of London School for Girls is heating its facility more efficiently and more comfortably, thanks to a wireless sensor system that allows each room to be controlled independently, in order to maintain the optimum temperature. The system is intended to lessen the school's carbon footprint by reducing the tendency to overheat some rooms, with wireless sensor nodes that were easier and less expensive to install than a traditional wired system.
The system, developed by Control Technologies Ltd. (CTL), was provided by sister company ARO Performance Systems Ltd. Another of CTL's partner companies, Ambient Environment Solutions Ltd., is undertaking installation using Jennic's JenNet system and wireless sensors, based on the IEEE 802.15.4 standard. The school installed the system in one floor over the summer break, and is now deploying the wireless sensors throughout the rest of the five-story building during the December winter break.
|
| Andrew Osborn |
A private day school for girls of all ages, the academic institution is considered one of London's more prestigious schools. It utilizes the city's enterprise-wide TAC Andover Continuum building management system (BMS) to control the temperature in its 120 classrooms and offices. The school has been struggling with inconsistent temperatures, whereby some rooms were overheated and the windows in those rooms were opened to cool them down, leading to energy waste.
Control Technologies Ltd. has been providing the City of London with building management service for its heating, ventilating and air-conditioning (HVAC) systems, both for restoration and maintenance purposes. In this case, faced with the challenges before the School for Girls, CTL found that a Jennic wireless system—which Control Technologies had been testing in other city buildings for the past two years—would be the optimal solution.
The five-story school, constructed with concrete, stone, masonry and a metal grid, did not lend itself to additional wiring, says Andrew Osborn, director of ARO and CTL. Running new wires through the building's walls was simply not feasible, but the school required an upgrade to its HVAC system. "The energy consumption at the school was very high," Osborn says, "and they needed to get that under control without disrupting the fabric of the building, and without disrupting school activities there." That meant there would be no drilling of holes or cable installation.
The school has under-floor heating mats and electric space heaters that warm the building in five heating zones. Until now, none of the heating elements within a specific zone could be controlled individually, leading to very little ability to regulate each classroom's temperature. With the new JenNet system, the school increased the number of individually controllable zones from five to approximately 130, using 160 Jennic wireless sensors.
Each Jennic device contains a 32-bit RFID chip wired to a temperature sensor, and is powered by two AA batteries. At preset intervals, the sensor node awakens, collects temperature data and transmits that information, along with its unique ID number and the condition of its batteries, to the wireless mesh routers at a distance of up to 100 feet, or through three partitions (such as walls). The sensor then goes back to sleep.
Six routers are plugged directly into outlets on each floor and, in turn, transmit signals to a "coordinator" or "gateway node"—one per floor. The sensor nodes and routers transmit their 2.4 GHz signals according to an IEEE 802.15.4 air-interface protocol. Each gateway node is connected to the BMS system on the proprietary RS485 serial field bus, connecting data to the enterprise system via the City's Ethernet wide area network (WAN). In this way, the City of London can monitor HVAC data from the many zones within the school, to see how the heating system is functioning.
Each floor's gateway node is also cabled to the school's power distribution boards, which control the power running the floor heating pads at any specific zone, based on that zone's temperature sensor data. There are six routers installed on each floor, with about 30 in the building altogether.
The greatest obstacle to the mesh system, Osborn says, involves the elevator shafts, which are highly metallic and can obstruct the RF signal. Nodes are installed in such a way, however, as to transmit around those obstacles.
The installation cost was 80 percent less than that of a wired solution, says Tony Lucido, Jennic's VP of marketing, and installation time was 90 percent less. What's more, he adds, "there was no need to redecorate the building after installation of the wireless sensor network."
By the end of December, Osborn predicts the system will be fully installed with 160 nodes. The installation is being conducted outside of school hours, but in the zones where it is already installed, he says, "It is going blindingly well." This, he notes, is not a plug-and-play solution. There has been a lot of pain over several years, he says, experimenting with the technology in several City of London buildings (mainly due to read range issues involving the stone, masonry and concrete of London's larger buildings) and finding the proper frequency that would transmit appropriately in older buildings such as the girls' school.
Now that the preliminary research has been completed, Lucido says, the wireless system is proving to be a simple installation. "This is a very convenient way to retrofit," he states.
from: http://www.rfidjournal.com/article/articleprint/4484/-1/1/ |
2008-12-02 13:47
http://www.unix-center.net/bbs/viewthread.php?tid=7689
Unix-Center.Net的Sun SPOT创意大赛
Unix-Center.Net已经获得5 套Sun SPOT设备,可以无偿借给本站对Sun SPOT技术感兴趣的用户。每套Sun SPOT包括两个有传感器的节点(可以用作远程节点)和一个没有传感器的节点(可以用作主机端数据采集节点)。我们从现在开始向全站用户征集创意,从中评 选出5 个最佳创意,向每个最佳创意提供一套Sun SPOT设备进行程序开发,为期6 个月。如果6 个月以后该创意成功实现,我们将考虑将该Sun SPOT赠送给相关开发人员。
如何参加这项活动?您需要按照如下步骤进行:
1 学习本站学习中心的“无线传感器网络 -- 从理论到实践”,了解无线传感器网络领域的基本概念,以及Sun SPOT的技术优势。
2 想一个具体的应用,如果您有一套Sun SPOT设备,你会用来做什么应用?
3 在本站论坛的“无线传感器网络”版本发表一篇帖子,题目为“项目提案:[项目名称] -- [本人ID]”,包括如下内容:
(1) 项目名称
(2) 项目小组成员
(3) 项目综述:这个项目的目的是什么,打算解决什么问题
(4) 项目设计:简单地陈述该项目的主要部分,每部分的主要功能,技术难点
(5) 项目计划:简单地陈述该项目分几个阶段完成,每个阶段需要多长时间
(6) 其他需要说明的部分
在您的创意中,需要突出为什么您选用Sun SPOT作为关键设备。Sun SPOT的哪些特性使得您决定采用Sun SPOT而不是其他类似的设备。 |
2008-11-27 09:31
http://www.nikkeibp.com.cn/china/news/mobi/pr_sino200811270110.html
【日经BP社报道】
 |
| 图1 富士通无线传感网络节能技术展区 |
 |
| 图2 无线传感网络节能技术展示 |
富士通公司在2008富士通中国论坛上,介绍展出了无线传感网络节能技术中研究成果。无线传感器网络(Wireless Sensor Networks,简称WSN)是集信息感知、采集、处理、传输于一体的综合智能无线信息系统,可用于生态环保、医疗健康、智能交通、仓储物流、智能家居 等诸多领域。无线传感网的节点一般由电池供电,对节点能耗有更加苛刻的要求,通过采用各种节能技术,在满足应用的条件下,最大化网络的生命期是需要优先考 虑的问题。
富士通公司对ECMA368、IEEE 802.15.4、SMAC协议进行了全面评估,比较它们在星型、树型、网格型拓扑结构下,在不同节点数、不同占空比、不同包间隔下的吞吐量、功率、能量 消耗等性能指标。使节能式无线传感器网络由希望变为现实,适用于军事、空间与海洋探索、建筑、工业安全、交通控制、智能家居及农业科学等领域。
富士通无线传感网中节能技术具有两个技术特点:
一是基于时效性约束WSN生命期最大化跨层优化设计。该设计体现为两个优化课题:优化设计每条路径上各个节点的发射功率,使路径上的总体能量 消耗最小化;设计优化的路径分配比例因子,使得整个网络的能量消耗最小化。每个节点按照优化的路径比例分配因子进行数据包传输的路径选择,每条路径上的节 点按照最优的发射功率进行调整,实现网络能量消耗的平衡,达到网络生命期最大化。
二是基于IEEE 802.15.4协议的传感器节点占空比独立自适应调节方法。通过延长传感器节点休眠时间可以最有效的减少节点功率消耗,但是会带来通信时延的增加。通过 采用网络协调器独立地根据从各节点收到的数据帧发送队列信息对各节点占空比和信标间隔进行自适应调节,使得网络的功率消耗和通信时延这对相互矛盾的性能指 标能够在不同的网络负载条件下取得良好的平衡。
富士通基于数据包时效性约束下无线传感网络生命周期最大化的跨层优化设计方法,即在网络的路由更新时间内,节点收集其附近的无线信道环境信 息,并通过无线多跳的形式传送给Sink节点。Sink节点根据路由表在该路径上各跳重传次数之和小于给定重传限制的条件下,使每条路径上传输数据所消耗 的能量最小化。根据能量有效性原则,Sink节点计算每条路经的最佳比例分配因子,即节点对路由表中的路径,按照路径比例分配因子进行数据包传输的路径选 择,平衡网络能量消耗,最大化网络生命周期。(特约记者:贾子昂) |
2008-11-08 10:55
2008-11-02 11:22
新的一轮分钱大战结束了,早先 说过我是打算组织课题组的博硕们努力一下,结果写好了,到了lab这一关就给卡了,说往年申请了那么多,今年支持的力度肯定没有这么大了,要确保主力方向的申请...大半年过去了,结果并不是那样,实际上现在我明白为什么了,因为所谓的课题组已经基本名存实亡了.尽管如此,但至少我还曾经努力过,不后悔啦:-)
列出来的目的是觉得,这些课题至少对我们研究生来说,可以作为选题的参考.
项目批准号/
申请代码1 |
项目名称 |
项目负责人 |
依托单位 |
批准
金额 |
项目起止年月 |
60874107/
F030307 |
多传感器网络决策和估计融合中的信道容错性问题研究 |
朱允民 |
四川大学 |
35 |
2009-01至2011-12 |
60873228/
F020809 |
大规模无线传感器网络节能与耐分割路由算法 |
朱艺华 |
浙江工业大学 |
35 |
2009-01至2011-12 |
60873221/
F020809 |
无线传感器网络恶意节点定位问题研究 |
周学海 |
中国科学技术大学 |
30 |
2009-01至2011-12 |
60873198/
F020703 |
基于信息隐藏的传感器网络安全研究 |
张军 |
广东商学院 |
31 |
2009-01至2011-12 |
60874079/
F030209 |
城市道路交通信息采集的无线传感器网络建模与信息协同处理方法研究 |
张和生 |
北京交通大学 |
28 |
2009-01至2011-12 |
60804067/
F030307 |
ISM频带中的无线传感器网络多网共存技术研究与容限分析 |
曾鹏 |
中国科学院沈阳自动化研究所 |
21 |
2009-01至2011-12 |
60803144/
F020805 |
无线传感器网络安全隐匿路由及其评价验证方法研究 |
杨武 |
哈尔滨工程大学 |
20 |
2009-01至2011-12 |
60873231/
F020805 |
无线传感器网络组播广播安全关键技术研究 |
杨庚 |
南京邮电大学 |
28 |
2009-01至2011-12 |
60803124/
F020809 |
基于多普勒效应的人体传感器网络动态三维定位与监测方法的研究 |
许斌 |
清华大学 |
20 |
2009-01至2011-12 |
60828006/
F0301 |
协同估计与控制理论及在传感器网络中的应用 |
谢立华 |
华南理工大学 |
20 |
2009-01至2010-12 |
60871042/
F010908 |
面向精准农业的新型无线传感器网络体系结构理论与关键技术研究 |
吴华瑞 |
北京市农林科学院 |
30 |
2009-01至2011-12 |
60874103/
F030307 |
面向大型建筑灾难救援的无线传感器网络理论与技术研究 |
吴成东 |
东北大学 |
28 |
2009-01至2011-12 |
60873223/
F020809 |
基于信息交互特性的无线传感器网络安全定位机制 |
王智 |
浙江大学 |
32 |
2009-01至2011-12 |
60873240/
F020809 |
无线传感器网络三维定位中坐标求精方法的研究 |
万江文 |
北京航空航天大学 |
35 |
2009-01至2011-12 |
60872055/
F010103 |
无线传感器网络的信任管理研究 |
田立勤 |
华北科技学院 |
28 |
2009-01至2011-12 |
50875272/
E051102 |
新型无线传感器网络模式下机械振动监测新方法研究 |
汤宝平 |
重庆大学 |
38 |
2009-01至2011-12 |
60874062/
F030119 |
传感器网络中的分布式融合状态估计算法研究 |
孙书利 |
黑龙江大学 |
30 |
2009-01至2011-12 |
60875070/
F030606 |
移动传感器网络的形态控制研究 |
宋光明 |
东南大学 |
30 |
2009-01至2011-12 |
60803126/
F020809 |
面向移动目标的无线传感器网络覆盖度量与优化研究 |
申兴发 |
杭州电子科技大学 |
18 |
2009-01至2011-12 |
60803120/
F020809 |
基于模糊位置信息的无线传感器网络路由技术研究 |
蒲菊华 |
北京航空航天大学 |
21 |
2009-01至2011-12 |
60803151/
F020805 |
基于秘密共享的无线传感器网络安全模型研究 |
庞辽军 |
西安电子科技大学 |
20 |
2009-01至2011-12 |
50875196/
E050302 |
基于无线传感器网络的车载轴温监测和轴承故障早期诊断技术基础研究 |
孟庆丰 |
西安交通大学 |
35 |
2009-01至2011-12 |
60833009/
F020809 |
无线多媒体传感器网络设计理论和关键技术 |
马华东 |
北京邮电大学 |
200 |
2009-01至2012-12 |
60872151/
F010403 |
适用于无线多媒体传感器网络的图像压缩算法及多节点协同图像传输技术研究 |
罗武胜 |
中国人民解放军国防科学技术大学 |
28 |
2009-01至2011-12 |
60873244/
F020809 |
无线传感器网络定位技术研究 |
罗海勇 |
中国科学院计算技术研究所 |
33 |
2009-01至2011-12 |
60810306016/
F02 |
计算机与传感器网络和系统国际会议 |
陆彦辉 |
郑州大学 |
4 |
2008-04至2008-12 |
60811340322/
F010202 |
中国-韩国关于间断连接无线传感器网络双边学术研讨会 |
李云 |
重庆邮电大学 |
8 |
2008-10至2008-12 |
60803109/
F0208 |
自维护的混杂式传感器网络部署策略研究 |
李石坚 |
浙江大学 |
19 |
2009-01至2011-12 |
60874104/
F030307 |
无线传感器网络中的量化状态信息融合研究 |
李建勋 |
上海交通大学 |
30 |
2009-01至2011-12 |
60802002/
F010909 |
应用于桥梁结构健康监测中的无线传感器网络关键技术研究 |
胡晓娅 |
华中科技大学 |
20 |
2009-01至2011-12 |
项目批准号/
申请代码1 |
项目名称 |
项目负责人 |
依托单位 |
批准
金额 |
项目起止年月 |
60873239/
F020809 |
传感器网络中以数据为中心的安全机制研究 |
胡建斌 |
北京大学 |
30 |
2009-01至2011-12 |
60872029/
F010202 |
时间反演算技术在无线传感器网络一些关键技术研究中的应用 |
洪劲松 |
电子科技大学 |
33 |
2009-01至2011-12 |
60873248/
F020809 |
水下传感器网络关键问题研究 |
郭忠文 |
中国海洋大学 |
34 |
2009-01至2011-12 |
60802030/
F010201 |
无线传感器网络智能定位机制与算法研究 |
郭强 |
山东经济学院 |
20 |
2009-01至2011-12 |
60803015/
F020204 |
传感器网络环境下数据挖掘关键技术的研究 |
郭龙江 |
黑龙江大学 |
18 |
2009-01至2011-12 |
60804064/
F030307 |
多约束多传感器网络融合及在船舶监控中的应用研究 |
葛泉波 |
杭州电子科技大学 |
19 |
2009-01至2011-12 |
60802016/
F010206 |
无线传感器网络敌节点检测和隔离理论与关键技术 |
高德云 |
北京交通大学 |
24 |
2009-01至2011-12 |
60870010/
F030307 |
具有能量采集感知的无线传感器网络分簇路由协议研究 |
樊晓平 |
中南大学 |
25 |
2009-01至2011-12 |
60803152/
F020809 |
基于三维空间栅栏的无线传感器网络覆盖问题研究 |
杜军朝 |
西安电子科技大学 |
19 |
2009-01至2011-12 |
60873199/
F020705 |
无线传感器网络数据安全免疫模型研究 |
董晓梅 |
东北大学 |
30 |
2009-01至2011-12 |
40876100/
D0611 |
极地极端环境无线传感器网络技术冰雪遥感监测研究 |
程晓 |
中国科学院遥感应用研究所 |
46 |
2009-01至2011-12 |
60873026/
F0202 |
无线传感器网络的最优化控制方法 |
陈力军 |
南京大学 |
28 |
2009-01至2011-12 |
60872126/
F010406 |
基于Clifford代数的混合型传感器网络覆盖理论的研究 |
曹文明 |
深圳大学 |
34 |
2009-01至2011-12 |
|
|
| |