I’m restarting a project that was suspended 6 years ago. I have 3 XBee Pro modules, two of which are in service in simple peer to peer ascii mode on custom carrier boards that interface to CAN bus. I can monitor communications between the two with the third on the USB evalutation kit carrier board.
Back then I also ordered two XBee Pro S2B modules with SMA connectors and antennas since the plan was to create a 32 node mesh that went for several city blocks.
I just read on the SparkFun web site that these are not compatible. Not even with a firmware upgrade.
So I have three of one, two of the other, and I want to form a mesh network where module X is clearly out of range from module Y but there are 10 modules between. Probably why I bought the router S2B versions way back when.
I haven’t been able to get the two S2B devices to talk to each other or even discover each other. I suspect I have to reflash the code in one as a Coordinator and leave the other as a Router. But before I try all that and since I have 3 of the other I’m wondering if the XBee 802.15.4 modules can also function as routers hopping messages to the end points?
The XBee 802.15.4 and XBee ZB (S2) modules are NOT compatible with each other.
Yes, in order to establish a Zigbee Mesh network with the XBee ZB (S2) modules, you do need to change the firmware on one of the two from Router to Coordinator.
Depending on how old your Xbee 802.15.4 modules are, you MAY be able to change their firmware to a Digi Mesh proprietary mesh firmware which then has Routers and sleeping routers (No coordinator required).
Even if your modules are capable of being upgraded to Digi Mesh, they will not communicate with the Zigbee (S2) modules as they operate with different network standards.
OK. Thanks. So for additional modules I’m better off buying more of the S2B or S2C modules and programming them as routers or router/End Device Digital I/O?
Most of the time I just need to broadcast ASCII messages to the modules which are interpreted by the on board PIC processor and translated to CAN bus messages. There will be a need to also address individual modules that are out of range and therefore the need for the message hopping.
Similarly the modules may from time to time have to asynchronously send an alarm message back to the Coordinator so it would have to hop back. My ASCII protocol includes module ID #'s so the Beagle Bone Black that will be attached to the Coordinator can determine from who the message was received.
Or am I doing this in a clumsy manner for XBee?
The S2 and S2C will come with the router AT code on them which has DIO functions available. The DIO and AIO function sets are strictly for the AIO and DIO adapter products.
Thanks. I’ve been able to get the router sending to the coordinator by broadcasting to the PAN DL=0xFFFF for both. If I attempt to program the router to be a router and DIO endpoint I’m warned it won’t have serial capabilities so that won’t work for me. Next step is to buy 6 more devices so I can do a better trial. I think I can probably just use XBEE S2 modules for this test.
Clumsy is dependent on how many modules you are working with. If you only have a few, then you can just use the default addressing on the radios. Otherwise I would recommend using API mode on the Coordinator and AT or Transparent mode on the routers and End devices.
The standard Router code has DIO functions in it. It just requires you to use API mode on the module that is to receive the API Status frame or to control the DIO output.
Hmm. The modules I’m interfacing to have a simple ASCII command line protocol. Most work is done with a USB to TTL dongle. But, your point is well taken. It maybe smarter to add an API mode to the modules so if an XBee module is plugged in place of the FTDI USB to Serial that I configure an alternate API mode. Especially useful with the 64 bit address since the modules have the DS1822 serial # device.
Thanks for the suggestion.
Your welcome.