DMX512 Data Rate “Limiter”
You get what you pay for. So if you pay squat, you get squat.
In my case, we bought super cheap LED spots to light our small-ish techno parties via DMX512. The money saved went into a pretty neat and modern lighting console. The result is that the cheap LED spots can’t keep up with data rate of the not-so-cheap console. Which causes the LED spots to do exactly … diddly-squat.
After some investigation I came up with the idea to half the data rate by masking every other DMX packet.
Easier said then done.
How it works
The lighting console we use sends a DMX512 packet with 192 channels every 28 milliseconds, that’s roughly 36 Hz. The packets don’t contain all 512 channels because the console only uses the first 192 channels. That’s good because that means there’s a rather big gap between the end of one packet and the start of the next one.
I used a 555 timer as a mono-flop which is triggered by the start of a data packet and falls back somewhere inside that gap between packets.
At this point the output of the 555 reflects the packet freqency of the DMX signal.
The signal from the 555 is then inverted using a simple transistor circuit and connected to the clock input of a D-flipflop. The flip-flop acts a simple 2:1 frequency divider by routing the inverted output back to the D input.
That signal – now with half the frequency – is fed into the ‘output enable’ pin of a bus driver.
Below, in green, is the output of the 555 timer which ist triggered by the lead in edge of the positive DMX line. The “on” time of that signal is determined by the monoflop timebase (R3 & C3 in the schematic) approximately 22 ms.
The Blue trace shows the output of the frequency divider which changes state at every falling edge of the 555 output. Since it’s the falling edge, the transitions of the control signal are well away from the DMX data. So, there’s very little danger of interference between the two. This signal then controls the output buffer. It’s negative logic, so the output is enabled when the signal is low.
And finally – in pink – the DMX output signal. Not much to say about this. On the screen it appears to be cleaner than the input signal. But that’s a lie. It’s just because nothing was connected to the output when I took the shot.
In order to supply the required current for the DMX bus without damaging the bus driver, I ganged four channels together for each DMX signal line.
The choice of components isn’t really based on necessity but on availability in my stash.
Instead of the D-flipflop I wanted to use either a proper frequency divider or a counter.
The extra transistor to invert the signal wouldn’t be necessary if I’d used a counter/freq-div with falling edge triggering. And finally the use of a bidirectional 8-bit bus transceiver isn’t a good choice as an output stage. An actual RS485 bus transceiver would have been appropriate, but I don’t have one and I didn’t feel like buying one. So, a bus driver it is.
I was planning on using a better (water proof) case … couldn’t be bothered. There’s also no protection circuitry anywhere. I built in a protection diode literally at the last minute, but if something goes wrong with that unit it could easily fry the lighting console. Well, no risk no fun, right!? Also, the circuit board is held in place by .. well .. nothing. It’s just wedged in there, somewhat fixed by the cables. It’ll be fine. For sure.