Rapid DMX LED switching

[flimflam_machine]

Hi, I'm a complete newbie to the lighting game so please accept my apologies for any technical misnomers and feel free to demand clarification. I really would appreciate anyone's help on this.

 

The quick version: I need to set up a lighting system which can switch states extremely rapidly. By rapidly I mean that I want to be able to switch a particular light source on for 60 milliseconds (yes, 0.06s). The lighting-up time (i.e. from dark to fully illuminated) needs to be in the order of 10 ms (0.01s). Assuming I'll be using LEDs, how should I acheive this?

 

The longer version: we want to record some video (at about 60 frames per second) and need to switch lighting conditions between frames. The idea is to combine differently lit images from successive frames. The provisional setup is 3 RGB LED ParCans, it's pretty simple because we only need to illuminate a small area. For each can we'd like to cycle Red->Green->Blue or Red->White->Red->White really rapidly (i.e. about every 20ms). Assuming that it is physically possible for the LEDs and the power source to switch this quickly (I've done a bit of research here), the problem is how to control it. DMX consoles appear to assume that nobody would want to switch this fast and so don't allow it, which means that we'll have to use a PC-based controller. So:

 

 

Has anyone come across a piece of software that will allow timings to be entered down to the level of 0.01s?

 

Apparently it takes at least 24ms to send a full 512 channels of information. Does anyone know of software that can speed this up by sending fewer channels (I think we'll only need 12)?

 

Will a USB-DMX dongle cause us problems? As I understand it, some dongles essentially buffer the DMX signal which will reduce the rate at which we can send control signals out. Are there any that won't cause us this problem?

 

 

Thanks for reading to the end, you obviously like a challenge (or you're finding my mangling of technical lighting terms hilarious). Thanks in advance for any and all help.

[Tomo]

The DMX control protocol can't do this reliably.

 

The fastest common rate of DMX is a 44Hz refresh rate, and you won't find anything much faster that can be reliably received.

 

While several DMX controllers are capable of sending DMX at the maximum theoretical rate, many receiving devices (especially at the cheaper end) can't receive DMX at the maximum rate.

Also, many of those that can apply a slight smoothing curve to the input to reduce flicker caused by single-bit errors.

 

(If you're thinking of using the cheap LED parcans, then forget it. They can't even come close.)

 

This is why the majority of strobes have a control channel for "Rate of flash", rather than "Flash Now".

 

Finally - while some DMX controllers may let you type in numbers of lesser magnitude, anything between 0.1s and 0s is essentially false simply due to the timings of the DMX protocol itself.

(Assuming zero internal processing time...)

 

You'll need to look at other control systems to achieve this effect.

There are such things as stroboscopic controllers - have a look at those.

[boatman]

The LEDs in the cans will certainly be able to respond fast enough, the problem will be the controlling electronics. The DMX512 spec gives a minimum time between packets as 1.204ms so DMX can be fast enough for your purpose and yes, by sending less channels you can increase the refresh rate to the level that you need. For the video application you describe, you will need to synchronise the DMX packets to the frame sync. I don't know of any DMX dongle which has that capability.

 

Being a lifelong hardware hacker, ever since I built my first crystal set in 1955, I would dismantle a LED PAR can and rewrite the software in it (or possibly build a new control board), but YMMV.

 

BTW, it would help to know where you are based, although the fact that you are recording video at 60fps will give us a good clue.

[the kid]

Surely when actually watching it you wont notice to colour change because its so fast, and if you do wont it be uber strobe and effects will be like several anime's that caused a load of people to have fits.

 

Like the opening of

[flimflam_machine]

@ Tomo

 

The DMX control protocol can't do this reliably.

 

Okey doke, not a great start.

 

 

The fastest common rate of DMX is a 44Hz refresh rate, and you won't find anything much faster that can be reliably received.

 

While several DMX controllers are capable of sending DMX at the maximum theoretical rate, many receiving devices (especially at the cheaper end) can't receive DMX at the maximum rate.

Also, many of those that can apply a slight smoothing curve to the input to reduce flicker caused by single-bit errors.

 

I'd gathered that 44Hz is pretty standard, but that faster rates are possible. Could you name any of the DMX controllers that can handle a higher refresh rate? I'd like to have a look at them. One option I'd considered was tinkering with open-source PC DMX software. If I can get one of those working, then it sounds like it will be a receiving issue. It's possible that this can be solved. The system that I was looking at was 3 of these:

 

http://www.pulsarlight.com/Products/LEDLig...79/Default.aspx

 

Run through one of these control units:

 

http://www.pulsarlight.com/Products/LEDLig...57/Default.aspx

 

My understanding is that the control unit acts as a single many-channelled DMX device with the ParCans as "slaves". Apparently, they can remove the smoothing capacitors from the control unit in order to allow really fast lighting-up times. But I don't know whether this solves the problem that the receiver hardware in the control unit is use to working at 44hz or slower.

 

 

Finally - while some DMX controllers may let you type in numbers of lesser magnitude, anything between 0.1s and 0s is essentially false simply due to the timings of the DMX protocol itself.

(Assuming zero internal processing time...)

 

This is the bit that I'm hoping to get round by stripping down the actual number of channels sent to the bare minimum. Is it even theoretically possible? Obviously a computer can run at ms resolution if need be, so if we can get a piece of DMX software to exploit this we may be onto something.

 

 

There are such things as stroboscopic controllers - have a look at those.

 

Thanks for the tip, I'll check them out. Off the top of my head I think that one problem is that we need consistent lighting during the time that the video frame is being acquired. I don't know if strobe lights provide a suitable illumination profile over time. Also I'll need to be in the room, and having loads of colour filtered strobes all going off sounds horribly uncomfortable.

 

A concurrent post has been automatically merged from this point on.

 

@ Boatman

 

The LEDs in the cans will certainly be able to respond fast enough, the problem will be the controlling electronics. The DMX512 spec gives a minimum time between packets as 1.204ms so DMX can be fast enough for your purpose and yes, by sending less channels you can increase the refresh rate to the level that you need.

 

Good to know that the LEDs at least will be up to the job.

 

Just to check the maths. I understand that the minimum number of channels in a packet is 24 (plus the 1-channel start code). Each channel is 11 bytes at 4 microseconds per byte so that gives us 1100 microseconds (1.100 ms) of actual data sending time. Between packets we need a break of at least 88 microseconds (22 bits of LO) and a MAB of at least 8 microseconds (2 bits of HI) which makes the total packet time 1196 microseconds (1.196 ms). I take it that the extra 8 microseconds in the 1.206 ms that you quoted is one extra bit in the break and the MAB for security?

 

Do you have any hardware-hacker suggestions as to how to send this few channels? Are there any PC DMX controllers that we can tinker with.

 

 

For the video application you describe, you will need to synchronise the DMX packets to the frame sync. I don't know of any DMX dongle which has that capability.

 

That is an issue, but I think it's one that we'll get round somehow, especially if we go the hacker route. The cameras that we'll be using are very controllable. Can you shed any light on my other concern about dongles? Do they all have some sort of channel buffer in them, or can they essentially be "straight-through" devices?

 

I guess, in some ways, the actual refresh rate is not the most important thing. The "scene" changes will be consistently repeated ad-infinitum and they don't need to react to anything e.g., sound. So as long as the processing and data-send times are consistent (and this is an issue that Tomo has raised) we can simply anticipate the necessary changes i.e. process the packet so that it actually goes out the dongle at the required time.

 

I'm UK based, the 60 fps is simply because of what we want to get out of the video

 

Thanks for the useful info.

 

A concurrent post has been automatically merged from this point on.

 

@ the kid

 

Surely when actually watching it you wont notice to colour change because its so fast, and if you do wont it be uber strobe and effects will be like several anime's that caused a load of people to have fits.

 

We're not planning to just watch the video. The aim is to take out individual frames to do clever stuff with.

 

The photo-sensitivity issue is serious and we have considered it. Hopefully we'll reduce the problems by having the lights switch from one colour to another, rather than from on to off. I'm not quite sure what the effect will actually look like, but I think the first time we try it, it will be with the brightness set pretty low.

[Chris Adam]

I'm guessing it does have to be a "one take deal"? Or is stop motion an option? (I know, a long slow process, but would be easier by far)Certainly sounds like a challange though. I've certainly never used a DMX controller that would output quicker than 0.1s. (In fact, the avo pearl I have out just now stops at 0.2)

 

Let us know the solution and post a link to the vid if you can. Would be good to see if it all works out.

[Sony]

Just FYI, I think your math is off by a bit. 60 Frames per second comes out to 1 frame every 0.016666666666666666~ seconds

 

1 second / 60 frames = 0.01666... seconds PER frame.

[flimflam_machine]

I'm guessing it does have to be a "one take deal"? Or is stop motion an option? (I know, a long slow process, but would be easier by far)

 

Yup, it does need to be captured in one go, sadly stop-motion is a non-starter.

 

 

Certainly sounds like a challange though.

 

Oh it certainly is! That's why I'm tapping into the serious knowledge-base that is this forum. Thanks to all!

 

A concurrent post has been automatically merged from this point on.

 

Just FYI, I think you math is off by a bit. 60 Frames per second comes out to 1 frame every 0.016666666666666666~ seconds

 

Thanks, I was rounding up. There are a few possible options, one of them involves changing the lighting every frame. The other involves slower lighting changes about 15 times per second. Essentially, the finer we can control the lighting the better.

[scjb]

Wouldn't it be simpler to program a PIC to switch off-the-shelf RGB LED's? Certainly you could get the timing tighter than with DMX...

[boatman]

.

.

@ Boatman

 

The LEDs in the cans will certainly be able to respond fast enough, the problem will be the controlling electronics. The DMX512 spec gives a minimum time between packets as 1.204ms so DMX can be fast enough for your purpose and yes, by sending less channels you can increase the refresh rate to the level that you need.

 

Good to know that the LEDs at least will be up to the job.

 

Just to check the maths. I understand that the minimum number of channels in a packet is 24 (plus the 1-channel start code). Each channel is 11 bytes at 4 microseconds per byte so that gives us 1100 microseconds (1.100 ms) of actual data sending time. Between packets we need a break of at least 88 microseconds (22 bits of LO) and a MAB of at least 8 microseconds (2 bits of HI) which makes the total packet time 1196 microseconds (1.196 ms). I take it that the extra 8 microseconds in the 1.206 ms that you quoted is one extra bit in the break and the MAB for security?

 

Do you have any hardware-hacker suggestions as to how to send this few channels? Are there any PC DMX controllers that we can tinker with.

 

No, paragraph 8.7 in the ESTA DMX spec states that there is no minimum number of channels, just a minimum time between packets. There are different timing for transmitter and receiver. You need to consider the transmitter timing. Minimum 'Space for Break' is 92us, minimum 'Mark After Break' is 12us and minimum 'Break to Break' time is 1204us. Having said that you may find that a lot of DMX devices may not respond to minimum timings and need at least 'typical' timings to work. The typical timing for 'Space for Break' is 176us.

 

It is fairly trivial to generate a DMX signal. I would use an Atmel ATmega8 with a 16MHz crytal and an RS485 interface (75176, MAX485 or similar). No more than ten components in total.

 

 

For the video application you describe, you will need to synchronise the DMX packets to the frame sync. I don't know of any DMX dongle which has that capability.

 

That is an issue, but I think it's one that we'll get round somehow, especially if we go the hacker route. The cameras that we'll be using are very controllable. Can you shed any light on my other concern about dongles? Do they all have some sort of channel buffer in them, or can they essentially be "straight-through" devices?

 

I guess, in some ways, the actual refresh rate is not the most important thing. The "scene" changes will be consistently repeated ad-infinitum and they don't need to react to anything e.g., sound. So as long as the processing and data-send times are consistent (and this is an issue that Tomo has raised) we can simply anticipate the necessary changes i.e. process the packet so that it actually goes out the dongle at the required time.

 

I'm UK based, the 60 fps is simply because of what we want to get out of the video

 

Thanks for the useful info.

.

.

 

If you go down the homebrew route, then feed your frame sync into an interrupt pin and you can synchronise the DMX stream to the video. Otherwise, with a few more components you can control one of Big Clive's LED panels. Have a look at Big Clive's RGB controller. It's not ideal for your purpose but will give you a good starting point. Since you already have the PAR cans it would be a simple job to burst one open and integrate a purpose designed controller which will avoid DMX altogether.

[smackdown]

If you made your own transmitters and receivers I think you could do it. You could program a microcontroller to send the DMX at the proper rate, and you could use a homemade device that can receive at that rate. For example this one:

 

http://www.hoelscher-hi.de/hendrik/english/led.htm

 

As a test I have programmed 16-bit PIC24 microcontrollers to successfully send and receive 32 channels of DMX at over 300 frames per second. So it is possible. But it would definitely violate the DMX spec. Not that it would matter since we are not talking about developing a commercial product here.

 

Well to be honest I am working on some related stuff right now and with the parts on the table in front of me I could easily do this. Might take a couple hours. Except that I have some other stuff to do and it's past 2 am in my time zone already.

 

Since you don't really need the PC interface either, the next question is how to sync with the shutter. Does your camera have any sort of output that the microcontroller could read in order to decide when to send the next packet?

 

Actually I just read the previous replies a little more closely and I see that the LED cans probably would respond quickly enough. So all you need to do is program a microcontroller to output the signal you need at the correct rate. If you don't have to worry about frame sync it is fairly trivial. All you need is a PIC, an RS-485 transceiver, some sort of DMX cable to attach to it, assorted resistors and capacitors, power supply and maybe a button to start and stop the effect. I think you could do it for under ten dollars, plus the cost of the PIC programmer.

[flimflam_machine]

Thanks for all the info folks. We're now getting well beyond my area of competence in terms of hardware e.g., RS485 etc. I'll do some reading and more research and bump this thread with a new post when I have some questions that I can be sure that aren't daft.

 

 

It is fairly trivial to generate a DMX signal. I would use an Atmel ATmega8 with a 16MHz crytal and an RS485 interface (75176, MAX485 or similar). No more than ten components in total.

 

As a test I have programmed 16-bit PIC24 microcontrollers to successfully send and receive 32 channels of DMX at over 300 frames per second.

 

Any more links or technical specs that could flesh these out would be hugely appreciated.

 

 

Since you don't really need the PC interface either, the next question is how to sync with the shutter. Does your camera have any sort of output that the microcontroller could read in order to decide when to send the next packet?

 

Yes, I think you can run the camera as a master (presumably it outputs a rising edge for every frame) or trigger it from an external source.

[boatman]

Here's a few places to look:

 

http://en.wikipedia.org/wiki/DMX512-A

 

http://www.dmx512-online.com/

 

http://www.avrfreaks.net/

[flimflam_machine]

Thanks Boatman, Wikipedia and dmx512-online are where I've been educating myself so far, I'll check out the other site.

 

The aspect that's confusing me is how the physical layer (RS485) works to generate the DMX signal. I was hoping (probably naively) that we could simply use a "straight" through converter that would hardwire the pins of a computer's serial port (for example) to the pins of an XLR connector. Hence by controlling the serial port we could generate a DMX signal. Probably a garbage idea, and it doesn't solve the issue of whether the decoder at the far end will be abel to work at the rates we're using.

[Dmills]

Possibly a silly thought, but how about just using a colour wheel on a syncronous motor in front of the camera?

3600 RPM is a standard two pole speed for 60hz and you could sync the cameras to a spg derived from a pll off the motor drive waveform.

 

Failing that, forget DMX and use the parallel port to drive a set of LED drivers directly, you will be much happier.

 

Regards, Dan.