How to make fragmentation work with SampleSwitch and SampleLight project in "Z-Stack Home 1.2.0" ?

You can send message larger than 160 bytes using AF_DataRequest. Please refer to the following codes in ZDConfig.h

#if defined ( ZIGBEE_FRAGMENTATION )
  // The application/profile must fill this field out.
  #define MAX_TRANSFER_SIZE                160
#else
  #define MAX_TRANSFER_SIZE                80
#endif

Hi YiKai,

Thanks for your reply, but I already tried to change MAX_TRANSFER_SIZE with all kinds of values, but still got the same reasult.
I wonder if what else settings I need to do to make this feature work.

Thanks.

I would suggest you keep the original value (160) and try to send 120 byte for example.

Hi YiKai,

I really wish I could send 120 byte packets only for our current project ... But, for the project implementation, we need to send packets with at least 250 byte "APS payload".

Fragmentation is very important to our project, so I have to brother experts here...

Please help and thank you very much!

As I know, most of zigbee implementation won't do Fragmentation this large. I would suggest you send your message separately by application side. 

Hi YiKai,

If doing this by application side, then meaning the "sync" should be handled by application too; but actually CC2538 is not a powerful multi-task cpu so I wonder if it can handle CC3000 wifi connections, Zigbee mesh message and the implementation that our project will achieve at the same time well.

Besides, fragmentation is defined in the spec, and also supported by TI z-stack home 1.2.0. All I need to know is how to use it and make this feature work.

Thanks and help if you know how to use fragmentation in z-stack home 1.2.0.

Basically, CC2538 is powerful. It embedded a cortex-M3 inside and should be no problem connect with CC3000. However, I don't how complex your application is and can't judge it. For your reference, my company has a product that transmit 200K bytes data using CC2530 and don't even use CC2538. From my point of view, Zigbee Fragmentation is not necessary for application.

If you don't modify the source code and send message that the length is between 81~160 bytes, you should be no problem to see fragmentation in Z-Stack Home 1.2.

For you information, The ZigBee 802.15.4 spec defines a maximum packet size of 128bytes. Due to the size of the packet header, the max message is around 80. If you want to send over 225 bytes using fragmentation, it means Zigbee stack has to send your message in 3 separate packets. As I know, most stack only support fragmentation in two separate packets and this is why Z-Stack use "#define MAX_TRANSFER_SIZE                160".

Hope these information helps.

Hi YiKai,

Thanks for your information.

Could you please help me to understand if there is any limit of "MAC_MAX_FRAME_SIZE = 116" in f8wConfig.cfg ? The comment for MAC_MAX_FRAME_SIZE is 802.15.4 default is 102, so I wonder what is the relationship between 128 max. packet size defined in ZigBee 802.15.4 spec and MAC_MAX_FRAME_SIZE here?

Excuse me, but what you mean is that "MAX_TRANSFER_SIZE" can not set more than 160 ? So, the limitation of TI z-stack Home 1.2.0 is "MAX_TRANSFER_SIZE=160" ?

We internally verified that CC3000+Sample Switch Coordinator+ two Sample Light End device with Z-stack Home 1.2.0, which is running EZ Mode (when in EZ Mode, there are many packets transmitted than before..), two Light End device transmit Asso. request, but ZC only received one of them successfully. Besides, we need to process CC3000 connection first until it gets IP address, then the binding can be done after. But our project will face several Wifi connections and events via CC3000 and mobile phones. CC2538 is powerful, but it handles event one by one. CC2530 transmits 200K bytes by using incoming and sending events for this giant packet, and I verified this method inside our project architecture; then even the timer is set to send event in app, but for long the CC2538 can not receive this expected event and failed to send the giant packet in app... ><"

For the need of our project is that there are at least 4 wifi connections, one coordinator, 4 end devices, 4 mobile phones which will send commands via CC3000 and CC2538 ZC and ZED often. That's why we hope our CC2538 application can only deal CC3000, mobile phone, ZC and ZED events but not to send giant packet...instead, we hope to use reliable z-stack to handle giant packet transmission.

Really appreciate your help !!

You can check the material here which contains some explanation about 128 max. packet size defined in ZigBee 802.15.4 spec and MAC_MAX_FRAME_SIZE.

Hi YiKai,

Thanks for your reply and information.

Actually for the fragmentation feature, what we face is not only not able to send over 225 byte data, but also not able to send over 100 byte data, which is not over MAX_TRANSFER_SIZE = 160 when ZIGBEE_FRAGMENTATION is enabled.

In order to remove the effect of application event handling, we added extra data in "zcl_SendCommand(..)". By this way, we won't affect other data sending calling, but only the "toggle command" we trigger by a key after the binding procedure between ZC and ZED is successful.

The issue we face is that when msgLen is added under 98 bytes, then the toggle command can be sent to ZED successfully. But when  msgLen is added over or equal to 98 bytes, then   stat = ( *apsfSendFragmented ) (&req); in asStatus_t AF_DataRequest ( ... )  will return 0x02 instead of 0x00, and the toggle command is failed to send.

Actually, I wonder if the z-stack really enable "fragmentation" feature because even if msgLen is added under 98 bytes and sent successfully to ZED, but from packet sniffer, the packet is not fragmented,but send as one APS payload. If the MAX_BUFFER_SIZE is kept as 80 bytes, then if we send 98 bytes toggle command, the z-stack should fragment it into two packets, shouldn't it ?

Please help us and really appreciate it.

[ Testing function ]

(1) ZStatus_t zcl_SendCommand ( ... )

{

...

unit8 temp[]={"ABCDEFGHIJKMNOPQRSTUVWXYZABCDEFGHIJKMNOPQRSTUVWXYZABCDEFGHIJKMNOPQRSTUVWXYZABCDEFGHIJKMNOPQRSTUVWXYZABCDEFGHIJKMNOPQRSTUVWXYZABCDEFGHIJKMNOPQRSTUVWXYZABCDEFGHIJKMNOPQRSTUVWXYZABCDEFGHIJKMNOPQRSTUVWXYZABCDEFGHIJKMNOPQRSTUVWXYZABCDEFGHIJKMNOPQRSTUVWXYZ"}

...

if ( cmd == COMMAND_TOGGLE )       msgLen += 98;

....

if ( cmd == COMMAND_TOGGLE )        osal_memcpy (pBuf, temp, 98 );

....

}

(2) asStatus_t AF_DataRequest ( ... )

{

...

if  (len > afDataReqMTU ( &mtu) )

{

    if (apsfSendFragmented)

    {

          stat = ( *apsfSendFragmented ) (&req);

    }

    else

    {

          stat = afStatus_INVALID_PARAMETER; 

    } 

    else

    {

          stat = APSDE_DataReq ( &req );

    }

}

 ........

}

Hi YiKai,

After referring to "http://e2e.ti.com/support/low_power_rf/f/158/t/134763.aspx" , so I tried to modify the dstAddr -> addrMode from afAddrNotPresent to afAddr16Bit.

Although the packets are not sent by z-stack still when the payload is over 100 bytes, the return value of "stat = (*apsfSendFragmented)( &req );" changed from 0x02 ( failed ) to 0x00 (successful).

Do you have any clue about this change ?

Please help and thanks !

Since you are using dstAddr -> addrMode=afAddr16Bit, what is your destination short address and end point? Do you use packet sniffer to check if the message is sent out?

Hi YiKai,

Here is my testing result and I have not changed my testing devices. I use packet sniffer to check if the message is sent out every time when I do the testing.

(1) When dstAddr -> addrMode= afAddrNotPresent, shortAddr = 0, dstEP = 0 and sending data = 100 bytes :

The toggle command can be sent to end device and perform light control of end device successfully. One packet with 100 byte size is sent to end device. The packet is not fragmented even the MAX_BUFFER_SIZE = 80 and MAX_TRANSFER_SIZE = 160.

The return value of "stat = (*apsfSendFragmented)( &req );" is 0x00 (successful).

(2) When dstAddr -> addrMode= afAddrNotPresent, shortAddr = 0, dstEP = 0 and sending data = 101 bytes :

The toggle command can not be sent to end device and no packet is caught, meaning no packet is sent out.

The return value of "stat = (*apsfSendFragmented)( &req );" is 0x02 ( failed ).

(3) When dstAddr -> addrMode= afAddr16Bit, shortAddr = 0, dstEP = 0 and sending data = 100 bytes :

The toggle command can not be sent to end device and no packet is caught, meaning no packet is sent out.

The return value of "stat = (*apsfSendFragmented)( &req );" is 0x00 (successful).

I think it is because shortAddr = 0 and dstEP = 0.

(4) When dstAddr -> addrMode= afAddr16Bit, shortAddr = 0, dstEP = 0 and sending data = 101 bytes :

The toggle command can not be sent to end device and no packet is caught, meaning no packet is sent out.

The return value of "stat = (*apsfSendFragmented)( &req );" is 0x00 (successful).

I think it is because shortAddr = 0 and dstEP = 0.

From the testing result I got, I am really confused about why addrMode will affect the return value of "stat = (*apsfSendFragmented)( &req );" ?

Please help and thanks.

You can't use end point 0. Maximum of 240 Endpoints per ZigBee Device (Endpoint 0 is reserved to describe the generic device capabilities and Endpoint 255 is reserved for broadcasting to all endpoints, Endpoints241-254 are reserved for future use). You can use end point 1 to 240 only.

Hi YiKai,

Thank you but excuse me. The two more tests I have done, and I still don't understand why "afAddrNotPresent" affects fragmentaion feature.

(5) When dstAddr -> addrMode= afAddr16Bit, shortAddr = a specific end device, dstEP = 1~240 and sending data = 200 bytes :

The toggle command can be sent to end device and perform light control of end device successfully. Fragmantated packets are sent to end device.
The return value of "stat = (*apsfSendFragmented)( &req );" is 0x00 (successful).

(6) When dstAddr -> addrMode= afAddrNotPresent, shortAddr = 0, dstEP =  1~240 and sending data = 101 bytes :

The toggle command can not be sent to end device and no packet is caught, meaning no packet is sent out.
The return value of "stat = (*apsfSendFragmented)( &req );" is 0x02 ( failed ).

The conclusion is that fragmentation can not work if dstAddr -> addrMode= "afAddrNotPresent" no matter if dstEP is set in the reasonable range or not. According to Z-Stack API, afAddrNotPresent is to let reflector figure out the destination address, so it is relative to binding table, isn't it ? Why this setting should affect fragmentation feature ? Is it related to any Zigbee spec ?

Please help and thanks.

Kelly

When you use dstAddr -> addrMode= afAddrNotPresent, it means you want to use destination in binding table. SO, you have to make sure you do the properly binding before using dstAddr -> addrMode= afAddrNotPresent.

Hi YiKai,

I am using Z-Stack Home 1.2.0 project, and the binding is controlled by E-Zmode, so I am pretty sure the binding is done successfully before doing my transfer data test.

I think binding is not the reason to let " dstAddr -> addrMode= afAddrNotPresent" affect the fragmentation in my project. But, according to your reply, it seems no special Zigbee spec mentioning that afAddrNotPresent can not be allowed for fragmentation...

Is it a bug ?  What do you think ?

Thanks.

You say "The toggle command can not be sent to end device and no packet is caught, meaning no packet is sent out when using dstAddr -> addrMode= afAddrNotPresent." This means bidding not successfully. I would suggest you trace into your code to confirm this.

Hi YiKai,

I think you misunderstood what "The toggle command can not be sent to end device and no packet is caught, meaning no packet is sent out when using dstAddr -> addrMode= afAddrNotPresent." means here.

Toggle command is trigger by key after binding is done. Why I am pretty sure binding is successful, because E-Zmode is triggered first and show the "Success". During binding, I also see "bindAddEntry(..)" is called. 

So, what the toggle command is nothing to deal with binding, and except this giant toggle command can not be sent, all ACK packets are transfered fine to keep binding status.

If you still think binding causes this, then it implies that E-Zmode has a bug to show binding is successful.

Thanks.

Kelly

While using dstAddr -> addrMode= afAddrNotPresent, the return value of "stat = (*apsfSendFragmented)( &req );" is 0x02 ( invalid parameter). I believe dstAddr -> addrMode= afAddrNotPresent doesn't support fragment.

Hi YiKai,

Thanks for your reply.

Although I don't know why Z-Stack Home 1.2.0 does not support "afAddrNotPresent" for fragment, the testing result is what you replied here.