Results 1 to 2 of 2

Thread: Another Home Brew Lighting System - RPi, Arduino, Teensy

  1. #1
    Join Date
    Oct 2016
    Post Thanks / Like

    Default Another Home Brew Lighting System - RPi, Arduino, Teensy

    ok, so here is my home brew lighting system. Mine is based on a raspberry pi (RPi) (not using FPP), arduino, and teensy.

    I know, I could have easily used FPP, along with the many controllers available, but where is the fun in that?

    NOTE: Everything is based on a RPi 3B. I have not yet purchased a 3B+. The 3B+ has a few enhancements that might help my system.

    I started this effort fall 2016. I had designed my own system using a RPi and arduino, and actually had a working light show for Christmas 2016. But, it had lots of problems So, after a 50% failure rate for my light show version 1, in early 2017, I started to redesign my system from the ground up. I sold my house last December and moved into an apartment while my new house was being built, so there was no Christmas 2017 show for me). I am in the final stages of developing version 2, so decided to post info on it here - maybe someone can use it or learn from it - or maybe I can learn from others.

    I won't be able to post my code here because of it's size (consists of multiple modules), so I will need to upload it on something like github for distribution. Also, I am in the final stages of the design, so there are a few loose ends that I am still "tidying up" (along with I still need to purchase a teensy and develop for it, but that is going to be super easy as it will be very similar to the code I have for the arduino).

    Forgive me as some of the terms that I will be using may be slightly different then the norm on this forum.

    The light show is mainly based on the RPi.

    I use Vixen to develop the sequence file (*.fseq), assigning generic controllers in vixen.

    The light show is based on two types of devices, a director and a controller.

    The director runs on a RPi. The director runs the show. It reads the *.fseq file, plays the media file (I use mp3 files), and sends all of the data to the controllers.

    The controller runs on a RPi also. A single RPi can be the director and a controller at the same time. The controller outputs the information to the lights.

    The director talks to remote controllers via IP, using my own simplistic protocol. Through testing, I found that two RPi's communicating over wi-fi sometimes had a latency of 100 msec or more - which is bad if you are updating lights every 50 msec). I tested the RPi with a couple different home routers with the same result. I found that the RPi's communicating over wired Ethernet had consistent latency of 1 msec or less. So, I use wired Ethernet, with the Wi-Fi radio's turned off on my RPi.

    A controller is split up with one or more "sub-controllers". Right now, it supports two types of sub-controllers:
    1. "Shift" - this is a standard non-dimming light controller. This sub-controller uses the GPIO pins on the RPi to communicate with shift registers (used to expand the number of channels, minimizing the number of GPIO pins), and then to generic SSR relays. My current controller uses 3 - 8 bit shift registers to give a 24 channel controller (number of shift registers is configurable). But, the code should support multiple shift sub-controllers on the same RPi. Since it is using RPi GPIO pins to communicate with shift registers, the shift registers and SSRs should be in close proximity to the RPi.
    2. "Pixel" - just as it sounds, a pixel controller. I have working code for a Arduino (and soon be incorporating the Teensy utilizing the OctoWS2811 library). The arduino or teensy is connected to the RPi over USB. The code should support multiple USB devices on one RPi - at code startup, I check the serial number of the attached USB device(s) to make sure it is connected to the right USB port.

    Everything is configurable via a config.xml file that is read at program start - i.e. no need to change define statements or anything in code to change number of channels, etc. I will attach a sample config.xml file at the end of this post.

    Everything on the RPi was written in python, so I have not tested the system yet on a very large scale with large number of channels. I know it is scalable, but I just don't know what the limit is - sometime in the future, if my show outgrows the speed capability of python, I will have to convert everything to C++.

    Some other interesting enhancements that I have added (again, all options are configurable through the config.xml file).
    1. PrevSlice - a time slice, i.e., the state of all the channels during that 50 msec increment - if this option is enabled, the current time slice is compared to the prev time slice, and if it is equal, then the channels are not updated because there was no change. Currently, the prevslice option is per controller, and not sub-controller.
    2. Distributed - Nondistributed mode is where the entire *.fseq file (from vixen) is on the director, the director is reading that entire file, and sending the channel info out to the controllers. It does this every 50 msec (actually the timeslice is configured as what ever is used in vixen). Distributed is where the *.fseq file is split up into multiple files, one file for each controller. These files are preloaded onto each controller. Now, since each controller has it's own *.fseq data file, the only communication that needs to occur between the director and remote controllers, is when to start what song, and then a sync message every x number of seconds (this freq is configurable). The sync message is necessary because the clock between the RPi's can drift more then desirable during a 5 minute song. I have a tool (run on the RPi) to split the *.fseq file into the multiple files.

    Ok, enough already I hope that my efforts my help someone with their home brew system. I will try and post my code shortly, and also post a picture or two of my system (I am still modifying my version 1 production controllers to version 2, as I have developed version 2 on breadboard prototype models).

    Below is a sample of a config.xml file. Each RPi has it's own config.xml file. This example, as you can see is a director and a controller with a shift sub-controller. A pixel sub-controller would be similar. Also as the director, there is one song on the list, and the list is played 1 time.

    The max error of 5 means that after 5 communication errors with a controller, the lightshow ends (I don't want my light show running, if a controller has gone out, and only half of the lights are working on the show). Every time the director sends information to the controller, the controller sends a ack back - so I have a crude way to determine communication errors.

    There are two controllers in this configuration - one is remote, and one is local (same RPi as the director).

    To schedule the lightshow, I use crontab.


    <?xml version="1.0" encoding="utf-8"?>

  2. #2
    Join Date
    Oct 2014
    Sauk City, WI USA
    Post Thanks / Like

    Default Re: Another Home Brew Lighting System - RPi, Arduino, Teensy

    Wow. Very ambitious. Good luck.


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts