Firmware v1.3.1 now available

j1sys

There are no rules, and those are the rules.
Community project designer
Joined
May 19, 2010
Messages
242
Location
Knoxville TN USA
The newest release of the firmware for the ECG (DMXRen8 and DR4) is now available in the download area on www.j1sys.com

This release includes three major updates:

1) Hash Table Multicast Filtering - the software now takes advantage of a hash table filter that is available in the hardware of the ENC624 Ethernet chip. This is transparent to the user and just helps reduce the processor load on the master processor in a heavily loaded multiple ECG environment. We still recommend Unicast as the most efficient transmission method and the ECG is still not fully compliant with the multicast protocol so you have to be sure your multicast aware switches are set for repeating all multicast packets out all connections.

2) User Configuration Of Keep-Alive Operation - there is a new set of parameters available on a per-slave basis on the slave configuration screen to enable/disable keep-alives, set the interval, and the clear and repeat interval count.

3) Last In Overrides Pending (LIOP) - each slave has a FIFO buffer that allows for multiple universes to be queued up for transmission by the slave. This can add some latency and is not necessarily appropriate when receiving a burst of packets all destined to the same universe. The current (non-LIOP) mode would queue up 4+ universe packets and then discard any additional overruns. Then the transmitter might take approximately 100ms to transmit the queued packets. LIOP mode examines the FIFO buffers and replaces (overrides) the queued data for the targeted universe thus keeping the queue to a minimum and always transmitting the most recent data available when the current buffer is depleted. The slave still queues multiple packets for multiple universes where needed for hyperDMX functionality.

The Master/Slave software should be updated to the same revision level. The Master should be flashed and then each Slave should be flashed and then the unit powered off to reboot. Be sure to read the information on the firmware download page about what software combinations are needed to program each processor.

If problems arise downgrade both master and slaves back to the same revision level. With all the new parameters the configuration memory had to be reorganized and all configuration data will be lost when upgrading or downgrading the software so be sure to document your current settings before proceeding. So your v1.3.1 Master should show all v1.3.1 Slaves as shown below:

MainPage.PNG


The configuration screen has been changed to include all the new parameters:

SlaveConf.PNG


Under protocol parameters (equivalent to the old configuration screen) we have added a new check box to enable the LIOP option. You can enable/disable it on a per slave basis.

A new section has been added to the configuration screen to configure the keep-alive parameters. On a per slave basis you can:

1) enable/disable keep-alive

2) enable/disable startup clear universe option

3) define the keep-alive interval in milliseconds

4) define an interval count since the last packet has been received at which the slave should clear (zero) the keep-alive buffer to then send all zeroed packets for the duration of the total keep-alive period. if set to 0 the buffer will not be cleared.

5) define an interval count that will terminate the keep-alive. if set to 0 the keep-alive will never terminate and will continue transmission until the unit is powered off.

6) define the initial universe size to be used for the startup cleared keep-alive if enabled. this is only used during startup keep-alive. The actual received universe size is used for all subsequent keep-alives.

The receipt of any new packet will take precedence over the pending keep-alive and reset the counters to start a new interval and a new count of interval to determine whether clear count (if any) has been reached or if the keep-alive should be terminated.

The example above has set all of the parameters to a conservative default. All keep-alives are enabled, all slaves will send zeroed universes on power-up/reboot to clear any outstanding lighting commands, the keep-alive interval is set to 500ms, the keep-alive buffer will be cleared after 10 intervals (5 seconds), the keep-alive will stop after 20 intervals (10 seconds), and for all Renard slaves the initial universe size is set to 128 slots while the DMX universe is set to 512 slots.

You can play with any of these parameters to tune the keep-alive to your particular needs. If you reduce the interval to less than the time it takes to transmit your universe it will, in essence, start keep-alives immediately UNLESS another packet has arrived. But since this may then take approximately 25ms to complete you will be adding a latency that we believe will be detrimental to the response time of the system. If you feel you need a quicker keep-alive than our 500ms example we would suggest never going less than 2.5 times your transmission period.

The startup keep-alive is enabled independently of the overall keep-alive but uses the Total Count to limit the zeros or to keep transmitting indefinitely if the Total Count is zero.

You might try the example values, power-up your unit, examine the stats and watch the lights to see the 20 zeroed keep-alive transmissions that occur and then the unit will go into idle state. Then transmit some data and you will see the 10 keep-alive transmissions with the last data received followed by the 10 keep-alive transmissions with zeroed data to clear your lights for a total of 20 additional keep-alive transmissions.

Please give it a try and let me know of any helps on lag times, better control on keep-alives, or any problems.

Ed
 

dmoore

Senior elf
Joined
Apr 26, 2010
Messages
586
Location
Houston, TX, USA
Thanks for the update to allow for the keep-alives and for the highly detailed instructions to go with it.

On a side note - what is the "usual" refresh rate (in ms's) inside of LSP?
 

Blickensderfer

Ohio, USA
Joined
Jun 6, 2010
Messages
390
Location
Gnadenhutten, OH
Ed,

I was successfully able to flash the DR4. But when I try to configure it via web browser it asks for un/passwd and I type in the admin/EthConGwy and it just repeats the login screen over and over again. It doesn't let me get past it.

I'm I missing something?

EDIT: I tried Firefox and had no issues. So I was thinking it was IE8 and I had to turn on Compatibility View and everything was working correctly.

Thanks,
Dan
 

j1sys

There are no rules, and those are the rules.
Community project designer
Joined
May 19, 2010
Messages
242
Location
Knoxville TN USA
i do use safari for most testing. i guess i need to start final testing with IE8 also. but at least safari or firefox should work.

-ed
 

SmartAlecLights

Im a SmartAlec what can i say!
Community project designer
Joined
May 4, 2010
Messages
1,533
Location
Murray Bridge, S.A.
Ed if the DR4 is working great for me.. do i realy need to upgrade the firmware.
im mainly waiting for the firmware so we can change the password an the ability to flash the board via its webpage.
P.S. thanks for a great product.
alec
 

j1sys

There are no rules, and those are the rules.
Community project designer
Joined
May 19, 2010
Messages
242
Location
Knoxville TN USA
Alec -

especially this time of the year - if it's not baroque don't fix it.

the update adds enhancements. no known bugs that would effect operation except perhaps some buffer overrun problems some people are having.

if it is working now, i wouldn't touch it!!!

-Ed
 

SmartAlecLights

Im a SmartAlec what can i say!
Community project designer
Joined
May 4, 2010
Messages
1,533
Location
Murray Bridge, S.A.
Ed i agree 100% with you. "If it aint broke dont fix it"
Your product is great, vixen never crash's now an im using the DR4 with 2 ch for 2ren64 = 4ren64's, an a tiger120 on another channel.
I have'nt noticed anything wrong with your product, thats why i was wondering if i really need to update.

smartalec
(one happy customer)
 
Top