I’m using API mode to send frames of commands and receive frames of data btw coordinator and end devices. So I would like to know what is the avatages or disavatages of using Zigbee Transmit Request (API ID = 0x10) and Explicit Addressing Zigbee Command Frame (API ID = 0x11)? Beside, where can I find the signification of the modem status when it returns the status code?
Thank you so much!
Document: 90000976_F.pdf (pages 103 tà 105)
In Rev D, the modem status’s are given as:
0 = Hardware reset
1 = Watchdog timer reset
2 =Joined network (routers and end devices)
6 =Coordinator started
Older versions had :
4 = Synch. Lost
5 = Coordinator Reassign
I used to use the modem status on my router/end devices to let me know when I was successfully joined to the PAN, but found it to be less than reliable. I switched to polling using the AI (Association Indication) AT command.
You shouldn’t need the 0x11 unless, as the doc says:
Application layer addressing is useful if an application must
• Interoperate with other ZigBee devices outside of the Digi application profile
• Utilize service and network management capabilities of the ZDO
• Operate on a public application profile such as Home Controls or Smart Energy.
So the 0x10 frame enough for me to send custom commands from Coordinator to End device and send custom data from End device to Coordinator?
You can send any data you want with the 0x10. It will come out the other module in a 0x90 packet. You do have limits on how much data you can send in one packet (the latest firmware will let you send more data, but it breaks it up internally), but not with what’s in it. You do have to know what address you want to talk to. In my application, that’s easy, everyone talks to the coordinator, and so the address is always 0x0000000000000000, but you could always start with a broadcast to find out the address.
Thank you very much Daworm, and my last question : How long is the data payload if I use 0x10 frame?
72 bytes and 69 with encryption enabled.
That really depends. You can send up to 84 bytes, but… if you use encryption, that is reduced. And, but… if you use the fragmentation feature (look for it in the spec) you can send up to 255 bytes.
If that’s not enough for your application, you can do what I do. Since my protocol uses XML, my messages tend to be much larger than a single frame, so I reserve the first two bytes of each frame for a packet number and packet count, and reassemble the full message on the receiving end, throwing away any out of sequence or duplicate frames.
Good idea, I will not use the encryption. But which is the command that we can setup this field of data length?
It isn’t a field, just the first two bytes of the payload.
As for the 84/72 difference, in older modules I found that 72 was correct. Newer specs claimed 84. I’m using both forms of encryption, so it was something like 64 (can’t remember off the top of my head). The NP command is supposed to tell you, but since they added fragmentation, that just returns 255. So… I just thew in the towel and made my packets break at 52 bytes (50 bytes of data plus my two bytes of overhead). For my purposes, it sometimes added one more packet than I might have needed, but that didn’t bother me.
I understand you well. I just want to know the command to configure the size of payload field if it exists. Thanks so much!
There is no command. The Length field of the Transmit Request frame will include the length of the payload data as part of its value. Look at the example given. It has a length of 0x16 or 22 bytes. There are 14 bytes of overhead (the Frame ID, addresses, etc) which leaves 8 bytes for payload, as shown in the Rf Data field. If you want to send 50 bytes in Rf Data, then your length will be 64 (0x40.