Communication Problems, X-CTU and ConnectPort X

XBee & XBee Gateway XBee - Zigbee
1

To start, I’m just trying to wrap my head around the API frame and transmission protocols with the Xbee radio and Connectport X. I’m using the dev board as a stand in for my uC in the application and using the X-CTU software to connect to the radio, also I’m hoping that would give me at least semi-transparent information about what the software is doing.

I’m running basic python commands on the Connectport X, using the supplied zigbee python examples (getnodelist, sockets, and sendto).

First, I’m trying to send data from the Connectpor X to the Xbee radio, I start with getnodelist() and it returns both the coordinator and the router, as it should. I’ve created the address tuple properly using to_socket_addr, and by forcing it by creating a list. So after calling sd.bind I want to send just a ‘hello world’ message to the radio to confirm that I can communicate between the nodes. If I check the terminal on the X-CTU software I get nothing. I would have expected that this would parse the entire frame that the coordinator is sending to the Xbee dev board. So that is the first thing I was hoping would work.

Now, trying the other way (let the coordinator sit and wait for data sent by the radio). I’m reading the pdf for the Xbee Znet 2.5 OEM modules and I’m looking at the example API frames on page 57. So with X-CTU I enable API without escape characters and go into terminal mode. I click assemble packet, and enter in the example API frame given “7E 00 16 10 01 00 00 13 A2 00 40 0A 37 8E FF FE 00 00 54 78 32 43 6F 6F 72 64 FC”. The only change I made is that I added the 64 bit address of the coordinator, but it doesn’t work if I leave it blank either. The python code running on the Connectport X is the sd.recvfrom() and it just sits waiting for the transmitted frame.

So I know the radios are talking to each other via the getnodelist() but I have absolutely no idea what is happening with the data I’m trying to transmit.

Any help would be greatly appreciated!

-Mike

2

Mike,
As far as your second approach goes, remember that you must recalculate the checksum if any of the bytes change value. According to my calculations the correct packet would be 7E 00 16 10 01 00 00 13 A2 00 40 0A 37 8E FF FE 00 00 54 78 32 43 6F 6F 72 64 38.
I hope this helps.

-Mark

3

Well. I found out some interesting stuff by trying to use a different Xbee radio. For whatever reason the UART on the first radio just does not work, it responds to getnodelist commands from the router and such, but just doesn’t parse uart data it seems. Is there a command that can do this?

So I guess my problem is fixed!

4

Ah good catch! One less thing I have to worry about going wrong. Unfortunately the packet still isn’t getting through.

Thanks!

5

Which firmware type is loaded on the non-responsive radio?

There are several firmware loads which disable the serial uart of the radio, namely Analog I/O, Digital I/O, and Router Sensor.

If the firmware loaded on the radio is one of these types, the behavior you’re seeing is expected and you would need to communicate with it over the air via X-CTU, or from your CP-X gateway via python script, depending on what that particular radio is associated with coordinator-wise.

6

Ah interesting. X-CTU doesn’t read the firmware properly, but I would assume its one of the I/O types as it was used with the 1-Wire Temperature Sensor.

There is one other problem I run into. When I was using X-CTU with both the point-to-point Xbee modules the terminal would show both the transmitted and received data. But using the other module I’m only able to terminal data from the radio to the gateway, but trying to send data from the gateway to the radio doesn’t produce anything via the terminal screen. Thoughts?

Thanks!