Milliseconds

I'm hoping you meant 35 milliseconds (0.035), not 3.5 (0.0035) milliseconds?

Keep in mind that on the DMX and sACN level, the maximum refresh rate you're going to see is ~44Hz, or ~22 milliseconds. A 35 millisecond follow, even if possible, would not arrive exactly after 35 milliseconds, but rather with the next DMX packet that is sent.

The shortest amount of time we can do at the moment on a cue timing level is a hundreth of a second (.01). Using timecode you can get down to a single frame (0.033s or 33ms) - the same provision about when the DMX packet will actually be updated applies.

So this asks the question a bit - what's the use case? What's requiring this timing window?

I'm hoping you meant 35 milliseconds (0.035), not 3.5 (0.0035) milliseconds?

Keep in mind that on the DMX and sACN level, the maximum refresh rate you're going to see is ~44Hz, or ~22 milliseconds. A 35 millisecond follow, even if possible, would not arrive exactly after 35 milliseconds, but rather with the next DMX packet that is sent.

The shortest amount of time we can do at the moment on a cue timing level is a hundreth of a second (.01). Using timecode you can get down to a single frame (0.033s or 33ms) - the same provision about when the DMX packet will actually be updated applies.

So this asks the question a bit - what's the use case? What's requiring this timing window?

Hi,

Sorry, I think what I am trying to say is 3 seconds and 5 deciseconds... If that makes any sense.

In any case when I am programming it seems that I can only program 1 second to be the smallest time unit. Not 1 hundredth of a second as you say is possible ( I think that is what you are saying?). Is it by chance that I need to change the dmx to send out packets faster than I am currently doing?

also I am trying to design and program lighting for a dance team with a song that has beats in between seconds.

Cue 2 Follow 3.5 Enter