Rainbowduino: Extra Technical Information

[miso]

Hello everyone.

I am new to arduino/rainbowduino development and currently in the process of learning. I have noticed that since there is a lot of information missing from official documents, many people end up reverse engineering the hardware/software interaction logic. Although a lot of information exists on this forum scattered in various posts can we centralise it?
Could we use this discussion thread/topic, to list the most important findings?

Some of the questions that I am listing I have answers to. Some I am are not sure about, but it would be nice if the experts could answered them.
For example some of the initial questions that I came accross were:

1. What is the normal I2C communication speed between an arduino and an array of rainbowduinos? Can this be maximised? Are there any better alternatives to I2C(ie serial coms)? Does the speed depend on the arduino type? What are the communication bottlenecks, arduino to rainbowduino or pc usb to arduino? Does connecting more rainbowduinos together affect the comunication speed (if yes in what way) or the frame rates?

2. What is the maximum frame rate that can be achieved by an arduino controlling 192 LEDs (single coloured ofcourse)?

3. What is the maximum range of intensities that can be output by a rainbowduino controlling 192 LEDs? Am I right to assume that it is only 16? Could this be increased by using any tricks such as linear or other interpolation?

4. What is the best way to dynamically update a frame on a set of rainbowduinos? An answer to this would include connectivity options (wired & wireless), timings if possible, best IDEs, best firmware/libraries and hardware (shields, arduinos) that can be used.

5. How to flush rainboduinos. Listing hardware incompatibilities or any issues that can cause problems, devices known to work.

6. What would also be nice, would be a sketch file that allows you to turn on an led at a time and an accompanied diagram of how to manually connect wires to the rainbowduinos that connect to individual LEDS.

Please feel free to answer individual questions or ask new questions and maybe then seeedstudio or me or someone else can then summarise the answers received in a pdf file or something. I quess I am referring to a document that should be called “Rainbowduino: The missing reference book”

Thanks,
M

[michu]

hey

the central place for documents is the new rainbowduino wiki: garden.seeedstudio.com/index.php … Atmega_328

1. What is the normal I2C communication speed between an arduino and an array of rainbowduinos?
   what do you mean with “communication speed”??? the bottleneck is definitve NOT the i2c bus.

2. What is the maximum frame rate that can be achieved by an arduino controlling 192 LEDs (single coloured ofcourse)?
   What do you mean with frame rate? the technical refresh rate? or full frames update?

3. What is the maximum range of intensities that can be output by a rainbowduino controlling 192 LEDs? Am I right to assume that it is
   only 16? Could this be increased by using any tricks such as linear or other interpolation?
   currently 16 brightness levels per color - I just check if I can increase (and the brightness levels would be visible).

4. the best way to dynamically update a frame … best IDEs, best firmware/libraries and hardware
   “the best” is not very specific - read the wiki about the different firmwares

-> wiki

cheers

[miso]

Hello michu and thanks for the new info.

The garden.seedstudio page is definitely the best source of information regarding rainbowduinos right now. I did not realise that anyone could edit it.
I can see that it got where it is through iterative improvements and what I was suggesting was for people to ask/answer questions here and then collect/use that information in order to make the page even more complete. There is important information on it now that I needed and was not there a couple of days ago.

1. What is the normal I2C communication speed between an arduino and an array of rainbowduinos?
   what do you mean with “communication speed”??? the bottleneck is definitve NOT the i2c bus.

I meant how many bytes per second can be send from the arduino to the rainbowduino? And if you have more than one connected is that speed shared?

2. What is the maximum frame rate that can be achieved by an arduino controlling 192 LEDs (single coloured ofcourse)?
   What do you mean with frame rate? the technical refresh rate? or full frames update?

I meant to say rainbowduino. Apologies. With frame rate, I mean how many times per second can you turn on and off 192 LEDs.

3. What is the maximum range of intensities that can be output by a rainbowduino controlling 192 LEDs? Am I right to assume that it is
   only 16? Could this be increased by using any tricks such as linear or other interpolation?
   currently 16 brightness levels per color - I just check if I can increase (and the brightness levels would be visible).

Thanks, it would be nice if this range could be improved a little bit.

4. the best way to dynamically update a frame … best IDEs, best firmware/libraries and hardware
   “the best” is not very specific - read the wiki about the different firmwares

Yes you are right. I wanted to leave this generic so that the answers would not be specific. Things that I was interested to hear about were things like: Is the default arduino IDE the easiest to use? Is it the most advanced one? Are there any other IDEs worth looking into and why. Regarding dynamically updating full frames, I wanted to know what experiences people had with wired/wireless solutions and different IDEs that they have used. Regarding firmwares I wanted to know if there are any significant optimisation differences between existing firmwares (memory/comunications) or whether they all pretty much use the same code which is adapted to do slightly different things in logic.

Once again, thanks for all the feedback,
M

[michu]

@miso

Hello michu and thanks for the new info.

The garden.seedstudio page is definitely the best source of information regarding rainbowduinos right now. I did not realise that anyone could edit it.
I can see that it got where it is through iterative improvements and what I was suggesting was for people to ask/answer questions here and then collect/use that information in order to make the page even more complete. There is important information on it now that I needed and was not there a couple of days ago.

Jep - I just started some days ago… fee free to add more information!

1. What is the normal I2C communication speed between an arduino and an array of rainbowduinos?
   what do you mean with “communication speed”??? the bottleneck is definitve NOT the i2c bus.

I meant how many bytes per second can be send from the arduino to the rainbowduino? And if you have more than one connected is that speed shared?

As i2c is a bus protocol, the speed is shared yes. but to be honest, I dont have a clue whats the theoretical troughput is when using i2c bus at 400khz…

4. the best way to dynamically update a frame … best IDEs, best firmware/libraries and hardware
   “the best” is not very specific - read the wiki about the different firmwares

Yes you are right. I wanted to leave this generic so that the answers would not be specific. Things that I was interested to hear about were things like: Is the default arduino IDE the easiest to use? Is it the most advanced one? Are there any other IDEs worth looking into and why. Regarding dynamically updating full frames, I wanted to know what experiences people had with wired/wireless solutions and different IDEs that they have used. Regarding firmwares I wanted to know if there are any significant optimisation differences between existing firmwares (memory/comunications) or whether they all pretty much use the same code which is adapted to do slightly different things in logic.

M

The arduino IDE works fine for me, but I guess there are other for the more advanced users (AVR stuff). My plan with the neorainbowduino was, flash the firmware once and then just your code using the processing ide - you could also use the eclipse ide for that.

[miso]

Flushing the rainbowduino once and sending it frames to render is what I need to do as well.
The good news it that I got my UARTSB device today and flushed my those rainbowduinos of which I managed to corrupt the firmware through the black widow flushing process that I tried.

Michu, you were interested to get some timings from my black widow. Do you have some code available that I could use to measure those timings?

A question which I have right now is (probably stupid), could the UARTSB device be used to send messages to the rainbowduino and therefore reduce any USB latencies?

I was also wandering how do people dynamically update frames on the rainbowduino? I understand that usually an arduino connects to the I2C connection of the rainbowduinos and tells them what to do, but what if I wanted to dynamically update the frames from my pc? Would the communication happen over serial to the arduino which later on passes the message through I2C to the rainbowduinos?

[michu]

@miso

Michu, you were interested to get some timings from my black widow. Do you have some code available that I could use to measure those timings?

A question which I have right now is (probably stupid), could the UARTSB device be used to send messages to the rainbowduino and therefore reduce any USB latencies?

I was also wandering how do people dynamically update frames on the rainbowduino? I understand that usually an arduino connects to the I2C connection of the rainbowduinos and tells them what to do, but what if I wanted to dynamically update the frames from my pc? Would the communication happen over serial to the arduino which later on passes the message through I2C to the rainbowduinos?

Hey miso, if you use the neorainbowduino firmware an its processing library, you should the round trip time (if you enable the debug log line from the processing library).

currently the arduino is only needed as (usb)serial-to-i2c converter. using only the uartsb would be possible, however then the rainbowduino needs to convert the serial data to i2c. and there is no room left for timing on the rainbowduino I guess. and about reducing the usb latency, the uartsb device IS ACTUALLY an usb to serial converter - so no

[miso]

hi michu.

I ll give it a go tomorrow and let you know about my results.

regarding the uartsb adaptor, I understand that it converts from usb to serial but I was curious if the timings would be any better than any other arduinos. For example the Uno is much faster than the rest and if I remember correctly it has to do with some change relating to the FTDI chip.

I found this guide about establishing a serial communication and sending/receiving data between a pc and an arduino
sheepdogguides.com/arduino/art4SeSimpFrmIDE.htm

In the above link the messages sent to the arduino are from the arduino ide. On windows the arduino usb maps to a com port. Would I be right to assume that I could use the windows CreateFile function to open the port and control the message flow in a standard serial coms way?

[miso]

Hi michu.

I had some problems getting the timings. First of all, in which file/firectory should I look for the line which needs modifying?
The other question I had was how do you see the timing and do you use the Processing IDE or the Arduino IDE?
Any additional guidelines would be handy.
I moved the compiled pde files on the arduino and rainbowduino through the arduino IDE and opened the serial monitor but got no results in it.