Category Archives: Cinematography

CoAP / Swift 3.0 / ESP32 research

Today, I started back into my C++ coding and research for my DMX controller.
For work, I bought the City Theatrical DMXCat in the meantime to get some semblance of what I am after out of a device.  I have even used it on set a few times.

I will probably also get an Android tablet and make it an entire controller in a case with independent power.   It has a lot of promise, but I might be working on something that can do more.

Been looking into the ESP32 micro-controller lines.  I see that they can do BLE and have an even faster clock speed than the Teensy 3.6 and have Wifi built-in.  It sucks that Wifi and BLE are so hard to do but PJRC is WAY behind on this one and I need this device now.  I have considered putting an ESP 8266 on the Pockonsole board.

However, I won’t be able to parse wifi data through CoAP unless I want to go with the much more capable ESP32..because BLE is a huge part of the requirement.

Perhaps that is how it will end up.  Looking into this guy’s work (https://github.com/oneam/Esp32LedControl), I might already have all that I need to do this.  It’s just parsing the CoAP data into a 512 value array of 8 bit ints then into the DMX Protocol working with ESP32’s UART that I need help on.

Also, an 8266 interfaced with the Teensy 3.6 doesn’t do BLE, so it is kind of useless in being a open source DMXCat replacement.  I used to think that MQTT was the way to go, but this CoAP standard seems even more interesting and robust because you can have BILLIONS of nodes asynchronously communicating.

As always, I want to think beyond current capabilities at the outset.  So CoAP looks REALLY good to ensure that…and would take care of much of the asynchronous behavior that has to happen that I have NO CLUE about at the moment.

Imagine an asynchronously programmed mesh network of LED’s  !?!?!?  It would be mind-blowing what lighting affects could be achieved.

More on this later.  I need to think on it. Just learning about CoAP now.

Red Green Blue Amber Tungsten Daylight = more color fidelity than RGB

Recently, I have been researching what it would take to bring the color fidelity of our LED’s in the film industry to the point where we are able to replicate any light source.
This interest was brought on by a fascinating podcast on fxphd about the Lightstage 6 and the SIGGRAPH paper pertaining to the LED sources in that lightstage.  The researchers discovered that there is a lot to be gained by adding more emitters to an LED rig (since LED’s have such a narrow spectrum per emitter).  They specifically mention that adding a “white” emitter and an Amber emitter at the very least goes a LONG way into helping the light to fill in those valleys in the LED spectrum that can really do some strange things to color.

During this last movie, we built a few custom wirelessly DMX-controllable RGB Tungsten Daylight Litegear panels to allow for the utmost in color variety.
While this was REALLY nice, I ended up seeing where 5 colors fell short spectrally (especially when mimicking Sodium Vapor heads) as well as wanting to evolve our entire idea in how we had been using it.
When I work on a film, I am constantly trying to improve the way that we attack certain approaches in our lighting.  Hoping to demo the evolution I’d like to see in these lights, I decided that I would make a 6 color LED panel that would add Amber to the equation.  On top of the color choices, our B5 dimmers from City Theatrical (and the wiring running to them) was very hard to rig since we had to keep redoing the rig each and every time they were added to it.  If it was raining, we had even more work to do.

My idea:  6-color LED panels that are controlled by two DMX/RDM B4 ballasts in a 100% waterproof Pelican, allowing for 2 more colors of LED’s to be added in the future.

This setup, I figured, would improve the fact that we kept having to reinvent the wheel each time we rigged the car in this movie.  We went through SO much trick line and tape that I started to wonder whether or not we should be looking into other more robust containers for the ballasts, which we were literally just taping to the side or top of the of the car most of the time.  I saw a lot of problems with this system naturally, and my mind started in on evolving the setup.

What I arrived at, while still not perfect, SIGNIFICANTLY improves the durability and ease of setup for a future project.

Waterproofing:

One thing that I am always annoyed by is that almost all of our lights aren’t actually waterproof at all.  In the case of the Arri Skypanel, we are dealing with a light that is only rated around IP20!!!!  That is sad since I actually have had to rig these to telephone poles, leaving them up over an entire rainy weekend.  While I did manage to wrap them adequately, they also tend to overheat if you make them as waterproof as they should have actually been coming off the factory floor.

Seeing this, I looked for an entire year for connectors that would actually allow us to at least have fully waterproof LED ballasts.  The problem I kept running into in my Pelican was the ports that have to enter the case.  Now, for many ports, there is probably some solution with IP68 cables, but many don’t go this far.

After COPIOUS research, however, I found the LP-20 connector by CNLinko in Shenzen.  These connectors come in 1 to 25 pin, USB3.0 , RS485, and everything you can imagine in both female and male versions both ports and connectors!  This ended up saving the project.  I bought many different varieties of these connectors and settled on:
– male Edison to female LP-20 3 pin to power the DC power supply
– 4 pin LP-20 to power the ballast pelican case for two lines of 12 Volt at 20 Amps
– male and female XLR to LP-20 5 pin in male and female (DMX adapters) for DMX without sacrificing IP68 qualities
– Pheonix 7 pin to LP-20 7 pin to power LED’s from the ballasts

DMX Control:

The biggest sticking point in this whole setup was that the ballasts I was planning to use have no knobs on them for control.  They quite literally NEED to be controlled by DMX, which is often too much to ask on a small set where there isn’t a dimmer board.  I started to price a pocket console dimmer board to run into the case, realizing that people are charging WAY too much for this stuff ($1000 for 8 faders and a plastic housing?  I’ll do it myself instead!).  I decided to build my own DMX controller that would have a power switch inside of the ballast case for those moments when I need to adjust the LED’s and don’t have a dimmer op feeding a line to the case.  It also allowed me to create a board that would allow me to be more versatile when it comes to electronic needs.

The requirements for the controller were far more ambitious than was required, but that was just because if I am going to take the time (and spend the money) to make something custom from scratch, it damn well better not just fulfill THAT immediate need but others that I may not even know about at the moment.

With this idea, the Pockonsole was born.  Behold!

I already have programmed this board to do what I originally wanted to do with it: control 8 channels of LED ballast from inside of the case, have a master fader for intensity, and be reconfigurable via open source coding.

I am already working on a version of this console that takes up much less room to sell to my coworkers.  Once you really start to make progress on this electronic stuff, you start to feel like you have some kind of superpower.  I can pull out Eagle and build something that might have never existed otherwise.  So empowering!  More to come on this subject since it has been the focus for the past month and a halff.

Working on programming a keypad for it right now.  I want the simple functionality to type in “1 thru 512 @ full” without spending $1000 on a simple device that does this.

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