XBEE shenanigans/desperate plea for assistance

Howdy All,

I’ve been playing with some electronics this week for our project 12 Tone, for VIVID Sydney this year. In essence, its a bunch of lights in some chunks of wood. It’ll be pretty, eventually…

I’ve come to an impasse with the XBEE Modules and any guidance on the subject would be fantastically appreciated.

End Goal:

We would like to transmit MIDI data from a central point, out to all the individual stacks as pictured;

The current situation:

I’ve spent this week making these things talk and generally familiarising myself with their ins and outs so I can actually ask meaningful questions and getting something from the suggestions. As far as I can tell, these modules will do what we’re asking of them.

I wrote a little bit of code using some examples @pelrun sent me. Its basically one teensy reading a pot and blinking a pot according to that value, and forwarding that value over serial to the second teensy running the same blink program.

Heres my code;



If I send the serial over a hardwired serial connection, it performs as intended. No lost packets, no latency issues.

One the XBEEs enter the equation though, things get all weird.

The specifics of the modules;

Product: XB24C
Function Set: ZIGBEE TH Reg
Firmware: 405F

These are the profiles I’ve set up according to various internet resources;

XBEE Coordinator Profile

XBEE Router Profile

The Problem:

Theres at best maybe 500ms latency, and at worst, maybe 20sec. I don’t know if they’re sleeping, or theres some buffer fuckery going on, I just dont understand enough to meaningfully diagnose the problem. I can send from the sender, and receive at the receiver, but something doesn’t quite talk properly.

XCTU is the configuration platform for XBEE. Its got a terminal. You can open a couple of instances of XCTU and send various packets etc back and forth. This is the best test Ive been able to really perform.

XCTU lets you create a packet, whatever size you like, and shoot it over at set time intervals. Looking at some MIDI documentation, it seems to me like most things can be done in a 10 byte packet. So I sent 10 byte packets, 20 times at various intervals and watched.

@2000ms - No packet loss or latency issue
@1500ms - ~1 lost packet, receiver hitting some kind of issue around the 10th transmission
@1000ms - ~3 lost packets, same issue as above, but a little earlier, maybe the 8th or 9th
@750ms - ~6 lost packets, starting at the 8th

During redoing these tests and writing it all down, I got curious what the connection was like from router>coordinator, the reverse direction of what I need. Its absolutely flawless. 10 byte packets, every 1ms, 0 out of 500 packets lost. Same conditions Coordinator> Router (The way I want to go), it falls over after about 70 packets.


Can you think of specific packets I should send?
Any thoughts on buffers?
Any thoughts on timeouts?
Any thoughts on a sleeping module?

Appreciate any advice anyone can provide. If theres any info you’d like to see, I can provide.

Thanks all.


This might seem like a dumb question and you’ve laid it out fantastically well but:

This is more a sanity thing to me, but given you’re controlling lights at the other end is it worth sending MIDI data instead of just the RGB or HSL values for what you want the lights to be?

I’ve experienced similar issues with XBEE in the past and some after the fact fault finding indicated it was due to sending control characters via the serial that the xbee didn’t like.

http://www.briangoldfain.com/tag/dropped-packets/ is a good example of how we got around it, which is why I’m asking if it’s worth just sending the RGB or HSL values as an A-Z 0-9 string.

Fine plan. My only thought would be whether the central teensy can handle it all.

In some good news, I updated the firmware to use the 802.15.4 TH Function set. Sending 20 byte packets at ~30hz and I cant see any discernable latency.

One setting and it just works… good god… haha.


Are you doing raw 802.15.4 or using Zigbee/6LoWPAN over the top?