XBee Series 1 micro->PC connection problems

Wireless & IoT
1

Overview

Guys I purchased a couple XBee series 1 1mW. I’m programming both of them in turn in a Sparkfun XBee Explorer USB. After I’m (supposedly) ready from programming using X-CTU, I’m placing the Coordinator into the XBee Explorer USB and the End Device into a Sparkfun XBee Explorer Regulated board which is in turn interfaced to an 8051 core microcontroller (AT89C51AC2 to be precise). At the time being I only connected the DIN pin of the XBee (End Device) to the TXD pin of the microcontroller.

The Problem

Anyway my problem is that, you guessed it, I can’t get these babies to communicate between each other. All I need is to receive a continuous stream of numbers from the microcontroller at 19200 bits/sec to PC. The XBee connected to the microcontroller (End Device) has it’s ‘DIN’ LED blinking fast which means it is actually sensing data from TXD. I’m using the following settings, my question is, any ideas regarding what I’m doing wrong?

The Settings I’m (Modifying and) Writing Using X-CTU

Coordinator (The XBee connected to PC via the USB board):

PAN ID: 3FFF

DH: 13A200 (equal to SH of the end device)

DL: 403CAC20 (equal to SL of the end device)

CE: 1

BD: 4

AP: 2

End Device (The Xbee connected to the microcontroller)

PANID: 3FFF

DH: 13A200 (equal to SH of the coordinator)

DL: 403CAC1D (equal to SL from the coordinator)

MY: FFFE

CE: 0

BD: 4

AP: 2

IT: 1

IR: 1

Thanks in advance for any help guys,

Kai

2

I finally see what’s wrong with your settings.

You are trying to just send data straight through but but XBess are in API 2 mode. This requires the DIN serial to be formatted into an API frame that expects the frame to have a valid checksum. Since the frame will be considered invalid the data is ignored.

For transparent mode set AP = 0 on both modules.

3

Do the series 1 even support coordinator/end-point modes? I thought they were all broadcast modules and that the zigbee style coordinator/end-point stuff was only present on series 2. I use the series 1 for a home automation application (in API mode) and they work great. As Walter notes, in API mode, you need to format the data frame as specified in the docs. Its not super complicated, but its no trivial either.

4

It depends on which firmware is loaded in the Series 1 XBee modules. The 802.15.4 does not have a coordinator/end-point modules but the DigiMesh protocol may.

However, the 802.15.4 firmware does support both the AT and API command modes which has nothing to do with being a coordinator or end device.

With both the 802.15.4 and ZigBee firmware you can send either a broadcast message to all modules (without any ACK of data) or you can address any specific module by its 64-bit MAC address.

Look at the links in the thread titled “Better XBee Documents” in this forum for some descriptions of the various XBee hardware/firmware combinations.

5

waltr:
It depends on which firmware is loaded in the Series 1 XBee modules. The 802.15.4 does not have a coordinator/end-point modules but the DigiMesh protocol may.

However, the 802.15.4 firmware does support both the AT and API command modes which has nothing to do with being a coordinator or end device.

With both the 802.15.4 and ZigBee firmware you can send either a broadcast message to all modules (without any ACK of data) or you can address any specific module by its 64-bit MAC address.

Look at the links in the thread titled “Better XBee Documents” in this forum for some descriptions of the various XBee hardware/firmware combinations.

I’m not sure I agree with the above. 802.15.4 firmware has AT commands and registers to enable/disable Coordinator role in any radio. And for end-nodes, there’s a setting (register) to “require” yes/no end points to associate with a coordinator. When DigiMesh (series 1) or ZigBee (Series 2) is uses, these settings are overruled.

At least that’s my understanding.

One can do peer-to-peer mode, where all nodes are equals and there is no coodinator or end-point notion. Thus, any node can broadcast to all, or send a packet to a selected node by knowing its MAC address. I don’t need meshing, so that’s the arrangement I use. To do this, disable coordinator mode and disable association required. I also disable the mode where the packets have two or so bytes prepended to each packet- this is needed for the virtual wire functions. So disabling all these, and enabling MAC layer ACKs, you have a generic 802.15.4 radio in peer to peer mode. And other-vendor radios, equally configured, will interoperate.

If a node has an attached microprocessor, that can receive and retransmit a packet, acting as a repeater. These schemes are far simpler that meshing, if your needs are so met.

You can think of this as LAN nodes talking to each other using their NIC’s MAC addresses that all nodes know a priori. Or a layer up, it’s like WiFi 802.11 ad hoc mode, where all nodes know a priori the IP address of all others, and there’s no DHCP.

I mention this because hobbyists and beginners might find this easier.