Advice: network communication to physical interface

I’m trying to come up with a strategy for communicating with an arduino over the network from oF. I’m hoping to send rgb values for around 400 pixels at around 40 fps. I’m thinking that ends up being around 1200 bytes per frame, so i’m looking at pushing 48000 byes per second. Is this feasible with an ethernet shield and an arduino (mega?, due?)

This is for a permanent installation. I had accomplished this previously by using an rPi + headless oF + wiringPi as the physical interface, but i keep encountering corrupted SD cards every few months. In general, it seems like a microcontroller would be more robust.

What type of architecture would people recommend here? Is it worth jumping into beaglebone black to get same speed as rPi, but avoid SD cards? Should I avoid ethernet/network in favor of usb > cat5 adaptor > usb?

Seems like your original approach is pretty ideal. Did you every figure out the source of the SD card corruption?

I haven’t figured out the corruption issue, although from what I’ve read it could be related to unstable or noisy power. I’m wondering if beaglebone black would be more robust. I know some people have been running oF on that device; I wonder if it has better power regulation or can deal with noisy power.

Yeah, that’s what I figured – have you tried it with the Raspberry Pi 2? From what I understand they figured out a lot of power stability issues with the newer platform. Sorry not trying to derail your original question, but I’m assuming minimal effort has its value in this case :smile:

another possibility is to connect an external hd with it’s own power to boot from it to the rpi or even boot from the net

I dont think an arduino has the internal buffer to handle that much data. A teensy could but I think sticking with the raspberry pi is probably still a better plan. Theres a lot more that can go wrong trying to communicate between the computer and teensy (is it the teensy buffer thats messing up or the program you uploaded) as opposed to a single board solution. Corrupted SD cards aren’t that problematic for permanent installations (coming from the museum field) since you can clone a dozen of them and swap them out if need be with very little effort unless you make it hard to access the pi (which you shouldn’t)

If you’re still curious heres PJRC’s great octoWS2812 library for handling a bunch of leds

Those are programmable leds but the concept is still the same in terms of handling data buffers, you would just need to adapt it to fit whatever hardware you are using

If your idea is to control an array of led pixels, maybe this dedicated controller may help you

It supports artnet input and controls un to 2000 pixels, and is only 180$, they are very stable in my experience and handles very well noisy power signals.

thanks, @arturo and @bakercp. I haven’t tried with the rPi 2 yet. I’ll look into that. @drakko I’ll look into this as well. I just emailed the company to see if they support the sm16716 chip, which is what i’m using.

As a side note… the sm16716 is inexpensive, but has a funky protocol that doesn’t depend on byte-sized packets, which makes it difficult to use SPI libraries (i believe wiringPi’s SPI stuff is all byte-based)… addon can be found HERE

Thanks, @DomAmato. You nailed my issue: for both of the installations I’m referring to, the rPis are in difficult to reach places. I’ve learned my lesson there!

The protocol doesn’t look as funky as WS2812s in fact its a pretty simple one, you just send each bit for each led. I haven’t played with one of those before but I may have to check it out as I’m curious about its speed.