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

[chausman]

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

That is a new edition of DMX, but that does not mean that everyone is following it.

While we are arguing about DMX, your original post says that:

I used the built-in strobe channel: the 4 PAR's did not light at the same time

Wouldn't that mean that it was something other then DMX? DMX isn't telling it to strobe, it is decided that based on the values for a specific channel being sent to it.

EDIT:In your videos, the latency seems quite random to me, as in sometimes the one on the left will be "last" on, but then on a different flash, the one on the center right, is the "last" on.

 

[STEVETERRY]

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?

Actually, I was thinking about articles and papers given at conferences. This is not about commercial advantage, but rather about all of us learning about the new lighting business we are in due to the tectonic changes brought about by solid state lighting.

ST

 

[JD]

The thing that jumps out at me when watching your video is that you are running a software based board on a laptop. That is not inherently a problem by any means, but it does add a few new variables such as processor divide time with the OS, and a communication interface. (Assuming USB > DMX)

Time to divide and conquer. Try running off a dedicated hardware board. At least you will know if it is a downstream problem (fixtures), or upstream, such as some idiosyncrasy between the software / laptop / dongle (interface) and those specific fixtures.

Remember "Shouldn't" and "Doesn't" are not always in agreement.

 

[LiveCommander]

That is a new edition of DMX, but that does not mean that everyone is following it.

Correct. Even the text from the PLSN website that I quoted and highlighted says that and note that it also says "This has been true ever since the original USITT DMX512, but some receiver manufacturers have missed or ignored this detail. "

There would actually be some advantages in having a fixed update rate of 44 times per second since fixtures will know when to expect the next update and for example scans could adjust their speed of movement to that (although I suppose that's still possible if you assume that the packet rate at least will be constant for long period

While we are arguing about DMX, your original post says that:

I used the built-in strobe channel: the 4 PAR's did not light at the same time

Wouldn't that mean that it was something other then DMX? DMX isn't telling it to strobe, it is decided that based on the values for a specific channel being sent to it.

I don't think it's DMX itself that is causing this and I don't think I ever said that. I think it's either an underpowered microcontroller that is too busy doing PWM for all four PARs or it's sub-par programming. DMX latency as such cannot be a factor with the experiment shown in my video. It's not the actual latency as such that is bothering me (although it appears to be close to or perhaps over 1/15 of a second for the last PAR which is a bit too much for my taste), it's the fact that the four PARs are responding differently to the very same DMX (dimmer) channel value.

EDIT:In your videos, the latency seems quite random to me, as in sometimes the one on the left will be "last" on, but then on a different flash, the one on the center right, is the "last" on.

It suggests to me that the routines that are controlling the PARs PWM cycles are running freely and indepedently of each other or something like that. Since those PWM cycles must be at least 100% I don't think that would actually explain it though.

 

[LiveCommander]

The thing that jumps out at me when watching your video is that you are running a software based board on a laptop. That is not inherently a problem by any means, but it does add a few new variables such as processor divide time with the OS, and a communication interface. (Assuming USB > DMX)

I'm using a Chauvet Xpress 512 which has its own processor (it can be used stand-alone without a PC too). I doubt it puts much of a strain on the host PC, unlike for example a Chauvet Xpress 100 which is a 'cable' type interface and essentially not much more than a basic UART and is limited to 100 dmx channels and cannot be used concurrently with 3d visualization (presumably because its drivers eat to much of the host PC's CPU time).

The Xpress 512 has no such limitations and the accompanying software (which is the same for all Chauvet/SweetLight dmx interfaces but using different drivers) is happily running on my notebook doing dmx and 3d and some fairly complicated MIDI mapping at the same time with my other fixtures without any hickups either in dmx world or midi land.

This test was done with just the dmx software running and without the 3d visualizer open of course.

Time to divide and conquer. Try running off a dedicated hardware board. At least you will know if it is a downstream problem (fixtures), or upstream, such as some idiosyncrasy between the software / laptop / dongle (interface) and those specific fixtures.

It's a possibility but a remote one imho, also given the very simple test scenario of setting the value of one DMX channel to 255 for 0.1 seconds and to zero for 1 seconds. I also did the same test with 1 second 255 and 1 second to zero with the same result.

I only have access to an ancient Leprecon controller that I'm totally unfamliar with so that may not make the best choice for diagnosing any problems.

Regardless, I had to return these fixtures this morning to ensure I can get a full refund with no hassle so I can't do anymore testing.

Remember "Shouldn't" and "Doesn't" are not always in agreement.

I agree but given what I have seen I really think it's the fixture that's causing this. I think I'm gonna try my luck with some Pucks.

 

[KeeperoftheKeys]

(...)

There would actually be some advantages in having a fixed update rate of 44 times per second since fixtures will know when to expect the next update and for example scans could adjust their speed of movement to that (although I suppose that's still possible if you assume that the packet rate at least will be constant for long period

(...)

The standard allows a refresh-rate anywhere between 1Hz and about 829Hz:
- an update has to be sent at least once per second (1Hz).
- if you use the shortest possible packet following every packet directly by the next packet you get just over 829Hz.