LED Uplighting status

MHV Lit up in Rainbows

The LED up-lighting really does look good when it’s working. Getting them to work reliably and with the ability to write new animations for them has been a bit of a struggle. My availability hasn’t aided that.

This photo was taken back when an Arduino was generating the pattern and the DMX512 signals to operate the lights. That wasn’t ideal because there was no way to interact with them. I want them to have a default animation (like the popular rainbow which can be seen here) and also have other animations that can be triggered. I thought the best way to do this was to buy an OpenDMX USB dongle and plug it in to one of the many Linux machines in the space. I had it plugged into the Axio industrial computer and had Open Lighting Architecture running, but that was pretty crash city so I lost confidence in it.

The OpenDMX dongle is essentially just an FTDI usb-serial converter with a max485 level converter on it. I spent a bit of time getting my head around the FTDI libraries and found a Python library that was a wrapper around one of the c libs. I wrote a short python script that managed to work on the printer machine, but not on Aquillo, probably because of the fact that doing microsecond level sleeps in python is a pretty silly idea. That code is here: https://gist.github.com/devdsp/90a39a9a9b4645ffd7e8

One of the troubles with the FTDI device as a DMX driver is you need lower level access to it than the drivers for generic ftdi serial devices give you and that ends up clashing with regular FTDI devices that tend to be used in so many things like… the 3D printers attached to the printer computer! DOH! Leaving it on the printer machine is not really an option. There are some kernel drivers that can expose the dongle as a character device which are probably an option for putting on Aspirin as long as there’s a big sign that says “Beware those who’d add FTDI devices to this machine, here be driver dragons.”. I have a RasPi that might be well suited to running this but that’s a bit more yak shaving than I’m keen on right now.

I just really want a system for people to be able to design animations and save them for later triggering when some other system in the space registers an event. RFID tag ins, space opening and closing, clean up time, that kind of thing.

BTW, I grant you permission to play with this.


What about using the iMac that is on the dining table? Can it be put so it’s screen is out the window like you had the industrial PC? Happy to have linux on that instead of OSX. I should have some time to help soon…

I don’t mind where it ends up running, I’m not even opposed to it running on OSX. I don’t much mind about the dashboard. I could always put the axio back up.

just wondering if you’d tried changing the DMX device PID (product id)? This would prevent clashes between software driving FTDI devices dedicated to printers vs. the DMX interface.

Hi. I did think about it, but I wasn’t sure if that was possible to do with normal user tools. I assume I’d also be able to change the VID too. If that is possible then I might give the OpenMoko Project an email, I’ve heard they’re willing to assign PIDs under their VID to open source projects. I believe that’s how Micah got the IDs for her FadeCandy board.

Well if the FTDI’s rouge driver can change the PID? to 0 to soft-brick the device and you can revert it with FTDI tools in theory it should be possible.

Granted it is likely to not be very user friendly (given the risk involved with bricking the device if something goes wrong) and may involve using linux to be able to coax the IC to do so

Also depends on how it’s set, in vusb it’s set in the header files for the hex, in other devices it’s in the eeprom and in some cases it’s burnt into the chip (ASICs, etc) and cannot be changed

I visited MHV today, and noticed that one of the LED strips is hanging down - I think the solder join has broken…

Does anyone have time to have a meetup this weekend to improve the installation of the lights & see if we can get the software sorted out?

Hey, new member here - I met a few people at the Maker Meetup at the start of this month.

I’m happy to help on the software for this, but I’d need someone to show me how the hardware has been setup.
I’m free the rest of this long weekend.

Hello @sahan,

I’ll be at the space from 10am tomorrow, I just put up an announcement about opening.

I’d be happy to show you the hardware setup, I know where it is although not exactly what it is :smile:
Hopefully some other people will turn up to help fix up the installation.

What time do you think you are likely to arrive?

@devdsp do you have any time to drop in tomorrow?

Sounds good. I should be there from around 10.30am.

I found this code on StackOverflow to test the minimum sleep time:

from datetime import datetime
import time

def check_sleep(amount):
    start = datetime.now()
    end = datetime.now()
    delta = end-start
    return delta.seconds + delta.microseconds/1000000.

error = sum(abs(check_sleep(0.050)-0.050) for i in xrange(100))*10
print "Average error is %0.2fms" % error

I had a look at the existing setup with @brenda yesterday.

The OpenDMX dongle is currently plugged into Aspirin. When plugged in it attempts to load the normal FTDI driver, which can be unloaded with:

sudo rmmod ftdi_sio

The command should be run with the dongle plugged in otherwise the driver seems to reload itself when you plug the device back in again.

I was then able to run the dmx.py gist by @devdsp, which had to be run as root (as a normal user gets a permission error when trying to open the USB device) which was working reliably.

From my reading of the DMX specification with regards to the timing, it seems to be a minimum sleep delay required, therefore accuracy isn’t a big deal.

We’ll need to expose some kind of API for people or other systems to be able to control it.
I have some ideas on creating a sequencer web page to design some animations, unless someone knows of something suitable that already exists?

Thanks sahan and brenda. I did a tiny bit more work on the script and got it reading the spaceapi json file so it should turn the led strips on when the space opens and off when it closes.

I really like how duration.cc does colour and something like that might work at a high level. At the lower levels, working out when to run which program and how to blend multiple inputs is tricker, but might be fun to hack on as a small group.