Easy to use open source hardware to drive WS2811 LEDs with high-quality color

Currently, the Fadecandy firmware uses a fixed strip length of 64 LEDs in order to support temporal dithering. Longer strips have a lower maximum update rate, and much above 64 LEDs there's too much flickering for it to work.

Strips with longer than 64 LEDs will never be the recommended configuration for WS2811 LEDs with Fadecandy, but it would be really useful to have a new firmware configuration mode that would support these long strips anyway.

Internally, this would require some refactoring so that we can use different RAM layouts for different firmware configuration modes. Most of the bits in the first byte of firmware configuration space will probably turn into a "mode" number, which selects a RAM layout and a redraw engine to use for that mode.

This would also require some fcserver support, so it knows about the different strip lengths. And any layout editor tool we build would really like to know this as well.

I saw the sample of running a video using processing in the examples and I think it is very interesting.

Unfortunately, for the pcduino, (the board I have currently interfaced with fadecandy) running video on processing is very very slow and I would like to use maybe cpp to directly to run a video with a shader (I think its the way to go, pipe the video from ffplay or so. I am okay with c but my shader knowledge is a bit limited)

BTW, I currently have the following setup to run the video, I externally read the pixel rgb using python on a computer and write them to a file. I load the pixels using node to read the file and set the frames with the desired framerate. It works perfectly until you add audio to it. Since you run audio and video separately this way, they have a 100 ms out of sync issue most of the time. So, it ruins the experience.

I would be grateful to anyone who can point me to a solution, just a pointer on how to proceed. Alternatively, if anyone has bumped into this issue and have found any solution I would be so happy if you could share it here.

The "zigzag" argument is handy to create daisy-chained grids, but what if we want to start from the other side? I don't think rotation gets us there, but this does.

Seems the order of my led's is GRB instead of RGB. Based on the example configs, I thought adding the string "grb" to the map would address this:

{
    "listen": ["127.0.0.1", 7890],
    "verbose": true,

    "color": {
        "gamma": 2.5,
        "whitepoint": [1.0, 1.0, 1.0]
    },

    "devices": [
        {
            "type": "fadecandy",
            "map": [
                [ 0, 0, 0, 512, "grb" ]
            ]
        }
    ]
}

I get 'unsupported json mapping instruction'. What is the correct way to modify this?

I'm really interested in the effortless rPI support in Issue #1, but until then it makes sense to have a simple rPI demo.

This could include setting up fcserver, writing effects in Python, and speeding them up with C++ code.

Or maybe this should jump straight to coding for Node, which might be fast enough to forgo the C++ code.

Would porting to the Teensy 3.6 be doable? Or would this require a complete reimplementation? I'd be willing to take a swing at this if it would be somewhat doable.

With 16x as much RAM as the Teensy 3.0 (256K), more DMA channels and a lot more CPU power I'd say it would be a big improvement, at least in the number of supported LEDs and strips.

I'm trying to follow your simple example using an LED strip (WS2812) and when I try to run the sketch in the processing IDE i get the error "the function registerDraw(OPC)" does not exist.

The error is on this line of OPC parent.registerDraw(this);

Use negative count to map pixels in reverse order along a strip.

This is useful for implementing matrices which reverse logical and physical orientation for certain segments.

I know this is not a fadecandy issue and is more of a linux issue, but I'm hoping somebody can point me in the right direction. I can't execute the fcserver-rpi script on my Raspberry Pi, and can't figure out for the life of me why.

bash: ./fcserver-rpi: No such file or directory

I have cloned the repo to ~/fadecandy and have tried executing the script both as root and as default "pi" user. I've tried chmodding to 777 and 755 with no luck, and I have also tried building the binaries with the make commands at https://github.com/scanlime/fadecandy/tree/master/server. Each time I try running the script, an error message comes back with the same text...

sudo: unable to execute ./fcserver-rpi: No such file or directory

I'm hoping that this is a simple syntax error that I'm not picking up on. Does anyone have any experience with running this on a pi?

Hello.

I have found a error on the FC schematic the RESET_B pin is not the number 26 but its the 34

In the PCB it is connected to the correct place but in the schematic it is not.

Thank you...

I am using Raspberry Pi with Fadecandy. The server is running and it works via test patterns pulldown. My issue is that I am unable to get any of the examples to respond. Any suggestions?

Thanks in advance.

Dear @scanlime ,

I just found out that the collaboration with Adafruit has ended because of a disagreement about environmental issues. I first landed at this repository to find a cryptic Readme.md (At least to non native english speakers this is more a kind of prosa and not a real statement) to then find some information about the recent events in the adafruit forum.

There were some tweets linked which were also cryptic (at least to a non native speaker they do not make a lot of sense). I guess there is some anger and frustration behind the whole topic but I would really suggest putting some statement in the Readme.md which explains what is going on (even if that means the project is discontinued and no more hardware is sold).

Thanks for the good work, we did a nice project some years ago and planned to use the board in a more recent project. We really had fun doing that.

Hello @plong0

I'm afraid I'm back! Got a segfault issue I've been trying to decode all evening and wondered if it's something replicatable.

• Rebuild server on RPi 4 using make / cmake Release / Debug (Tried all the combinations here)
• Run sudo ./fcserver config.json / sudo ./debug-fcserver config.json
• Connect Web on raspberrypi:7890 (All as expected, connects to board and identifies fine)
• Open https://github.com/scanlime/fadecandy/blob/master/examples/html/grid8x8_dots-relay.html (Connects to 7891 relay fine)
• Run https://github.com/scanlime/fadecandy/blob/master/examples/cpp/simple.cpp (or any example)

~~As soon as the first render gets sent by the client, the server segfaults.~~ When either the first or second message comes through, the server segfaults:

[1615409938:2652] NOTICE: Relay client  #connected!
Thread 3 "debug-fcserver" received signal SIGSEGV, Segmentation fault.

Running GDB shows the error is (I think) being thrown by libwebsocket_write(*cli, buffer, bufferLen, LWS_WRITE_BINARY); https://github.com/scanlime/fadecandy/blob/master/server/src/tcpnetserver.cpp#L583

which I think is being called from self->mTcpNetServer.relayMessage(msg); https://github.com/scanlime/fadecandy/blob/master/server/src/fcserver.cpp#L165

And the specific error in question is being thrown by libwebsockets, I think. lws_issue_raw (wsi=0x18, buf=0x4 <error: Cannot access memory at address 0x4>, len=28)

The length of 28 makes sense here as I was pushing just 8 leds at the time.

#0  0x1c82a4c0 in ?? ()
#1  0x00033b5c in lws_issue_raw (wsi=0x18, buf=0x4 <error: Cannot access memory at address 0x4>, len=28) at libwebsockets/lib/output.c:153
#2  0x000275cc in FCServer::cbOpcMessage (msg=..., context=0xbefff414) at src/fcserver.cpp:165
#3  0x00019964 in TcpNetServer::opcRead (this=0xbefff4f4, context=0x8e2d0, wsi=0xb53005b8, client=..., in=0x8e3f0 "", len=28)
    at src/tcpnetserver.cpp:363
#4  0x00019520 in TcpNetServer::lwsCallback (context=0x8e2d0, wsi=0xb53005b8, reason=LWS_CALLBACK_SOCKET_READ, user=0xb5300b48, in=0x8e3f0, len=28)
    at src/tcpnetserver.cpp:207
#5  0x0002e808 in lws_read (context=0x8e2d0, wsi=0xb53005b8, buf=0x8e3f0 "", len=28) at libwebsockets/lib/handshake.c:69
#6  0x00033770 in lws_server_socket_service (context=0x8e2d0, wsi=0xb53005b8, pollfd=0x8f430) at libwebsockets/lib/server.c:180
#7  0x000300b8 in libwebsocket_service_fd (context=0x8e2d0, pollfd=0x8f430) at libwebsockets/lib/libwebsockets.c:1011
#8  0x00030474 in libwebsocket_service (context=0x8e2d0, timeout_ms=100) at libwebsockets/lib/libwebsockets.c:1327
#9  0x00019348 in TcpNetServer::threadFunc (arg=0x8e2d0) at src/tcpnetserver.cpp:156
#10 0x0002b590 in tthread::thread::wrapper_function (aArg=0x96678) at src/tinythread.cpp:167
#11 0xb6e36494 in start_thread (arg=0xb641a450) at pthread_create.c:486
#12 0xb6cf3578 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73 from /lib/arm-linux-gnueabihf/libc.so.6

Having a look at the data going into libwebsocket_write, everything seems as expected:

(gdb) print buffer
$2 = "\000\000\000\030\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\377\377\377\000\000\000\000\000"
(gdb) print bufferLen
$3 = 28

Am I missing something really obvious?

Thanks again and I'll keep working away at this in the mean time just incase I've missed anything.

Sam.

Update: Running https://github.com/scanlime/fadecandy/blob/master/examples/cpp/simple.cpp with the 8x8 layout file allows a single event to come through before segfaulting!

The single event packet data seems as expected:

[[Uint8Array]]: Uint8Array(196) [0, 0, 0, 192, 0, 0, 0, 147, 156, 109, 178, 190, 133, ...

This is needed for Mac OS X Catalina because it only supports 64 bit binaries.

When you run this you will see changes to libusbx and libwebsockets directories. Since these are submodules, I am not sure what the process is for updating them.

I am also not sure if there are any tests to make sure the binary still behaves the same compiled as 64bit vs 32bit.

Fixes #132

Running fcserver-osx on macOS Catalina (10.15) results in a Bad CPU type in executable error. This is likely due to Catalina dropping support for 32 bit applications. 😭

Hello Micah

I am Tony from China. Fadecandy is a very good product. It allows users to quickly display the effects of led. But fadecandy can only be manufactured and sold in the United States. It is very inconvenient for people in Asia who want to buy fadecandy. It took more than 10 days and 30$(ship and tax) to get one fadecandy. Any plans to manufacture and ship in China or Aisa? Like raspberry pi, raspberry pi is manufactured and sold in China and UK.