Page 3 of 77 FirstFirst 123451353 ... LastLast
Results 21 to 30 of 761

Thread: SanDevices version 5 firmware information thread

  1. #21
    Join Date
    Nov 2011
    Location
    Texas
    Posts
    779
    Post Thanks / Like

    Default Re: SanDevices version 5 firmware information thread

    Quote Originally Posted by jchuchla View Post
    What's that white stuff in your driveway ? ;-)

  2. #22
    Join Date
    Mar 2012
    Location
    Lebanon, Illinois, USA
    Posts
    2,685
    Post Thanks / Like

    Default Re: SanDevices version 5 firmware information thread

    Quote Originally Posted by Lionking_Tx View Post
    What's that white stuff in your driveway ? ;-)
    I have personally checked. That "white stuff" is gone. So are most of the lights, for this season.
    Live, Laugh, Love.

  3. #23
    Join Date
    Dec 2009
    Posts
    1,216
    Post Thanks / Like

    Default Re: SanDevices version 5 firmware information thread

    Quote Originally Posted by Barnabybear View Post
    Hi Jim, thanks for all the hard work keeping the E68x's up there and challenging the others.
    I'm currently running a pair of stock E681's, they've only ever had software upgrades. I have the Wiznet upgrade kits for them (haven't needed them untill this year) and am looking to get the mod done. As you commented "but possibly requiring a minor hardware upgrade" should I hang back on the purchase if the Wiznets untill V5 is complete?
    A minor hardware upgrade would be a crystal change. You can go ahead and upgrade the Wiznets.
    The Sandevices E680/E681/E682 Pixel Controllers, part of the[SIZE=3] [COLOR=red]P[/COLOR][COLOR=orange]I[/COLOR][COLOR=blue]X[/COLOR][COLOR=lime]E[/COLOR][COLOR=magenta]L[/COLOR] [COLOR=red]P[/COLOR][COLOR=lime]R[/COLOR][COLOR=blue]O[/COLOR][COLOR=red]J[/COLOR][COLOR=magenta]E[/COLOR][COLOR=cyan]C[/COLOR][COLOR=red]T[/COLOR]
    [URL="http://www.sandevices.com"]www.sandevices.com[/URL][/SIZE] <-email jim at

  4. #24
    Join Date
    Dec 2009
    Posts
    1,216
    Post Thanks / Like

    Default Re: SanDevices version 5 firmware information thread

    Quote Originally Posted by Skunberg View Post
    We can still use our GECE?
    GECE will probably not be in the first beta release of version 5. Support for the GEs and TLS3001s will require another software module and that's not part of the first release.
    The Sandevices E680/E681/E682 Pixel Controllers, part of the[SIZE=3] [COLOR=red]P[/COLOR][COLOR=orange]I[/COLOR][COLOR=blue]X[/COLOR][COLOR=lime]E[/COLOR][COLOR=magenta]L[/COLOR] [COLOR=red]P[/COLOR][COLOR=lime]R[/COLOR][COLOR=blue]O[/COLOR][COLOR=red]J[/COLOR][COLOR=magenta]E[/COLOR][COLOR=cyan]C[/COLOR][COLOR=red]T[/COLOR]
    [URL="http://www.sandevices.com"]www.sandevices.com[/URL][/SIZE] <-email jim at

  5. #25
    Join Date
    Dec 2009
    Posts
    1,216
    Post Thanks / Like

    Default Re: SanDevices version 5 firmware information thread

    I am attaching a screen shot of one of the web pages on the version 5 user interface. Because of the additional configuration capabilities, it's necessary to go to 2 pages.

    Here's a description of what's on this page. This page is for configuring the 16 individual outputs, 1 line per output.
    Output number, eg 1-1, and output type. Output type is still done per groups of 4 outputs, and that selection is done on the other web page, display only here.

    Length is the number of pixels for pixel outputs, or the number of channels for channel-based outputs. Renard is always a channel=based output. DMX can be done both ways, as a pixel-based output or as a channel-based output depending on whether or not you're running DMX pixels (or dumb RGB pixels via a dumb to DMX controller) or other non-pixel DMX devices.

    The color order drop-down varies by output type. Standard RGB pixel outputs have the 5 possible RGB color orders. RGBW pixel types have 12 RGBW color orders to choose from. Non-pixel DMX and Renard have no color order drop-down.

    Start Universe and Channel. Much like before although there is now the ability to specify either 510 or 512 channels for each universe. 512 channels makes more sense for RGBW pixels or non-pixel DMX outputs.

    Ending Universe and channel are straightforward. but notice that universes 13-16 have been set as 512 channels per universe. For example, the 128 RGBW pixels on output 2-1 use all 512 channels of universe 13.

    The Reverse check box indicates that the output is reversed, in other words data that normally goes to the first pixel of the string goes to the last pixel. For those not familiar with the feature, imagine a roofline with a pixel controller located in the center a 2 strings of pixels, one in each direction. By flagging the left-hand pixel string as reversed, the sequencing software can address the entire roofline sequentially from left to right.

    Null pixels, same as before, except now you cannot add nulls to DMX or RENARD outputs.

    Group size is used to reduce channel count by driving pixels in sequential groups instead of individually. This is in the existing firmware. One new feature is the "Chase" flag. When set it tells the controller that it should use groups as a chase. In other words, if your group size is 5 and the CHASE is set, the string will appear to be 5 pixels long. Pixel 1 data will also appear on pixels 6, 11, 16 etc. So if you run a "chase" pattern across the first 5 pixels it will chase across the entire string.

    The zigzag feature has been improved. The zigzag feature is designed for use with a pixel matrix or megatree where the string lengths are larger than the matrix height, so strings are snaked up and down the matrix. The previous zigzag feature would ony work if the matrix height divided exactly into the string length, say a 10-high matrix with strings of 50 pixels. The new zigzag adds a "first zig" entry so that you can use zigzag even if matrix height doesn't divide evenly. Say the matrix is 12 high. The first 50-pixel string will have 2 pixels on the 5th column of the matrix. On the 2nd string you would say first zig=10 and other zigs=12.

    Finally, the DIMMER entry allows several selectable intensity levels for each output.

    Tomorrow I will poet the other web page and run through it. One new feature is a "power limiter" that you can use if your power supply isn't capable of running all pixels at 100% white. the power limiter keeps track of the cumulative intensity levels for all pixel channels, and from that it calculates total power consumption. If this exceeds the settable threshold the board will automatically dim the entire display to keep total power below the threshold.





    Attached Images Attached Images
    The Sandevices E680/E681/E682 Pixel Controllers, part of the[SIZE=3] [COLOR=red]P[/COLOR][COLOR=orange]I[/COLOR][COLOR=blue]X[/COLOR][COLOR=lime]E[/COLOR][COLOR=magenta]L[/COLOR] [COLOR=red]P[/COLOR][COLOR=lime]R[/COLOR][COLOR=blue]O[/COLOR][COLOR=red]J[/COLOR][COLOR=magenta]E[/COLOR][COLOR=cyan]C[/COLOR][COLOR=red]T[/COLOR]
    [URL="http://www.sandevices.com"]www.sandevices.com[/URL][/SIZE] <-email jim at

  6. Thanks sonic777 thanked for this post
    Likes Spyder, sonic777 liked this post
  7. #26
    Join Date
    Jun 2007
    Location
    Now in Melbourne Australia, Down Under
    Posts
    112
    Post Thanks / Like

    Default Re: SanDevices version 5 firmware information thread

    Mate, that is looking great cant wait to play with this it will make life so much easier
    Cheers

  8. #27
    Join Date
    Jan 2016
    Location
    Ashburn, VA
    Posts
    395
    Post Thanks / Like

    Default Re: SanDevices version 5 firmware information thread

    Very cool.

    Quote Originally Posted by jstjohnz View Post
    One new feature is the "Chase" flag. When set it tells the controller that it should use groups as a chase. In other words, if your group size is 5 and the CHASE is set, the string will appear to be 5 pixels long. Pixel 1 data will also appear on pixels 6, 11, 16 etc. So if you run a "chase" pattern across the first 5 pixels it will chase across the entire string.
    Not sure I get it.

    I think of a "group" as a sequential row of pixels that is controlled and reacts as a single pixel. 5 RGB pixels in a group takes 3 channels.
    Say I have a string that is 9 RGB pixels long (1-9).
    If I configure group size to be 3: pixels 1,2,3 are a group (channels 1-3); pixels 4,5,6 are a group (channels 4-6); and pixel 7,8,9 are a group (channels 7-9).

    Is a "chase" like group, but instead of sequential, adjacent pixels acting together, it is a set of pixels that are a fixed distance apart?
    Back to my string of 9 RGB pixels (1-9)
    I configure group size to 3 and turn on "chase". Are pixels 1,4,7 now in the same "group" (channels 1-3); Pixels 2,5,8 in a "group"(channels 4-6); and pixels 3,6,9 in a "group" (channels 7-9)?

    Is the lingo in the first case: "I have 3 groups of 3 RGB pixels" and in the second case: "I have 3 chases of 3 RGB pixels"


    Quote Originally Posted by jstjohnz View Post
    One new feature is a "power limiter" that you can use if your power supply isn't capable of running all pixels at 100% white. the power limiter keeps track of the cumulative intensity levels for all pixel channels, and from that it calculates total power consumption. If this exceeds the settable threshold the board will automatically dim the entire display to keep total power below the threshold.
    That's very cool.
    Is there a "simple" mode (no power limiting and no extra configuration)?
    I assume the user would have to know the max power draw of each pixel or channel and configure that on output port basis? Or is it configured as 1 value across all the ports?
    What if the power draw is not linear? (that's a silly question because of PWM, isn't it?)
    You say "dim the entire display". Is that across the output port or across the entire display?

  9. #28
    Join Date
    Jan 2016
    Location
    Ashburn, VA
    Posts
    395
    Post Thanks / Like

    Default Re: SanDevices version 5 firmware information thread

    Quote Originally Posted by jstjohnz View Post
    Group size is used to reduce channel count by driving pixels in sequential groups instead of individually. This is in the existing firmware. One new feature is the "Chase" flag. When set it tells the controller that it should use groups as a chase. In other words, if your group size is 5 and the CHASE is set, the string will appear to be 5 pixels long. Pixel 1 data will also appear on pixels 6, 11, 16 etc. So if you run a "chase" pattern across the first 5 pixels it will chase across the entire string.
    In your example screen shot, with group size set to 1, "chase" doesn't have any effect does it?

  10. #29
    Join Date
    Dec 2009
    Posts
    1,216
    Post Thanks / Like

    Default Re: SanDevices version 5 firmware information thread

    Chase is essentially a different mode for the GROUP value. With normal grouping, each GROUP consecutive pixels behaves as a single pixel, and the length of the string appears to be length/GROUP pixels. A 50 pixel string with a group of 5 would appear as 10 pixels to the controller.

    A CHASE is n consecutive pixels whos values are repeated over and over across the entire length of the string. The entire string uses GROUP*3 channels.

    A chase group with a group size of 1 would treat the entire string as a single pixel. The same would be true for a normal group with a group size = to string length. The code to reflaect the use of CHASE mode in calculating end address is not in place yet.

    The power limiting feature uses a single power per pixel value in the first go-round. There's a possibility of expanding this to allow specifying power per pixel for each output.

    Setting power limiting to 0 disables it.
    Last edited by jstjohnz; 02-24-2016 at 12:23 PM.
    The Sandevices E680/E681/E682 Pixel Controllers, part of the[SIZE=3] [COLOR=red]P[/COLOR][COLOR=orange]I[/COLOR][COLOR=blue]X[/COLOR][COLOR=lime]E[/COLOR][COLOR=magenta]L[/COLOR] [COLOR=red]P[/COLOR][COLOR=lime]R[/COLOR][COLOR=blue]O[/COLOR][COLOR=red]J[/COLOR][COLOR=magenta]E[/COLOR][COLOR=cyan]C[/COLOR][COLOR=red]T[/COLOR]
    [URL="http://www.sandevices.com"]www.sandevices.com[/URL][/SIZE] <-email jim at

  11. #30
    Join Date
    Dec 2009
    Posts
    1,216
    Post Thanks / Like

    Default Re: SanDevices version 5 firmware information thread

    Quote Originally Posted by Jerry-Rigs View Post
    Very cool.



    Not sure I get it.

    I think of a "group" as a sequential row of pixels that is controlled and reacts as a single pixel. 5 RGB pixels in a group takes 3 channels.
    Say I have a string that is 9 RGB pixels long (1-9).
    If I configure group size to be 3: pixels 1,2,3 are a group (channels 1-3); pixels 4,5,6 are a group (channels 4-6); and pixel 7,8,9 are a group (channels 7-9).

    Is a "chase" like group, but instead of sequential, adjacent pixels acting together, it is a set of pixels that are a fixed distance apart?
    Back to my string of 9 RGB pixels (1-9)
    I configure group size to 3 and turn on "chase". Are pixels 1,4,7 now in the same "group" (channels 1-3); Pixels 2,5,8 in a "group"(channels 4-6); and pixels 3,6,9 in a "group" (channels 7-9)?

    Is the lingo in the first case: "I have 3 groups of 3 RGB pixels" and in the second case: "I have 3 chases of 3 RGB pixels"




    That's very cool.
    Is there a "simple" mode (no power limiting and no extra configuration)?
    I assume the user would have to know the max power draw of each pixel or channel and configure that on output port basis? Or is it configured as 1 value across all the ports?
    What if the power draw is not linear? (that's a silly question because of PWM, isn't it?)
    You say "dim the entire display". Is that across the output port or across the entire display?
    Yes, a good way of looking at a chase is as grouping pixels that are n pixels apart.

    Pixel power consumption is generally pretty linear but can become non=linear because of voltage drop. The first revision will drop the entire display to 50%, a relatively small reduction in terms of perceived intensity. I'm going to need some real world testing to refine this but the geeral idea is to be able to prevent power supply shutdown in situations where the power supply capacity isn't sufficiet to support worst-case pixel power draw.
    The Sandevices E680/E681/E682 Pixel Controllers, part of the[SIZE=3] [COLOR=red]P[/COLOR][COLOR=orange]I[/COLOR][COLOR=blue]X[/COLOR][COLOR=lime]E[/COLOR][COLOR=magenta]L[/COLOR] [COLOR=red]P[/COLOR][COLOR=lime]R[/COLOR][COLOR=blue]O[/COLOR][COLOR=red]J[/COLOR][COLOR=magenta]E[/COLOR][COLOR=cyan]C[/COLOR][COLOR=red]T[/COLOR]
    [URL="http://www.sandevices.com"]www.sandevices.com[/URL][/SIZE] <-email jim at

Page 3 of 77 FirstFirst 123451353 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •