Timeout period on ECG-DR4 (1.3.1 firmware)

[JonB256]

I'd never noticed it before with other controllers, but when connected to one of RJ's MR16 (16 channel DC) controllers, there is a very short timeout before it starts flashing.


Is that the Keep Alive setting? and can I increase it? and do I want to increase it?


I'm just using test software, not a sequencer, to drive the lights. When I move the slider, it is perfect. Nice smooth fades. But when I stop, 0.5 seconds later it starts flashing. Move the slider and keep moving it, and it is fine.


Using a ENTTEC Pro or Lynx dongle does not do this.


I don't see anything obvious in the configuration webpage for the DR4.

[JonB256]

I've done lots of searches and reading. It appears to be a problem that isn't really a problem. In software (Vixen or LSP), it never does it because they continue to send data, never causing a Keep Alive to trigger.


So, I'll ignore it for now.


so - for anyone who has upgraded the Master firmware from 1.3.1 to 1.3.1a, was it worth it? I'm not sure it will fix anything for the DR4.

[ɟɐsʇǝppʎ]

I have my DR4 keep alives set to 30ms and active for 512 channel, that way a dmx signal is always being sent. This is important when using LOR in dmx or cheap chinese controllers as when the controller doesnt see a DMX signal with the LOR you will get a delay as it looks to see if its a DMX or LOR signal when the signal is restarted and with some of the chinese controllers it will default to putting out a test pattern when no DMX signal is not seen.

[dowdybrown]

I finally upgraded my DR4 to firmware 1.31a. I am testing a CCR operating in DMX mode connected to the DR4. I am using xLights to test. When I only send E1.31 UDP packets when the data changes (or once every 1/2 second, whichever is sooner), then it almost seems like the CCR is only seeing every other packet. This causes obvious problems when data is changing faster than every half second (it drops half the packets). I have played with a wide variety of values in every field in the DR4 slave setup screen, including the suggested 30ms interval, but there is not a setting that seems to make any difference.


However, when I change the xLights code to send a packet every 50ms regardless of whether the data changes, then the CCR responds much better, though occasionally a bit jerky.


By comparison, I can plug a TP3244 into the second port on the DR4, run the same test, and it is flawless every time. Regardless of whether I am only sending changes or a constant stream.


I can also plug the CCR into a Lynx USB dongle and it works fine.


I can just go ahead and program xLights to send UDP packets every 50ms, but this seems like a waste of bandwidth - but maybe necessary to avoid problems.


Any ideas? Thanks,


Matt

[AussiePhil]

Matt
 
Maybe the following will just muddy the waters but hopefully not.
 
The DMX standards only mandate a minimum refresh rate of once per second for universe, for 512 channels the Max refresh rate is 44Hz.
 
Now the Lynx Dongle, (and Enttec Pro) transmits a continuous 44Hz DMX stream when it is powered on, this data stream will be the last values seen by the processor in the dongle from the USB port or all zero bits freshly powered on.
Certainly a lot of the DMX devices seem to expect this constant stream of DMX and fail to handle slower or apparent intermitant DMX streams well. Sounds like the CCR may fall into this group.
 
The DR4 keep alive settings are there so the DR4 can in effect be forced to output this constant stream of data.
 
The TP3244 firmware handles Standards Compliant DMX correctly so that will explain why it will work as expected.
 
Some DMX controllers in this hobby will struggle with Standards Compliant DMX including my own, due to the expectation of a continuous stream.
 
Interestly the way some of the cheap chinese controllers default back to a pattern is actually compliant with the DMX512 Standard
The standard says the controller should document what it will do in the event of a loss of the DMX Stream.
 
Phil

[dowdybrown]

Phil, thanks so much for the response. The only weird thing is that I couldn't find a keep-alive value on the DR4 that would solve the issue. I guess I will have to do a little more testing this weekend.


Matt

[ɟɐsʇǝppʎ]

I have the keep alives set at 60ms in the DR4 to run my CCR controllers, this way if it misses more than 1 refesh it will not go looking to see if its DMX or LOR. The CCR controllers never missed a beat all season

[dowdybrown]

OK, I had done something stupid. I had flashed the master but not the slaves on my DR4. That is why the timeouts would not work (the slaves were still on firmware 1.3.0).


But with that solved, I could finally test to optimize the timeout value! I programmed xLights to only send packets when the data changes or every 1/2 second, whichever is sooner.  This is the way the currently released version works (2012a), and I will keep it that way, now that this issue is solved. Values >=125 caused the CCR to drop packets. With values from 30 to 100 there were varying levels of jerkiness running chases across the CCR. The amount of jerkiness also varied with the rate at which the data changed. There was still noticeable jerkiness at 30ms. With a timeout value of 26ms, the jerkiness was gone - no matter how fast or slow the data changed. This is the value I will recommend in the xLights wiki.


All testing was done with the LIOP (last in overrides pending) box checked.


Matt