As the Big Movie Time Sink Winds Down

As the big movie time -sink winds down, I find myself less interested in the Wheels project and more interested in a quicker, less innovative project: A DMX Tester/Playback machine.  I talked to Matthias a few times over the course of this hiatus from Electrical Engineering projects where I focused almost entirely on my day job (as a rigging electrician on a prominent, 200 million dollar sequel to a famous franchise that I cannot currently talk about).

My friend, Eric has this device, which I have used a few times to test rigs on this movie.  He said he paid $1400 for the device.  Though I love the device, I figure that I can actually make my own for around 200 dollars total.  I could even make it open source and user-modifiable.  So, while the Hurricane Wheels project is currently on my radar, I think my free time is more wisely invested in something that a few coworkers would buy off of me.  I want to basically do exactly what the Fleenor device does, but also add in some advanced features and some hardware fader pots to allow it to be used for cues.

The fleenor design is ingenius because you can type “1 thru 512 at 100%” and it transmits a signal to turn all lights in one universe to 100 percent.  You’d think a device like the Swiss-on would be able to do something this simple in a few keystrokes, but you’d be dead wrong.  On the Swisson, there is no option for 1 through 512, which in my opinion, is totally dumb.

So far, I have made some enhancements to the fleenor idea in that you can assign channels in more advanced ways.  For example, say I want to select hundreds of lights without selecting a certain light in the sequence.  I could type “1 through 512 minus 52 through 332” and I would have each light from 1 through 512 selected while excluding channels 52 through 332.  That is powerful because the Fleenor is the cheapest way to currently achieve this and, as far as I know, it doesn’t allow this kind of “subraction” of channels.

Right now, I am thinking about only the intial features and electrical design of this box.  Here are some of the features that should reside in the beta version:

  • control of 1 universe (512 channels of DMX)
  • internal, rechargeable lithium polymer battery
  • RDM communication
  • programming language type channel assignments (1 thru 512 minus 22 thru 56)
  • ability to increment channel assignments (Image 85’s have a Hi/Lo 9th channel on each light, the programming language would have the ability to exclude or include these special channels into another submaster)
  • ability to record cues from a more advanced board and play them back (edit them eventually once I get more advanced at DMX/RDM)
  • no wireless due to FCC regulations 🙁
  • chases and pre-programmable sequences
  • LCD screen
  • 4 faders with LED, OLED, or E-INk display for each
  • Controls/Buttons: 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, Ent, Thru, Minus, @, Fader 1, Fader 2, Fader 3, Fader 4, play, pause, stop, record, Up, Down, Left, Right, Clr, Every, Light


I got the quadrature encoders working after a bit of fiddling with grounds (and not knowing jack shit about electronics, honestly).   At one point, I even fed voltage through one of the wheels backwards.  I realized my mistake when the LED didn’t go on and quickly switched it off.  No harm done.  But, for a little while, it appeared that I had done quite a bit of harm, so I contacted the wheel guy himself, Matthias in Germany and asked him about it.  He did NOT alleviate my fears.  However, it appears that I have indeed not fried them.  The wheels stopped reading for quite a while.

Yesterday, I got it all hooked up correctly after some pointers on having grounds all over the place by the creator of the Teensy at PJRC.

The problem with the quad encoder WAS actually the MOSFET circuit I had introduced as a sort of buffer between the two circuits.  The Teensy 3.1 guru himself told me that it is OK to send the 5V logic level directly into the Teensy and strongly urged against the component I had been using to step down the voltage.  Instead, he suggested this chip for such a task: the 74LCX125 Low voltage quad buffer.

I will be looking into them once I get this project settled.  An extra 6ns doesn’t seem like a lot, but if he says that 5V is OK, I can run the wheels at 4.8V and be fine for both electronic components.

That leaves me with being able to have a connected system ground and hot that are the same voltage.

USB Power or Not? How about both by simply swapping out a cable?

I have been working on finding a USB cable that doesn’t send 5V.  I haven’t had any luck.
I want to be able to keep my USB connected to the computer while I power the electronics from elsewhere.

I am thinking about building in the capability to power both of the wheels with one USB cable and, if I switch out the cable, I can suddenly flash new firmware and test it without un-patching stuff.   I just need to make sure the powered cable is never attached at the same time as the battery or mains…. something I will prevent by cutting the USB, and sticking a fused voltage regulator before the USB power in.
Might be cool to have like 10 microcontrollers attached to a hub inside the unit and be able to flash them all without connecting 10 different cables too.


Today, I finally managed to get proper values from my Hurricane Wheels.  I had been overcomplicating my work by adding that voltage level shifter in between the wheels and the Teensy 3.1.  I had (falsely) believed that the wheels would need a buffer circuit.  Cleared up and working.