More On Software and Hardware Engineering

This site has been pretty deserted lately. Sorry about that. I have been spending too much time on work and none on documentation.

Today, I ported a script I made in Swift 3 into Python 3.5.  It calculates exposure in the absence of one variable.  I had written complex control logic into the function in Swift, but my recent research into functional and asynchronous architectures has shown me that a separate control flow function that calls each equation to be more scalable and elegant.
The Python code:

import math
import fractions

def lVtoLux(lV): #working
return ((pow(lV, 2))*2.5)

def lVtoFC(lV): #working
return (((pow(lV, 2))*2.5)/10.76)

def lVtoLumens(lV): #working
return ((pow(lV, 2))*2.5)

def stopCalc(lV, iSO, shutterTime): # calculate T-Stop
return((math.sqrt(((math.pow(2, lV))*(iSO*shutterTime))/100.0)*100.0)/100.0)

def shutterCalc(lV, aperture, iSO): # calculate shutter speed in fractions of a second
return(Fraction((100*(math.pow(aperture, 2)) / (math.pow(2, lV)))/iSO).limit_denominator(8000))

def iSOCalc(lV, aperture, shutterTime): # calculate EV/LV/Lux
return((100*((math.pow(aperture, 2))) / (math.pow(2, lV))/shutterTime))

def lvCalc(aperture, iSO, shutterTime): # calculate EV/LV/Lux

def fcCalc(aperture, iSO, shutterTime): # calculate Footcandles



and here it is in Swift 3 (there may be some errors because I just fixed this stuff to exclude the control flow part.)

func stopCalc(ISO iSO: Double,shutter shutterTime: Double, eV:Double) -> Double {



func isoCalc(tStop aperture: Double,shutter shutterTime: Double, eV: Double) -> Double {

    return(round((100*((pow(aperture, 2))) / (exp2(eV))/shutterTime)))


func shutterCalc(tStop aperture: Double, ISO iSO: Double, eV:Double) -> Double {

    return((100*(pow(aperture, 2)) / (exp2(eV)))/iSO)


func lVCalc(tStop aperture: Double, ISO iSO: Double,shutter shutterTime: Double) -> Double {



func fCCalc(tStop aperture: Double, ISO iSO: Double,shutter shutterTime: Double) -> Double {

    return(((pow(2, (log2((100*(pow(aperture,2)))/(iSO*shutterTime)))))*2.5)/10.76)


I think I will do that with every piece of code I write, but I also want to get into the world of functional programming, which may cause me to go back to the drawing board in each language.

Category Theory is absolutely insane, but apparently, it allows for complex mappings and behaviors in software that would, for example, allow me to quickly go through all of the permutations in a piece of software.

So far, I know pieces of BASIC, C/C++ (for Arduino), Swift 4, and I am just starting with Python 3.5.  This is just a short post to get me back in the rhythm of it again.

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 (, 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.


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.