Remote Control Delay Problem

[Gordon Lights]

I seem to be having and issue with remote controlling Madrix from Light-O-Rama S2 via DMX. I have replicated this on two different computers. Here's my different test scenarios and the results.


1. Enttec USB DMX Pro Output using Enttec Pro Utility SEND TEST, sending to another Enttec USB DMX Pro Input using Enttec Pro Utility RECEIVE TEST. Changes are received immediately, test passed.


2. Enttec Pro Utility SEND TEST output via Enttec USB DMX Pro to Enttec USB DMX Pro Input using Madrix DMX Watcher. Changes are received immediately, test passed.


3. Light-O-Rama (using both Hardware utility and sequencer software) output via iDMX-1000 to Enttec USB DMX Pro Input using Enttec Utility RECEIVE TEST. Changes are received immediately, test passed.


4. Light-O-Rama (using both Hardware utility and sequencer software) output via iDMX-1000 to Enttec USB DMX Pro Input using Madrix DMX Watcher. Changes are very consistently received about 20 seconds late., test failed. Other DMX devices on the same universe, in fact in the same physical chain, responded as expected, not late.


Any thoughts?


Thanks for your help.


Fabian

[Wissmann]

The first 3 test works and the last not sounds strange ????
The only idea we have for the moment is to check the sending frequency of your light o rama. Maybe it is to fast for our Enttex USB Pro implementation.
You have a chance to test a different input interface? MADRIX USBone?

[Gordon Lights]

You have a chance to test a different input interface? MADRIX USBone?

I have not tried a different interface but would be willing to try your USBone if I can find one to borrow.

Fabian

[Fritzsche]

I just wanted to update this thread with some information we have gathered about the situation:

The ENTTEC USB DMX PRO uses a built-in memory to buffer incoming DMX values (DMX-IN).
Instead of overwriting the buffer every time with new data, the incoming values are queued. Hence, DMX-IN is stored in the buffer and send to output in succession.

Of course, the buffer has a limited capacity. When you input a lot of data, you can actually cut the physical connection and the interface will still output data that is stored in its buffer. In our test this was about 20 sec.
The interface will not output any new data until all the input buffer has been emptied (i.e. before the queue has been processed)!

When sending with a high frame rate, the input buffer is likely to overflow and thus creating a delay. This effect is further amplified by MADRIX as it captures with a certain maximum input frame rate and cannot "empty" the queue fast enough.

In general, we recommend to send full frames to the ENTTEC interface. Also, the DMX512 Standards speaks of a standard maximum frame rate of 43/44Hz. We highly recommend sticking to these standards.
Frame rates that are too high might result in poor performance of interfaces from other manufacturers as well.

[neilric99]

Will the release 2.13b which was released today 10/27/11 resolve this issue

from the release notes

◦Device Manager, ENTTEC USB DMX PRO: Increased FPS (up to 200FPS) for Input (DMX-IN).

Neil

[Pinzer]

The version 2.13b did not complete resolve the issue, it only gives you now a chance to set the reading framerate in madrix up to 200 fps. If the input which is sending to the enttec interface is higher then 200 fps then the delay will still exist. But we can't go higher in the framerates because this will reduce speed of all other processes in Madrix, which makes no sense. So if you really want to read DMX input data with higher framerates then please use an other interface which can handle this better.