What message to use for indirect addressing mode

vincent hartman

Other Parts Discussed in Thread: Z-STACK, CC2530

After successfully binding (end device bind request) two End devices, I would like to use indirect addressing mode to send from the one bound end device to the other, however I cannot find an appropriate message. As it stands I can successfully send from the one to the other using the AF_DATA_REQUEST, however only when using the destination party short address, which is defying the purpose somewhat. If I follow the message flow it does get sent to the Coordinator and then to the destination end point as expected. For obvious reasons II would like to get away from first retrieving and then using the destination short address of the other bound party. Could you please advise.

The software I have is the ez430 zigbee mini-kit example code and the Z-stack the kit shipped with. I do not currently have the capability to compile the stack.

The current message I use (to send data to the other bound peer device) looks as follows:

znpBuf[0] = AF_DATA_REQUEST_PAYLOAD_LEN + dataLength;
znpBuf[1] = MSB(AF_DATA_REQUEST);
znpBuf[2] = LSB(AF_DATA_REQUEST);

znpBuf[3] = LSB(destinationShortAddress);
znpBuf[4] = MSB(destinationShortAddress);
znpBuf[5] = destinationEndpoint;
znpBuf[6] = sourceEndpoint;
znpBuf[7] = LSB(clusterId);
znpBuf[8] = MSB(clusterId);
znpBuf[9] = transactionSequenceNumber++;
znpBuf[10] = MAC_ACK; //Could also use AF_APS_ACK;
znpBuf[11] = DEFAULT_RADIUS;
znpBuf[12] = dataLength;

memcpy(znpBuf+AF_DATA_REQUEST_PAYLOAD_LEN+3, data, dataLength);

over 10 years ago

0 YiKai Chen over 10 years ago

Guru 735695 points

You should use AF_DATA_REQUEST_EXT command and AddrNotPresent in DstAddrMode to send indirect message.

0 vincent hartman over 10 years ago in reply to YiKai Chen

Intellectual 750 points

Thank you, I understood from the spec CC2530ZNP Interface Spec that the _EXT was used for inter-pan messaging and ignored it. I will give this a go and provide feedback.
Best regards

0 YiKai Chen over 10 years ago in reply to vincent hartman

Guru 735695 points

You are welcome. By the way, please help to press "Verify" button to my replies to benefit others have the same problem.

0 vincent hartman over 10 years ago in reply to YiKai Chen

Intellectual 750 points

Hi YiKai,

I don't have the indirect addressing working yet.

In the message (extended dat req) below, it is unclear what should be used for the destination address, I initially used the MAC of the destination, but the message dit not pass. I then made the address mode 0x02 (see below) and gave the two least significant bytes of the destination MAC. The message appears to be sending (please also check out the sniffer log: The extended dat req should be just before message 507.dat_req_ext_at_507.psdI also tried the real short address of the destination without success.

znpBuf[0] = 0x14 + dataLength;
znpBuf[1] = MSB(AF_DATA_REQUEST_EXT);
znpBuf[2] = LSB(AF_DATA_REQUEST_EXT);
znpBuf[3] = 0x02;//destAddrMode;

unsigned char destAddr [8];
destAddr[0] = 0xD8;
destAddr[1] = 0x4F;
destAddr[2] = 0xCE;
destAddr[3] = 0x01;
destAddr[4] = 0x00;
destAddr[5] = 0x4B;
destAddr[6] = 0x12;
destAddr[7] = 0x00;

memcpy(znpBuf+4, destAddr, 8);
znpBuf[12] = destinationEndpoint;
znpBuf[13] = 0x00; //pan
znpBuf[14] = 0x00; //pan
znpBuf[15] = sourceEndpoint;
znpBuf[16] = LSB(clusterId);
znpBuf[17] = MSB(clusterId);
znpBuf[18] = transactionSequenceNumber++;
znpBuf[19] = 0x20; //options AF_DISC_ROUTE
znpBuf[20] = DEFAULT_RADIUS;
znpBuf[22] = dataLength; //
znpBuf[21] = 0x00; //dataLength msb - as this msg can also handle bigger data;

memcpy(znpBuf+23, data, dataLength);

0 YiKai Chen over 10 years ago in reply to vincent hartman

Guru 735695 points

Before you call AF_DATA_REQUEST_EXT, do you make sure binding successfully?

0 vincent hartman over 10 years ago in reply to YiKai Chen

Intellectual 750 points

Yes, the actual binding should also be in the sniffer log.

0 YiKai Chen over 10 years ago in reply to vincent hartman

Guru 735695 points

I don see anything send out after binding in your sniffer log. Do you check the response of ZNP command AF_DATA_REQUEST_EXT?

0 vincent hartman over 10 years ago in reply to YiKai Chen

Intellectual 750 points

Yes, I do check the response. Cant remember off-hand, but I think it is the same message type as for the non-extended version. Will print it out to verify.

From re-reading your initial reply, I notice that I have an incorrect destAddrMode - I will re-test with Address Mode set to 0x00.

0 YiKai Chen over 10 years ago in reply to vincent hartman

Guru 735695 points

Yes, you should use correct address mode to send indirect message.

0 vincent hartman over 10 years ago in reply to YiKai Chen

Intellectual 750 points

I send:

AF_DATA_REQ_EXT

14 24 02 00 D8 4F CE 01 00 4B 12 00 FE 00 00 38 09 00 05 30 0F 00 00

I get the following response:

af_data_confirm 03 44 80 B9 38 05

But I dont see anything on the sniffer.

0 YiKai Chen over 10 years ago in reply to vincent hartman

Guru 735695 points

14 24 02 00 D8 4F CE 01 00 4B 12 00 FE 00 00 38 09 00 05 30 0F 00 00

In ZNP command, the red byte is len and is set 0. So why do you have green byte? If so, why the data length (blue byte) is 0x14? Where is FCS byte?

0 vincent hartman over 10 years ago in reply to vincent hartman

Intellectual 750 points

I take it that the status (inside the af_data_confirm)=0xB9, which means 'no bound device' according to the CC2530ZNP interface spec. The byte following the status (0x38) is the end point attempting to send the af_data_req_ext message. I presume I must re-visit my binding effort? Please comment.

0 YiKai Chen over 10 years ago in reply to vincent hartman

Guru 735695 points

Are you sure that you do binding successful? If possible, please attach sniffer log.

0 vincent hartman over 10 years ago in reply to YiKai Chen

Intellectual 750 points

This is message print from application level, so the FCS is not showing.

The length of the data payload is 2 bytes according to "CC2530ZNP Interface Spec" for 'af_data_req_ext'. Is the spec wrong?

0 YiKai Chen over 10 years ago in reply to vincent hartman

Guru 735695 points

You can check Z-Stack Monitor and Test API.pdf. If Len byte is 0, there should be no data byte followed. By the way, do you check if you do binding successfully with packet sniffer?

0 vincent hartman over 10 years ago in reply to YiKai Chen

Intellectual 750 points

Hi YiKai,

The len byte is "00 00" (two bytes long) according to the Test API.pdf and the 2530 Interface Spec. I will verify the binding process - I assume something went wrong in that arena.

The reason I cannot roperly verify the binding is that I did not yet have success reading the binding table (a previous post of mine on this forum). I will nevertheless pass a log of my binding.

0 YiKai Chen over 10 years ago in reply to vincent hartman

Guru 735695 points

To check binding, you can use Ubiqua Packet Analyzer to watch over the air message.

0 vincent hartman over 10 years ago in reply to YiKai Chen

Intellectual 750 points

push button on EP#1

Requesting Binding from Endpoint.
Tx: 13 25 20 00 00 C6 F1 E0 52 CE 01 00 4B 12 00 D7 D7 D7 01 09 00 00

Rx: 03 45 A0 00 00 00

push button on EP#2

Tx: 13 25 20 00 00 6F 10 E0 52 CE 01 00 4B 12 00 D7 D7 D7 00 01 09 00

Rx:03 45 A0 00 00 00

On the Coordinator the following is seen after the binding requests were sent:

Msg Received
Unknown msg was received:03 45 A2 6F 10 88

Msg Received
Unknown msg was received:03 45 A1 6F 10 00

The 8-byte green address is the Coordinator MAC address.

C6F1 (F1C6) is the short address of the first device requesting a binding.

Will post the packet sniffer log shortly.

Bind_again.psd

0 YiKai Chen over 10 years ago in reply to vincent hartman

Guru 735695 points

03 45 A1 6F 10 00 means ZDO_BIND_RSP success.

03 45 A2 6F 10 88 means ZDO_UNBIND_RSP not success.

I also see bind/unbind request in sniffer log. Do you send bind/unbind request from coordinator?

0 vincent hartman over 10 years ago in reply to YiKai Chen

Intellectual 750 points

I only send the two endpoint binds that you see initially. The unbind I cannot explain, although it occurs first and then the bind success. Not sure why.

0 YiKai Chen over 10 years ago in reply to vincent hartman

Guru 735695 points

Which Z-Stack example is your test based on?

0 vincent hartman over 10 years ago in reply to YiKai Chen

Intellectual 750 points

The code is based on the example_basic_comms_router_afzdo.c wich was part of the "CC2530ZNP_Mini_Kit"-> "ZNP_Examples".

$Rev: 602 $
$Author: dsmith $
$Date: 2010-06-16 13:09:46 -0700 (Wed, 16 Jun 2010) $

However the binding part I added.

0 YiKai Chen over 10 years ago in reply to vincent hartman

Guru 735695 points

Check why you destination endpoint is 0xFE?

24 02 00 D8 4F CE 01 00 4B 12 00 FE 00 00 38 09 00 05 30 0F 00 00

0 vincent hartman over 10 years ago in reply to YiKai Chen

Intellectual 750 points

Hi, I played around with the destination endpoint, no success, however if the two devices are bound - the destination endpoint should not at all be important or do I have it wrong?

0 YiKai Chen over 10 years ago in reply to vincent hartman

Guru 735695 points

Yes, destination EP should be not related. Don't know why you can not make it work. I don't have CC2530 Mini Kit so cannot do the same test.

0 vincent hartman over 10 years ago in reply to YiKai Chen

Intellectual 750 points

Hi Yikai, Hector,
Just an update, after a fresh reload of all devices (both ZED and ZC) the exact same software started working! I am relieved. Could it perhaps have been a polluted bind or maybe route table....?

Nevertheless, I can now successfully bind using ZDO_BIND_REQ and send messages between two ZEDs. I guess I have to learn how to maintain the bind table via UNBIND_REQ. Is there a easy way to remove the bindings in one go?
Thanks for your input.

0 YiKai Chen over 10 years ago in reply to vincent hartman

Guru 735695 points

By using ZNP/MT command, you can only use ZDO_UNBIND_REQ to remove bindings one by one. If our previous replies help you, please do remember to press verify button to help others have similar issue.

Zigbee & Thread

Zigbee & Thread forum

What message to use for indirect addressing mode