资深大牛ZigBee技术应用经验汇总
作者:yichun417
作品名称: 基于TI的Zigbee模块的医院输液管理系统
一、 项目设计背景及概述
每个医院输液大厅里面同时都有很多病人在输液,如何保证每个病人每瓶输液快结束时护士能够准时来换药瓶或者拔管,因此就需要一个输液管理系统。
二、 项目设计原理
1、 原理概述
首先每个输液装置自成一个从节点,从节点中包含重力传感器来测量瓶子里面剩余药液的多少(相对值),同时给每种规格的药瓶一个满液初始值和一个空瓶最终值。通过采集重力传感器的输出来算出剩余药液的百分比。通过无线模块传送到服务器端(护士站电脑)进行实时显示。同时每个装置也自带LCD显示实时结果和按键来设置参数。当百分比低于某个值时装置产生报警(蜂鸣器响),同时通过无线模块给服务器端发送报警信号。护士接收到报警信号迅速根据节点号来到病人跟前等待换药或者拔管。由此可以避免医疗事故的发生。
预期效果:可以保证每个病人的换药和拔管及时,避免医疗事故的发生。
主节点实物图: |
从节点实物图: 从节点实物图: 传感器实物图: 传感器实物图: |
作者:54chenjq
作品名称: 基于cc2530的ZIGBEE无线网络自学经验分享
我是从零开始学,一步一步摸索过来的,这些都是我在第一阶段说设计的东东(这么说的意思是掩盖了我现阶段也在摸着石头过河的尴尬而已),拿出来分享一下吧! 先上一组核心板吧,看着还像回事的。 |
作者:she_xiang
作品名称:Zigbee无线通知设备(CC2530)
最近做了一个使用Zigbee做生产线通知仓库送料设备。功能很简单,就是发送器按键按下,接收器接收到发送器数据后,报警并回应,发送器在接收到回应后,指示灯点亮表示数据发送成功。在这个过程中,遇到最大的问题就是传输距离的问题,因为在厂房内部产线和仓库之间隔了很多机器,又有一层比较厚的水泥墙。造成无线信号在传输的过程中有较大的损耗。所以只要改功率和接受灵敏度了,结果距离还是不够,只好再加一个路由器节点来作为中继了。这样才达到了要求。本来客户要求一个接收器配两个发送器。在所有东西都弄好后,准备到客户那儿去安装,后来不知怎么的,他们突发奇想,要一个接收器配一个发送器,共两套。谁让客户是上帝,没办法,只有改了。真是吐槽无语凝噎啊。说多都是泪啊,去改PANID吧。改完测试,正常工作。需要说明的是,因为交期短,来不及做PCB,只有用之前做的一块PCB了,在这之前,曾做了一块仿PLC的PCB(有点大材小用),并预留了Zigbee模块接口(Zigbee模块是淘宝买的).
-
控制板
另外关于给大家介绍:Zigbee 设置信道,PANID,发射功率
现对z-stack里几个网络参数的设置以及如何获取总结一下。
信道配置:
Zigbee在3个频段定义了27个物理信道:868MHz频段中定义了1个信道,915MHz频段中定义了2个信道,信道间隔为2MHz,2.4GHz频段上定义了16个信道,信道间隔为5MHz.
信道编号
中心频率/MHz
信道间隔/MHz
频率上限/MHz
频率下限/MHz
k=0
868.3
--
868.6
868.0
k=1,2,…,10
906+2(k-1)
2
928.0
902.0
k=11,12,…,26
2401+5(k-11)
5
2483.5
2400.0
Z-stack中可以在f8wConfig.cfg里设置信道,相关部分如下:
/* Default channel is Channel 11 - 0x0B */
// Channels are defined in the following:
// 0 : 868 MHz 0x00000001
// 1 - 10 : 915 MHz 0x000007FE
// 11 - 26 : 2.4 GHz 0x07FFF800
//
//-DMAX_CHANNELS_868MHZ 0x00000001
//-DMAX_CHANNELS_915MHZ 0x000007FE
//-DMAX_CHANNELS_24GHZ 0x07FFF800
//-DDEFAULT_CHANLIST=0x04000000 // 26 - 0x1A
//-DDEFAULT_CHANLIST=0x02000000 // 25 - 0x19
//-DDEFAULT_CHANLIST=0x01000000 // 24 - 0x18
//-DDEFAULT_CHANLIST=0x00800000 // 23 - 0x17
//-DDEFAULT_CHANLIST=0x00400000 // 22 - 0x16
//-DDEFAULT_CHANLIST=0x00200000 // 21 - 0x15
//-DDEFAULT_CHANLIST=0x00100000 // 20 - 0x14
//-DDEFAULT_CHANLIST=0x00080000 // 19 - 0x13
//-DDEFAULT_CHANLIST=0x00040000 // 18 - 0x12
//-DDEFAULT_CHANLIST=0x00020000 // 17 - 0x11
//-DDEFAULT_CHANLIST=0x00010000 // 16 - 0x10
//-DDEFAULT_CHANLIST=0x00008000 // 15 - 0x0F
//-DDEFAULT_CHANLIST=0x00004000 // 14 - 0x0E
//-DDEFAULT_CHANLIST=0x00002000 // 13 - 0x0D
//-DDEFAULT_CHANLIST=0x00001000 // 12 - 0x0C
-DDEFAULT_CHANLIST=0x00000800 // 11 - 0x0B 这里默认使用的是编号为11的信道
当建网过程开始后,网络层将请求MAC层对规定的信道或由物理层默认的有效信道进行能量检测扫描,以检测可能的干扰。网络层管理实体对能量扫描的结果以递增的方式排序,丢弃那些能量值超出可允许能量水平的信道,然后再由网络层管理实体执行一次主动扫描,结合检查PAN描述符,对剩下的信道选择一个合适的建立网络。
若要在应用中查看信道,可以这样获得,_NIB.nwkLogicalChannel,读取这个就OK了。(NIB -NWK Information base-. 其中包含一些网络属性 PANID ,NETWORK ADDRESS 等等。其中_nib.nwkpanID是本网的ID标识,_NIB.extendedPANID按照字面意思是外网ID)
PANID:
在确定信道以后,下一步将是确定PANID,如果ZDAPP_CONFIG_PAN_ID被定义为0xFFFF,那么协调器将根据自身的IEEE地址建立一个随机的PANID(0~0x3FFF),如ZDAPP_CONFIG_PAN_ID没有被定义为0xFFFF,那么网络的PANID将由ZDAPP_CONFIG_PAN_ID确定。
“如果ZDAPP_CONFIG_PAN_ID被定义为0xFFFF,那么协调器将根据自身的IEEE地址建立一个随机的PANID(0~0x3FFF)”这句话怎么理解呢,我经过试验发现,这个随机的PANID并非完全随机,它有规律,与IEEE地址有一定的关系:要么就是IEEE地址的低16位,要么就是一个与IEEE地址低16位非常相似的值。如IEEE地址为0x8877665544332211,PANID很有可能就是2211,或相似的值;IEEE地址为0x8877665544337777,PANID很有可能就是3777,或其它相似的值;
Z-stack中相关部分代码如下:
/* Define the default PAN ID.
*
* Setting this to a value other than 0xFFFF causes
* ZDO_COORD to use this value as its PAN ID and
* Routers and end devices to join PAN with this ID
*/
-DZDAPP_CONFIG_PAN_ID=0xFFFF
若要在应用中查看PANID可以这样获得,_NIB.nwkPanId,读取这个就OK了。
发射功率:
传送范围的大小是和发射功率还有信道环境有关, 传送速率和传送范围之间没有直接联系。所以呢,适当的增大发射功率可增大传送范围。但也是有一定的限制的。具体详见datasheet。
在mac_radio_def.h里有可以设置:
#define MAC_RADIO_CHANNEL_DEFAULT 11
#define MAC_RADIO_TX_POWER_DEFAULT 0x1F
#define MAC_RADIO_TX_POWER_MAX_MINUS_DBM 25
这些只是举例说明一下,这些参数的意义,以及在z-stack里的什么地方修改。还有很多其它的参数,可以查看相关的源文件。
[mac_radio_def.h]
#define MAC_RADIO_SET_CHANNEL(x) st( FSCTRLL = FREQ_2405MHZ + 5 * ((x) - 11); )
#define MAC_RADIO_SET_TX_POWER(x) st( TXCTRLL = x; )
#define MAC_RADIO_SET_PAN_ID(x) st( PANIDL = (x) & 0xFF; PANIDH = (x) >> 8; )
[mac_radio.c]
void macRadioInit(void)
{
/* variable initialization for this module */
reqChannel = MAC_RADIO_CHANNEL_DEFAULT;
macPhyChannel = MAC_RADIO_CHANNEL_DEFAULT;
reqTxPower = MAC_RADIO_TX_POWER_DEFAULT;
macPhyTxPower = MAC_RADIO_TX_POWER_DEFAULT;
}
[mac_low_level.h]
uint8 macRadioRandomByte(void);
void macRadioSetPanCoordinator(uint8 panCoordinator);
void macRadioSetPanID(uint16 panID);
void macRadioSetShortAddr(uint16 shortAddr);
void macRadioSetIEEEAddr(uint8 * pIEEEAddr);
void macRadioSetTxPower(uint8 txPower);
void macRadioSetChannel(uint8 channel);
void macRadioStartScan(uint8 scanType);
void macRadioStopScan(void);
void macRadioEnergyDetectStart(void);
uint8 macRadioEnergyDetectStop(void);
设置发射功率:
CC2530 设置RF的发送功率寄存器为TXPOWER,全局搜索一下可以看到以下代码
#define MAC_RADIO_SET_PAN_COORDINATOR(b) st( FRMFILT0 = (FRMFILT0 & ~PAN_COORDINATOR) | (PAN_COORDINATOR * (b!=0)); ) #define MAC_RADIO_SET_CHANNEL(x) st( FREQCTRL = FREQ_2405MHZ + 5 * ((x) - 11); ) #define MAC_RADIO_SET_TX_POWER(x) st( TXPOWER = x; )</font> #define MAC_RADIO_SET_PAN_ID(x) st( PAN_ID0 = (x) & 0xFF; PAN_ID1 = (x) >> 8; ) #define MAC_RADIO_SET_SHORT_ADDR(x) st( SHORT_ADDR0 = (x) & 0xFF; SHORT_ADDR1 = (x) >> 8; )
继续跟踪MAC_RADIO_SET_TX_POWER
/************************************************************************************************** * @fn macRadioUpdateTxPower * * @brief Update the radio's transmit power if a new power level has been requested * * @param reqTxPower - file scope variable that holds the last request power level * macPhyTxPower - global variable that holds radio's set power level * * @return none ************************************************************************************************** */ MAC_INTERNAL_API void macRadioUpdateTxPower(void) { halIntState_t s; /* * If the requested power setting is different from the actual radio setting, * attempt to udpate to the new power setting. */ HAL_ENTER_CRITICAL_SECTION(s); if (reqTxPower != macPhyTxPower) { /* * Radio power cannot be updated when the radio is physically transmitting. * If there is a possibility radio is transmitting, do not change the power * setting. This function will be called again after the current transmit * completes. */ if (!macRxOutgoingAckFlag && !MAC_TX_IS_PHYSICALLY_ACTIVE()) { /* * Set new power level; update the shadow value and write * the new value to the radio hardware. */ macPhyTxPower = reqTxPower; <font color="#ff0000"> MAC_RADIO_SET_TX_POWER(macPhyTxPower);</font> } } HAL_EXIT_CRITICAL_SECTION(s); }
在这里我们可以看到TXPOWER的设置值实际上应该是reqTxOower,让我看一下reqTxOower在哪里设置吧,继续跟踪可以发现reqTxPower在函数MAC_INTERNAL_API uint8 macRadioSetTxPower(uint8 txPower)中得到更新,一路跟踪下去可以在函数uint8 MAC_MlmeSetReq(uint8 pibAttribute, void *pValue)看到以下代码
case MAC_PHY_TRANSMIT_POWER: /* Legacy transmit power attribute */ #if !defined HAL_MAC_USE_REGISTER_POWER_VALUES && \ !defined HAL_PA_LNA && !defined HAL_PA_LNA_CC2590 /* Legacy transmit power attribute value for CC2530 alone, * or runtime selection support build means a negative absolute value. * However, when used as register power values or * with HAL_PA_LNAxxx definition (without runtime selection) * the attribute value is not a negative absolute value. */ macPib.phyTransmitPower = (uint8)(-(int8)macPib.phyTransmitPower); #endif /* !defined HAL_MAC_USE_REGISTER_POWER_VALUES && ... */ /* pass through to next case -- do not break*/ #endif /* MAC_OBSOLETE_PHY_TRANSMIT_POWER */ case MAC_PHY_TRANSMIT_POWER_SIGNED: (void)macRadioSetTxPower(macPib.phyTransmitPower); break;
到这里为止Z-Stack发送功率的设置流程已经明确,但是我找遍Z-Stack的工程也没有找到调用uint8 MAC_MlmeSetReq(uint8 pibAttribute, void *pValue)的地方想来应该是封装在TI提供的LIB文件中了,
修改TXPOWER的方法有两种:一、在uint8 macRadioSetTxPower(uint8 txPower)函数中通过修改macPib.phyTransmitPower = (uint8)(-(int8)macPib.phyTransmitPower);的值来修改TXPOWER参数,系统复位后将使用调用该函数设置发送功率。修改macPib.phyTransmitPower = (uint8)(-(int8)macPib.phyTransmitPower);可以通过修改以下结构体中的红色部分来修改static CODE const macPib_t macPibDefaults = { 54, /* ackWaitDuration */ FALSE, /* associationPermit */ TRUE, /* autoRequest */ FALSE, /* battLifeExt */ 6, /* battLifeExtPeriods */ NULL, /* *pMacBeaconPayload */ 0, /* beaconPayloadLength */ MAC_BO_NON_BEACON, /* beaconOrder */ 0, /* beaconTxTime */ 0, /* bsn */ {0, SADDR_MODE_EXT}, /* coordExtendedAddress */ MAC_SHORT_ADDR_NONE, /* coordShortAddress */ 0, /* dsn */ FALSE, /* gtsPermit */ 4, /* maxCsmaBackoffs */ 3, /* minBe */ 0xFFFF, /* panId */ FALSE, /* promiscuousMode */ FALSE, /* rxOnWhenIdle */ MAC_SHORT_ADDR_NONE, /* shortAddress */ MAC_SO_NONE, /* superframeOrder */ 0x01F4, /* transactionPersistenceTime */ FALSE, /* assocciatedPanCoord */ 5, /* maxBe */ 1220, /* maxFrameTotalWaitTime */ 3, /* maxFrameRetries */ 32, /* ResponseWaitTime */ 0, /* syncSymbolOffset */ TRUE, /* timeStampSupported */ FALSE, /* securityEnabled */ /* Proprietary */ #if defined (HAL_PA_LNA) 19, /* phyTransmitPower for CC2591 */ #elif defined (HAL_PA_LNA_CC2590) 11, /* phyTransmitPower for CC2590 */ #else <span style="color:#ff0000;">0, /* phyTransmitPower without frontend */</span> #endif MAC_CHAN_11, /* logicalChannel */ {0, SADDR_MODE_EXT}, /* extendedAddress */ 1, /* altBe */ MAC_BO_NON_BEACON, /* deviceBeaconOrder */ };
该值可以再-22到3之间变化具体可以参考
const uint8 CODE macRadioDefsTxPwrBare[] = { 3, /* tramsmit power level of the first entry */ (uint8)(int8)-22, /* transmit power level of the last entry */ /* 3 dBm */ 0xF5, /* characterized as 4.5 dBm in datasheet */ //0 /* 2 dBm */ 0xE5, /* characterized as 2.5 dBm in datasheet */ /* 1 dBm */ 0xD5, /* characterized as 1 dBm in datasheet */ /* 0 dBm */ 0xD5, /* characterized as 1 dBm in datasheet */ /* -1 dBm */ 0xC5, /* characterized as -0.5 dBm in datasheet */ /* -2 dBm */ 0xB5, /* characterized as -1.5 dBm in datasheet */ /* -3 dBm */ 0xA5, /* characterized as -3 dBm in datasheet */ /* -4 dBm */ 0x95, /* characterized as -4 dBm in datasheet */ /* -5 dBm */ 0x95, /* -6 dBm */ 0x85, /* characterized as -6 dBm in datasheet */ /* -7 dBm */ 0x85, /* -8 dBm */ 0x75, /* characterized as -8 dBm in datasheet */ /* -9 dBm */ 0x75, /* -10 dBm */ 0x65, /* characterized as -10 dBm in datasheet */ /* -11 dBm */ 0x65, /* -12 dBm */ 0x55, /* characterized as -12 dBm in datasheet */ /* -13 dBm */ 0x55, /* -14 dBm */ 0x45, /* characterized as -14 dBm in datasheet */ /* -15 dBm */ 0x45, /* -16 dBm */ 0x35, /* characterized as -16 dBm in datasheet */ /* -17 dBm */ 0x35, /* -18 dBm */ 0x25, /* characterized as -18 dBm in datasheet */ /* -19 dBm */ 0x25, /* -20 dBm */ 0x15, /* characterized as -20 dBm in datasheet */ /* -21 dBm */ 0x15, /* -22 dBm */ 0x05 /* characterized as -22 dBm in datasheet */ };
二、就是使用MT功能
void MT_SysSetTxPower(uint8 *pBuf) { /* A local variable to hold the signed dBm value of TxPower that is being requested. */ uint8 signed_dBm_of_TxPower_requeseted; /* * A local variable to hold the signed dBm value of TxPower that can be set which is closest to * the requested dBm value of TxPower, but which is also valid according to a complex set of * compile-time and run-time configuration which is interpreted by the macRadioSetTxPower() * function. */ uint8 signed_dBm_of_TxPower_range_corrected; /* Parse the requested dBm from the RPC message. */ signed_dBm_of_TxPower_requeseted = pBuf[MT_RPC_POS_DAT0]; /* * MAC_MlmeSetReq() will store an out-of-range dBm parameter value into the NIB. So it is not * possible to learn the actual dBm value that will be set by invoking MACMlmeGetReq(). * But this actual dBm value is a required return value in the SRSP to this SREQ. Therefore, * it is necessary to make this redundant pre-call to macRadioSetTxPower() here in order to run * the code that will properly constrain the requested dBm to a valid range based on both the * compile-time and the run-time configurations that affect the available valid ranges * (i.e. MAC_MlmeSetReq() itself will invoke for a second time the macRadioSetTxPower() function). */ <font color="#ff0000"> signed_dBm_of_TxPower_range_corrected = macRadioSetTxPower(signed_dBm_of_TxPower_requeseted);</font> /* * Call the function to store the requested dBm in the MAC PIB and to set the TxPower as closely * as possible within the TxPower range that is valid for the compile-time and run-time * configuration. */ (void)MAC_MlmeSetReq(MAC_PHY_TRANSMIT_POWER_SIGNED, &signed_dBm_of_TxPower_requeseted); /* Build and send back the response that includes the actual dBm TxPower that can be set. */ MT_BuildAndSendZToolResponse(((uint8)MT_RPC_CMD_SRSP | (uint8)MT_RPC_SYS_SYS), MT_SYS_SET_TX_POWER, 1, &signed_dBm_of_TxPower_range_corrected); }
作者:传媒学子
作品名称:基于CC2530的zigbee无线信息传输系统的制作
我记得TI公司出的CC系列的无线芯片性能非常好,而且集成了片上MCU处理器,直接串口输出,只用增加一个usb转串口的芯片就行。
我本科的时候玩过这个模块,当时测试的时候,我和一同学分别站在图书馆和校门口,距离大概500米,能收到信号,然后大概可以穿透3面墙。当时吧
没见过什么世面,觉得这款cc2530碉堡了,最后上了TI官网,发现这只是其中普通的一款,还有CC2540等更牛的芯片。
刚才搜索了一下,又出现了好多新的芯片,CC2545.
我以前用的是CC2530,当时花了我150人民币买了两个CC2530模块。
这款CC2530 2.4-GHz 专用ZigBee 芯片。貌似它还可以建立节点,当时我电脑的建立的是主节点,我同学的是另外一个节点。CC2530还自带了业界标准的增强型8051 CPU,系统内可编程闪存,8-KB RAM 和许多其它强大的功能。CC2530 有四种不同的闪存版本:CC2530F32/64/128/256,分别具有32/64/128/256KB 的闪存。
它还具有不同的运行模式,极大的促进了无线低功耗技术的发展。超远距离传输也使得无线应用,智能家居,智能农田成为了可能。
说一下测试的过程吧:
首先插入厂家赠送的光盘
安装相应的配置模块,下载相应的程序。
然后打开我们的串口精灵,我发送循环发送 abcd...。然后我同学电脑就能收到abcd.
随着距离的增加,收到abcd的速度会减慢,系统内部在进行自我纠错。距离达到500米后,错误比较多,系统正确发送的包就会速度降低。
这款zigbee确实强大,我记得我大二接触的NRF2104之类的无线模块有效距离特别近。
之后,我们有实验了能穿透多少面墙,1、2面是毫无压力,但是4面以上就有压力了。
由于只有2个无线模块,所以传说中的节点就没法实验了。
这两个模块,在我本科毕业的时候送给学弟了,不知道,他们是否善待了它两。
作者:yichun417
作品名称:【TI 无线主题征集】+ 基于单元轨道板测量系统的CC2530应用
为了适应我国高速铁路建设的要求,板式无砟轨道已经逐渐代替了传统的有砟轨道和既有的无砟轨道。板式无咋轨道在施工时,将轨道板场事先预制生产的轨道板铺设在现场施工好的支撑层上,再用扣件系统将钢轨安装在轨道板上。轨道板的铺设精度将直接影响轨道最终的平顺性,为了确保铺设精度,一般采用轨道板精调系统来完成轨道板的精密铺设:首先在支撑层上沿线路中线每隔6.5m测设基标点,作为坐标基准,利用基标点将轨道板粗铺到位,然后在基标点上架设测量机器人和定向棱镜,启动工控机的轨道板精调软件,测量架设在轨道板1、5、10号承轨台标架上的棱镜,通过软件计算,得出与设计值的偏差,将偏差值显示在工作车的显示器上,调板工作人员根据偏差值,通过调整支架,调整轨道板至规程要求。采用轨道板精调系统,测量调板的控制精度在0.3mm,轨道板调整好后,基本不用调整钢轨。类似的系统还有轨道板测量调板装置(专利号ZL 200820064211.1)、轨道板精调测量系统以及调整方法(公开号CN 101067294A)。其缺点是:系统组成散乱,多个终端显示与工控机和温度传感器等用线缆连接在一起,散布于需调整的轨道板上,使用和运输极为不便,可靠性无法保障。
在高铁轨道办铺板过程中,为了保证铺板的精度,我们必须设计一套测量系统。系统总体结构如下图所示,手簿、全站仪和主支架之间通过无线连接(此无线模块用的是手簿和全站仪相同的模块),而系统中包含有3个测量支架,3个测量支架之间通过ZigBee无线技术连接。
系统工作原理:通过手簿上的测量软件控制全站仪测量轨道板的空间相对于3级基准点的空间坐标来调整轨道板的位置,同时主支架将3个支架上的角度传感器的数据传回到手簿上,经过软件计算后将调整数据发送到主支架,主支架接收到数据后发送到从支架,从而工程人员通过每个支架上的显示屏上的数据来调整轨道板的位置,最后将轨道板调整到合适的位置进行灌封固定。
在无线模块中我们用到了TI的Zigbee模块CC2530,系统要求此模块的通讯距离必须保证在20米左右(因为3个支架彼此距离不超过10米,但是数据都是从主支架传送到其他2个从支架,因此必须保证20米左右)。下图红色圈内即为该无线模块。
下面为我们系统产品的相关图片:
作者:yichun417
作品名称:基于CC2530的四轴飞行器开发
四轴飞行器现在是个非常火的话题,包括亚马逊都考虑用他们来给客户送包裹,可见其以后发展的前景有多大。 同时,国内也有一些专门做这个的公司,比如大疆等等,都是一些非常专业的公司。
我们利用Zigbee模块所设计开发的大都是一些处于学习阶段或者娱乐阶段的产品,仅仅只能够说明一些问题而已。实用的目的还不是很强。其中包括一些非常典型的设计理念和方法,空心杯电机驱动,四轴平衡算法,还有就是包括飞行器前进、后退、转弯和悬停的技巧。
目前,国家打算开放1000米以下的空域给民众,到时候会有好多成熟且功能强大的作品问世。或许国家有意让民众来开放低空域应用,给一些重要应用领域开放提供先决条件,对于民用或者军用都会产生很大的推动作用。
在此,我们仅以自己开发的一些小产品来展望一些未来世界,可以让工程师的梦想尽快加以实现。
作者:路飞d梦想
作品名称:基于CC2530的WSN节点设计
本科毕业设计做的是这个,基于CC2530的WSN节点设计。
无线传感器网络(Wireless Sensor Network,简称WSN)就是由部署在监测区域内大量的廉价微型传感器节点组成,通过无线通信方式形成的一个多跳的自组织的网络系统,其目的是协作地感知、采集和处理网络覆盖区域中被感知对象的信息,并发送给观察者。无线传感器网络能够获取客观物理信息,具有十分广阔的应用前景,能应用于军事国防、工农业控制、城市管理、生物医疗、环境检测、抢险救灾、危险区域远程控制等领域。
本设计的无线传感器网络节点的MCU采用了TI公司的CC2530射频芯片。CC2530是用于ZigBee 应用的一个真正的片上系统(SoC)解决方案。它能够以非常低的总的材料成本建立强大的网络节点。
根据TI公司提供的参考设计方案,应用Altium Designer Winter 09专业绘图软件绘制了最小系统板、网关电源底板、、节点电源底板的原理图和PCB图,然后对板子进行了焊接和调试。然后在此基础上实现无线传感器网络节点的通信。
在软件部分采用了TI公司提供的Z-Stack协议栈。Z-Stack采用操作系统的思想来构建,采用事件轮循机制,当各层初始化之后,系统进入低功耗模式,当事件发生时,唤醒系统,开始进入中断处理事件,结束后继续进入低功耗模式。如果同时有几个事件发生,判断优先级,逐次处理事件。这种软件构架可以极大地降级系统的功耗。接下来还对Tiny OS操作系统进行了简单的了解与尝试移植。
目前传感器节点能力仍然受限,这些体现在传感器具有的能量、处理能力、存储能力和通信能力等都十分有限,因而在实现各种网络协议和应用系统时,传感器节点的能力要受到以下一些限制:
1、电源能量受限。由于传感器节点的微型化,节点的电池能量有限,而且由于物理限制难以给节点更换电池,所以传感器节点的电池能量限制是整个无线传感器网络设计最关键的约束之一,它直接决定了网络的工作寿命。传感器节点消耗能量的模块包括传感器模块、处理器模块和无线通信模块,其中绝大部分的能量消耗在无线通信模块上,通常1比特信息传输100m距离所需的能量大约相当于执行3000条计算指令所消耗的能量[5];
2、计算和存储能力有限。廉价微型的传感器节点带来了处理器能力弱、存储器容量小的特点,使得其不能进行复杂的计算,而传统的Internet网络上成熟的协议和算法对于无线传感器网络而言开销太大,难以使用,因此必须重新设计简单、有效的协议及算法。如何利用有限的计算和存储资源完成诸多协同任务成为对无线传感器网络设计的挑战;
3、通信能力有限。通常,无线通信的能耗E与通信距离d的关系为:E=kdn,其中2<n<4。参数n的取值与很多因素有关:由于传感器节点体积小,发送端和接收端都贴近地面,障碍物多,干扰大,n的取值要偏大;另外,天线质量对信号发射质量的影响也很大。综合考虑这些因素,通常取n为3,即通信能耗与通信距离的3次方成正比,随着通信距离的增加,能耗也会急剧增加。为节能起见,无线传感器网络应采用多条路由的通信传输机制,尽量减少单跳通信的距离。 由于无线信道自身的物理特性,通常使得它所能提供的网络带宽相对有限信道要小得多。此外,节点能量的变化,周围地势地貌以及自然环境的影响,使得网络的无线通信性能也会经常变化,甚至通信有可能时断时续。因此,如何设计可靠的通信机制以满足网络的通信需求是无线传感器网络所面临的一个重要挑战。
无线传感器网络可以分为三个部分:分布于监控区域内的传感器节点、中心汇聚节点、汇聚节点通过有线或无线网络连接到管理节点,其结构类似于图2-1。 |
-
Z-Stack 协议栈
Zigbee[7]是基于IEEE802.15.4[8]标准的低功耗个域网协议。根据这个协议规定的技术是一种短距离、低功耗的无线通信技术。这一名称来源于蜜蜂的八字舞,由于蜜蜂(bee)是靠飞翔和“嗡嗡”(zig)地抖动翅膀的“舞蹈”来与同伴传递花粉所在方位信息,也就是说蜜蜂依靠这样的方式构成了群体中的通信网络。其特点是近距离、低复杂度、自组织、低功耗、低数据速率、低成本。主要适合用于自动控制和远程控制领域,可以嵌入各种设备。简而言之,ZigBee就是一种便宜的,低功耗的近距离无线组网通讯技术。图2-2给出了ZigBee协议的五层结构。
物理层(PHY)定义了物理无线信道和MAC子层之间的接口,提供物理层数据服务和物理层管理服务。物理层的内容是激活ZigBee;检测当前信道的能量;检测接收链路服务质量信息;定义ZigBee信道接入方式;选择信道频率;负责数据传输和接收。 介质接入控制子层(MAC)负责处理所有的物理无线信道访问,并产生网络信号、同步信号;支持PAN连接和分离,提供两个对等MAC实体之间可靠的链路。 MAC层功能为网络协调器产生信标;与信标同步;支持PAN(个域网)链路的建立和断开;为设备的安全性提供支持;信道接入方式采用免冲突载波检测多址接入(CSMA-CA)机制;处理和维护保护时隙(GTS)机制;在两个对等的MAC实体之间提供一个可靠的通信链路[9]。 网络层(NWK)是整个ZigBee协议栈的核心部分。网络层主要实现节点加入或离开网络、接收或抛弃其他节点、路由初始化、查找及传送数据、维护信息库等功能。 ZigBee应用层(APL)框架包括应用支持层(APS)、ZigBee设备对象(ZDO)和制造商所定义的应用对象。应用支持层的功能包括:维持绑定表、在绑定的设备之间传送消息。ZigBee设备对象的功能包括:定义设备在网络中的角色(如ZigBee协调器和终端设备),发起和响应绑定请求,在网络设备之间建立安全机制。ZigBee设备对象还负责发现网络中的设备,并且决定向他们提供何种应用服务。ZigBee应用层除了提供一些必要函数以及为网络层提供合适的服务接口外,一个重要的功能是应用者可在这层定义自己的应用对象。 应用程序框架(AF)运行在ZigBee协议栈上的应用程序实际上就是厂商自定义的应用对象,并且遵循规范(profile)运行在端点1~ 240上。在ZigBee应用中,提供2种标准服务类型:键值对(KVP)或报文(MSG)。 ZigBee设备对象(ZDO)的功能包括负责定义网络中设备的角色,如:协调器或者终端设备。还包括对绑定请求的初始化或者响应,在网络设备之间建立安全联系等。实现这些功能,ZDO使用APS层的APSDE-SAP和网络层的NLME-SAP。ZDO是特殊的应用对象,它在端点(entire)0上实现。远程设备通过ZDO请求描述符信息,接收到这些请求时,ZDO会调用配臵对象获取相应描述符值。 Z-Stack是在IEEE 802.15.4标准基础上建立的,是ZigBee的具体实现,定义了协议的MAC和PHY层。Z-Stack采用操作系统的思想来构建,采用事件轮循机制,当各层初始化之后,系统进入低功耗模式,当事件发生时,唤醒系统,开始进入中断处理事件,结束后继续进入低功耗模式。如果同时有几个事件发生,判断优先级,逐次处理事件。这种软件构架可以极大地降级系统的功耗。在ZigBee协议中,协议本身已经定义了大部分内容。在基于Z-Stack协议栈的应用开发中,用户只需要实现应用程序框架即可。从图2-2可以看出应用程序框架中包含了最多240个应用程序对象。如果我们把一个应用程序对象看做为一个任务的话,那么应用程序框架将包含一个支持多任务的资源分配机制。于是OSAL便有了存在的必要性,它正是Z-Stack为了实现这样一个机制而存在的。 OSAL就是以实现多任务为核心的系统资源管理机制。所以OSAL与标准的操作系统还是有很大的区别的。简单而言,OSAL实现了类似操作系统的某些功能,但并不能称之为真正意义上的操作系统。
整个Z-stack的主要工作流程如图2-3,大致分为系统启动,驱动初始化,OSAL初始化和启动,进入任务轮循几个阶段。
Tiny OS操作系统
由于无线传感器网络的特殊性,为解决Z-Stack定位程序代码量大[10]、结构复杂等问题,需要操作系统能够高效地使用传感器节点的有限内存、低功耗处理器、多样传感器、有限的电源,并且能够对各种特定应用提供最大的支持。基于此,UC Berkeley 研究人员专为嵌入式无线传感器网络开发出Tiny OS系统,目前已经成为无线传感器网络事实上的标准平台。
Tiny OS具有微型化、支持轻量级并发操作、灵活、低功耗等优点,已经被成千上万的研发人员采用,应用于范围广阔的无线传感器网络中。Tiny OS的设计特点主要体现在一下三个方面:(1)基于组件的编程模型(2)基于事件触发的并发执行模型(3)采用基于主动消息的通信模型[11]。
Tiny OS操作系统采用了组件的结构,它是一个基于事件的系统。系统本身提供了一系列的组件供用户调用,其中包括主组件、应用组件、执行组件、感知组件、通信组件和硬件抽象组件,其层次结构如图2-4所示。组件由下到上通常可以分为3类:硬件抽象组件、综合硬件组件和高层软件组件。硬件抽象组件将物理硬件映射到Tiny OS的组件模型;综合硬件组件模拟高级的硬件行为,如感知组件、通信组件等;高层软件组件实现控制、路由以及数据传输等应用层的功能。高层组件向底层组件发出命令,底层组件向高层组件报告事件。Tiny OS的层次结构就如同一个网络协议栈,底层的组件负责接收和发送最原始的数据位,而高层的组件对这些数据进行编码、解码,更高层的组件则负责数据打包、路由选择以及数据传输[12]。
MCU 选型
CC2530是用于ZigBee应用的一个真正的片上系统(SoC)解决方案。它能以非常低的总的材料成本建立强大的网络节点。CC2530结合了领先的RF收发器的优良性能,业界标准的增强型8051CPU,系统内可编程闪存,8-KB RAM。CC2530具有不同的运行模式使得尤其适应超低功耗要求的系统。CC2530F256具有256-KB内存,结合了德州仪器的ZigBee协议栈(Z-StackTM),提供了一个强大和完整的ZigBee解决方案。CC2530的内部结构图如图2-5所示。
如图2-5所示,模块大致可以分为三种类型:
1、CPU 和内存相关的模块:一个单周期的8051兼容内核、三种总线结构、内存仲裁器、8-KB RAM、32/64/128/256 KB闪存块;
2、外设、时钟和电源管理相关的模块:具有三种供电模式、IEEE 802.15.4 MAC定时器、通用定时器、AES协处理器、DMA、可配置分辨率的12位ADC。
3、无线电相关的模块:CC253x设备系列提供了一个IEEE 802.15.4兼容无线收发器。RF内核控制模拟无线模块。另外,它提供了MCU 和无线设备之间的一个接口,这使得可以发出命令、读取状态、自动操作和确定无线设备事件的顺序。无线设备还包括一个数据包过滤和地址识别模块,硬件支持CSMA/CA[14],支持精确的RSSI/LQI定位。
结合以上的数据,可以看出CC2530是无线传感器网络节点设计的不二选择。
巴伦天线电路 巴伦是平衡不平衡转换器的英文音译,原理是按天线理论,偶极天线属平衡型天线,而同轴电缆属不平衡传输现,若将其直接连接,则同轴电缆的外皮就有高频电流流过(按同轴电缆传输原理,高频电流应在电缆内部流动,外皮是屏蔽层,是没有电流的),这样一来,就会影响天线的辐射(可以想象成电缆的屏蔽层也参与了电波的辐射)。 因此,就要在天线和电缆之间加入平衡不平衡转换器,把流入电缆屏蔽层外部的电流扼制掉,也就是说把从振子流过电缆屏蔽层外皮的高频电流截断。有两种方法实现巴伦: 1、采用分立元件实现,LC巴伦设计的本质就是一个电桥,被称为“格子形式”巴伦,电路中包含两个电容和两个电感,分别产生+90。相移。在工作频率时,满足, , L=Zc/ω ,C=1/ω*Zc ..如图3-3所示。
采用Johnson technology 公司的的Bulan-LPF芯片2450BM15A0002。这款芯片是专为CC253x系列射频芯片所做射频低通滤波器,这简化了计算和选择匹配的电感电容的麻烦。如图3-4是该芯片的连接方式。 因为设计之前并没有找到这款芯片,所以在制版时我采用了第一种方案,这也是TI官网的方案。根据计算得出实际的L=2nH,C=1pF。如图3-5所示,天线使用的是2.4G单轴陶瓷天线。C11、C12、C15的作用是前后两端隔离低频信号的作用。 |
-
了解协议栈
当打开IAR的时候可以看到如图4-3所示的文件结构图。下面就依次分析每一个文件夹的作用。
APP:应用层目录,这是用户创建各种不同工程的区域,在这个目录中包含了应用层的内容和这个项目的主要内容,在协议栈里面一般是以操作系统的任务实现的。HAL:硬件层目录,包含有与硬件相关的配置和驱动及操作函数。MAC:MAC层目录,包含了MAC层的参数配置文件及其MAC的LIB库的函数接口文件。MT:实现通过串口可控各层,于各层进行直接交互。NWK:网络层目录,含网络层配置参数文件及网络层库的函数接口文件,APS层库的函数接口OSAL:协议栈的操作系统。Profile:AF层目录,包含AF层处理函数文件。Security:安全层目录,安全层处理函数,比如加密函数等。Services:地址处理函数目录,包括着地址模式的定义及地址处理函数。Tools:工程配置目录,包括空间划分及Z-Stack相关配置信息。ZDO:ZDO目录。ZMac: MAC层目录,包括MAC层参数配置及MAC层LIB库函数回调处理函数。ZMain:主函数目录,包括入口函数及硬件配置文件。Output:输出文件目录,这个EW8051 IDE自动生成的。 从上面的描述中可以看出,整个协议栈中,对于ZigBee的功能已经全部体现,在此基础上建立一个项目的方法主要是改动应用层 。
4.2.2 应用程序添加
整个协议栈是以一个OS贯穿的,要加入自己的应用,就要添加一个任务,在任务中执行,与协议栈实现无缝连接。
1、添加一个任务。在协议栈中的OSAL.c文件中,byteosal_init_system( void )函数的功能是初始化OS、添加任务到OS任务表中。在这个函数中通过调用osalAddTasks()函数来定制项目所需要应用的任务,该函数属于应用层和OS之间的接口函数,一般项目的建立需要根据系统的需要自己编写改函数,并将函数放到应用层。osalAddTasks()函数是通过osalTaskAdd()函数完成任务添加。
首先,将支持协议栈功能需要的任务加载到该函数中,
void osalAddTasks( void )
{
osalTaskAdd (Hal_Init, Hal_ProcessEvent,OSAL_TASK_PRIORITY_LOW);
#if defined( ZMAC_F8W )
osalTaskAdd( macTaskInit, macEventLoop,OSAL_TASK_PRIORITY_HIGH );
#endif
#if defined( MT_TASK )
osalTaskAdd( MT_TaskInit, MT_ProcessEvent,OSAL_TASK_PRIORITY_LOW );
#endif
osalTaskAdd( nwk_init, nwk_event_loop,OSAL_TASK_PRIORITY_MED );
osalTaskAdd( APS_Init, APS_event_loop,OSAL_TASK_PRIORITY_LOW );
osalTaskAdd( ZDApp_Init, ZDApp_event_loop,OSAL_TASK_PRIORITY_LOW );
}
这些任务是协议栈运行的先决条件,为了更好的使用协议栈,建议将这些任务都添加到任务列表中。这些函数的参数条件在协议栈中已经定义好,可以直接使用。
从上面加载的函数中可以发现,要建立一个单独的任务,必须先将osalTaskAdd()函数所需要的参数条件定义好,这些参数分别是初始化函数example_Init,任务处理函数example_event_loop和任务优先级。
2、任务初始化函数。任务初始化函数的功能是将该任务需要完成的功能的功能部件初始化,在每一个任务的初始化函数中,必须完成的功能是要得到设置任务的任务ID。
void SampleApp _Init ( uint8 task_id )
{
SampleApp _Init = task_id;
}
由于在这个任务中还有其他的功能,所以,对其他功能也需要做一定的初始化,包括对发送数据的设置,按键的设置等。实现的函数为:
void SampleApp_Init ( uint8 task_id )
{
SampleApp_TaskID = task_id; //任务ID
SampleApp_NwkState = DEV_INIT; //网络类型
SampleApp_TransID = 0; // 设置发送数据的方式和目的地址,
SampleApp_All_DstAddr.addrMode =(afAddrMode_t)AddrBroadcast;//广播到所有的设备
SampleApp_All_DstAddr.endPoint =SAMPLEAPP_ENDPOINT;
SampleApp_All_DstAddr.addr.shortAddr = 0xFFFF;
// 单播到一个设备
SampleApp_Single_DstAddr.addrMode =(afAddrMode_t)afAddrGroup;
SampleApp_Single_DstAddr.endPoint =SAMPLEAPP_ENDPOINT;
// 设置 endpoint description.
SampleApp_epDesc.endPoint = SAMPLEAPP_ENDPOINT;
SampleApp_epDesc.task_id =&SampleApp_TaskID;
SampleApp_epDesc.simpleDesc
= (SimpleDescriptionFormat_t*)&SampleApp_SimpleDesc;
SampleApp_epDesc.latencyReq = noLatencyReqs;
// 登记endpoint description 到 AF
afRegister( &SampleApp_epDesc );
// 登记所有的按键事件
RegisterForKeys( SampleApp_TaskID );
}
3、任务处理函数。任务处理函数是对任务发生后的事件进行处理,在这个项目中主要完成的功能是通过协调器上的按键发送一个数据,控制路由器的小灯。所以里面就应该设计到按键的事件处理,网络状态的判断(判断设备的类型,是协调器还是路由器或者是终端设备)和接收到信息后的处理。处理函数为:
uint16 SampleApp_ProcessEvent( uint8 task_id,uint16 events )
{
afIncomingMSGPacket_t *MSGpkt;
if ( events & SYS_EVENT_MSG ) //系统信息,
{ MSGpkt= (afIncomingMSGPacket_t *)osal_msg_receive( SampleApp_TaskID ); //OS发送过来的信息
while ( MSGpkt )
{
switch ( MSGpkt->hdr.event )
{ // 按键事件
case KEY_CHANGE: //按键处理函数
SampleApp_HandleKeys( ((keyChange_t*)MSGpkt)->keys );
break; // 接收数据事件
case AF_INCOMING_MSG_CMD: //接收数据的处理函数
SampleApp_MessageMSGCB( MSGpkt );
break; // 网络状态发生变化时间
case ZDO_STATE_CHANGE:
SampleApp_NwkState =(devStates_t)(MSGpkt->hdr.status); //获取网络状态
if ( (SampleApp_NwkState == DEV_ZB_COORD)//判断网络类型
|| (SampleApp_NwkState == DEV_ROUTER)
|| (SampleApp_NwkState == DEV_END_DEVICE) )
{
}
else
{ // 设备不属于这个网络
}
break;
default:
break;
} // 释放存储器
osal_msg_deallocate( (uint8 *)MSGpkt ); // Next- 如果有一个空闲的任务
MSGpkt = (afIncomingMSGPacket_t*)osal_msg_receive( SampleApp_TaskID );
} // 返回未处理的任务
return (events ^ SYS_EVENT_MSG);
}
return 0;
}
4、按键子函数。按键子函数的功能是处理所有的按键事件,按键的底层驱动函数在Hal_key.c中,在这里按键需要完成的任务是,当协调器按键1被按下后,以广播的方式发送数据去让路由器小灯闪烁。
void SampleApp_HandleKeys(uint8 keys )
{
if ( keys & HAL_KEY_SW_1 )
{
if(SampleApp_NwkState == DEV_ZB_COORD) //如果是协调器
SampleApp_SendFlashMessage(SAMPLEAPP_FLASH_DURATION ); //发送数据
else
{
}
}
}
5、接收处理函数。接收处理函数的功能有两部分,一是路由器的接收函数,二是协调器的接收处理函数。在这个项目里面,我们将这两种设备的处理函数都固化在了一个函数里面,用串ID来判断他们的设备类型。当路由器接收到数据后,先判断该信息的串ID,然后判断命令,如果命令正确,则小灯闪烁,然后单播发送确认信号给协调器,协调器收到信号后,同样先判断串ID,然后确认命令后小灯闪烁示意。
void SampleApp_MessageMSGCB(afIncomingMSGPacket_t *pkt )
{
unsigned char Rx_Buf[4];
switch ( pkt->clusterId )
{
case SAMPLEAPP_CLUSTERID1:
memcpy(Rx_Buf,pkt->cmd.Data,3);
if((Rx_Buf[0] == 'Y') && (Rx_Buf[1] =='E') && (Rx_Buf[2] == 'S'))
{
HalLedBlink( HAL_LED_4, 4, 50, 250); //小灯闪烁四次
}
break;
case SAMPLEAPP_CLUSTERID2:
memcpy(Rx_Buf,pkt->cmd.Data,4);
if((Rx_Buf[0] == 'O') && (Rx_Buf[1] =='P') && (Rx_Buf[2] == 'E') && (Rx_Buf[3] == 'N'))
{
HalLedBlink( HAL_LED_4, 4, 50, 250); //小灯闪烁四次
SendData("YES",pkt->srcAddr.addr.shortAddr,3);//以单播的方式回复信号
}
break;
}
}
6、发送函数:广播发送一段数据
void SampleApp_SendFlashMessage( uint8 *buffer )
{
if ( AF_DataRequest( &SampleApp_All_DstAddr, &SampleApp_epDesc,
SAMPLEAPP_CLUSTERID2,
4,
buffer,
&SampleApp_TransID,
AF_DISCV_ROUTE,
AF_DEFAULT_RADIUS ) == afStatus_SUCCESS )
//********************************************************************
void SampleApp_SendData(uint8 *buf, uint16 addr, uint8 Leng)
{
SampleApp_Single_DstAddr.addr.shortAddr = addr;
if ( AF_DataRequest( &SampleApp_Single_DstAddr, //发送的地址和模式
&SampleApp_epDesc, //终端(比如操作系统中任务ID等)
SAMPLEAPP_CLUSTERID1,//发送串ID
Leng,
buf,
&SampleApp_TransID,
AF_DISCV_ROUTE,
// AF_ACK_REQUEST,
AF_DEFAULT_RADIUS ) == afStatus_SUCCESS ) {
}
else
{
}
}
发送数据只是调用一个函数,在这里不多做解释。
在完成以上的步骤之后就可以完成任务的添加。用户就可以实现自己的程序功能,但是由于Z_Stack已经把通信协议写好(如图4-4),所以只需要调用函数就可以完成无线传感器网络,这样只能使用却不能了解关于具体底层的信息。所以对于无线传感器网络开发来说的话,Tiny OS则是完全开放源代码的专用于无线传感器网络的操作系统。
-
Tiny OS系统在Windows环境下移植与开发
首先,就先来安装cygwin: 从cygwin.com下载一个名为setup.exe的安装程序,打开,选一选安装路径,一路点下一步就会完成安装。装完后,桌面上多出一个cygwin图标,打开即可进行cygwin的命令行,所有操作都在这个命令行中完成[18]。 cygwin默认安装的工具比较少,连gcc4,perl,python,make,rpm都没有,所以去重新打开setup.exe,在select packages页中将gcc4,perl,python,make,rpm,libmpfr4标记为安装。
现在,cygwin环境已经比较完整,接着就该配置tinyos环境了。 TinyOS环境的配置在官方文档中有很详细的描述,但是只针对cc2530的话可以将配置过程简化很多:
下载nesc和tinyos-tools的cygwin安装包,
nesc-1.3.1-1.cygwin.i386.rpm,
tinyos-tools-1.4.0-3.cygwin.i386.rpm
放到某个目录下,比如c盘根目录下。然后,在cygwin中切换到该目录,安装这两个包:
cd /cygdrive/c
rpm -ivhnesc-1.3.1-1.cygwin.i386.rpm
rpm -ivhtinyos-tools-1.4.0-3.cygwin.i386.rpm
这样tinyos环境就配置好了。接着就去下载cc2530的tinyos移植的源代码tinyv6,开发者把cc2530的tinyos移植和一个ipv6协议栈一块发布了,所以甚至可以在cc2530上用tinyos跑ipv6。
解压下载的源码包:
tar xvf tinyv6-x.x.tar.bz2
接着执行一个脚本自动设置一些环境变量:
cd tinyv6-x.x
source tinyv6.sh
-
作者:sfwang666
作品名称:基于CC2530芯片ZigBee RF4CE 技术遥控行业中的研究与应用
市场分析: 目前市场上的电子产品大部分目前采用的都是红外线遥控(IR)技术. 此技术目前弊端如下: (1) 遥控器与电器之间的距离不能过远,一般不能超过8米. (2) 遥控器使用时应对准电器的接收方向,左右偏差角度不能超过25度,否则电器无法准确接收指令. (3) 遥控器在使用时要避免强光或其它光源的干扰. (4) 遥控器与电器之间不能存在障碍物,否则红外信号会被阻挡. 所以用户无法把电器设备隐藏在其他有物体遮挡的地方,影响用户客厅美观效果. (5) 遥控器与电器之间的通讯仅为单向 (6) 不同的电器设备可能需要不同的遥控器,增加了成本,同时给使用带来极大不便. (7) 因为红外遥控码值固定,不同电器直接的码值可能相同.引起误操作. 因此有时出现用不同的遥控器操作时候,而同时也遥控到其他设备的情况发生. 以上红外遥控技术令人头疼的缺陷严重影响了数字化家居的生活品质,基于此, 通过本项目的研究,使新的Zigbee RF4CE技术应用到电子产品中.让产品的遥控操作变得更加的方便快捷,摆脱受到环境干扰与遥控角度距离的限制.让用户得到更好的操作体验. 研究目标与介绍: 本次项目研究的目的是把ZigBee RF4CE的技术推广并应用到各种家用电器设备中,以取代传统红外遥控器,提高各电器设备的易操作性,使用户有更好的操作体验,并为后续物联网做准备 1. Zigbee RF4CE遥控器技术的传输距离和抗干扰性 2. 实现电器设备与遥控器的双向通信 研究成果: 1、 本次以TI的CC2530芯片平台为基础进行研究开发。 2、 RF射频遥控采用CC2530芯片来完成RF4CE 的无线遥控功能要求. 3、 RF无线射频遥控能提高操作的可靠性;提高信号的传输距离和抗干扰性;使信号传递不受障碍物影响; 消费者将不再需要用遥控器的发射端准确指向电器的接收端.RF遥控距离无障碍物可以达到50米,有障碍物可以达到30米. 4、 RF无线遥控器节能省电, 遥控器电池寿命也可显著延长(1~2年)。,也不再需要数个遥控器来操作家中不同的电子设备 RF4CE RF无线遥控的信号工作频段示意图以及基本指标参数如下: |