Rapid DMX LED switching

[boatman]

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.

 

The DMX signal is simply the output from a standard serial UART (8N2 in Mickey$oft speak) and a break signal to indicate the start of the packet. Any cheap microcontroller with a built-in UART should be able to generate it.

 

RS485 is the line driver standard which is differential to improve noise immunity. If you want to use DMX fixtures as light sources you will need to convert your serial port signal to RS485 levels.

 

I really think that a dedicated controller would be better for your project rather than spending a lot of time trying to get a DMX solution to work.

[musht]

No ones mentioned Professor Howard `Doc` Edgerton inventor of high speed photography:

 

http://en.wikipedia.org/wiki/Harold_Eugene_Edgerton

 

With LEDs you might want to look at actually running them at a pulsed current much higher than their continuous rating, otherwise it will probably look quite dim.

[flimflam_machine]

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

 

Not at all silly, it was our first thought in fact. You can get motors that output their spindle position and be synched together so it would give us sufficient control. Ultimately we came to the conclusion that a non-mechanical solution would be better (cheaper, more controllable and more reliable), hence the interest in LEDs.

 

 

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

I really think that a dedicated controller would be better for your project rather than spending a lot of time trying to get a DMX solution to work.

 

I defer to your greater knowlegde on the subject. Presumably the idea would still be able to use a programmable micro-controller to run the repeated sequence, and use it to control a higher wattage supply that actually powers the lamps. I've no doubt that this is possible, but it's beyond my current skill so any more advice and links would be great. BigClive's RGB controller does look like a good start (as you say), but I think we'll need something more finely programmable.

 

Keep the information and ideas coming please, this is great stuff.

[the kid]

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

 

 

In that case why not change the colour in the edit?

[smackdown]

do also check out the material at:

 

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

 

His DMX analyzer is an extremely useful tool. Also if you dig through the site you will find open source code for programming AVRs to send and receive DMX. With relatively minor modification his code can be compiled to run on PIC24 and dsPIC MCUs as well. If you build the analyzer tool it is quite useful in determining whether your constructions are successfully sending and/or receiving DMX signals and at what rate. Also he has published some code for dimming using the parallel port on these microprocessors.

 

That said, I don't want to discount the wisdom of previous remarks. It's easy for me to say that I would just make a device that would send out the proper signals all the time without user intervention, but I'm sure it would take you a lot longer to figure out how to do that than to learn how to get your MCU to flash an LED directly.

 

I guess either way you're going to have to get into something a little complex. On the one hand if you go the DMX route you have to build and program a microcontroller circuit with a UART, so it is more of a software challenge. If you want to control the LEDs directly you will have to figure out how to do that and it might be more of a hardware challenge.

[peterejones]

I don't normally frequent this part of the blue room, it's so very bright and smokey in here.

 

Can I suggest that if you need to sync pulsed lighting with a camera, that a video based solution is what you need.

 

You could use a panel or two of LED video wall, to give you very bright soft floodlights. Alternatively if you need hard spotlights, a projector shone at the action could provide this. The video could be driven off any source that can provide frame accurate video, and sync the camera to this. Maybe a hippo or catalyst would be ideal? You could edit the "lighting" using a video editing package, or using hippo's "timeline" feature you could build something which is also easy to edit. You could focus the light by creating shapes using photoshop or video software.

 

It may cost a modest budget, but it will definately work, and you can spend your time being creative. One other thought is that LED generally use single frequency light output, which doesn't nescesarily give you the colourimetry you require, whereas a projector will give you wide bandwidth light output. If you needed to soften light output from a projector, you could bounce it off something white.

 

Good luck however you proceed!!

[Sony]

a projector actually seems like a very good idea. Most LCD Projectors have a refresh rate of 60hz or higher, you just need to create a program that can change the screen color for every cycle and it shouldn't be too hard to get a frame sync going too..

[Jivemaster]

LEDs will pulse far faster than you need power FETs will switch as fast if well driven. For your project DMX is neither necessary or suitable If you can generate the sync triggers from the camera then a fast op amp will trigger a power FET to light banks of LEDs LEDs and FETs will switch in nano-seconds, so you can use currents above the continuous rating to improve brightness.

 

You may generate DMX fast enough for your purposes, good cable may well transmit it cleanly. BUT cheap commercial receivers will struggle to get up to speed and don't like being driven too fast. Also some of the better ones have so much error correction built in that fast changes may simply be seen as repeated errors and ignorred.

 

LEDs unfortunately have a poor spectral output.

 

Look also at Xenon flash tubes behind appropriate filters, there are studies published about the flash duration especially for high spped photography.

[adam2]

Does the speed of flashing/pulsing need to be variable? or would a fast enough fixed speed be acceptable?

 

What about simply useing the 50 cycle mains frequency?

 

Wire pairs of different colour LEDS in inverse parralell, wire a suitable number of such pairs in series and connect to a 12 or 24 volt transformer*, via a dropper resistance to limit the LED current to a suitable value.

You can run the LEDs at about twice the normal rating since each one of a pair will only be lit half the time.

The mains frequency is nice and stable, and easily synced to a video camera etc.

 

Make sure that the output is AC ! The term "transformer" is often used in reference to what should be called DC power supplies.

[Tomo]

Jivemaster has hit the nail on the head.

 

Basically the only way to do this is to find some way of getting a framesync pulse out of the cameras, and use that to directly fire the LEDs in the RGB sequence you want.

- I suspect this is very easy with the kit you must be using to do a reliable 60Hz framerate.

 

The best way will probably be to use a decade counter/divider IC such as the CMOS 4017.

 

Send the frame sync pulse into the CLOCK input.

Use an external Enable switch to start/stop the flashing

- You probably also want a Reset button as well so you can start from a known state.

Use outputs 0,1,2 to each drive a bank of Red, Green, Blue LEDs via suitable MOSFETs.

 

Output 3 is directly connected to the RESET input - this means that it steps 0,1,2,0,1,2 etc, with the transition to the next output occurring on the positive-going edge of the clock input.

 

The 4017 chip should be around 5 to 10 pence, if that.

 

Use the above circuit to replace the original DMX decoding circuit - if you;'re using the cheap LED parcans, then you can simply remove the original processor chip and wire your RGB outputs directly to the pins originally used to drive the LED MOSFETs. The 4017 will drive anything that a standard microcontroller can cope with, so you're unlikely to have any trouble.

 

Much cheaper than any DMX solution.

 

- Downsides:

1) There's no dimmer, and no choice of colours other than Full Red, Full Green, Full Blue.

I suspect this is what you want anyway!

 

2) You've got to dismantle the LED units you buy.

However, if you take care and the original processor chip is socketed, you could put it back together afterwards.

[Jivemaster]

IF you can get sync from the camera!

 

Set up some blocks of LEDs of sufficient brightness get a PWM or like controller for colour, running at say 500Hz or more, then switch state cotrol using fast triggered FETs 60Hzis dead slow for everything except DMX which has a full speed of 44 refreshes per second and needs fine tuning to better this, then all the reasonably priced decoder chips cannot decode this quickly.

 

With the product the final "film" may have apparent strobing and ill afflict some members of the community (Epilepsy etc).

 

There could also be issues with BBFC if there are flash frames that could be considered for subliminal message carriers in a film intended for release.

[boatman]

There have been several misleading statements about DMX refresh rates in this thread and I think it's time to clarify the situation.

 

Table 6 in E1.11-2004 states that the minimum duration for the "BREAK" is 92us and the "MARK" after BREAK is 12us. Each data slot occupies a minimum of 44us and the minimum "BREAK" to "BREAK" time is 1204us.

 

Paragraph 8.7 states that there is no minimum number of data slots. However, using the above timings, the minimum packet size is sufficient to contain a "START" code and 24 "DATA" slots, although the latter do not have to be filled. That allows a maximum refresh rate of 830 updates/sec.

 

Now, if all 512 data slots are used then the packet duration is 22.676ms which is where the refresh rate of 44 updates/sec comes from. By sending less data slots the refresh rate can be increased above the 44 u/s level and still be a valid DMX signal.

 

There may very well be a problem with fixtures that will not respond to faster refresh rates but that is because they don't comply with the E1.11 specification and not because the specification doesn't allow it. The specification also allows much slower refresh rates down to 1 update/sec, but some fixtures may decide that the DMX signal is lost with such a slow rate.

 

Perhaps this could be added to the Wiki.

[Jivemaster]

I don't doubt Boatman's information about the DMX512 standard.

 

However in the use the OP suggests DMX may not be the best control protocol. A full spec system may be fast enough if finely tuned, but many economy LED PARcans may not respond well unless their DMX decoder is fully compliant with the standard. Also any digital processing may put in enough latency to spoil the camera sync. There is no point in running DMX at it's fastest if the receivers cannot use it.

[boatman]

Yes, almost every reply in this thread has recommended a dedicated RGB LED controller synchronised to the video frame, which is the right way to go. But, since 'DMX' appears in the title, this thread will pop up in a BR search and as such it should contain valid information.

[flimflam_machine]

Thanks for all the useful advice folks. One more quick question: Can anyone recommend and RGB LED Par Can that would be relatively easy to disassemble in order to bypass the DMX decoder and control the RGB channels directly. We'll be using 3 Par Cans, and they only need to be powerful enough to illuminate a persons head so it can be videoed.

 

Tomo's response seems pretty comprehensive, although I can't claim to understand every detail of it. I think that we'll use an entirely separate controller/timer to control the lights and to trigger the cameras. If we do "remove the original processor chip and wire your RGB outputs directly to the pins originally used to drive the LED MOSFETs" what inputs do the MOSFETs need?

 

From your comment:

 

- Downsides:

1) There's no dimmer, and no choice of colours other than Full Red, Full Green, Full Blue.

 

(which isn't a problem by the way) I take it that the MOSFETs will respond to a simple hi or low input by either delivery full or no power. How are they controlled by the original DMX controller to deliver only middle brightness for any or all channels?