All posts by harryprayiv

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.

Pockonsole Prototyping Platform

I am a big fan of Teensy Microcontrollers and have been working with them for a year now. The best thing about them, to me, is the speed and massive I/O compared to any other arduino board.

I recently started a project where I was going to build a simple DMX circuit with 9 faders for controlling DMX levels. As I got further in, I was inspired by Tall Dog’s Teensy 3.1/3.2 Breakouts on Tindie. I contacted my friend who is a talented EE and we sat down and worked on a custom circuit that not only breaks out the Teensy 3.6, it adds, an RS485 chip for DMX transmission, over-current protection, a regulator for up to 36V in, 9 faders, an SPI OLED screen, and a prototyping area that is inspired by breadboards with a full breakout of all unused pins all on a fairly big circuit board. I am excited about it because it will not only allow me to have a robust version of the circuit I was originally going to wire together with point-to-point wiring, it adds some of the bells and whistles (and esoteric electrical best practices) that I would have avoided (for example, a .1 uF capacitor on each potentiometer was NOT in my plan) along with being an excellent platform for future projects.

There’s a lot of expansion that has happened on this project.  Since getting a custom circuit made and designed is so damned expensive, I wanted to be getting the most bang for my buck.  More on this topic in a few minutes.  I need to document all of the stuff that Steve and I came up with as well as a fe wprojects that I haven’t quite had the time to mention and document.  Big things are happening in my life as far as learning about and transitioning to a side career in inventing film tools/engineering…and this is the coolest one yet.