zigbee组网过程浅析
zigbee协议栈使用的是zstack版本，该协议栈的整体功能有点类似于操作系统。下面以SimpleApp例程为例，对协议栈的组网流程进行描述。
协议栈是用C语言实现的，由于C语言的入口都是main函数，因此需要找到main函数，下图为协议栈各层列表（主要包括应用层、硬件层、MAC层、网络层、安全层、服务层等），TI公司的编程比较规范，文件的命名就意味着相关的功能。
图1 协议栈的整体架构
可以看到，ZMain文件下面有ZMain.c文件，而该文件就是整个协议栈的入口地址。打开ZMain.c文件，可以看到函数intmain( void )；该函数就是整个协议栈最开始的入口。在main函数里面可以看到语句：
// Initialize the operating system
osal_init_system();
该语句的实际含义是初始化zigbee协议栈。
进入函数osal_init_system()的内部(具体方法：使鼠标停留在osal_init_system上，并且单击右键，在弹出的选项中选择“go todefinition of osal_init_system”)，定位到下列语句：
// Initialize the system tasks.
osalInitTasks();
从这个函数的名字就可以知道它是用于初始化系统任务的。在zigbee协议栈中，一个非常重要而且贯穿协议栈生命周期的概念就是任务，也就是说协议栈的信息处理和数据传输等过程都是通过任务来实现的，即如果某个节点需要传输一个数据包，它会通过调用相关任务通知操作系统需要发送数据包。
既然任务是个非常重要的概念，那么就很有必要进入到osalInitTasks()函数内部，看看这个函数究竟是初始化那些任务！！
类似，点击右键进入osalInitTasks函数内部，下面是该函数的内容：
voidosalInitTasks( void )
uint8 taskID = 0;
tasksEvents = (uint16 *)osal_mem_alloc(sizeof( uint16 ) * tasksCnt);
osal_memset( tasksEvents, 0, (sizeof( uint16) * tasksCnt));
macTaskInit( taskID++ );
nwk_init( taskID++ );
Hal_Init( taskID++ );
#ifdefined( MT_TASK )
MT_TaskInit( taskID++ );
APS_Init( taskID++ );
ZDApp_Init( taskID++ );
SAPI_Init( taskID );
函数内部表明，函数执行了协议栈各层的初始化操作，包括mac层、网络层、硬件层等各层初始化。这里看到了此语句：ZDApp_Init(taskID++ );该语句的作用是初始化zigbee设备对象（ZDO），那zigbee设备对象是用来干什么的呢？为什么要对它进行初始化呢？
一句话，应用层可以通过ZigBee设备对象(ZDO)对网络层参数进行配置和访问。也就是说ZDO会对要组建的zigbee网络进行各种配置。
那ZDApp_Init()内部又是怎么实现的呢？同理进入到ZDApp_Init()内部，可以看到ZDApp_Init()就是对网络的各种初始化配置，定位到下列语句：
if ( devState != DEV_HOLD )//在本人的zstack上devState不是DEV_HOLD
ZDOInitDevice( 0 );
所以就执行了语句：ZDOInitDevice(0 )；该函数是什么作用呢？？它是负责启动网络。在函数ZDOInitDevice()内，定位到下列语句：
// Trigger the network start
ZDApp_NetworkInit( extendedDelay );
到这里就设置了定时触发启动网络了；
而ZDApp_NetworkInit()函数内部是怎么样出发网络启动的呢？？
右键点击ZDApp_NetworkInit()，进入到ZDApp_NetworkInit()内部，它的函数体如下：
voidZDApp_NetworkInit( uint16 delay )
if ( delay )
// Wait awhile before starting the device
osal_start_timerEx( ZDAppTaskID,ZDO_NETWORK_INIT, delay );
osal_set_event( ZDAppTaskID,ZDO_NETWORK_INIT );
在ZDApp_NetworkInit()内部有个if-else选择分支，if分支是经过一段时间后，再添加网络初始化任务，而else分支则是直接执行网络初始化任务，即else分支是直接执行语句osal_set_event(ZDAppTaskID, ZDO_NETWORK_INIT)，而if分支经过一个延时后，再执行osal_set_event(ZDAppTaskID, ZDO_NETWORK_INIT)语句。说到底，ZDApp_NetworkInit()的内部就是执行语句：osal_set_event(ZDAppTaskID,
ZDO_NETWORK_INIT)，即触发zigbee网络初始化，而且传送过来的参数是ZDO_NETWORK_INIT。
协议栈触发了网络初始化任务的事件后，是不是需要有个函数来执行这个任务呢？？答案是肯定的，协议栈会自动调用zigbee专门的事件处理函数：ZDApp_event_loop(uint8 task_id, UINT16 events)，该函数的功能就是处理各种事件。进入ZDApp_event_loop()函数的内部，发现该函数实际上是多个if分支构成，我们把osal_set_event()函数传递过来的参数ZDO_NETWORK_INIT和ZDApp_event_loop()函数的if分支进行匹配，发现下列的if分支：
if( events & ZDO_NETWORK_INIT )
// Initialize apps and start the network
devState = DEV_INIT;
ZDO_StartDevice((uint8)ZDO_Config_Node_Descriptor.LogicalType, devStartMode,EFAULT_BEACON_ORDER, EFAULT_SUPERFRAME_ORDER );
// Return unprocessed events
return (events ^ ZDO_NETWORK_INIT);
即存在着网络事件初始化的if分支，具体是怎么样初始化的呢？此外由于zigbee网络存在路由器节点、协调器节点和终端节点等各种类型节点，网络初始化会不会针对不同类型节点有不同的配置呢？？
答案也是肯定的。首先，下面的语句就是网络初始化的具体入口：
ZDO_StartDevice((uint8)ZDO_Config_Node_Descriptor.LogicalType, devStartMode,EFAULT_BEACON_ORDER, EFAULT_SUPERFRAME_ORDER );
而且可以看到，ZDO_StartDevice中的确是根据不同节点的类型，其配置有所不同(ZDO_Config_Node_Descriptor.LogicalType，类型节点)。进入ZDO_StartDevice()函数的内部（方法类似，鼠标右击该函数，点击go todefinition of ZDO_StartDevice）。可以看到ZDO_StartDevice()也是一系列的if分支。
在zigbee网络建网过程中，首先启动的一定是协调器节点，因为只有此种节点才能创建和配置网络，其他的节点只能加入网络，而不能创建网络。
所以，这里首先介绍协调器创建网络过程。下列的if分支是coordinator组网代码：
if(ZG_BUILD_COORDINATOR_TYPE&&
logicalType==NODETYPE_COORDINATOR )
//我们这里的startMode是MODE_HARD，
if ( startMode == MODE_HARD )
//所以程序执行此分支
devState = DEV_COORD_STARTING;
ret = NLME_NetworkFormationRequest(zgConfigPANID, zgApsUseExtendedPANID, zgDefaultChannelList, zgDefaultStartingScanDuration,beaconOrder, superframeOrder, false );
else if ( startMode == MODE_RESUME )
// Just start the coordinator
devState = DEV_COORD_STARTING;
ret = NLME_StartRouterRequest(beaconOrder, beaconOrder, false );
#ifdefined( LCD_SUPPORTED )
HalLcdWriteScreen( "StartDeviceERR", "MODE unknown" );
在协调器的创建网络和配置网络过程中，下列语句是zigbee的原语：
ret = NLME_NetworkFormationRequest(zgConfigPANID, zgApsUseExtendedPANID, zgDefaultChannelList, zgDefaultStartingScanDuration,beaconOrder, superframeOrder, false );
何为原语？说白了也是个函数，只是处理过程不开源，简单点说，就是gap这边有个请求（信息处理命令），zigbee协议栈内部将请求原语传递到gap那边进行处理，并反馈结果，而这个过程是不开源的。
图2 原语请求与反馈
也就是说协调器节点想协议栈内部发出了组建网络的请求原语（NLME_NetworkFormationRequest），那协议栈的回复原语是什么呢？zigbee的回复原语是ZDO_NetworkFormationConfirmCB(ZStatus_t Status )，进入到函数ZDO_NetworkFormationConfirmCB的内部，可以知道，如果协议栈同意协调器节点建网并且网络建立成功，则会点亮LED灯，同时函数最后还会触发事件：osal_set_event(ZDAppTaskID, ZDO_NETWORK_START
相信大家对函数osal_set_event()都不会陌生了，协议栈对osal_set_event()是怎么处理的呢？协议栈是调用函数ZDApp_event_loop(uint8 task_id, UINT16 events )对函数进行处理的，同样进入ZDApp_event_loop的内部看看，这次又是怎么操作的呢？这次传递过来的实参是ZDO_NETWORK_START。
在下列分支找到了参数为ZDO_NETWORK_START的分支：
if ( ZSTACK_ROUTER_BUILD )
if ( events & ZDO_NETWORK_START )
ZDApp_NetworkStartEvt();
// Return unprocessed events
return (events ^ ZDO_NETWORK_START);
if ( events & ZDO_ROUTER_START )
if ( nwkStatus == ZSuccess )
if ( devState == DEV_END_DEVICE )
devState = DEV_ROUTER;
osal_pwrmgr_device( PWRMGR_ALWAYS_ON );
// remain as end device!!
osal_set_event( ZDAppTaskID,ZDO_STATE_CHANGE_EVT );
//Return unprocessed events
return (events ^ ZDO_ROUTER_START);
首先简单解释下ZSTACK_ROUTER_BUILD，选择go todefinition of ZSTACK_ROUTER_BUILD，就会发现它实际上是一串的宏定义判断：
#if ( ZG_BUILD_RTR_TYPE )
#if ( ZG_BUILD_ENDDEVICE_TYPE )
#define ZSTACK_ROUTER_BUILD
(ZG_BUILD_RTR_TYPE &&ZG_DEVICE_RTR_TYPE)
#define ZSTACK_ROUTER_BUILD
#define ZSTACK_ROUTER_BUILD
由于现在启动的是协调器节点，所以ZG_BUILD_RTR_TYPE为真（验证方法：go todefinition of ZG_BUILD_RTR_TYPE），而ZG_BUILD_ENDDEVICE_TYPE为假，自然而然，程序就执行了宏定义 #define ZSTACK_ROUTER_BUILD
1，因此就得到了ZSTACK_ROUTER_BUILD为真的信息。同时由于上面传递过来的参数是ZDO_ROUTER_START，因此，程序很自然的就执行语句：ZDApp_NetworkStartEvt();
同样进入到函数ZDApp_NetworkStartEvt()内部，如果网络启动成功的话，在函数ZDApp_NetworkStartEvt()内部执行下列分支：
if ( nwkStatus == ZSuccess )
// Successfully started a ZigBee network
if ( devState == DEV_COORD_STARTING )
devState = DEV_ZB_COORD;
osal_pwrmgr_device( PWRMGR_ALWAYS_ON );
osal_set_event( ZDAppTaskID,ZDO_STATE_CHANGE_EVT );
这里网络启动后，触发了ZDO设备状态改变的事件，osal_set_event(ZDAppTaskID, ZDO_STATE_CHANGE_EVT );同样，跳转到函数内部ZDApp_event_loop()内部看看，此时发现与ZDO_STATE_CHANGE_EVT 相对应的if分支执行函数ZDO_UpdateNwkStatus(devState );即更新网络状态信息。
函数ZDO_UpdateNwkStatus()内部是如何更新网络信息的呢？同样进入ZDO_UpdateNwkStatus()内部，发现协议栈在配置了网络短地址等相关信息后，会发送网络状态更新信息到每一个注册的端点号（端点号类似应用端口），发送信息的函数为：osal_msg_send(*(epDesc-&epDesc-&task_id), (uint8 *)msgPtr )。
协议栈收到该信息后怎么处理呢？协议栈会调用函数MT_ProcessIncomingCommand()来处理相关信息，到这里为止，协调器节点基本上就已经创建和配置好了一个无线网络。
在介绍了协调器组建zigbee无线网络的过程后，紧接着介绍下路由节点和终端节点加入网络的过程。
由于终端节点和路由节点加入网络过程中，都是从main函数为入口，再继续执行。和协调器节点创建网络，启动协议栈的过程部分有重复，为了简单起见，协议栈启动初期的部分重复内部就不再赘述。图4中的第(1)步到第(8)步为路由器节点、终端节点和协调器节点都需要组网（入网）经过的步骤，所以就略过描述了。
图 3协调器、路由器和终端节点相同执行部分
我们直接从第(8)步开始讲述路由器节点和终端节点入网的执行过程。即执行到：ZDO_StartDevice((uint8)ZDO_Config_Node_Descriptor.LogicalType,devStartMode,DEFAULT_BEACON_ORDER,DEFAULT_SUPERFRAME_ORDER)，进入函数内部，找到适合于类型是终端节点或路由节点的分支，如下：
if ( ZG_BUILD_JOINING_TYPE &&(logicalType == NODETYPE_ROUTER || logicalType == NODETYPE_DEVICE) )
我们已经对MANAGED_SCAN进行了宏定义，因此对终端节点和路由节点if分支内部执行如下分支，该分支的功能是发现网络：
#if defined( MANAGED_SCAN )
ZDOManagedScan_Next();
ret = NLME_NetworkDiscoveryRequest(managedScanChannelMask, BEACON_ORDER_15_MSEC );
同样，zigbee对于发现网络原语的请求，也是采用原语进行回应的；回应的原语如下：ZStatus_tZDO_NetworkDiscoveryConfirmCB( uint8 ResultCount,networkDesc_t *NetworkList )，进入函数ZDO_NetworkDiscoveryConfirmCB的内部，定位到最后一句话，也就是：
ZDApp_SendMsg( ZDAppTaskID, ZDO_NWK_DISC_CNF,sizeof(ZDO_NetworkDiscoveryCfm_t), (uint8 *)&msg );这里记住发送的参数是ZDO_NWK_DISC_CNF。
对于ZDApp_SendMsg()函数发送信息之后，
协议栈利用ZDApp_ProcessOSALMsg()进行处理的；具体ZDApp_ProcessOSALMsg()内部如何处理的呢？同样，进入到该函数的内部，发现函数ZDApp_ProcessOSALMsg()主要是switch选择语句，由于前面发送过来的参数是ZDO_NWK_DISC_CNF，因此在ZDApp_ProcessOSALMsg()找到相对于的case分支，由于这里是节点加入网络的过程，所以case分支内部会执行分支if (devStartMode == MODE_JOIN)，程序继续往下执行，最后会执行到下面分支，
if (NLME_JoinRequest( ((ZDO_NetworkDiscoveryCfm_t *)msgPtr)-&extendedPANID,BUILD_UINT16(((ZDO_NetworkDiscoveryCfm_t *)msgPtr)-&panIdLSB, ((ZDO_NetworkDiscoveryCfm_t*)msgPtr)-&panIdMSB ), ((ZDO_NetworkDiscoveryCfm_t*)msgPtr)-&logicalChannel,
ZDO_Config_Node_Descriptor.CapabilityFlags ) !=ZSuccess )
可以看到，这里是一个节点申请加入网络的原语，对于此原语的回应，协议栈会自动调用voidZDO_JoinConfirmCB( uint16 PanId, ZStatus_t Status)原语进行回复。
同样，在回复原语ZDO_JoinConfirmCB()中，也存在着发送加入网络信息的语句：ZDApp_SendMsg(ZDAppTaskID, ZDO_NWK_JOIN_IND, sizeof(osal_event_hdr_t), (byte*)NULL );这里记住发送的参数是ZDO_NWK_JOIN_IND，后面的ZDApp_ProcessOSALMsg()会用到；
而对于该语句的回复，协议栈同样是调用语句ZDApp_ProcessOSALMsg()进行回复，由于ZDApp_ProcessOSALMsg()内部执行的是switch语句，所以找到ZDO_NWK_JOIN_IND相对应的case分支，如下：
caseZDO_NWK_JOIN_IND:
if (ZG_BUILD_JOINING_TYPE &&ZG_DEVICE_JOINING_TYPE )
ZDApp_ProcessNetworkJoin();
很自然地，协议栈会执行了函数ZDApp_ProcessNetworkJoin();这个函数是处理节点入网的过程。
这里对于路由器节点和终端节点，协议栈执行的方法各有不同；
首先介绍下对于路由节点，协议栈是如何应对函数ZDApp_ProcessNetworkJoin()的呢？
对于路由节点，协议栈调用voidZDApp_ProcessOSALMsg( osal_event_hdr_t *msgPtr )来回复ZDApp_ProcessNetworkJoin()函数。
前面已经分析过了ZDApp_ProcessOSALMsg()函数内部执行的是swtich选择分支，而且对于路由节点而言，该switch选择分支执行是建立路由器节点的相关分支，因此定位到分支if (ZSTACK_ROUTER_BUILD )，如下：
if ( ZSTACK_ROUTER_BUILD )
// 节点类型不是终端节点
if (ZDO_Config_Node_Descriptor.LogicalType!= NODETYPE_DEVICE )
NLME_StartRouterRequest( 0, 0, false);
所以程序很自然的执行了建立路由器请求原语：NLME_StartRouterRequest(0, 0, false );而zigbee协议栈对该路由请求原语，自动调用函数ZDO_StartRouterConfirmCB( ZStatus_t Status )进行回复。
在函数ZDO_StartRouterConfirmCB()内部，又触发了设置任务事件的语句：
osal_set_event( ZDAppTaskID,ZDO_ROUTER_START );
而对于该语句，协议栈会调用函数ZDApp_event_loop()进行回复。进入函数ZDApp_event_loop()内部找到相应于ZDO_ROUTER_START的if分支，如下：
if ( events &ZDO_ROUTER_START )
if ( nwkStatus == ZSuccess )
if ( devState == DEV_END_DEVICE )
devState = DEV_ROUTER;
osal_pwrmgr_device( PWRMGR_ALWAYS_ON );
// remain as end device!!
osal_set_event( ZDAppTaskID,ZDO_STATE_CHANGE_EVT );
// Return unprocessed events
return (events ^ ZDO_ROUTER_START);
到这里为止，路由器就加入网络并成功启动了！！
对于终端节点，协议栈是如何应对函数ZDApp_ProcessNetworkJoin()的呢？
进入到ZDApp_ProcessNetworkJoin()函数内部，定位到下列if分支：if( nwkStatus == ZSuccess )，此if分支的含义是：如果终端节点企图加入节点成功，则执行此分支。此分支内部有语句：osal_set_event(ZDAppTaskID,
ZDO_STATE_CHANGE_EVT )；这里是网络状态更新事件。同样，对于该语句，协议栈自动调用函数ZDApp_event_loop()进行处理。进入到函数内部，找到相对于ZDO_STATE_CHANGE_EVT的if分支。该if分支内部执行了函数ZDO_UpdateNwkStatus(devState )，即更新网络状态函数，此函数内部有语句：osal_msg_send(*(epDesc-&epDesc-&task_id), (uint8 *)msgPtr )，协议栈是如何处理该语句的呢？
协议栈是自动调用函数MT_ProcessIncomingCommand(mtOSALSerialData_t *msg )，而该函数内部执行的是一个switch选择结构，找到分支：caseZDO_STATE_CHANGE，则是内部执行了函数: MT_ZdoStateChangeCB((osal_event_hdr_t*)msg);
到这里，终端节点加入网络的过程也就介绍完了！关于协调器建网、路由器节点和终端节点入网的过程也就全部介绍完了！
没有更多推荐了，(window.slotbydup=window.slotbydup || []).push({
id: '2014386',
container: s,
size: '234,60',
display: 'inlay-fix'
&&|&&0次下载&&|&&总41页&&|
您的计算机尚未安装Flash，点击安装&
阅读已结束，如需下载到电脑，请使用积分（）
下载：20积分
相关分类推荐
0人评价7页
0人评价4页
0人评价2页
0人评价3页
0人评价1页
所需积分：（友情提示：大部分文档均可免费预览！下载之前请务必先预览阅读，以免误下载造成积分浪费！）
（多个标签用逗号分隔）
文不对题，内容与标题介绍不符
广告内容或内容过于简单
文档乱码或无法正常显示
文档内容侵权
已存在相同文档
不属于经济管理类文档
源文档损坏或加密
若此文档涉嫌侵害了您的权利，请参照说明。
我要评价：
价格：20积分VIP价：Zigbee组建一个完整的网络包含两个步骤：网络初始化和节点加入网络。其中，节点加入网络可以分为通过协调器直接连接入网和通过已有父节点入网。下面来依次说明。 1. 网络初始化 ZigBee网络初始化只能是由网络协调器发起的，在组建网络前，需要判断本节点还没与其他网络连接。如果节点已经与其他网络连接时，此节点只能作为该网络的子节点。一个ZigBee网络中有且仅有一个ZigBee协调器，一旦网络建立好了，协调器就退化成路由器的角色，甚至是可以去掉协调器的，这一切得益于ZigBee网络的分布式特性。
网络初始化流程图如下：
每层详细解释： 1 .& 协调器通过主动扫描，发送信标请求命令(Beacon request command)，设置一个扫描期限(T_scan_duration)，如果在期限内没检测到回应信标，则认为在其范围内没有其他协调器，那么此时可以建立自己的ZigBee网络，并且作为网络的协调器。非信标网络的设备会等待请求，信标网络的设备会周期性的产生信标并且广播出去。 2.
&&&&& 2.1 能量扫描&&&&&&&&&& 对指定信道或者默认信道进行能量检测，以避免可能的干扰，以递增的方式对所检测的信道能量值进行排序，抛弃那些能量值超出范围的信道。选择一系列可用信道。
&&&&&& 2.2主动扫描&&&&&&&&&&& 接着通过主动扫描的方式，获取节点通讯半径内的网络信息，然后根据这些信息，找一个最好的、相对安静的信道。最后选择的信道应该是存在最少的ZigBee网络，最好是没有ZigBee网络。 3.&& 在所选定的信道上，网络ID(PAN ID)必须是唯一的，不能和其他ZigBee网络冲突，不能为广播地址(0xFFFF)。可以使用设定的PAN ID，也可以通过监听其他网络的ID来随机选择一个不会冲突的ID号.当路由节点或者设备入网时，协调器会给节点分配短地址来通讯。对于协调器来说，网络地址始终为0x0000 &
2.ZigBee入网流程 ZigBee设备的入网流程，详见下图：
每层详细解释4 节点入网将选择范围内信号最强的父节点加入网络，成功加入后，会得到一个网络短地址，并通过这个地址进行数据的收发。网络拓扑关系和地址会保存在各自的flash中。
选择一个合适的ID后，设备的上层会请求MAC层对物理层和MAC层的phyCurrentChannel、macPANID等PIB属性进行相应的设置。 &
3.ZigBee分离流程 详见下图：
阅读(...) 评论()Zigbee技术组网特点
查看: 2159|
摘要: 　　ZigBee的特点主要有以下八个方面：　　1.低功耗：在低耗电待机模式下，2节5号干电池可支持1个节点工作6-24个月，甚至更长。这是ZigBee的突出优势。相比之下蓝牙可以工作数周、WiFi可以工作数小时；　　2.低成本 ...
　　ZigBee的特点主要有以下八个方面：　　1.低功耗：在低耗电待机模式下，2节5号干电池可支持1个节点工作6-24个月，甚至更长。这是ZigBee的突出优势。相比之下蓝牙可以工作数周、WiFi可以工作数小时；　　2.低成本：通过大幅简化协议降低成本（不足蓝牙的1/10），也降低了对通信控制器的要求，按预测分析，以8051的8位微控制器测算，全功能的主节点需要32KB代码，子功能节点少至4KB代码，而且ZigBee的协议专利免费；　　3.低速率：ZigBee工作在250kbps的通讯速率，满足低速率传输数据的应用需求；　　4.近距离：传输范围一般介于10～100m之间，在增加RF发射功率后，亦可增加到1-3km，这指的是相邻节点间的距离。如果通过路由和节点间通信的接力，传输距离将可以更远；　　5.短时延：ZigBee的响应速度较快，一般从睡眠转入工作状态只需15ms，节点连接进入网络只需30ms，进一步节省了电能。相比较，蓝牙需要3-10s、WiFi需要3s；　　6.高容量：ZigBee可采用星状、片状和网状网络结构，由一个主节点管理若干子节点，最多一个主节点可管理254个子节点；同时主节点还可由上一层网络节点管理，最多可组成65000个节点的大网；　　　　7.高安全：ZigBee提供了三级安全模式，包括无安全设定、使用接入控制清单(ACL)防止非法获取数据以及采用高级加密标准(AES128)的对称密码，以灵活确定其安全属性；　　（8）免执照频段：采用直接序列扩频在工业科学医疗2.4GHz(全球)频段。
上一篇：下一篇：
看过《Zigbee技术组网特点》的人还看了以下文章:
Powered by &
这里是—这里可以学习 —这里是。
栏目导航：如果433M能自组网了，那zigbee还有什么优势==www.ic37.com
热门型号：
&&&当前位置：
如果433M能自组网了，那zigbee还有什么优势
用户名：xnwxq
注册时间： 22:18:00
如果433M能自组网了，那zigbee还有什么优势
是无线数据传输的革命性技术，这是毋庸置疑的。正像你所说，zigbee的优势之一是自组网，但是否zigbee就会成为无线传输的最佳方案，这还要针对具体的应用来说。
从工程上来讲，zigbee的出发点应该是短距离、低数据量的应用。也就是说，在距离不是特别远，通信数据量不是特别大的场合，zigbee是适用的。但也有例外，与载波频率有关，后面我再详细说明。
一、频率与速率
关注zigbee的工程技术人员都清楚zigbee工作在，频率高速率就高，因此2.4G频点理论的数据通信速率较高，但是增加了自组网功能后，zigbee需要花很大精力去做路由查询，路由查询的复杂成都取决于节点数量，随着节点数量增加，路由查询复杂度迅速上升。如果各节点通信数据量大，整体的通信效果就要打折，至少给用户的感觉是不方便的。这是限制zigbee的瓶颈之一，但不是最主要的限制。
二、2.4G通信特性
无线电波传输特性是zigbee无法跨越的鸿沟。2.4G的电波在传输过程中损耗小，但绕射能力差，穿透能力差，有较强的方向性要求。也就是说，在人眼能够看到的范围2.4G传输有优势，但如果障碍物能阻挡视线，很可能也会阻挡2.4G的电波。我个人认为这是zigbee技术最大的掣肘。
三、技术复杂度
zigbee是结合了多种复杂应用于一体的技术结晶，设计zigbee协议的工程技术人员考虑到了zigbee的很多具体应用，如果应用合适，zigbee可以高效地解决技术问题。也正因为涵盖内容多，消化zigbee协议也需要设计人员投入较大的精力。而很多应用并不需要zigbee复杂的协议，因此其他的技术仍然有很大的发展空间。
四、某些场合比zigbee更高效的无线通信技术。
a)433M智能组网技术
我们发展433M智能组网技术已经有好多年了，开始发展这项技术时国内还没有提zigbee的概念，出发点是解决几公里区域内移动点的通信问题。技术成熟后，又在与客户合作过程中逐步改进，最终发展成适用于2公里内移动点通信和500米内障碍物现场通信的智能组网技术。这两种应用都是使用zigbee技术难于完成的。而我们可以通过主动设置路由，非常出色地完成任务。
我们发展这项技术还真的不是为了对抗zigbee技术，有点儿“无心插柳柳成荫”的味道。b)2.4G数传技术zigbee概念在国内提出后，我们也进行了技术分析和行业应用的调查，前面的三点就是分析和调查的梗概。基于上面的判断，我们推出了简单协议的2.4G无线通信技术和产品，通过UART口进行数据通信。我相信还有很多致力于无线通信的技术团队也有2.4G的技术和产品。我们的产品保留了zigbee的损耗小，距离远，速率高的技术特点，绕开了较复杂的组网协议，简化了技术体制。
我要再次重申，我们发展的433M智能组网通信技术和2.4G数传技术，完全是从实践出发，只想把我们关注的应用场合做好，而不是要与zigbee技术一较高下。我撰写本文也不是要质疑zigbee的实用性。
以上的内容只是我个人对于无线通信技术的一些浅见，欢迎朋友们与我进行探讨。
用户名：PowerAnts
注册时间： 10:08:00
433M是窄带业务, 通讯速率很低
用户名：chunyang
注册时间： 15:27:00
Zigbee的本质优势是标准化，这样不同厂家的产品可以实现兼容，但在其成本下降到与自有协议相当之前，这个优势的体现就不明显。
用户名：ZigBee笔记
注册时间： 23:52:00
这是标准化与非标准化的区别，在433M开发适合自己的智能网络，也并非难事，根据需要而定，只能说各有特点
用户名：netjob
注册时间： 0:22:00
说些什么呢？楼主~
什么蛛网不组网的。 用的着吗? 蜂窝电话网络吗？ 路由？
对我们电工，能实行通信就基本OK了，一个主站，256个子站，
CC1100 无线又不能多个子站同时通信的。这样会频道干扰和占用～。
以前用红外，串口、RS485,CAN 现在用无线（也就几十米到200米的范围），就这么简单～。
局域网和手机模块仍然没有什么能取代。
用户名：xiehaitang
注册时间： 10:51:00
主要是想用什么工作方式和协议，无线自动组网协议是目前最前沿的技术，要看工作产品的工作模式，从而设计合适的通信工作协议。有机会可以多交流下。QQ：
用户名：annaxs
注册时间： 9:55:00
Zigbee确实没有什么实用性。自己做个简单的协议组网来的更实际！！！
用户名：上海逻迅
注册时间： 13:03:00
正解。zigbee参考价值大于实际应用价值
用户名：china_fog
注册时间： 9:52:00
物联网目前还基本停留在炒作阶段。这个需要各行各业的相互融合才能达到最终理想的状态，当然，我们有理由相信技术正在朝此方向发展
用户名：whicun
注册时间： 23:06:00
就现在zigbee实现来看，2.4G频速率达到250Kbps，多少长几个频点速率都要比这个速率低成多。
用户名：空外之旅
注册时间： 17:14:00
呵呵，目前zigbee还是有很多产品了
用户名：freemann
注册时间： 15:41:00
433还不能达到Zigbee的组网效果, 因为没有理想的硬件支持
用户名：AD9851
注册时间： 18:42:00
Zigbee和WIFI是两个应用目标不一样的标准平台
WIFI针对高速、高性能、短距离应用；
Zigbee针对低速、低功耗、短距离应用；
两者有着互补的关系，不能说谁劣谁优，前景都很被看好。
用户名：AD9851
注册时间： 22:33:00
真没有用过，一个也没有用过。对他们只是有点点了解。
我只见过以前公司同事他们做微波接力机，就是那种带有路由 自组网的功能，主要用作战术多路通信、野战地域通信网、战略通信网的干线传输信道以及特殊紧急通信等。比如汶川地震后，大面积通信中断了，可以按要求定点空投若干个接力机，然后各接力机自动搜寻链接到他相邻的接力机，自动建立路由表，组成一个临时的通信网络。当其中某个或某些接力机出了故障，工作中的接力机可以重新路由新的路径，保持通信畅通。
zigbee也有类似的功能，zigbee可能相对简单些。
用户名：SmartEnergy
注册时间： 23:05:00
请教一下，433MHz用可以PCB天线吗？
用户名：AD9851
注册时间： 0:06:00
433Mhz是完全可以使用PCB天线的。
用户名：AD9851
注册时间： 0:09:00
不知道为什么sinanjj一定要以实时性能来评定一种网络的性能呢，对于分组（包）交换的网络来说是没有真正的实时性的。就好像你非要以飞行性能评定汽车的性能一样。当然要设计这样的汽车也是可以的，但这样去评定当前市场上的汽车是不合适的。
你所看好的WIFI同样也是非实时的，只不过他速度更高，延时相对短而已。
用户名：AD9851
注册时间： 0:12:00
我说的接力机频率不方便透露，但肯定不是2.4G，具体频率是军方秘密
用户名：AD9851
注册时间： 13:03:00
真不想和你争这无谓的问题！
zigbee是有延时的，wifi也是有延时的，虽然大多数情况下zigbee的延时比wifi长，但我早说过了他们是针对不同的应用，只要他能满足某些设计应用他就是成功的。就好比我们对传输速度的要求，有人可能觉得100M网、1000M网速度都不够，但有些人有些应用就用9600b的串口都绰绰有余了。所以你不能一概而论，一棒打死！
基于分组交换的网络的延时具有不可预测性和不规律性，在网络拥塞时候（如洪水攻击）延时可能无限长（就是丢包）。你觉得WIFI延时很短实际上只是你在没有网络拥塞情况下得出的片面结论而已。WIFI延时有可能比3s比10s长得多。
用户名：SmartEnergy
注册时间： 17:35:00
30# AD9851 讨论的这个问题，应该是隐含了带宽不成瓶颈的条件吧。
用户名：AD9851
注册时间： 20:29:00
市场需求是多样性的，10G骨干网有用、100M以太网有用、1M的蓝牙也有用、串口的应用也很广泛，市场就这么简单！
热门型号：