Broadcasts Succeed, Unicasts Do Not

Dantourin · March 5, 2010, 9:34pm

Hello! I have two 802.15.4 modules running firmware 10E6.

When operating in AT (transparent) mode, it was very easy to unicast from one module to the other once they were paired.

After switching to AP Mode 2, the application can no longer successfully unicast, but broadcast works perfectly.

Thanks in advance for any help you may be able to provide!

johnf · March 6, 2010, 1:04am

Give us an example of a packet that fails in API mode 2. That will probably help to narrow down the problem.

Dantourin · March 6, 2010, 3:19am

Thanks, John.

I am using the XBee API (http://code.google.com/p/xbee-api/), so most of this has been abstracted from me. I know, shame on me. It wasn’t until after I started looking into this much more that I even came to understand the API at all!

From the sample packet formats that I have seen, this appears to be the appropriate “raw” data sent. If this is the wrong data, I apologize and will try again.

Data (in hex) from a successful broadcast (sending the number 1 to a 16 Bit Address):
7e 0 6 1 1 ff ff 1 1 fd

Data (in hex) from an unsuccessful unicast (sending the number 1 to the destination (low) of 20):
7e 0 6 1 1 0 14 0 1 e8

One piece of information, and I don’t know if this makes any difference, but the unicast fails (ack failure) immediately - it does not wait for the timeout and this occurs whether or not the remote device is on or not.

Once again, I am very grateful for any assistance!

johnf · March 6, 2010, 11:12pm

Hmm.

Well, I’ve tried sending such packets in API mode 2 (which I admit I don’t normally use) and they seem to get through just fine. I’m running 10E6, same as you.

According to packet-check, the packets you’ve quoted are valid. They don’t happen to contain characters that would need to be escaped, so in fact they’d be valid in any API mode.

I downloaded the xbee-api code and did a quick scan - it looks very well put together and I’ll add a reference to it in the FAQ because a lot of people have asked for sample code in these forums.

None of which, unfortunately, answers your original question.

So this is what I’m thinking:

Given that “it works for me” it probably isn’t the XBees that are at fault.
That seems to leave the possibilities that there may be an error in the xbee-api code or in your own code that’s using the API. I’m speaking dispassionately here and no-one should feel that their expertise has been insulted

Can you perhaps clarify what you mean by
> but the unicast fails (ack failure) immediately
?
The string ‘ack failure’ doesn’t seem to exist in the xbee-api source, so I’m not sure what it relates to.

And I suppose I have to ask: are you sure that both XBees are in API mode 2?

Dantourin · March 7, 2010, 5:06am

Once again, thank you so much for your help. And thank you very much for your cookbook. It was a very valuable tool for advancing my XBee understanding in a short time.

The mode setting has been verified as “2” for both XBee’s.

The radios were configured with the addresses of 10 and 20 with the destination low setting pointing to each other. Although this worked in AT mode, I thought that maybe, since API mode commands contains addresses, it would be causing a problem. So I tried again with the destination setting cleared. Still no luck.

As to your other question, the API returns a status when a synchronous message is sent (synchronous waits for a response or times out). With the timeout set to 10 seconds, I still get an immediate failure. This returns an XBeeResponse object for which the “ApiId” must be checked (so the object can be cast to the appropriate class type). According to the documentation, it should return a TxStatusResponse (which it does). Then, checking the methods, I get an error (via isError()) and drill down to an Ack error (via isAckError()). So, when I click the send button (I created a handy test harness), the “ack error” immediately returns. It does not wait for the timeout. The Tx light on the locally attached XBee blinks on send, but the RSSI led on the remote XBee does not blink (unless in broadcast mode).

One other tidbit. I tried both synchronous and asynchronous sending - the async send is the same method used when broadcasting (which works). That fact, coupled with the fact that the sync send method is pretty foundational for this API, I find it hard to believe that I would have found a bug on my first attempt.

The only other thing that I have noticed is with the X-CTU application. I do not seem able to download the remote XBee’s data. When I bring up the remote config panel and run discover, the only id that shows up is 0xFFFFFFFF0000 and the other XBee does not seem to appear.

I also swapped modules so I have tried 10 sending to 20 and 20 sending to 10. Their ids appear correct in byte stream (0x0a and 0x14), but it does not work any better.

If it would help, I would be happy to post any and all of my source. Also, if it matters, the receiver is connected to an Arduino and makes use of the Arduino version of the XBee-Api.

johnf · March 7, 2010, 3:47pm

Well, the fact that you are getting an immediate “No Ack” response (and I’ve now found that part in the api source code) is normal and suggests that the packet may be addressed to an XBee that isn’t there. I’ve just tried sending a TX packet to a non-existent address, and got an immediate TX response packet back with status 1, which is what you’ve been seeing. So maybe there is something going wrong with addressing - though from your descriptions, I can’t see what it would be. The API timeout would apply only if no TX response was ever received.

Perhaps you could set up the experiment again, and turn on maximum logging in the API package. From what I can see, that should log the packets that are sent and received. Post the result, and also use X-CTU to save the settings of both XBees to .pro files, then attach those as well.

I don’t know why X-CTU isn’t discovering the other XBee. What happens if you send the ND command as an AT command from the terminal window?

So far, what the TX response and X-CTU seem to be telling you is that the other XBee simply isn’t there. But your success with broadcast messages implies otherwise.

Oh, and I’m glad the cookbook was helpful!

johnf · March 7, 2010, 4:04pm

Oops! For “turn on maximum logging” in my previous post substitute INFO level. That should be enough.

Dantourin · March 8, 2010, 4:40am

With DEBUG (INFO was sparse) Logging:

Successful BROADCAST (for reference)


DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacketParser: starting reader thread
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.XBeePacketParser:run no data available.. waiting for new data event or timeout
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.Checksum:compute computed checksum is base10=252,base16=0xfc,base2=11111100
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: Packet byte 0 is 0x7e
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: Packet byte 1 is 0x00
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: Packet byte 2 is 0x06
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: Packet byte 3 is 0x01
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: Packet byte 4 is 0x01
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: Packet byte 5 is 0xff
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: Packet byte 6 is 0xff
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: Packet byte 7 is 0x01
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: Packet byte 8 is 0x02
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: Packet byte 9 is 0xfc
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: pre-escape packet size is 10
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: post-escape packet size is 10
INFO AWT-EventQueue-0 com.rapplogic.xbee.api.XBee:sendPacket sending packet to XBee 0x7e 0x00 0x06 0x01 0x01 0xff 0xff 0x01 0x02 0xfc
DEBUG Thread-3 com.rapplogic.xbee.RxTxSerialComm:serialEvent serialEvent: 7 bytes available
INFO Thread-3 com.rapplogic.xbee.api.XBee:handleSerialData RXTX serialEvent
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.XBeePacketParser:run packet parser thread woken up by RXTX
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.XBeePacketParser:run Read base10=126,base16=0x7e,base2=01111110 from input stream
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Read Length MSB byte, val is base10=0,base16=0x00,base2=00000000
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Read Length LSB byte, val is base10=3,base16=0x03,base2=00000011
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:parsePacket packet length is base10=3,base16=0x03,base2=00000011
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Read byte base10=137,base16=0x89,base2=10001001 at position 3, packet length is 3, #escapeBytes is 0, remaining bytes is 3
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Read API ID byte, val is base10=137,base16=0x89,base2=10001001
INFO XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:parsePacket Handling ApiId: TX_STATUS_RESPONSE (0x89)
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Read byte base10=1,base16=0x01,base2=00000001 at position 4, packet length is 3, #escapeBytes is 0, remaining bytes is 2
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Read TxStatus Frame Id byte, val is base10=1,base16=0x01,base2=00000001
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Read byte base10=0,base16=0x00,base2=00000000 at position 5, packet length is 3, #escapeBytes is 0, remaining bytes is 1
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Read TX Status byte, val is base10=0,base16=0x00,base2=00000000
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Read byte base10=117,base16=0x75,base2=01110101 at position 6, packet length is 3, #escapeBytes is 0, remaining bytes is 0
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Checksum byte is 117
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.Checksum:verify verify checksum is 255
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Read Checksum byte, val is base10=117,base16=0x75,base2=01110101
INFO XBee Packet Parser Thread com.rapplogic.xbee.api.XBeePacketParser:run Received packet from XBee: apiId=TX_STATUS_RESPONSE (0x89),length=3,checksum=0x75,error=false,frameId=0x01,status=SUCCESS
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.XBeePacketParser:newPacketNotification Notifying API user that packets are ready
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.XBeePacketParser:run no data available.. waiting for new data event or timeout

Failed UNICAST


DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacketParser: starting reader thread
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.XBeePacketParser:run no data available.. waiting for new data event or timeout
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.Checksum:compute computed checksum is base10=231,base16=0xe7,base2=11100111
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: Packet byte 0 is 0x7e
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: Packet byte 1 is 0x00
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: Packet byte 2 is 0x06
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: Packet byte 3 is 0x01
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: Packet byte 4 is 0x01
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: Packet byte 5 is 0x00
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: Packet byte 6 is 0x14
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: Packet byte 7 is 0x00
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: Packet byte 8 is 0x02
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: Packet byte 9 is 0xe7
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: pre-escape packet size is 10
DEBUG AWT-EventQueue-0 com.rapplogic.xbee.api.XBeePacket: post-escape packet size is 10
INFO AWT-EventQueue-0 com.rapplogic.xbee.api.XBee:sendPacket sending packet to XBee 0x7e 0x00 0x06 0x01 0x01 0x00 0x14 0x00 0x02 0xe7
DEBUG Thread-3 com.rapplogic.xbee.RxTxSerialComm:serialEvent serialEvent: 7 bytes available
INFO Thread-3 com.rapplogic.xbee.api.XBee:handleSerialData RXTX serialEvent
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.XBeePacketParser:run packet parser thread woken up by RXTX
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.XBeePacketParser:run Read base10=126,base16=0x7e,base2=01111110 from input stream
DEBUG Thread-3 com.rapplogic.xbee.RxTxSerialComm:serialEvent serialEvent: 6 bytes available
INFO Thread-3 com.rapplogic.xbee.api.XBee:handleSerialData RXTX serialEvent
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Read Length MSB byte, val is base10=0,base16=0x00,base2=00000000
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Read Length LSB byte, val is base10=3,base16=0x03,base2=00000011
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:parsePacket packet length is base10=3,base16=0x03,base2=00000011
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Read byte base10=137,base16=0x89,base2=10001001 at position 3, packet length is 3, #escapeBytes is 0, remaining bytes is 3
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Read API ID byte, val is base10=137,base16=0x89,base2=10001001
INFO XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:parsePacket Handling ApiId: TX_STATUS_RESPONSE (0x89)
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Read byte base10=1,base16=0x01,base2=00000001 at position 4, packet length is 3, #escapeBytes is 0, remaining bytes is 2
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Read TxStatus Frame Id byte, val is base10=1,base16=0x01,base2=00000001
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Read byte base10=1,base16=0x01,base2=00000001 at position 5, packet length is 3, #escapeBytes is 0, remaining bytes is 1
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Read TX Status byte, val is base10=1,base16=0x01,base2=00000001
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Read byte base10=116,base16=0x74,base2=01110100 at position 6, packet length is 3, #escapeBytes is 0, remaining bytes is 0
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Checksum byte is 116
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.Checksum:verify verify checksum is 255
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.PacketStream:read Read Checksum byte, val is base10=116,base16=0x74,base2=01110100
INFO XBee Packet Parser Thread com.rapplogic.xbee.api.XBeePacketParser:run Received packet from XBee: apiId=TX_STATUS_RESPONSE (0x89),length=3,checksum=0x74,error=false,frameId=0x01,status=NO_ACK
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.XBeePacketParser:newPacketNotification Notifying API user that packets are ready
DEBUG XBee Packet Parser Thread com.rapplogic.xbee.api.XBeePacketParser:run no data available.. waiting for new data event or timeout

As requested, the .pro files are attached.

I had already forgotten about the ND command, but I did try it before. Repeating the test (10 is on my local system, 20 is the remote device), I get the following:
+++OK
atnd
20
13A200
403B5B11
2B

So it does appear to be discovering the remote node…in some capacity.

Dantourin · March 8, 2010, 4:49am

Sorry, I do not seem to have the permissions to attach files.

XBee #20

xb24_15_4_10e6.mxi
FE
0
231
10E6
0
[A]CH=C
[A]ID=6771
[A]DH=0
[A]DL=0
[A]MY=20
[A]MM=0
[A]RR=0
[A]RN=0
[A]NT=19
[A]NO=0
[A]CE=0
[A]SC=1FFE
[A]SD=4
[A]A1=0
[A]A2=0
[A]EE=0
[A]NI= 
[A]PL=4
[A]CA=2C
[A]SM=0
[A]ST=1388
[A]SP=0
[A]DP=3E8
[A]SO=0
[A]BD=5
[A]NB=0
[A]RO=3
[A]AP=2
[A]PR=FF
[A]D8=0
[A]D7=1
[A]D6=0
[A]D5=1
[A]D4=0
[A]D3=0
[A]D2=0
[A]D1=0
[A]D0=0
[A]IU=1
[A]IT=1
[A]IC=0
[A]IR=0
[A]IA=FFFFFFFFFFFFFFFF
[A]T0=FF
[A]T1=FF
[A]T2=FF
[A]T3=FF
[A]T4=FF
[A]T5=FF
[A]T6=FF
[A]T7=FF
[A]P0=1
[A]P1=0
[A]PT=FF
[A]RP=28
[A]DD=10000
[A]CT=64
[A]GT=3E8
[A]CC=2B

XBee #10


xb24_15_4_10e6.mxi
FE
0
231
10E6
0
[A]CH=C
[A]ID=6771
[A]DH=0
[A]DL=0
[A]MY=10
[A]MM=0
[A]RR=0
[A]RN=0
[A]NT=19
[A]NO=0
[A]CE=0
[A]SC=1FFE
[A]SD=4
[A]A1=0
[A]A2=0
[A]EE=0
[A]NI= 
[A]PL=4
[A]CA=2C
[A]SM=0
[A]ST=1388
[A]SP=0
[A]DP=3E8
[A]SO=0
[A]BD=5
[A]NB=0
[A]RO=3
[A]AP=2
[A]PR=FF
[A]D8=0
[A]D7=1
[A]D6=0
[A]D5=1
[A]D4=0
[A]D3=0
[A]D2=0
[A]D1=0
[A]D0=0
[A]IU=1
[A]IT=1
[A]IC=0
[A]IR=0
[A]IA=FFFFFFFFFFFFFFFF
[A]T0=FF
[A]T1=FF
[A]T2=FF
[A]T3=FF
[A]T4=FF
[A]T5=FF
[A]T6=FF
[A]T7=FF
[A]P0=1
[A]P1=0
[A]PT=FF
[A]RP=28
[A]DD=10000
[A]CT=64
[A]GT=3E8
[A]CC=2B

johnf · March 8, 2010, 3:42pm

Ah! I think we may have the answer. Here’s the packet you sent:

[john@eccles ~]$ packet-check
API Packet analyzer version 1.1 for Series 1 XBee (802.15.4)
Note: if it prompts for more bytes and you’re done, hit return
Enter packet: 0x7e 0x00 0x06 0x01 0x01 0x00 0x14 0x00 0x02 0xe7

Packet: 7E 00 06 01 01 00 14 00 02 E7
7E // Correct packet header byte
00 06 // payload length (decimal 6)
01 // Packet type: TX request with 16-bit address
01 // frame id: non-zero so response packet expected
00 14 // 16-bit destination address
00 // TX options
02 // transmitted data STX
E7 // checksum - correct

The destination address is 0x14, but the remote’s MY parameter is 0x20. I think you entered the address in decimal instead of hex…

Does that help?

Dantourin · March 8, 2010, 5:10pm

Wow, that’s a rookie mistake if I ever saw one. I mean, I totally noticed the 0x14, and, doing the mental math, knew 20 was equivalent.

I just never imagined that the address setup in X-CTU was actually in hex! I honestly thought the address of the device was 20 decimal.

That also explains why it didn’t work in either direction, too. To think, if I had picked 1-9, I would never have discovered this.

Once again, John, thanks so much for your assistance. Your patience…and resolution…have been humbling.

johnf · March 9, 2010, 1:19am

Hey, I’m just glad it worked!

The “rookie mistakes” are always the best - so simple, and yet so hard to spot that we all keep tearing our hair out over them

Topic		Replies	Views
Problems with transmit request API XBee - 802.15.4	22	1986	September 12, 2008
API-Mode 64-Bit Addressing Unicast XBee - 802.15.4	5	1000	August 13, 2010
Unicast setup for two Xbee pro 900? XBee & XBee Gateway setup , broadcast , unicast	3	617	February 18, 2016
Unicast example configuration XBee Pro series 2 XBee - 802.15.4	3	1562	February 4, 2010
XBee(S1) Transmitting in API mode XBee - 802.15.4	5	872	August 12, 2008

Broadcasts Succeed, Unicasts Do Not

Related Topics