I have problem when using 0x10 command(transmit request) in Xbee Coordinator API

XBee & XBee Gateway XBee - Zigbee
, , ,
1

I use Xstick2 ZB as an API coordinator and Xbee Pro S2B as an API end device. Configured them via X-CTU as following configurations…

Xstick(coordinator API):
ID=11111111
SC=7FFF
DH=0
DL=FFFF //For broadcasting
SP=AF0
SN=AF0
(Others are the default configurations)

Xbee(end device API):
ID=11111111
SC=7FFF
DH=13A200 //SH of Xstick
DL=409B820E //SL of Xstick
ST=FFFE
SP=20
SN=1
(Others are the default configurations)

At first, I sent API packet from the node(end device API)

“7E 00 13 10 01 00 00 00 00 00 00 00 00 00 00 00 00 41 42 43 44 45 9F”

to the coordinator via ‘Assemble Packet’. The result was the coordinator could receive packet correctly with 0x90 command shown in the coordinator’s terminal window.

Then, I sent the same packet from the coordinator to the node, but there is no action on the node’s terminal. But there is the receiving packet with 0x90 command in coordinator terminal like following link

-coordinator’s terminal >> http://upload.siamza.com/1418316

-node’s terminal >> http://upload.siamza.com/1418327

I am a beginner about Xbee and really have no idea about this, please suggest me, many thanks :slight_smile: :slight_smile:

2

Try changing the address in the API frame from the Coordinator (0x0000) to the mac address of your end device. Just also make sure you re-calculate the Checksum.

3

I tried to do following your suggestion, but the result was still the same

link of coordinator’s terminal: http://upload.siamza.com/1420322

…T^T

4

Ryen,

Have you worked with transparent mode yet? Since you stated you are new to the XBee, it may be better if you start there since API mode is an extension to the transparent mode functions.

5

I have tried with transparent already, they worked well with AT mode(coordinator AT / router AT) the coordinator could receive packets from the router, and the router could receive packets from the coordinator also. But while I changed to coordinator API and router API there would be the problem occur.

6

Hi,

I have the same problem.
Starting off with 1 coordinator and 1 router both in api mode trying to get something to work here…
Modules used: XBP24-Z7WIT-004 (god knows how I can be sure, but I guess this is a XBP24-ZB type but where the hell I can find that for sure, no idea).
I have 1 command I send to the router (via UART line):
“0x7E, 0x00, 0x12, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFC, 0x00, 0x00, 0x54, 0x65, 0x73, 0x74, 0x54”
I have 1 command I send to the coordinator (via UART line):
" 0x7E, 0x00, 0x12, 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFC, 0x00, 0x00, 0x74, 0x73, 0x65, 0x54, 0x54"
Both commands should broadcast to all routers. So, when the router receives this command over UART then with a serial line monitor tool I see the 0x90 frame on the coordinator UART line with some small delay of 10ms (due to wireless transmission) = OK
The frame: “0x7E, 0x00, 0x10, 0x90, 0x00, 0x13, 0xA2, 0x00, 0x40, 0xBF, 0x62, 0xA8, 0xA7, 0xF3, 0x01, 0x54, 0x65, 0x73, 0x74, 0x76”
However when the coordinator receives his command over the UART line then 4.5ms later I see the 0x90 frame on the coordinator UART line again?
The frame: “0x7E, 0x00, 0x10, 0x90, 0x00, 0x13, 0xA2, 0x00, 0x40, 0xC2, 0x9B, 0x84, 0x00, 0x00, 0x01, 0x74, 0x73, 0x65, 0x54, 0xF8”

So as you can see the reply to the command send to the coordinator is returning on the coordinator UART line (I would expect to see this data on the router UART line)…

Can anyone explain, please???

After 5 days of reading how easy it is to set up a network with xbee modules I’ m starting to loose my mind on this one!!!
Final goal: some end devices that sample there IO (this works, however not yet tested combined with the routers), some routers for expanding network and some with additional HW (so UART line should be working) and a coordinator with HW (so UART line should be working also here)…

7

May I suggest you start with all nodes in AT command mode and get working sending and receiving data first? The API, ADC and DIO functions are all designed to work around these function. So taking a step back and just getting the most basic function to work something is all you need.

8

I already got the AT mode working: every 5 seconds I send a package (±50 bytes) from coordinator to router and some package back. Works fine. But when both devices initiate I get a large burst of commands (around 50 burst of 50 bytes every 100ms). This works fine for about 5 commands and then the coordinator doesnt send anything anymore for about 5 seconds. After those 5 seconds I get larger burst of data, however some data was already lost (buffer was full). Very strange for a device which claims it can reach speeds of 250kbs (if I recall correctly).
I reduced my speed to every 1000 ms a package, still NG.
Then I tried to let my coordinator only scan on 1 channel, because I was thinking maybe the scan is interrupting the data transfer, but also there no luck…

I’m running towards my deadline for proof of concept so anybody that can explain why I have the API problem? If not, any ideas on other wireless modules instead of the xbee’s I can use (preferably with better documentation)?

Tnx

9

That is because you are at or exceeding its capabilities and the standard in which it is designed to meet.

The 250kbps rate you are referring to is the fixed over the air data rate. It is not the stated throughput. That is considerably lower and documented in the manual which is also dependent upon the number of hops and if the data is being sent from router to router or end device to router.

As for API, you need to have the API firmware installed for API frames to work. As for Duplicated packets, I would suggest making sure you have the most current firmware installed and check the RR and if you are having any bumps on the line. Using change detect can cause this.

10

Sending 50 bytes every second is hopefully not at or exceeding its capabilities in AT mode…

Off course API framework is installed and always with latest version.

Latest update: for proof of concept I refer to the 64 bit address of each router and to 16 bit 0 address of the coordinator ==> all problems solved in API mode (just have to send the same command many times for each router = far more than 50 bytes every second). When I switch on coordinator to broadcast to all routers it fails again…

Since nobody can give me a good answer on the why part, I’m gone let it rest for now and continue with the highly dynamic solution of 64 bit addressing to make it work.

11

Broadcast transmissions have large delays and required times of silence that is most likely causing issues with your application. In addition, if you do not implement some sort of delay protocol that keeps each node from trying to communicate all at once, you will have data collisions that will occur thus keeping you from receiving the data.