Coordinated communication between 1 Coordinator and 2 Routers

Good afternoon!

I’ve inherited a project that wasn’t quite finished before a staff member at my lab left and am having a heck of a time with it.

Hardware: 3 XBee S2 modules, one coordinator AT (on XBee Explorer) and two router ATs (on Arduino boards).

General goal: have two devices (strain gauges) send data to one receiver attached to a computer in an orderly fashion so that they can be time synched and further processed in MATLAB.

Current state: the two strain devices will send data to the computer, but the data read from the single serial COM port that the XBee coordinator provides is a bit jumbled/stacked on top of itself. Data will be read from the first strain device for 4 frames, then 2 from the second device, then it’ll read half an item from the first device and a read from the second device will overwrite the second half, etc. etc. If only one strain device is on and transmitting it’ll work just fine.

I haven’t been able to find where to start on a problem like this through Googling; anyone have any ideas how to get the coordinator to read from each device in an alternating fashion?

Thanks for any ideas!

The safest solution would be to switch the coordinator to API mode. The mode of the 2 remotes is uninportant. then you will see full API frames including the length and MAC address of the source, giving you solid information to safely store in the correct 1-of-2 source buffers.

You may still need to deal with a fragmented message, so hopefully the strain-guage puts out an orderly format with perhaps an CR or nL at the end.

Parsing the binary API frames will make your MATLAB work harder. I have no idea how much harder as I’ve never used it.

If you wish to remain in AT mode, then your Arduino code would need to include a unit address and end-of-message tag, plus make sure your XBee RO setting is high enough to eliminate the remote Xbee from prematurely sending partial data.

Another commong problem is such designs is Arduino could which sends a message 1 byte here, 2 bytes there and so on to manually build up a message in the Xbee buffer. This greatly increases the chance of premature packet sends. ideally, you build the message first within the Arduino memory, then use well-crafted UART code (or a high-priority busy-wait loop) to push the bytes without the chance for a pause or gap which would cause a premature packet send.

Thanks for your reply! I’ve taken a look at the skill level required to use the coordinator in API mode, and while I could handle it with a little reading, it looks like I’m leaving this project (and state!) soon myself, so I should probably make it as easy to step into as possible for the next person.

I know for sure that only two strain gauge devices will be used (it’s for getting forces from bike pedals); given your experience might it make more sense (in my case, be simpler) to use two coordinators in AT mode and two routers with one router specifically paired to each coordinator? It looks pretty simple to assign PAN IDs and the like, but I’m unsure if there’s still a propensity for cross-talk in that kind of scenario. $50 to put together another coordinator would be a lot less pain down the road than having a fresh-faced student step in to whatever API mess I’d make :slight_smile:

Yes, the 2nd coordinator would be easy, and as long as both coordinator & router pair have a distinct PAN ID fixed & matching you won’t have any cross-talk … but to be sure, you can also force the 2 coordinators to select different frequencies by setting SC of 0x0F00 in one and 0x00F0 in the other. This gives each a menu of 4 channels which doesn’t overlap. The routers can retain their original SC=0x7FFF or whatever it is, because it is the coordinator which picks the frequency. This will prevent the 2 sensors from competing directly for air-waves, giving a little better throughput.