SFX electronics: remote-controlled LED skin prosthetic

I’m talking to a film producer friend about a make-up prosthesis that includes small lights that need to be remote-controlled. Here’s some thoughts on practical design and safety.

Trade-offs loom large in a project like this; the practicalities of filming and production is one of the most interesting parts.

This is a living document

Technology choice: bespoke or industry?

Common industry tech like Wireless DMX needs considering.

Wireless DMX offers more robust wireless comms (CRMX) and is highly attractive if control should be centralised (e.g. a control desk and a tech who is overseeing several things). There are relatively cheap receiver chips for this for use in the lighting unit.

However, compact on-body lighting effects that are controlled by a dedicated tech often use a bespoke design, and I think that’s the correct choice for this project.

Assumed scope

I’m designing and building the electronics part of a wirelessly-controlled battery powered small light SFX.

It’s embedded in a prosthesis build by a makeup/SFX artist. Collaboration is a strong aspect here.

We need up to approx 10 units (including spares).

The light effect must be able to show different light patterns under live wireless control.

The colour and sequence of the light effect needs to be remotely controllable in real-time during shots (i.e. the lighting needs to change on narrative cues).

Remote control should be as convenient as possible. For example, a mobile phone remote control app would be much better than having to use a laptop.

We need redundancy, including the remote control aspect: a mobile remote control app should be downloadable by anyone with e.g. an iPhone.

The light effect must be filmable without artefacts (strobing, throbbing, or incorrect colour).

The light effect must be filmable under natural and artificial light, and under bright and dim light, possibly at frame rates and other PWM lighting sources of unknown frequency.

The light effect has to keep the DP and director happy which probably means, at a minimum, we can tweak:

• colour temperature
• brightness
• what patterns can actually be shown

We need adequate device battery life. At a minimum, it needs to reliably last half a day, ideally a full day.

Safety

With embedded tech that is close to people we minimise risk:

1. Barrier protection between electronics and actor, especially the power cell
2. Ideally the actor can remove the battery from their body quickly¹
3. Consider using a tough shell around any soft power pouch to mitigate penetration/crushing risk (e.g. a 3D printed PLA plus shell)
4. A power cell pouch such as LiPo shouldn’t be re-charged while in-situ on actor (recharging is the riskiest time for overheating and/or malfunction)
5. actor-worn power cells should not be mounted near face, neck, arteries, or the spine
6. Lithium cells like LiPo should be transported and charged in a safety box
7. Destructive testing during design: for example, of wires used²
8. Realistic testing: the unit might work safely on your desk, but how about for e.g. 4 hours in a realistic use case (in prosthesis/under clothes)?

Battery life

Low power off

LiPo and similar power cells tend to discharge power until the device they are powering can’t cope and goes off. The LiPo cell can then recover slightly, and later the device will power on again briefly, then drain the LiPo again, etc.

This kind of ‘cell bounce’ is bad news on a production because a dead device can appear to revive and be ok, and then time can be wasted putting in into use again, only for it to die seconds later.

One solution is implementing low power off: when the cell reaches a low enough voltage, the microcontroller permanently switches itself off; it needs some sort of manual reset (maybe a button press) when a recharged cell is attached.

Standy mode

Tests confirm that most power is used on the radio (BLE), rather than the LEDs.

Two steps to reduce power drain:

1. have radio polling for commands at intervals (say, every 200msec)
2. have a low power mode controlled from the app. In low power mode the radio is infrequently polled (every say 5 seconds) for a ‘wake up’ command which can put it back into normal mode

Production time

Lead time to production and amount of units required is crucial for approach. If you need quite a few units, and you have the time, a small custom PCB manufactured might be the best bet (e.g. JLCPCB or PCBWay). These services are quite affordable and in the past I’ve had turnaround times of a few weeks.

If you don’t have much time, and/or there aren’t many units needed, hand-connected and mounted is a possibility.

Camera-safe lighting FX

The choice of the lighting tech is critical to not getting any unpleasant surprises on the set.

In particular, lighting that uses PWM³ to control brightness and colour can be a nightmare because it can interact with the camera frame rate and artificial set lighting to create unpleasant effects (strobing, throbbing, “the wrong colour”, etc.).

For example, WS2812B colour RGB LED lighting I’ve used in my first prototype is not generally camera safe, due to its awkward 440Hz frequency.⁴

Ways to get camera-safe lighting (ordered least-to-most desirable):

1. know your camera shutter speed (and possibly shutter angle) and external lighting frequency, and use PWM tech that works with those (ugh)
2. use high frequency PWM (whereby the camera and lighting freqs become irrelevant) or ‘safe’ alternatives (see below)
3. use analogue lighting where there’s no frequency to worry about (e.g. LEDs with fixed or variable resistor)

Camera-safe alternatives to WS2812B

• “Flicker-free” LED drivers (e.g. Mean Well HLG series)
• High-freq PWM driver ICs (PCA9685, TLC5947)
• SK6812 “pro” variants (although some batches run ~1.1 kHz it seems)

For a job like this, the size and complexity of using alternatives is a big factor though. Convenience often comes with a size increase.

For this project, a low-tech analogue lighting (no PWM) feels like the right choice.

Bespoke software

1. The ESP32-C3 (or similar) needs firmware writing (listens to remote commands and control lighting).
2. An iPhone app to broadcast BLE to the ESP32-C3 (configure lighting and mode)

RF noise on production sets

BLE is designed to be resiliant, but large sets can have a lot of wireless/radio device chatter which has potential to interfere with (or reduce range) of BLE control commands.⁵ It might be interesting to use SDR on-set to see the RF pollution present (and where it’s clustered).

Examples of interference sources:

• Phones, tablets, laptops and smartwatches — potentially dozens or hundreds of BLE and Wi-Fi radios. Even devices that aren’t actively being used can transmit BLE advertisements, Wi-Fi management traffic, discovery traffic, etc.
• Wi-Fi (2.4 GHz) — production Wi-Fi, video-village networks, crew phones/hotspots, wireless routers/APs, cameras, tablets, DIT equipment, etc. Wi-Fi channels are much wider than BLE channels and can occupy a substantial part of the BLE band
• Wireless video systems — some camera-to-monitor/video-assist transmitters use 2.4 GHz, although professional systems are also commonly in 5 GHz, 6 GHz, or other licensed/unlicensed bands depending on equipment and region. A nearby high-power transmitter can be particularly troublesome.
• Wireless camera control / monitoring — cameras, gimbals, focus systems, lens-control systems, remote heads, telemetry systems, camera-control apps and accessories may use Bluetooth, BLE, proprietary 2.4 GHz links, or Wi-Fi.
• Wireless DMX / lighting control — many wireless DMX systems use frequency-hopping 2.4 GHz links. On a lighting-heavy stage there can be numerous transmitters and receivers.
• Wireless audio equipment — conventional professional radio mics are usually not in 2.4 GHz, but some digital wireless microphones, IFB-type products and consumer/prosumer audio systems are.
• Bluetooth headphones, speakers, keyboards, mice and controllers — Bluetooth Classic and BLE occupy the same 2.4 GHz band.
• Drones and remote-control equipment — many RC/control/telemetry links operate around 2.4 GHz.
• Wireless follow-focus / FIZ systems — depending on the system, 2.4 GHz proprietary RF can be used.
• Consumer IoT equipment — smart plugs, practical-light controllers, Zigbee devices, wireless sensors, etc. Zigbee/IEEE 802.15.4 also overlaps the 2.4 GHz BLE spectrum.
• Microwave ovens — relevant around catering/base/studio facilities. They produce broadband-ish interference around 2.45 GHz when operating, especially if you’re close to one.

Questions for film producer

Ask H&S adviser / production manager what their requirements are for a bespoke actor-worn electronic effect.

Requirements might relate to:

• written risk assessment/method statement
• battery protection, charging and LiPo physical protection
• maximum temperatures under both normal operation and plausible faults
• protection against shorts/overcurrent
• secure insulation and construction so conductive parts can’t touch the performer
• what happens if the electronics or firmware fails
• how it is attached/removed from the performer
• a rapid means of disconnecting power
• appropriate testing before it goes onto an actor

Unit breakdown

The form factor of the lights-on-skin part is important (we want it as thin as possible). The ESP32-C3 and battery live elsewhere, out of sight, and their compactness is less crucial; they need to be fairly convenient though.

We could use wired LEDs for the lights-on-skin part⁶, but for convenience it’s preferable to make a flex pcb containing just the LEDs (and some ballast resistors at the far end).

More to come

• Electronics