05/30/2017 please see post #446 for firmware for UPGRAED 680s and E681s.
05/29/2017 now v5.030. Added support for driving RELAYS and a few other changes, see pg 44 post #435 for details.
Update 12/05/2016 the current version 4 firmware revision is now 4.078, it is attached here in place of the prior 4.051 version. Fixes the data corruption issue when a UInicast universe is received that the board is not configured for.
Update 11/28/2016. Version 5.023 attached is latest. Includes fix for WS2813 pixels.
Update 07/28/2016 version 5.018 for E682 and E6804 attached, also prelliminary doc file.
DMX issues resolved I believe. DMX TIMING selection now allows choice of sending specified number of channels or force full 512 channel frame by adding pad channels of 0s.
No longer need restart after changing output type between 3wire/4wire.
Renard issues resolved I think.
Power Limiter function is operational. Allows capping total pixel power consumption. See docs. Units are # of equivalent full intensity pixel channels.
Known bugs:
The controller name input entry still has issues. Somebody needs to teach me some HTML 101.
Flicker in RGBw mode of type 6818 pixels.
The ending address universe number may display as 65535 for output 4-1 after loading factory default setup.
Not all combinations of grouping/chase/reverse are working correctly. Understatement.
End address channel number is not calculated correctly if the group size doesn’t divide evenly into length.
---------------------------------------------------------------------------------------------------------------------------------------
Update 07/22/2016 version 5.016 for E682 and E6804 attached. Also attaching version 4.051 if you want to go back from v5 beta to version 4, use 4.051 as it is the current release version and is compatible with all boards.
A lot of the recent work has been 'under the hood' stuff to consolidate the code. Now, it's a single program that works on all hardware platforms. That will mean a lot less time on my part to do future updates.
Also, for the original V5 I was hoping to cram all of the pixel-related assembly language code into one object. That was not to be, so now using 2 assembly objects, one to handle all 3-wire pixel types and the other for 4-wire pixels.
That ate a lot of time but had to be done. I have not yet had time to tackle the optimization of the E1.31 data transfer to accomodate more universes. The room is there however. I can bump it up to 12 universes but it won't do 40 frames per second refresh rate.
GE pixels are back, but no TLS3001 yet.
I think Renard has some issues, not really tested yet.
The pixel types that I have tested appear to work fine.
I believe that RGBW and RGBw (derived white) pixels are working fine.
Subnet mask set automatically based on IP address. is now a settable parameter again rather than being
A couple of known issues:
You will need to restart the controller after changing an output type from a 3-wire pixel to a 4-wire pixel or vice versa.
The controller name field input is still screwy.
Test patterns will only work properly for 510-channel universes. With 4-channel pixels (RGBW) and 512 channels per universe the test patterns will look strange.
The Power Limiter is still not implemented but should be soon.
Working on some docs.
-----------------------------------------------------------
Update 05/11/2016
I will list known bugs here:
Known issue: In test patterns 4-6, the chasing bright pixel does not light consistently. Fixed but not yet released.
In Art-Net and Unicast modes, incoming pixel data is shifted by 1 or 2 channels when a universe boundary is crossed.
05/11/2016 FIXED IN 5.003, attached.
-------------------------------------
Version 5 firmware is in the works and is actually a bit ahead of schedule. Questions, comments and suggestions are welcome.
Initial release will be for the E682 and upgraded E680s and E681s, in other words, this is for the 16-output controllers.
The primary goal of this release is to overcome some significant addressing limitations of the current firmware. With existing firmware, on all controllers except the E6804, you specify one length, one start address, and one color order for each group of 4 outputs, and addresses for those 4 outputs are always assigned sequentially.
This is not convenient for users who have many different string lengths.
With version 5, you will be able to set any start address and any length on each of the 16 outputs. In addition, color order, pixel grouping, and zigzag can be set per-string (as well as per-string nulls and reverse which you can already do). The zigzag function has been improved so that you can specify 2 values: the number of pixels until the first zig, and the number for all subsequent zigs. This allows the zigzag feature to be used on a matrix or megatree even if the string length is not an even multiple of the matrix height.
Version 5 will support RGBW pixels in 2 modes. In RGBW mode the sequencing software is expected to send 4 channels of data to each pixel. In derived white mode (idea from Joe Hinkle), the controller only receives the R, G, and B channels, then it derives the final value for the RGBW channels to be sent to the pixel. This allows use of RGBW pixels with standard RGB sequencing software.
I expect (not 100% guaranteed yet) to be able to handle 16 universes of pixel data with version 5, with the potential to do even more , but possibly requiring a minor hardware upgrade. In addition to increasing the total number of pixels that can be controlled from 2,040 up to about 2,700, it also allows users to configure the controller as "1 output = 1 universe". The concept of universes is confusing to many users, and a lot of folks think that outputs and universes are the same thing, and have trouble dealing with 16 outputs but only 12 universes.
Version 5 will support 512 or 510 channels per universe. I'm not sure exactly how that will be done, whether global (entire board), per output group, or per universe.
By the way, the output type will still be assigned per groups of 4 outputs. That's a hardware limitation right now. I am freeing up at least one CPU so that opens up the possibility of a 5th output group in a future design.
Multiple DMX modes: DMX Pixel mode allows use of features such as color order, grouping, reverse, zigzag, and also length is specified in pixels, and standard DMX mode where the length is specified in number of channels. Renard output 'length' will also be specified in channels also, and there will be support for multiple baud rates for Renard outputs.
Multiple timing options for 1804/2811 class pixels.
Output addressing settable as universe-channel number or just as a relative channel number.
A controller name field on the web page, and a short controller name field that will appear in the browser tab, to simplify controller identification in multi-controller setups.
Not coded yet but on the wish list:
Support for SACN Priority, and SACN HTP (highest takes precedence).
Undo command to undo multiple levels of configuration changes.
A name field for each individual output.
Auto addressing of outputs.
05/29/2017 now v5.030. Added support for driving RELAYS and a few other changes, see pg 44 post #435 for details.
Update 12/05/2016 the current version 4 firmware revision is now 4.078, it is attached here in place of the prior 4.051 version. Fixes the data corruption issue when a UInicast universe is received that the board is not configured for.
Update 11/28/2016. Version 5.023 attached is latest. Includes fix for WS2813 pixels.
Update 07/28/2016 version 5.018 for E682 and E6804 attached, also prelliminary doc file.
DMX issues resolved I believe. DMX TIMING selection now allows choice of sending specified number of channels or force full 512 channel frame by adding pad channels of 0s.
No longer need restart after changing output type between 3wire/4wire.
Renard issues resolved I think.
Power Limiter function is operational. Allows capping total pixel power consumption. See docs. Units are # of equivalent full intensity pixel channels.
Known bugs:
The controller name input entry still has issues. Somebody needs to teach me some HTML 101.
Flicker in RGBw mode of type 6818 pixels.
The ending address universe number may display as 65535 for output 4-1 after loading factory default setup.
Not all combinations of grouping/chase/reverse are working correctly. Understatement.
End address channel number is not calculated correctly if the group size doesn’t divide evenly into length.
---------------------------------------------------------------------------------------------------------------------------------------
Update 07/22/2016 version 5.016 for E682 and E6804 attached. Also attaching version 4.051 if you want to go back from v5 beta to version 4, use 4.051 as it is the current release version and is compatible with all boards.
A lot of the recent work has been 'under the hood' stuff to consolidate the code. Now, it's a single program that works on all hardware platforms. That will mean a lot less time on my part to do future updates.
Also, for the original V5 I was hoping to cram all of the pixel-related assembly language code into one object. That was not to be, so now using 2 assembly objects, one to handle all 3-wire pixel types and the other for 4-wire pixels.
That ate a lot of time but had to be done. I have not yet had time to tackle the optimization of the E1.31 data transfer to accomodate more universes. The room is there however. I can bump it up to 12 universes but it won't do 40 frames per second refresh rate.
GE pixels are back, but no TLS3001 yet.
I think Renard has some issues, not really tested yet.
The pixel types that I have tested appear to work fine.
I believe that RGBW and RGBw (derived white) pixels are working fine.
Subnet mask set automatically based on IP address. is now a settable parameter again rather than being
A couple of known issues:
You will need to restart the controller after changing an output type from a 3-wire pixel to a 4-wire pixel or vice versa.
The controller name field input is still screwy.
Test patterns will only work properly for 510-channel universes. With 4-channel pixels (RGBW) and 512 channels per universe the test patterns will look strange.
The Power Limiter is still not implemented but should be soon.
Working on some docs.
-----------------------------------------------------------
Update 05/11/2016
I will list known bugs here:
Known issue: In test patterns 4-6, the chasing bright pixel does not light consistently. Fixed but not yet released.
In Art-Net and Unicast modes, incoming pixel data is shifted by 1 or 2 channels when a universe boundary is crossed.
05/11/2016 FIXED IN 5.003, attached.
-------------------------------------
Version 5 firmware is in the works and is actually a bit ahead of schedule. Questions, comments and suggestions are welcome.
Initial release will be for the E682 and upgraded E680s and E681s, in other words, this is for the 16-output controllers.
The primary goal of this release is to overcome some significant addressing limitations of the current firmware. With existing firmware, on all controllers except the E6804, you specify one length, one start address, and one color order for each group of 4 outputs, and addresses for those 4 outputs are always assigned sequentially.
This is not convenient for users who have many different string lengths.
With version 5, you will be able to set any start address and any length on each of the 16 outputs. In addition, color order, pixel grouping, and zigzag can be set per-string (as well as per-string nulls and reverse which you can already do). The zigzag function has been improved so that you can specify 2 values: the number of pixels until the first zig, and the number for all subsequent zigs. This allows the zigzag feature to be used on a matrix or megatree even if the string length is not an even multiple of the matrix height.
Version 5 will support RGBW pixels in 2 modes. In RGBW mode the sequencing software is expected to send 4 channels of data to each pixel. In derived white mode (idea from Joe Hinkle), the controller only receives the R, G, and B channels, then it derives the final value for the RGBW channels to be sent to the pixel. This allows use of RGBW pixels with standard RGB sequencing software.
I expect (not 100% guaranteed yet) to be able to handle 16 universes of pixel data with version 5, with the potential to do even more , but possibly requiring a minor hardware upgrade. In addition to increasing the total number of pixels that can be controlled from 2,040 up to about 2,700, it also allows users to configure the controller as "1 output = 1 universe". The concept of universes is confusing to many users, and a lot of folks think that outputs and universes are the same thing, and have trouble dealing with 16 outputs but only 12 universes.
Version 5 will support 512 or 510 channels per universe. I'm not sure exactly how that will be done, whether global (entire board), per output group, or per universe.
By the way, the output type will still be assigned per groups of 4 outputs. That's a hardware limitation right now. I am freeing up at least one CPU so that opens up the possibility of a 5th output group in a future design.
Multiple DMX modes: DMX Pixel mode allows use of features such as color order, grouping, reverse, zigzag, and also length is specified in pixels, and standard DMX mode where the length is specified in number of channels. Renard output 'length' will also be specified in channels also, and there will be support for multiple baud rates for Renard outputs.
Multiple timing options for 1804/2811 class pixels.
Output addressing settable as universe-channel number or just as a relative channel number.
A controller name field on the web page, and a short controller name field that will appear in the browser tab, to simplify controller identification in multi-controller setups.
Not coded yet but on the wish list:
Support for SACN Priority, and SACN HTP (highest takes precedence).
Undo command to undo multiple levels of configuration changes.
A name field for each individual output.
Auto addressing of outputs.
Last edited:
