what is the default behavior of the ECG when it receives no more data

jstjohnz said:
But when just converting from E1.31 to "standard" DMX, you can never know for sure what you're driving, and an approach that's a fix for some may cause grief for others.
Click to expand...

Ed's 60 second time-out/keep alive is a workable solution for now (for me). I would like the option to have something that allows you to continue sending a keep-alive heartbeat as long as the ECG is powered up though.
 
Just my two cents here, the way the Lynx Dongle and Enttec Pro behave the way they do in keeping the DMX signal going with last received values takes a very large load off the processor doing the sending in that it only has to send updates as needed instead of sending all over and over again within a certain time frame. Windows and even Linux can cause issues with these time frames as they are not entirely deterministic, asyou have other processes competing for those time slots. When too many things start competing you could have intermittent dropouts if an external adapter is not there to pick up the slack. When we start running these 3k and 4k channels, you are starting to get into a lot of horsepower that is going to be required to keep all those channels updated at the proper rate.

Ed, you are doing a wonderful job. I got my DR4s the other day and they look great. Kind of wish I would have gotten the enclosure too, but I guess I will have to make do.

Ryan
 
Re: rmonty's post

The DMX USB PRO and Lynx dongles "buffer" the signal, in that they hold the last values sent to them and continue to send those values down the wire.

I would like to see that behaviour duplicated on the DR4 and DMXRen8, or at least as an option. Many of the controllers designed here and on DIYC will either turn off or slowly fade if they don't get a DMX signal for awhile. This somewhat mirrors the default behavior of LOR and Renard controllers - since they don't change the state of their output unless they get a message down the wire.

I've been struggling with getting my ECG-DMXRen8 properly configured again - either with Vixen or LSP, but then I had to decommission the laptop that I was using...

If the v1.3 source code for the slave section gets posted, then I'll take a look at it.
 
v1.3.0 does include a simple dmx keep alive that is hard coded.

I thought I had documented WHAT it does. I could have done it in chat and never posted it. I did announce that it did it just never defined what it did.

On DMX only the slave will initialize a universe buffer to all zeros and send that out immediately upon reset/power-up. Then it follows the keep-alive rules below.

Any time a DMX slave has not received a universe packet in 333ms it will check the keep-alive logic. For 30 keep-alive periods (10 sec) it will resend the last universe packet in its buffer. After 30 keep-alives periods have passed it will clear the buffer to zeros and then continue for 30 more keep-alives (another 10 sec). After that it will cease to transmit.

As a hard-coded implementation of a simple keep-alive this seemed to match what most people were asking for and was introduced mainly as a test to see if my ideas were headed in the right direction.

v1.3.1 will allow the user to configure all of the parameters discussed above. They will be able to enable/disable the entire keep-alive operation, enable/disable the startup logic, define the keep-alive period, enable/disable the clearing of the buffer at a period count, and set the total keep-alive to their own limit or 0 for indefinite.

The specs, as I read them, allow for any of this and simply say that the manufacturer should define the action that will be taken for this. I'm not 100% sure I agree with how the other devices do this and I have not copied their logic but, with the configurable parameter, will allow the user to setup their system to match the needs of their environment either forced on them by other equipment needs or based on their own personal opinions of how it should be done.

v1.3.1 will default to the behavior of v1.3.0 and then can be configured from there.

All of this will only work for DMX. I will add Renard keep-alives in a future release but will have to add more configuration variables and screens since the size of the Renard 'Universes' can vary greatly based on the baud rate and refresh speed.

-Ed
 
Ed, you never cease to amaze me. Thanks for the update and sounds like a very flexible implementation.

Ryan
 
You must log in or register to reply here.
Back
Top