strategy 4 receiving 3 bytes really fast via xbee?

I have an arduino duemilanove that is set up to receive 3 bytes that represent an RGB color. It then takes those three bytes and does an analogwrite to control an rgb led. Super simple and it works.

I am trying to receive those three bytes via an xbee set at 56.7kbps. The problem is that the arduino does not seem to be able to process these instructions quick enough. The issue is probably due in part to the way I am encoding the messages: Right now I use a a start byte 'A', two bytes to represent each color (so the value 255 would be encoded as hex characters 'ff') and a terminating character 'x'.

So for example if I wanted to send the value %100 red, I would send this message: Aff0000x.

This means that the Arduino has to parse the message, convert the Ascii pairs of values into their decimal equivalents and then write to the three pwm ports.

Given the baudrate this has to be accomplished in about 700uS. Is this a reasonable expectation?

Should I reduce the traffic by using 4 bytes instead: 1 byte for parity and 3 bytes for the data? If I did this how would I know the starting byte if a byte was lost?

As far as error correction goes I would rather discard a corrupt message than try to fix it. In other words speed is more important than anything since values are constantly being sent.

Should I look at Xbee API mode and send data as a set of 3bytes in a packet? My concern with this is speed since the sending xbee is awaiting an ack on each packet sent.


The first thought that comes to mind is this. Can you see the LED change colors that fast? What does the LED color correspond to?

Now, you are sending 8 bytes per packet. This could be reduced to 5 () or even 4 (RGB!), where R, G, and B are sent as bytes, rather than strings representing color values.

But, the question remains why you need to change the color of the LED that fast.

Using the API mode would not be faster, as extra data is added to each packet in order for the XBee to handle errors.

I want to be able to send fast enough to remotely control fading of the led. This is actually part of a system that is converting DMX into wireless control of individual leds.

If I just send the byte values do I not run the risk of losing a byte and then the arduino starts processing the wrong color order?

e.g. if I am seding rgbrgbrgbrgbrgb and then a byte gets lost then I will be processing grbrgrbrgrbrgbr where each color value is assigned to the wrong led.

You need something to identify the start or end of a set of bytes for one color change. If you are sending rgb!rgb!rg!rgb!r!, you can tell when data is missing, and skip that packet. If you don't have some sort of marker, then, yes, you will get out of sync.

There is no need, though, to change the color of the LED faster than the eye can track the color changes. 57K will result in a lot of color changes in a very short period of time - faster than the eye can register.

so if I am sending something like rgb! then each color value can only be in the range 0-254 since I am using one of the ascii charcters as a start byte. (assuming I was intending to send the byte values and not ascii). This is where I was getting a little confused becuase if I send the full range of byte values, one of them may be the ascii equivalent of the terminating or start character.

So I guess for refresh rate I only need about 24-30fps right? (just like movies or tv)

So that is approximate 1 frame ever 33ms, and if I am sending 4x8 bits of data per update then I need 1 bit sent every ms. So that is a baudrate of 1000bps? By that logic 9600bps should be more than adequate.

My signal chain is as follows: DMX console--->Arduino decoding DMX (@250kbps)--->sends the stripped out values to another arduino via I2C (I tried to get NewSoftSerial to work but couldn't. This is in another thread) ---> then the other arduino that is receiving I2C sends the values via xbee to the wireless rgb led.

I have this whole signal chain working but there was some major latency (about 500-1000ms) and the rgb led color changes were really choppy. There are obviously a lot of things in this chain that I need to isolate as being the problem.

so if I am sending something like rgb! then each color value can only be in the range 0-254 since I am using one of the ascii charcters as a start byte.

Good point. I think I’d use 255 as the packet separator. I’m not sure I can tell the difference between an LED lit at 254 vs. one lit at 255.

I use 255 as a packet starter all the time...the "protocol" is the same as the MiniSSC method.

It would also be lightweight to allow the Arduino to calculate an interpolation to fade to each new color, to reduce the necessary update rate a little bit. Say every fade is interpolated over 1/10th or 1/20th of a second...full brightness swings will still look sharp as desired but gentle fades will look much smoother than immediately jumping to the new value. You can even put in some logic to just jump to the new color if your delta is large enough.