Is is possible to communicate over 1 XBee to multiple microcontrollers?

Question

MC1>XB1 ==> XB2>MC2,MC3,MCn

What I am looking to do is control large LED panels, wirelessly, with control of each LED pixel. My concern is the processing limitations of a single controller and/or the cost of adding many XBee units. Controlling a single LED panel would be done via a PWM enabled LED driver/shift register. I could multiplex or charlieplex the panels but I'm afraid that will take even more processing power than writing out to a set of shift registers.

Does anyone have ideas how something like this might work?

Answer 1

If hardwired connection between controllers MC2 ... MCn is acceptable (as appears to be what you are saying) then there are numerous hardware solutions available which would work on even very bottom end uC's (microcontrollers).

Interconnecion could be by SPI, Asynchronous serial (TTL level "RS232), IIC (less likely) and more. RS422 family transmitters/receivers/transceivers allow multidrop serial with good range and noise immunity.

MC2 could be identical to MC3...MCn or could be more capable if required to handle the communications task.

Communications could daisy chain from MC2 - MC3 - MC 3 ... or could star radiate from MC2 or, if there are many uC's could have a multi level star.

Issues to consider in choosing best scheme are data rate (uC's x data bits per display x updates/second), physical distances between uC's, RF link range wanted, powering and more.

If total data rate was modest you could use a single data stream with all stations on it and each accepts only it's own addressed "packets". As number of displays or and or bits per display rise you may wish to partition the data stream at MC2 so that MC3 ... see only a subset of total data or only their own data.

Useful to know:

Data bits per display.
Max number of displays.
Refresh rate per second.
Powering.
Physical environment
Distances between stations.
...

Answer 2

Before choosing any design;

First define the Spec of what information MUST be sent to a display device and what may be sent or "nice to have". - number of pixels * colours * levels of intensity - Pixel update time not field refresh rate. - net Pixel rate bandwidth [MPix/sec]

Before you consider the waggle dance of XBee ( a trademark) , remember " ZigBee has a defined rate of 250 kbit/s best suited for periodic or intermittent data or a single signal transmission from a sensor or input device"

Consider if you have embedded scaleable fonts, then you dont have to transmit every pixel for each character. But if you choose analog style display of video images with text, then consider an analog communication link with NTSC converted to raster LED TV display, or compressed video in a packet Tx mode using whatever Wireless technology you desire. Also consider encryption, interference, hack-proofing and watch-dog timers to prevent public displays of bad data.

If this is say for a CMS or changeable message sign, then certainly, one can compute the latency of sending a static display update given the burst error rate of Zigbee and local density conditions and retry success rates.

Yes ZigBee is addressable to many targets, so it is ripe for creating a new standard for LED addressable remote RF controlled displays vs the old RS485 standard. Research it to find what protocols have been established already.