if(u16StatusContent & TIMER1_IRQ_MASK)
//中断类别为定时器1中断
{
time_slot++; //每次超时都将时槽加1
if(time_slot==16)
time_slot=0; //时槽数的合法数值为0-15
PLMEEnableMC13192Timer1(1875);
//每个时槽的长度为1.875ms
switch(time_slot)
{
case 0: LoadBaecon(&tx_pkt);//读取一个Baecon
MCPSDataRequest(&tx_pkt);//发送Baecon
break;
case 8:
MLMERXEnableRequest(&rx_pkt1,0);
//打开接收天线，并将数据保存到rx_pkt1
break;
case 9:
MLMERXEnableRequest(&rx_pkt2,0);
break;
case 10:
LoadPacket(&tx_pkt,0,1); //读取一个数据包
MCPSDataRequest(&tx_pkt);//发送数据
case 11:
LoadPacket(&tx_pkt,0,1); //读取一个数据包
MCPSDataRequest(&tx_pkt);//发送数据
//12-15时槽略
}}
手持设备的程序设计与网关设计大同小异，所不同的是，网关在每个超帧的开始自动发送Baecon，而手持设备则被动的接收Baecon，每次收到Baecon之后才打开定时器来划分时槽，而第15个时槽完毕后，手持设备需要打开接收天线以接收下一个超帧的Baecon。
MC13192与语音编解码器及网络设备的协同工作
因为MC13192支持的速率仅为250kbit/s，因此在网关与手持设备之间必须只能传输编码后的语音数据。在选择编解码方案之前，首先需要粗略估计一下带宽，由于极限速率为250Kbit/s，而由于协议所限，仅有一半时槽可供使用，即125Kbit/s，供两个设备上下行使用。这样，每个设备的单向极限速率仅为31.25kbit/s。而MC13192自身的切换时间为144us，而如2.3.3节描述，30ms为一个超帧，每个时槽长度为1.875ms，再加上物理层头部的消耗，每设备单项可用速率约为20kbit/s。所以，在本方案中选用ITU-T G.726作为语音编解码方案。G.726语音编码消耗带宽16kbit/s，可以满足MC13192的带宽要求。
对于网关而言，需要记录每个手持设备的通话对象，它通过MC13192及802.15.4 MAC协议获得时槽中的数据，根据对应的时槽确定数据属于哪个手持设备。最后将收到的语音数据封装成RTP包发送到手持设备的目的地。对于从网络上收到的语音数据，则需要确定属于哪一个手持设备，再通过MC13192在特定的时槽发送出去。
对于手持设备则比较简单，它只需要在特定的时槽发送要编码后的数据，再在特定的时槽接收数据。
设计总结
该设计方案已经被用于本人参与的基于MC13192的zigbee电话项目中。经过实际测试，在40M范围内，可以实现无误码通信，通话质量优良。相对于基于其他技术的同类方案，本方案具有低成本、低功耗等优点，是一种比较有经济和技术价值的设计。
