Arduino, leds and serial speed

Hi,

I’m wondering how many bytes I should be able to send to arduino per frame in a reliable way.
I got some of adafruit neopixels (adafruit.com/products/1426), which look cool to play with, but now I’m wondering if it’s even possible to control a decent number of them through serial.

My simplest test goes as follow:
(using 255 as a separator, and else sending only byte per color value)
On Touch side, I’m doing :

for i in range(48):
	op('serial1').sendBytes(i)

op('serial1').sendBytes(255)

On Arduino side I’m doing :

[code] serialIn = 0;

while(Serial.available() > 0) {
incomingByte = Serial.read();

if(incomingByte == 255) {
   //Serial.println(0);
  break;
}


else {
    Serial.println(incomingByte);
    pixels[serialIn] = incomingByte;
    serialIn++;


  }
}[/code]

With rate at 9600, it’s fairly reliable for 48 iterations as above, but starts to loose some packet near the end as soon as 64, when I read packet size in arduino is supposed to be 128.

And 9600 is awfully slow, it looks like it takes 1ms for one byte, so even for not that many RGB leds I can only refresh every few frames.

And I tried setting the rate at 115200, but then it starts to break a lot earlier, and I get lots of random values in arduino.

Is there a way to make it work at a higher rate?

Else do other have experience with this, anyway to stream more data to the arduino, or is is just not supposed to be used this way? (kinda wondering about the ethernet shield)

Thanks!
Vincent

You might want avoid the overhead of the python interpreter itself, and create one big bytes object, and then send that in one shot:

 list = []
 for i in range(48):
     list.append(i)
 c = bytes(list)
 op('serial1').sendBytes(c)

Hi Rob,

Thanks for the tip! Though the python overhead wasn’t the issue, playing with it more I discovered the neopixel library messed up the serial reading on the arduino… After some tweaking I was able to go to 115200 bauds. Now I need to get more leds :wink:

Looks like some other boards like teensy or beaglebone are able to control a lot more though.

That is very cool to know. Surprised 115200 worked.
Keep us posted,
Rob.

Yes I’ll post a short video soon! It’s really fun to play with.

hello,

i’m doing some tests- trying to optimize serial transmission speed between Touch Designer and an Arduino (Uno). I’ve never had a need to get the fastest speeds possible, so I’ve never run into issues like this before.

I attached a .tox I’m using to test round trip speed. I send one byte from Touch Designer to the Arduino, serial.read() it on the Arduino, serial.write() it, and receive it back in Touch Designer.

If anybody could take a look at this and try to duplicate my results I’d be super grateful. Running at 60fps in Touch Deigner, no matter what baud rate I always get a round trip time of about 50ms. If I change my Touch Designer fps to, say, 120- I get a round trip time of about 30ms.

I’m trying to build a very simple, very reliable benchmarking and optimization setup for Touch / Arduino serial transmissions. Digging around on the internet I’ve found tons of information about Arduino serial latency issues- especially this one:

neophob.com/2011/04/serial-laten … s-arduino/

I’ve tried two methods suggested in that post. First, using a patch for the java rxtxSerial.dll in the Arduino IDE. Second, actually using a teensy++2.0. Still got exactly the same results with my Touch Designer network!

So, I’ll keep digging and trying. Any help would be super appreciated!

G
arduino_serial_speed_test.tox (1.14 KB)

i should probably start a new thread on this one—

in all my years using touch designer i haven’t done much with two way, round trip, handshake confirmed communications. usually i send a command out the pipe and i can see whether or not it worked- on some sort of display or other visual update.

all the testing i’ve been doing lately makes me realize i’m not sure i understand fully how to optimize communications for round trip speed. as explained in my previous post, i’m looking for fast two-way communication between Touch and microcontrollers. serial and tcp ip. all my testing points to my system design being bottlenecked on the Touch Designer side and I’m not sure why.

i’ve attached two .tox files, which i am running on the same machine- on two separate instances of Touch. I send a single value via Touch Out, receive it, process it, send it back, then compare the time it took to make the trip. my results are consistently in the 30ms to 130ms range, this seems super crazy wacky to me. i can see the delay in send/receive (that’s why i ended up testing with this approach, it’s super hard to find good serial/tcpip monitoring software.

something is broke? my brain? thanks in advance…
roundtrip_test_node_2.tox (726 Bytes)
roundtrip_test_node1.tox (918 Bytes)

Hey Gardyll,

I’m interested into these issues as well. I thought you would get better resutls with a teensy, so I’m surprised with your results.
I’ll have a look at your files!

In the meantime, as promised here’s the result of my little experiment : vimeo.com/92467776

vincent-

that is awesome! that is pretty much exactly what i am trying to accomplish! a physical, realtime extension of Touch Designer.

well, i guess a good way to describe what i’m trying to do is to first understand, then create a way to use Touch Designer as a brain and control system for all sorts of realtime physical applications. i’ve got a lot of experience with physical installations, but only if you count video projectors, cameras, and light sensors as the physical extensions.

i’ve been concentrating so hard on learning about electronic engineering and microcontroller programming- that i never really realized that getting super fast round trip communications between Touch (PC) and microcontrollers would become an issue.

my latest round of tests is simple but frustrating. very simple round trip “ping” tests. using tcp/ip and serial both, i’ve only been able to get round trip times of about 30mS between a Touch node as a server and a Touch node as a stand in for a microcontroller.

my whole approach (theory) relies on the foundation that all the heavy lifting takes place on the Touch Designer side. everything- the only thing the microcontroller needs to do is interpret short, tiny bursts of code and run that request, for only one microcontroller cycle. then, send a short burst back to TD, saying “i’m ready for my next task”.

if this loop is fast- and the handshake is fairly reliable, then there’s not much need for complex microcontroller code.

earlier in another post, Rob suggested-

in order to achieve realtime interactivity, i need to choose option a.

here’s a great example of what i want to achieve.

http://www.slickstreamer.info/2012/03/real-time-control-of-stepper-motor.html

but not just motors. all sorts of stuff, lights, motors, robots, etc. a true physical extension of TD…

well, thanks and i’ll post some more benchmark results soon

build 61,110+ will now reduce the round-trip latency by 1 frame period.
(From 2 frame periods, to 1)

See: derivative.ca/Forum/viewtop … 03&p=34364

all this is at 60fps? If you can turn off vsync, you can run it at relly high frame rates and reduce your interframe period.

Any chance you still have the .toe and Arduino sketch for this? It’s sick!