Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 40

Thread: New SanDevices V5 firmware coming soon

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

    Default Re: New SanDevices V5 firmware coming soon

    I spent the last 2-3 days trying to track down a very weird issue. When I make a lot of firmware changes at one time, it's not unusual to find that I have broken something that previously worked. I was testing and realized that my 2811-compatible pixels would not light up white. All of the standard test patterns worked, but as soon as I tried 25%, 50% etc white, the pixel would go almost completely dark. Other test pixels, 2801s, worked just fine.

    When using sacnview and changing RGB settings with sliders, all was fine until all 3 intensity settings approached the same value, at which time the pixel dimmed and went out.

    I've never seen this type of issue. It looked like the processing that I do when running RGBW pixels from RGB data. In that case the controller derives the W channel value from the RGB values, and if, for example, RGB values are all equal, it sets RGB to 0 and copies the original RGB value into W. So it was acting just like that, except these pixels did not have a W channel so the pixel just went dark when trying to display white.

    Anyway, I spent a ridiculous amount of time trying to track this down and came up with nothing. Finally, the light bulb clicked and I decided to test a different set of pixels. They worked fine. So, something about this particular set of pixels is causing them to act very weird when trying to display white, and all of my troubleshooting time could have been saved if I had tried swapping pixels first.
    Live and learn.

    Now to figure out why those pixels are acting that way.....

    The point? That's my excuse for being a bit behind schedule on this release.
    Sandevices E682/6804

  2. #12
    Join Date
    Dec 2009
    Posts
    1,236
    Post Thanks / Like

    Default Re: New SanDevices V5 firmware coming soon

    Quote Originally Posted by dkulp View Post
    HTTP headers always use CRLF (2 bytes, dec 13 and 10) for the line separator, and then there is a blank line (again CRLF) between the header and the payload. Thus:

    HTTP/1.0 200 OK(CRLF)
    Content-Type: text/html(CRLF)
    (CRLF)

    This appears to work, not sure if it was the blank line, CRLF instead of CR, or both.

    I will try to get you a page dump of the html source.
    Sandevices E682/6804

  3. #13
    Join Date
    Dec 2014
    Location
    Grand Rapids, MI
    Posts
    44
    Post Thanks / Like

    Default Re: New SanDevices V5 firmware coming soon

    Has a command been added so software like xLights can get and set the controller configuration without having to parse the raw HTML web page and posting multiple HTTP requests?
    Scott H.

  4. #14
    Join Date
    Dec 2009
    Posts
    1,236
    Post Thanks / Like

    Default Re: New SanDevices V5 firmware coming soon

    My apologies for the prolonged delays. I will get firmware posted here as soon as I can.
    Sandevices E682/6804

  5. #15
    Join Date
    Dec 2009
    Posts
    1,236
    Post Thanks / Like

    Default Re: New SanDevices V5 firmware coming soon

    OK, I would like some input please. I know this is very long and probably not of interest to a lot of folks but there's not a short way to describe it.

    One of the additions on the version 5 firmware was an attempt to make the zigzag function more versatile. The zigzag is primarily intended to be used when creating a pixel matrix. The zigzag function basically says, every N pixels, reverse the direction of the pixels. Say you are creating a matrix that is 25 pixels high and 32 pixels wide, using 16 strings of 50 pixels. Each pixel string would form 2 columns of the matrix, 25 pixels going up from the bottom to the top and the next 25 pixels coming down from top back to the bottom.
    By using the zigzag function, and setting segment length to 25, the controller would effectively reverse the address order of the last half of each string. Then the sequencing software that is driving the pixels sees the matrix as 800 consecutive pixel addresses.

    That's the ideal case, where the pixel string length is an exact multiple of the matrix dimension and all you need to specify is one zigzag factor because all segments are the same length.

    However, you often don't have an ideal case and the string length may not be an even multiple. That creates a problem. Say, for example, matrix height is 40 and string length is 100. The first string would zig at 40, then again at 80, easy enough. The 2nd string starts in the middle of the 3rd column and would zig at 20 then again at 60. That's what v5 was designed to do, to allow you to have a first zigzag segment length (20 in this case) AND a zigzag segment length for all other segments of that string (40 in this case).

    But there is an even worse case. Say matrix height is 30 and string length = 100. The first string covers the first 3 columns and the top 10 pixels of the 4th column. Then the second string does the bottom 20 pixels of the 4th column, columns 5 and 6, and the bottom 20 pixels of the 7th column.

    In this case we create a situation where the address ranges of two pixel strings can overlap. For simplicity, I'm just looking at relative addresses within the matrix where the 1st column is addresses 1-30, 2nd column is 31-60, etc.

    In this last example the address ranges of the first string segments are 1-30, 60-31 (goes down because this segment is reversed), 61-90, and 120-111. Note the gap between pixel 90 and pixel 111.
    The 2nd string's addresses would be 110-91, 121-150, 180-151, 181-200.

    What would you call the start address of that string? Is it the address of the 1st physical pixel of the string? The lowest address in the range of addresses for that string?

    I can see this creating mass confusion.

    I warned you that this wouid be boring.

    Looking for suggestions:

    1) Eliminate zigzag and let the sequencing software handle it.
    2) Go back to v4 version, one zigzag segment length.
    3) Have 2 zigzag segment lengths, but limit to cases where every pair of strings exactly fits N columns.
    4) Try to make it universal and figure out how to deal with start addresses and overlapping address ranges.
    5) ???
    Sandevices E682/6804

  6. #16
    Join Date
    Mar 2015
    Location
    Bloomingdale Ga
    Posts
    229
    Post Thanks / Like

    Default Re: New SanDevices V5 firmware coming soon

    Quote Originally Posted by jstjohnz View Post
    Looking for suggestions:

    1) Eliminate zigzag and let the sequencing software handle it.
    2) Go back to v4 version, one zigzag segment length.
    3) Have 2 zigzag segment lengths, but limit to cases where every pair of strings exactly fits N columns.
    4) Try to make it universal and figure out how to deal with start addresses and overlapping address ranges.
    5) ???
    For me personally, somewhere between 1, 2, and 3. I only have a small Tune to sign Matrix and it's all one string, other than my Mega tree.. Why not just let the software do it?
    Rayhjr I Love This Stuff!

  7. #17
    Join Date
    Nov 2010
    Location
    Hammonton, NJ
    Posts
    243
    Post Thanks / Like

    Default Re: New SanDevices V5 firmware coming soon

    Quote Originally Posted by jstjohnz View Post
    OK, I would like some input please. I know this is very long and probably not of interest to a lot of folks but there's not a short way to describe it.

    One of the additions on the version 5 firmware was an attempt to make the zigzag function more versatile. The zigzag is primarily intended to be used when creating a pixel matrix. The zigzag function basically says, every N pixels, reverse the direction of the pixels. Say you are creating a matrix that is 25 pixels high and 32 pixels wide, using 16 strings of 50 pixels. Each pixel string would form 2 columns of the matrix, 25 pixels going up from the bottom to the top and the next 25 pixels coming down from top back to the bottom.
    By using the zigzag function, and setting segment length to 25, the controller would effectively reverse the address order of the last half of each string. Then the sequencing software that is driving the pixels sees the matrix as 800 consecutive pixel addresses.

    That's the ideal case, where the pixel string length is an exact multiple of the matrix dimension and all you need to specify is one zigzag factor because all segments are the same length.

    However, you often don't have an ideal case and the string length may not be an even multiple. That creates a problem. Say, for example, matrix height is 40 and string length is 100. The first string would zig at 40, then again at 80, easy enough. The 2nd string starts in the middle of the 3rd column and would zig at 20 then again at 60. That's what v5 was designed to do, to allow you to have a first zigzag segment length (20 in this case) AND a zigzag segment length for all other segments of that string (40 in this case).

    But there is an even worse case. Say matrix height is 30 and string length = 100. The first string covers the first 3 columns and the top 10 pixels of the 4th column. Then the second string does the bottom 20 pixels of the 4th column, columns 5 and 6, and the bottom 20 pixels of the 7th column.

    In this case we create a situation where the address ranges of two pixel strings can overlap. For simplicity, I'm just looking at relative addresses within the matrix where the 1st column is addresses 1-30, 2nd column is 31-60, etc.

    In this last example the address ranges of the first string segments are 1-30, 60-31 (goes down because this segment is reversed), 61-90, and 120-111. Note the gap between pixel 90 and pixel 111.
    The 2nd string's addresses would be 110-91, 121-150, 180-151, 181-200.

    What would you call the start address of that string? Is it the address of the 1st physical pixel of the string? The lowest address in the range of addresses for that string?

    I can see this creating mass confusion.

    I warned you that this wouid be boring.

    Looking for suggestions:

    1) Eliminate zigzag and let the sequencing software handle it.
    2) Go back to v4 version, one zigzag segment length.
    3) Have 2 zigzag segment lengths, but limit to cases where every pair of strings exactly fits N columns.
    4) Try to make it universal and figure out how to deal with start addresses and overlapping address ranges.
    5) ???
    I say 1 let the software handle it. Today’s software is very advanced and seems like it would be no problem.
    Please check out: http://animalaidusa.org/ Adopt a furry friend and save two life's.
    The one you adopt and the one you just made room for in the shelter!
    Like Us On Facebook @ Madison Avenue Lights

  8. #18
    Join Date
    Dec 2011
    Posts
    6,559
    Post Thanks / Like

    Default Re: New SanDevices V5 firmware coming soon

    Get rid of it and add Tls 3001 control to ver 5

  9. #19
    Join Date
    Dec 2012
    Location
    Newtown CT
    Posts
    4,414
    Post Thanks / Like

    Default Re: New SanDevices V5 firmware coming soon

    You are over complicating things a bit? Who says a string MUST be 50 or 100 pixels long? If your matrix is 40 up and 40 down, cut the string off at 80. Or better yet, inject power and make the string up to 640 pixels (16 columns @ 40 per column). That means your matrix only uses two ports on the controller. There is no reason (other than power injection) to limit your strings to such a short length.


    2020 Full sized show reworked for the new location. Only adding (famous last words) 13 RBLs that I finally got converted to using pixels
    2019 - Just moved into a new home (yet another change of plans). Will be dim but not dark. Too much to do at the new place to leave time for a show. Dim show (3000 pixels) had regular visits most nights.
    https://www.youtube.com/channel/UCyX...ttrsZNARkUce0Q

  10. #20
    Join Date
    Jul 2012
    Location
    Novi, MI
    Posts
    415
    Post Thanks / Like

    Default Re: New SanDevices V5 firmware coming soon

    Let the software handle it.

Page 2 of 4 FirstFirst 1234 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
  •