mrpackethead
Full time elf
If the ECG stops receiving data what is the default behavior? If i stop sending it data it stops transmitting DMX after a few seconds.. Is this what i shoudl expect?
what is the default behavior of the ECG when it receives no more data
- Thread starter mrpackethead
- Start date
dmoore
Senior elf
I'm wondering the same thing. It doesn't seem to have a heartbeat like the Lynx dongle. The Lynx seems to send a heartbeat even if it doesn't have a stream as where the ECG doesn't send a stream even when it has power. This causes problems with my DMX controllers that go into a "self test" mode when they don't see a DMX heartbeat.
IMO, it should continue the DMX stream, but drop the output levels to zero after 60 seconds or so. (time configurable would be nice)
dmoore
Senior elf
How do "other" DMX controllers work? is this typical behavior or is what the Lynx Dongle doing non-typical?
What I outlined is the typical (and expected) behaviour in the commercial DMX dimming world.
mrpackethead
Full time elf
- Thread starter
- #6
As it turns out, i was playing with nomis52's OLA on my mac.. Its got a really useful wee tool that lets you send art-net/dmx/acn etc out various ports and translate between the various protocols ( it's a lighting guys toolbox of trickery actually, and theres ports for linux and various other stuff. )..
Anyway, theres a web gui console that you can use to set levels.. However, it only sends data when theres a change ( nomis might change this to send it periodically .
Like Dmoore, my led tubes go into a test pattern if they loose dmx..
Anyway, theres a web gui console that you can use to set levels.. However, it only sends data when theres a change ( nomis might change this to send it periodically .
Like Dmoore, my led tubes go into a test pattern if they loose dmx..
I just read the DMX standard again to check what a transmitter should do.
Fact
Now the standard doesn't specify what data should be transmitted but does say that a TX device must send a NULL Start Code Packet (data packet) at least once per second.
Belief
It is commonly accepted that this data packet will contain the last values received by the transmitter, this should continue indefinately.
Fact
For a receiver the standard is even more vague with a recommendation that it should wait for 60 seconds for DMX to resume and then do if no DMX do whatever the manufacturer decides.
The requirement of the standard is that the manufacturer document what occurs and when.
-----------------
Please note the difference between TX and RX behaviour.
So for the ECG it should send a minimum of one DMX packet a second if there is no incoming E131 data, this could be all zero's at power up or the last data values received from software.
Dongles like the lynx etc fire up a DMX stream at power up at full data rate as it is obviously easier to code.
Cheers
Phil
Fact
Now the standard doesn't specify what data should be transmitted but does say that a TX device must send a NULL Start Code Packet (data packet) at least once per second.
Belief
It is commonly accepted that this data packet will contain the last values received by the transmitter, this should continue indefinately.
Fact
For a receiver the standard is even more vague with a recommendation that it should wait for 60 seconds for DMX to resume and then do if no DMX do whatever the manufacturer decides.
The requirement of the standard is that the manufacturer document what occurs and when.
-----------------
Please note the difference between TX and RX behaviour.
So for the ECG it should send a minimum of one DMX packet a second if there is no incoming E131 data, this could be all zero's at power up or the last data values received from software.
Dongles like the lynx etc fire up a DMX stream at power up at full data rate as it is obviously easier to code.
Cheers
Phil
mrpackethead
Full time elf
- Thread starter
- #8
Ed, if you read this, perhaps an option to add this as a behavior you can configure..
" If nothing is received then;
after 'N' seconds, continue to output last know data OR go to black.
I knwo what i'd perfer.. the "last know data"
" If nothing is received then;
after 'N' seconds, continue to output last know data OR go to black.
I knwo what i'd perfer.. the "last know data"
DMX dimmer packs almost always continue to keep their output levels as per the last good frame received. If there is no valid DMX input for more than a few seconds, what happens is a grey area.
In reality, most dimmer packs will hold their last levels for 60 seconds then fade to black. This is so the lights will go out eventually if someone turns the desk off (in the control booth), but forgets to turn the dimmer pack off (back stage).
No commercial dimmer would (or should) fade to black for temporary loss of DMX input. The 60 seconds grace is also designed to allow a desk to be unplugged, rebooted and reconnected (or suffer an outage) without interruption of stage lights.
I would think that a momentary loss of Ethernet should be treated the same way. ie. Keep the DMX stream going at normal rate with the last good frame. After 60 seconds (or configurable time), fade/snap to black. (all channels zero)
In reality, most dimmer packs will hold their last levels for 60 seconds then fade to black. This is so the lights will go out eventually if someone turns the desk off (in the control booth), but forgets to turn the dimmer pack off (back stage).
No commercial dimmer would (or should) fade to black for temporary loss of DMX input. The 60 seconds grace is also designed to allow a desk to be unplugged, rebooted and reconnected (or suffer an outage) without interruption of stage lights.
I would think that a momentary loss of Ethernet should be treated the same way. ie. Keep the DMX stream going at normal rate with the last good frame. After 60 seconds (or configurable time), fade/snap to black. (all channels zero)
Rev 1.1 of software is a dumb repeater. If it gets a packet it sends a packet.
We are working on simple/fixed keep alives and timeouts that we believe are in the spirit of the specs and common world practices.
These simple versions should be ready for v1.3 code being released with the shipments of the DR4 and also to be ready for upgrading the DMXRen8.
At that time we will document the defaults and then start working on enhancements, including configurable options, for future releases.
Ed
We are working on simple/fixed keep alives and timeouts that we believe are in the spirit of the specs and common world practices.
These simple versions should be ready for v1.3 code being released with the shipments of the DR4 and also to be ready for upgrading the DMXRen8.
At that time we will document the defaults and then start working on enhancements, including configurable options, for future releases.
Ed
Ed
You are a wonderful man
Cheers
Phil
You are a wonderful man
Cheers
Phil
dmoore
Senior elf
My $6 DMX modules think that is a wonderful idea! Good getting even better!
I'd vote for an option that says "send zero intensity to all channels/universes" when power is applied and there is not a signal on that universe/slave.
I'd vote for an option that says "send zero intensity to all channels/universes" when power is applied and there is not a signal on that universe/slave.
mschell
Full time elf
Glad to hear that this is being addressed. Because my limited testing of swapping between my commercial Enttec DMX USB PRO and the ECG-DMXRen 8 with a Ren48LSD with DMX firmware, I saw the lights "fade out" when sending data from the ECG, but staying on when connected to the Enttec, and I believe, RPM's DMX dongle as well.
And I did notice the lack of any flickering on the ECG status LEDs once I stopped sending changing data via LSP.
And I did notice the lack of any flickering on the ECG status LEDs once I stopped sending changing data via LSP.
mschell
Full time elf
Ed,
Any update on the plans for the next rev of code for the RenDMX8? I know you've been busy with the DR4, but I'm starting to get into the testing phase for my Christmas show - connecting controllers and the like to be sure things will work.
Also, do you plan to post the source code for the slaves PICs or just post binary firmware files? Everything I've seen on DIYC or on J1SYS.com doesn't have source for the PICs.
Keep up the great work!
Any update on the plans for the next rev of code for the RenDMX8? I know you've been busy with the DR4, but I'm starting to get into the testing phase for my Christmas show - connecting controllers and the like to be sure things will work.
Also, do you plan to post the source code for the slaves PICs or just post binary firmware files? Everything I've seen on DIYC or on J1SYS.com doesn't have source for the PICs.
Keep up the great work!
jstjohnz
Apprentice elf
j1sys said:
There is something in the E1.31 spec re a flag that signals that the sender is about to shut down. I think the frame with this flag set is sent 3 times. I'm not sure of the usefulness of that, other than it tells you that the shutdown is intentional.
I'm inclined to think that a repeater should be just that, repeat whatever it sees. I have a project similar to your ECG that I have been working on, and I have debated this point myself. I guess a user-selectable option is probably safest. I also have a board that is E1.31 directly to pixel strings, and in that case, since you know you're driving lights, going to all 0's after a period of time makes sense.
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.