1，TI的ZigBee協議棧不同版本的區別，如何選擇合適的協議棧進行產品開發

TI ZigBee 協議棧Z-Stack從最開始的Z-Stack 0.1到大家熟悉的Z-Stack 2.5.1a，以及到現在Z-Stack Home 1.2.1, Z-Stack Lghting 1.0.2, Z-Stack Energy 1.0.1, Z-Stack Mesh 1.0.0. 在協議棧的升級過程TI主要對協議棧做了兩方面的工作，1) 根據ZigBee Alliance的ZigBee Specification進行一些新的Feature添加，比方說ZigBee2007是樹形的路由，在ZigBee Pro中有了Mesh路由，并且提出了MTO和Source Routing等路由算法，所以TI的把相應新的功能添加到協議棧上去。當然有一部分是Spec中相關bug的修正，比方說有些描述模棱兩可的；2) TI ZigBee協議棧本身軟件bug的修復。一個版本的協議棧相對于之前一個版本協議棧的區別，都可以在協議棧安裝目錄下的Release Note中找到。

在Z-Stack 2.5.1a以后，TI的協議棧并沒有繼續以Z-Stack 2.6.x的形式直接發布，而是按照Application Profile的方式來發布了，原因在于TI希望開發者根據實際的應用選擇更有針對的性的協議棧進行開發。像Z-Stack Home 1.2.1之類的協議棧，主要包括兩部分，1）核心協議棧Core Stack，這部分起始就是之前的Z-Stack 2.5.1a以后的延續版本，可以在協議棧安裝目錄下 Z-Stack Core Release Notes.txt文件中找到，Version 2.6.2 。2）應用協議棧 Profile相關，這部分主要跟實際應用相關的，Home Automation 協議棧里都是ZigBee Home Automation Profile相關的實現。同樣Z-Stack Lghting 1.0.2和Z-Stack Energy 1.0.1也是一個Core Stack再加上應用上的Profile。1)Z-Stack Home 1.2.2a 針對智能家居相關產品的開發。2)Z-Stack Lighting 1.0.2 針對ZLL相關產品的開發。3)Z-Stack Energy 1.0.1 針對智能能源，Meter, In Home Display, 等相關產品的開發。4)Z-Stack Mesh 1.0.0 針對相關私有應用的產品的開發，只利用標準ZigBee協議相關功能, Mesh路由等，應用層有開發者自己定義。

在ZigBee聯盟發布ZigBee 3.0協議以后，最新的ZigBee協議棧是Z-Stack 3.0, 目前支持的設備有CC2530, CC2538, CC2652R。

2，產品如何進行標準ZigBee測試認證，需要了解哪些，需要走什么流程

以開發標準ZigBee Home Automation相關產品為例。首先開發者開發產品時要按照ZigBee Home Automation Profile Specification 中描述的產品進行開發，這個文檔可以在www.zigbee.org下載到。在完成產品的開發后，開發著需要了解ZigBee Home Automation Profile Test Specification, 這個文檔描述了一個特定產品需要在Test House過的相關測試項，文檔也可以在www.zigbee.org下載到，另外除了以上兩個文檔以外還有一個PICS文檔，這個文檔專門用于描述需要過認證測試產品所支持的功能，開發者根據開發產品的實際紅能，和Specification中所要求的功能，在文檔中進行打鉤確認。下面是測試的流程，

1) 首先加入ZigBee聯盟，一般可以有測試實驗室幫助完成。

2) 寄送樣品到測試實驗室，完成PICS文檔的填寫。
3) 第一輪預測試，測試實驗室對測試結果反饋，開發者修改樣品代碼。
4) 測試實驗室對修改后的樣品進行驗證，然后開始正式測試。
5) 測試實驗室協助開發者完成ZigBee聯盟網上認證申請資料的準備和提交。
6) 測試實驗室提交正式測試報告給ZigBee聯盟。聯盟會完成審核并發證

目前國內可以完成標準ZigBee測試的測試實驗室有兩家

1) CESI 北京 中國標準化電子研究所。

2) Element 深圳辦事處(總部在英國)

詳細可以參考下面的wiki地址，

http://processors.wiki.ti.com/index.php/ZigBee_Product_Certification_Guide

3，設備的64位 MAC地址是怎么樣選取的？

在CC2530/CC2538/CC2630中分為兩個IEEE地址，一個稱為Primary IEEE地址，另外稱為Secondary地址。Primary IEEE地址是存放在芯片的Information Page里面，這個地址是TI向IEEE協會購買的，每個芯片的地址都是唯一的。并且用戶只能Read這個值，沒辦法擦除/修改。在協議棧中直接通過讀地址可以獲得 osal_memcpy(aExtendedAddress, (uint8 *)(P_INFOPAGE+HAL_INFOP_IEEE_OSET), Z_EXTADDR_LEN)。Secondary地址是存放在CC2530里的Flash最后一個Page里面，用戶可以進行Read/Write. 通過函數HalFlashRead(HAL_FLASH_IEEE_PAGE, HAL_FLASH_IEEE_OSET, aExtendedAddress, Z_EXTADDR_LEN);。

協議棧運行是，是如何選擇Primary IEEE地址或者Secondary地址作為設備的MAC地址的，具體在函數zmain_ext_addr(void)操作。

1) 從NV中讀取 IEEE地址，如果已經存在(都不為0xFF)，就使用該地址作為MAC地址了。

2) 如果1)中沒有，從Secondary IEEE地址存放位置讀取，如果有(都不為0xFF)，把該地址寫入到NV中，以后就用該地址作為MAC地址了。

3) 如果2)中沒有，從Primary IEEE地址存放位置讀取，如果有(都不為0xFF)，把該地址寫入到NV中，以后就用該地址作為MAC地址了

4) 如果3)中沒有，就隨機產生一個64位的變量，寫入到NV中，并作為MAC地址。

4，End Device是低功耗設備, 有電池供電, 節點在斷網以后，如何能夠禁止節點持續搜索網絡，或者把發送Beacon Request間隔增大

1)啟動搜索網絡uint8 ZDApp_StartJoiningCycle( void )

停止搜索網絡 uint8 ZDApp_StopJoiningCycle( void )

2) 更改發送Beacon Request的周期

修改變量zgDefaultStartingScanDuration

// Beacon Order Values

#define BEACON_ORDER_NO_BEACONS 15

#define BEACON_ORDER_4_MINUTES 14 // 245760 milliseconds

#define BEACON_ORDER_2_MINUTES 13 // 122880 milliseconds

#define BEACON_ORDER_1_MINUTE 12 // 61440 milliseconds

#define BEACON_ORDER_31_SECONDS 11 // 30720 milliseconds

#define BEACON_ORDER_15_SECONDS 10 // 15360 MSecs

#define BEACON_ORDER_7_5_SECONDS 9 // 7680 MSecs

#define BEACON_ORDER_4_SECONDS 8 // 3840 MSecs

#define BEACON_ORDER_2_SECONDS 7 // 1920 MSecs

#define BEACON_ORDER_1_SECOND 6 // 960 MSecs

#define BEACON_ORDER_480_MSEC 5

#define BEACON_ORDER_240_MSEC 4

#define BEACON_ORDER_120_MSEC 3

#define BEACON_ORDER_60_MSEC 2

#define BEACON_ORDER_30_MSEC 1

#define BEACON_ORDER_15_MSEC 0

5，如何讓End Device進入低功耗狀態，休眠時間是如何設定的？

在協議棧宏定義中使能POWER_SAVING后，然后在f8wConfig.cfg文件里面把-DRFD_RCVC_ALWAYS_ON=FALSE，就可以讓End Device進入休眠狀態。

關于休眠的時間是有OSAL操作系統的調度來決定，每次休眠時間都是按照最新會發生的一個Event Timeout作為休眠時間。具體在協議棧hal_sleep函數中有說明。

這個timeout主要分為兩類，一類是應用層事件的timeout，另外一類是MAC層事件的timeout，

1)應用層的timeout的時間，是在osal_pwrmgr_powerconserve( void )函數中，通過osal_next_timeout();獲得的。

2)MAC層的timeout時間，是通過halSleep( uint16 osal_timeout )函數里面，通過MAC_PwrNextTimeout();來獲得的。

6，ZigBee 3.0協議棧有哪些新的東西？

請參考下面的鏈接，介紹了ZigBee 3.0協議棧相對于之前ZigBee Home Automation/ZigBee Light Link 所增加的東西。

http://processors.wiki.ti.com/index.php/What%27s_New_in_ZigBee_3.0

7，TI ZigBee協議棧中關于終端設備的狀態機切換

http://www.deyisupport.com/question_answer/wireless_connectivity/zigbee/f/104/t/104629.aspx

8，關于TI協議棧中OAD和OTA的區別

OAD全稱Over the Air Download, OTA全稱Over the Air. 這兩個實現的功能都一樣，都可以叫做對程序的空中升級。在早期的ZigBee協議標準中，并沒有關于節點程序空中升級方面的標準，但是很多客戶都對空中升級有需求，所以TI自己開發了一套關于程序空中升級的協議棧，并且命名為OAD。后來ZigBee聯盟看到產品對空中升級的需求越來越來，隨機也指定了空中升級方面的標準，命名為OTA，該標準也是參考了TI的OAD實現方式，做了相關的修改。所以TI的早期協議棧中，空中升級叫OAD，后來的協議棧中跟隨ZigBee聯盟的空中升級協議，就叫OTA了。

9，如果在非低功耗設備中，未焊接32K晶振，Z-Stack協議棧需要怎么修改？

在Z-Stack協議棧中，初始化都有對使用的晶振是否穩定進行檢測。如果未焊接32K晶振，則需要對下面的代碼進行修改。TI Z-Stack 協議棧默認是使用32K晶振的。

在hal_board_cfg.h文件，

#define OSC32K_CRYSTAL_INSTALLED FALSE

10，如果開發基于ZigBee Mesh網絡的私有應用，應該選擇哪個協議棧？

很多用戶只想把zigbee mesh網絡的功能運用在自己的系統或者產品中，并不需要完全按照zigbee 定義的應用層規范來做，特別是一些行業性的應用。針對這樣的應用需求，應該如何選擇TI 合適的協議棧進行產品開發呢？

http://www.deyisupport.com/question_answer/wireless_connectivity/zigbee/f/104/t/132197.aspx

11，使用CC2630/CC2650進行ZigBee開發，Debug時可以在Core stack代碼進行下斷點調試嗎？

可以下的，你要下載斷電的代碼對應的文件，一定要提前打開，然后進行Debug，就可以去打開的文件進行Debug了。

12，Zigbee協調器是如何選擇合適的信道創建網絡？

Zigbee網絡的創建必須有協調器來完成，一個Zigbee網絡有且只有一個協調器。Zigbee協調器在創建網絡時主要完成的是網絡信道的選擇和PANID的生成。關于信道的選擇，大致可以分為兩個步驟，1)被動掃描也叫能量掃描Energy Scan，所謂被動掃描就是協調器將自己的接收機打開，然后在事先設定的信道列表上依次掃描，掃描后會得到每個信道的能量值，這個能量主要來自其他的Zigbee網絡，或者其他的2.4GHz無線信號。協調器會將能量值高于事先設定的閾值的信道認為有較大的干擾存在，將該信道排除。2) 主動掃描Active Scan，在第一輪掃描以后留下的信道中，依次發送Beacon Request，如果收到對應的Beacon數據包，認為該信道中存在其他的Zigbee。最后協調器會選擇一個沒有其他的Zigbee網絡PANID., 或者存在Zigbee網絡最少的信道建立自己的網絡并且設定一個沒有沖突的PANID.