xbee point to point with many points

Wireless & IoT
1

Hello,

I didn’t want to call this thread “point-to-multipoint”, because that may be describing something else. Here’s the setup:

6 remote xbees

1 central xbee

All xbees are series 1 (802.15.4).

The remotes only talk to the central, the central has to talk to each of the remotes. For the remotes it was simple: I just set the remote DH and DL to the central SH and SL. I am confused on the central one, though. I could just use broadcast, but doesn’t that disable the resend / packet checking that is the whole reason for using xbees in the first place?

So it seems like I need to be able to set the DH and DL of the central xbee on the fly, right? So here’s what I am sending (baud rate has already been checked, and I know the xbees are hooked up properly because they do receive and transmit when the central is in broadcast mode):

+++

ATDH(remote xbee SH)

ATDL(remote xbee SL)

ATCN

(Data)

It doesn’t seem to work, though. No lights flash on the receiving xbee. I’m sending the above from a terminal, specifically the serial terminal in the Picaxe software. If I can get it working, I’ll be sending it from Serial Bridge on a Mac.

Am I even on the right path here? I’ve read several tutorials on how to have one xbee talk to one other xbee, but I haven’t seen one that does what I’m describing.

Thanks for the help.

Brian

2

You may want to use API command mode for the central XBee. This way the address of the remote is embedded in the API frame. Additionally, the address of a sending XBee will be in the received API frame along with the data. This does require write code that builds and parses API frames but it isn’t that hard to do.

3

API mode is best; there is some sample code around for that.

Alternative: set DH:DL at the central to FFFF, the broadcast address. All remotes in RF range will likely get the data. There is no ACK or error correction for broadcast packets. So you either ignore the lost packets, or you have the remotes send a sequence-numbered “I got it” message. This is an application layer ACK. It’s like using UDP in IP networks.

4

Thanks for the replies. API mode does look good, but I am at my byte limit for two of the Picaxe’s. I actually got the AT mode working, I just needed a 1 second delay after the +++ before I sent commands. Too bad you can’t send in API mode and receive in transparent.

Brian

5

I am at my byte limit for two of the Picaxe’s

Maybe its time to upgrade the processors you are using. There are lots of better ones with plenty of program space.
6

Not in a 14 pin DIP. :mrgreen:

7

So I happened to come across a Digi Knowledge Base Article (http://www.digi.com/support/kbase/kbase … jsp?kb=184) which says that the receiving module does not need to be in AP1 to use API. Neat!

The central node xbee, which is attached directly to the computer, can send out API packets with the computer doing the needed calculations. The remote nodes can just reply in transparent mode, because they don’t need to change their DH or DL (which is permanently set to the address of the central node).

What I am not finding, though, is what will happen when the central node xbee (in AP1) receives data sent from a transparent mode (AP0) xbee. Will it hear the data? Or will the data get tossed?

Thanks.

Brian

8

Well that is exactly what Steve and I suggested.

Only the ‘central’ XBee needs to be in API mode. When data is send from a remote, in ‘transperant’ mode, the receiving XBee, central, puts the data into an API frame before sending it out the serial port. The reverse is also true, data embedded in an API frame will be send from the central XBee to a remote where it only sends the data out the serial port.

This works very well and is how I have my XBee network setup.

An API frame is not transmitted on the RF link. It is used between the serial port and the MAC layer.

9

Brilliant. Thanks waltr, I’m slow, but I get there eventually.

Brian