DMX-frame accurate timing in LED PAR (sets)?

[LiveCommander]

Hi,

I have a question about timing performance of LED slim PAR's. Last night I unpacked and tried my EuroLite KLS-1001 slim LED par set (4 slim pars on a bar with 12 3W TCL Led's each).

To my amazement I quickly noticed that the four separate pars do not respond at the exact same time when you control them through DMX. Even if you use the single dimmer channel which is shared between all four pars you can easily notice how the 4th light comes on a little bit later than the 1st.

Since it's only 1 DMX channel that is being changed it can't have anything to do with any latency inherent in the DMX protocol (which is pretty fast anyway) and the effect even occurred if I used the built-in strobe channel: the 4 PAR's did not light at the same time (but they almost did so I don't think it was intentional to have them strobe at different points in time).

Being an EE I suspect that the poor little microcontroller that is in this set is simply being taxed to heavily and I assume it must both PWM the LED's for dimming and take care of the incoming DMX signal.

There also seemed to be some general latency between DMX controller these lights which seemed to exceed what I would expect (DMX should be able to update 40 times per second and since I only use addressed in the range 0-64 I should be getting an even higher refresh rate).

These are my questions:

• Has anyone ever noticed a similar phenomenon with a product like this (4 PARs with one integrated DMX controller that control all four)
• If you use separate LED PARs each with their own individual DMX input and set them at subsequent DMX addressed, will you be able to notice them switching on not synchronously? I also have some ancient Martin RoboColors and if I control their individual shutters they seem to be in perfect sync.
• Any recommendations for a similar 4x slim LED PAR set with known accurate DMX response and timing? MUST have TCL or QCL led modules.

I'm hoping some manufacturer is using a higher spec'd microcontroller but I was not expecting this at all so I'm not quite willing to just order something similar from other entry or mid level manufacturers like ShowTec, ADJ, Chauvet etc. Blizzard lighting does not seem to be available here but I think they are entry level too, right? And afaik Blizzard only makes separate PARs (which has its advantages of coure).

The SKL-1001 cost EUR 520 / US$ 740 excluding VAT so that's EUR 620 / US$ 185 per light (including suitcase and T-bar) and I don't really want to spend more than that.

 

[douglasheriot]

I've never worked with one of those fixtures with 4 LED slim PARs, but regularly use a group of 4 individual cheap eBay LED PARs. While I don't usually see any latency like that, I have noticed that sometimes when they're all set to strobe, the last one is ever so slightly delayed. These are rigged in pairs, on each side of the stage with about 15m of cable in between.

 

[DuckJordan]

I'm pretty sure that I've had these problems with any led pars. It gets added to by using non dmx cable that would be the first I check. If its not that then I have no suggestions since I've never had experience with the "high end pars"

Sent from my ADR6300 using Tapatalk

 

[JD]

Compared to modern data systems, DMX operates at the speed of an 1800's telegraph system, so I don't think it is a matter of a processor being taxed. Still, the DMX data is refreshed at a rate faster than the human eye could ever hope to detect.

Most likely, the DMX signal is being obscured by noise and it is taking the circuit in the LED many passes before it gets a packet that it considers valid. Cable type, proper termination, and ground loop noise would be on the top of my list.

 

[LiveCommander]

Compared to modern data systems, DMX operates at the speed of an 1800's telegraph system, so I don't think it is a matter of a processor being taxed.

Many of the microcontrollers that were current when DMX was introduced are still being used today in all sorts of equipment so you might be surprised. As was suggested by someone over at BlueRoom it could also just be sloppy programming.

Still, the DMX data is refreshed at a rate faster than the human eye could ever hope to detect.

Exactly. But even if that wasn't the case, I was only changing the one shared dimmer channel so all lamp respond to the very same byte that is being transmitted in this case.

Most likely, the DMX signal is being obscured by noise and it is taking the circuit in the LED many passes before it gets a packet that it considers valid. Cable type, proper termination, and ground loop noise would be on the top of my list.

I was using a brand-new (never been used before) proper DMX cable. There was only this one 15 ft cable running directly from my USB DMX interface to the KLS-1001 and it was the only fixture connected. The DMX interface was connected to my laptop which takes its power from an non-grounded AC/DC adaptor (which would cause galvanic separation anyway) so the notebook is never grounded but it wasn't even plugged in.

Now I did forget to plug a terminator into the DMX OUT of the KLS-1001 but somehow with this cable length and it being the only cable and only and therefore last fixture on the circuit I doubt that reflections could have been causing any problems. However I suppose I should check it one more time with a terminator plugged in to make sure.

Since there were no other glitches of any kind I doubt the terminator is going to make any difference (I will try it though) given that even the built-in strobe function was showing the same behavior and that I was only controlling the single shared dimmer channel which applies to all four 'lamps'. Here's the DMX channel layout of this fixture:

Effect
Dimmer
Shutter
Red
Green
Blue
Red
Green
Blue
Red
Green
Blue
Red
Green
Blue

If there was any 'crosstalk' on one of the first three shared channels it would (or should if it is properly designed) certainly affect all three lamps identically. If there was any interference on any of the individual RGB channels I should have been seeing color glitches.

 

[LiveCommander]

I've never worked with one of those fixtures with 4 LED slim PARs, but regularly use a group of 4 individual cheap eBay LED PARs. While I don't usually see any latency like that, I have noticed that sometimes when they're all set to strobe, the last one is ever so slightly delayed. These are rigged in pairs, on each side of the stage with about 15m of cable in between.

As long as the cabling is ok the distance between the fixtures should be irrelevant but what DMX addressed are you using for these fixitures on the left and right side? Every DMX channel takes 44us to send so if the one on the left is at DMX channel 1 and the one on the right at DMX channel 512 the second fixture would be lagging 512x44us= 22.5ms or 0.0225s or just over 2/100 of a second. I think it's possible to detect this, especially if you can see both PARs from the (different) corners of your eyes.

Of course if you PARs are on nearby channels this would not explain it, I really don't think you could see a timing difference of, say, 10x44us= 0.00044 or less than 4/10000 of a second.

Then again if you have them at say channels 5 and 10 and hit the button on you your controller just as it has finished transmitting channel 5 that you get a simlar delay of (512-5)x44us delay.

In general I wouldn't be totally (but stil somewhat) surprised to see such problems if all fixtures are set to strobe individually. I'd love to hear from people who have noticed such timing differences with the fixtures' shutter/dimmer channels being controlled directly from software not using any built-in strobe or macro functions.

I'm going to send an email to Blizzard Lighting to see if they can tell me something about how their Puck series does in this regard. Only problem is I can't get them here locally in the Netherlands so I'd have to import them. Is Farralane a good place to do business with?

 

[LiveCommander]

I'm pretty sure that I've had these problems with any led pars. It gets added to by using non dmx cable that would be the first I check. If its not that then I have no suggestions since I've never had experience with the "high end pars"

Using just one proper and brand-new DMX cable. How far apart are your LED pars in terms of DMX channels?


Thanks to everybody for your suggestions. If anyone can recommend a specific (slim) LED PAR (Tri-Color or QCL LEDs only) that has known accurate timing and response I'd love to hear from you.

 

[LiveCommander]

This video on YouTube of the Puck 3 suggests that it will do what I want:

‪The Puck 3

I'm not sure if what I'm looking for can actually be captured on video accurately but the scanning/strobing effect on the short strobe as captured by the video cameras's vertical scanning (hope you get what I mean) seems to suggest that they turn on and off pretty much simultaneously, at least well within 1/30 of a second.

 

[douglasheriot]

As long as the cabling is ok the distance between the fixtures should be irrelevant but what DMX addressed are you using for these fixitures on the left and right side? Every DMX channel takes 44us to send so if the one on the left is at DMX channel 1 and the one on the right at DMX channel 512 the second fixture would be lagging 512x44us= 22.5ms or 0.0225s or just over 2/100 of a second. I think it's possible to detect this, especially if you can see both PARs from the (different) corners of your eyes.

That's an interesting idea. The ones on the right side are around 20 DMX channels after the first ones. As you said, that shouldn't really be noticeable. Nothing we have is really very high quality, so almost every part of the system could be a factor…

 

[JD]

DMX should be able to update 40 times per second and since I only use addressed in the range 0-64 I should be getting an even higher refresh rate.

Sync followed by 512 bytes no matter how many channels are used. Unused channels are written as zeros.

 

[DuckJordan]

I'm pretty sure. You aren't going to find a single par that will be synchronized with every other in the real world. It doesn't matter how many channels used. Or what type they are. It comes from the daisy chaining and from the lights listening to the dmx signal. It may miss the first 3 packets and finally read the last one but that would throw it off as well as if it is towards the end of a chain.

Sent from my ADR6300 using Tapatalk

 

[JD]

as well as if it is towards the end of a chain.

As DMX is a backbone topology with pass through connectors, and the signal is traveling at about 186,000 miles per second, I suspect any difference between "first in chain" and "last in chain" would not be visible to the human eye.

 

[LiveCommander]

Sync followed by 512 bytes no matter how many channels are used. Unused channels are written as zeros.

I'm sure that is true for some or many (or perhaps even all) DMX controllers in existence. But although I don't have a copy of the actual DMX512 standard document (wish I had one), every technical description of DMX that I have read says that a packet can consist of up to 512 slots (channels) and that fewer may be sent. In fact Wikipedia says

A maximum-sized packet, which has 512 channels (slots following the start code), takes approximately 23 ms to send, corresponding to a maximum refresh rate of about 44 Hz. For higher refresh rates, packets having fewer than 512 channels can be sent.

Note that I'm not relying on this, 44 updates per second is quite enough for my purposes.

 

[LiveCommander]

I'm pretty sure. You aren't going to find a single par that will be synchronized with every other in the real world. It doesn't matter how many channels used. Or what type they are.

In this particular case with the KLS-1001 we're talking about a single fixture with presumably a single DMX decoder that drives four PARs. Missing packets should not cause any timing differences between these four pars.

It comes from the daisy chaining

How is that? I'm not familiar with DMX input/output hardware design and I assume there is a buffering circuit between them rather than a hardwired pass-through but with a maximum of 32 DMX fixtures allowed any delay added by such circuits should be completely negligible. Total combined length of the cables cannot possibly be a factor either.

The only thing that adds a significant delay is the relatively slow data transmission speed of the protocol with each channel taking 44us to transmit and all channels being transmitted in order (ie you can't sent just channel 60, you'll have to send channels 1 to 59 first).

and from the lights listening to the dmx signal. It may miss the first 3 packets and finally read the last one but that would throw it off as well as if it is towards the end of a chain.

I find that hard to believe. Although DMX has no error detection or correction it is a simple and apparently robust protocol. As long as your cabling, termination etc is ok and within specs I find it unlikeley that it would miss several packets in a row on a regular basis (I'm sure it can happen on occassion though).

In this particular case it cannot explain what I'm seeing as there's only one fixture and only one single brand new proper DMX cable from controller to fixture which has a terminating plug in its DMX out so nothing else is connected. If it's unable to reliable receive each and every packet there would be something very wrong with this fixture.

I'll try uploading a video later today that I think will show that whatever is happening is not being caused by my DMX controller or cabling.

 

[STEVETERRY]

Hi,

I have a question about timing performance of LED slim PAR's. Last night I unpacked and tried my EuroLite KLS-1001 slim LED par set (4 slim pars on a bar with 12 3W TCL Led's each).

To my amazement I quickly noticed that the four separate pars do not respond at the exact same time when you control them through DMX. Even if you use the single dimmer channel which is shared between all four pars you can easily notice how the 4th light comes on a little bit later than the 1st.

Since it's only 1 DMX channel that is being changed it can't have anything to do with any latency inherent in the DMX protocol (which is pretty fast anyway) and the effect even occurred if I used the built-in strobe channel: the 4 PAR's did not light at the same time (but they almost did so I don't think it was intentional to have them strobe at different points in time).

Being an EE I suspect that the poor little microcontroller that is in this set is simply being taxed to heavily and I assume it must both PWM the LED's for dimming and take care of the incoming DMX signal.

There also seemed to be some general latency between DMX controller these lights which seemed to exceed what I would expect (DMX should be able to update 40 times per second and since I only use addressed in the range 0-64 I should be getting an even higher refresh rate).

These are my questions:

• Has anyone ever noticed a similar phenomenon with a product like this (4 PARs with one integrated DMX controller that control all four)
• If you use separate LED PARs each with their own individual DMX input and set them at subsequent DMX addressed, will you be able to notice them switching on not synchronously? I also have some ancient Martin RoboColors and if I control their individual shutters they seem to be in perfect sync.
• Any recommendations for a similar 4x slim LED PAR set with known accurate DMX response and timing? MUST have TCL or QCL led modules.

I'm hoping some manufacturer is using a higher spec'd microcontroller but I was not expecting this at all so I'm not quite willing to just order something similar from other entry or mid level manufacturers like ShowTec, ADJ, Chauvet etc. Blizzard lighting does not seem to be available here but I think they are entry level too, right? And afaik Blizzard only makes separate PARs (which has its advantages of coure).

The SKL-1001 cost EUR 520 / US$ 740 excluding VAT so that's EUR 620 / US$ 185 per light (including suitcase and T-bar) and I don't really want to spend more than that.

This is not an uncommon problem on low-performance LED luminaires. Unless the software was designed and tested to make DMX frame lock a priority, it may very well be that the fixtures are grabbing data from multiple DMX packets, depending on what else they are busy doing with PWM, color calculation, etc.

This points out that we need a new vocabulary for specifying LED fixtures. Performance issues that we previously took for granted must be identified and called out in our specs.

Latency is one of these items, but so are thermal droop, color accuracy, color consistency between fixtures, etc.

I hate to say it, but the chances of getting high performance in all these areas on a cheap-and-cheerful fixture is nil. Now, I make no judgment on your particular fixture, as I have no experience with it.

So, as in other areas, it may be that you get what you pay for!

ST

 

[JD]

How is that? I'm not familiar with DMX input/output hardware design and I assume there is a buffering circuit between them rather than a hardwired pass-through

No. Just a hard wire pass through, no buffering. Cannot rule out any exceptions, but have yet to open a fixture and find anything else. There is good reason for this. Although not in the DMX standard, there are fixtures that talk back (see RDM RDM - ControlBooth ) and a buffer circuit would block this.

I'm sure that is true for some or many (or perhaps even all) DMX controllers in existence. But although I don't have a copy of the actual DMX512 standard document (wish I had one), every technical description of DMX that I have read says that a packet can consist of up to 512 slots (channels) and that fewer may be sent.

Regarding DMX-
"DMX is a basic serial data protocol EIA-485. The data stream consists of a start bit, 512, 8-bit data blocks and an end bit that is transmitted 44 times per second, which works out to a baud rate of 250k. The data blocks contain a value between 0 and 255."
You can generally trust the Wiki here to be quite accurate.
(See DMX http://www.controlbooth.com/wiki/DMX )

 

[Pie4Weebl]

This points out that we need a new vocabulary for specifying LED fixtures. Performance issues that we previously took for granted must be identified and called out in our specs.

Latency is one of these items, but so are thermal droop, color accuracy, color consistency between fixtures, etc.

I hate to say it, but the chances of getting high performance in all these areas on a cheap-and-cheerful fixture is nil. Now, I make no judgment on your particular fixture, as I have no experience with it.

So, as in other areas, it may be that you get what you pay for!

ST

A bold new vocabulary which I'm sure you will be willing to provide us with on more and more promotional material in the coming months right?

 

[LiveCommander]

This is not an uncommon problem on low-performance LED luminaires. Unless the software was designed and tested to make DMX frame lock a priority, it may very well be that the fixtures are grabbing data from multiple DMX packets, depending on what else they are busy doing with PWM, color calculation, etc.

That's my guess as well. As I write in another forum, I think it's all down to manufacturers wanting to use the cheapest/slowest microcontroller they can make a functioning product with. For most applications this would suffice but for my somewhat more stringent requirements on timing it's not. I wonder what controller is in there.

This points out that we need a new vocabulary for specifying LED fixtures. Performance issues that we previously took for granted must be identified and called out in our specs.

Latency is one of these items, but so are thermal droop, color accuracy, color consistency between fixtures, etc.

I hate to say it, but the chances of getting high performance in all these areas on a cheap-and-cheerful fixture is nil. Now, I make no judgment on your particular fixture, as I have no experience with it.

So, as in other areas, it may be that you get what you pay for!ST

If you compare this video that I made to the demo of the Puck 3 I have some hope that the Puck will perform a lot better:

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

Compare this to the following demo showing four Puck 3 fixtures which do some impressive strobing:

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

Even if this is using the built-in strobing all four fixtures must have received the command to start strobing at pretty much the same instant for them to strobe with such synchronicity.

EDIT: Check out 1:34 to 1:58 of the Puck demo video in particular.

 

[LiveCommander]

No. Just a hard wire pass through, no buffering. Cannot rule out any exceptions, but have yet to open a fixture and find anything else. There is good reason for this. Although not in the DMX standard, there are fixtures that talk back (see RDM RDM - ControlBooth ) and a buffer circuit would block this.

In that case daisy-chaining can certainly not be causing any significant delay and even if there was buffering I'm sure the delay from the packet/slot transmission time is many times larger.

Regarding DMX-
"DMX is a basic serial data protocol EIA-485. The data stream consists of a start bit, 512, 8-bit data blocks and an end bit that is transmitted 44 times per second, which works out to a baud rate of 250k. The data blocks contain a value between 0 and 255."
You can generally trust the Wiki here to be quite accurate.
(See DMX DMX - ControlBooth )

Maybe the Wiki needs updating. From PLSN | New Edition of DMX512-A Available | Edition, New, Dmx, Data, Lighting :

New Edition of DMX512-A Available

NEW YORK—A new edition of a lighting protocol that started with DMX 512 is now available. ANSI E1.11 - 2008, Entertainment Technology - USITT DMX512-A, Asynchronous Serial Digital Data Transmission Standard for Controlling Lighting Equipment and Accessories, can now be purchased from The ESTA Foundation. The path to the document starts at ESTA Foundation - Publications - About Publications, Browse & Purchase . The list price is $40; member and quantity discounts are available. ANSI E1.11 - 2008 is the most recent updating of the ubiquitous lighting control protocol that started with the USITT DMX512 standard in 1986. It corrects errors and clarifies text in the 2004 edition and adds functionality.

An important clarification is the maximum update rate. The maximum rate is 44 Hz if 512 data slots are being sent, but it can be almost 20 times faster if a data packet contains fewer slots. This has been true ever since the original USITT DMX512, but some receiver manufacturers have missed or ignored this detail.

 

[KeeperoftheKeys]

There is no minimum slot count in DMX, but there is a minimum break-to-break time, 1204us, which is more or less equivalent to 24 slot times.
How you fill said period is entirely up to you (as long as you stay inside the spec), you can lengthen inter-slot times, you can lengthen break times etc.

However most gear/software does not automatically shorten the packet and raise the refresh rate when you aren't using all 512 slots/channels, it is something you generally have to explicitly configure.

Explicitly configuring shorter frames and higher refresh rates is not recommended since gear with weaker controllers (and/or manufactured by someone who did not realize the possibility of higher refresh rates) may not be able to handle the higher refresh rates. (Just shorter frames @ 44.1 Hz or less should generally be fine)

LiveCommander
Then again if you have them at say channels 5 and 10 and hit the button on you your controller just as it has finished transmitting channel 5 that you get a simlar delay of (512-5)x44us delay.

As far as the distance between slots goes if 'go' gets pressed while a frame is being broadcast, I may be wrong here, but I think that the frame that is already in the broadcast buffer (and partially broadcast) would not be affected by the 'go' anymore and only the next frame would contain the new values.
Obviously this will differ between implementations but an on the fly rewrite of the frame from the point you are at requires so much extra complexity in hw and sw that I can't imagine it being worth the <=1/44th of a second gain.

A slightly offtopic question:
- TCL and QCL are companies, or types of LEDs?