Flex strip GRB rather than RGB?

[fyb2000]

Just received my first flex strings from Ray and after hooking up to a SSC I noticed that the channel order for them was GRB rather than RGB. Not a big deal with LSP (and I am sure other softwares, no shameless plug here, LSP has other *problems*) and easy enough to rectify by reconfiguring the channels order, but I was wondering if that was something that was to be expected? The SSC used for the test is 100% functional and was taken away from a regular smart string part of my show. I only tested one of the flex string, and hooked it up the same way I did for my regular smart strings, using 3 prongs connectors from Ray, blue with blue (and going to the data of the flex string) red with red, connected to +VC and green with green going to GND.
As mentioned earlier, not a big deal, just curious. 

[rrowan]

Did you set for flex strip in the SS utility?

Is the reason RJ put it in the software to adjust for the order of the different nodes.

Its under the Smart String Device Type

Rick R.

[zwiller]

+1

Each different pixel type may have it's own color order with the SSC test firmware running.  With the testware running, my flex strips and square modules are both GRB, but pixels are RGB.  Once you change SSC firmware and assign channels with the utility they are corrected to RGB. 

[fyb2000]

The SSC was already programmed and I didn't want to change it for testing, eliminating one parameter if the string ended up not working at all. I'll ask RJ when he comes back how he does the swizzeling in the firmware. From a performance perspective, it might be more advantageous to have it done in the sequencer rather than at run time. But either way that is good info that I had missed completely.
btw zwiller, did you ever receive your flex? I got mine today and I am pretty sure I ordered them after you?

[rm357]

For sanity sake, do it in the ssc. You have to program the start channel you want anyway, just check the proper box at the bottom of the screen in the programming utility. Then everything in the sequencing program is treated the same... As RGB

As far as the firmware goes, RJ is not likely to waste time removing the option... There is plenty of processing power in the ssc pic so that it is not an issue.

[zwiller]

The SSC was already programmed and I didn't want to change it for testing, eliminating one parameter if the string ended up not working at all. I'll ask RJ when he comes back how he does the swizzeling in the firmware. From a performance perspective, it might be more advantageous to have it done in the sequencer rather than at run time. But either way that is good info that I had missed completely.
btw zwiller, did you ever receive your flex? I got mine today and I am pretty sure I ordered them after you?

Yep, I got them Monday.  Ray shipped seperately.  I still am waiting for wire, square and rectangular modules, and some other stuff.  But at least I can work on the most difficult of my display.  I was really glad someone here suggested chat.  It helped alot.

As to color order, although the platform has some issues, LSP really simplifies channels and colors.  But even then I would just let the ssc do it.  One less thing to worry about. 

[fyb2000]

rm,
I do not even consider asking RJ to remove the option, just want to know how the swizzeling is done. If for each packet going through there is a test done to see if this is the first channel of a node and if this is the case, a swap of that value is done with the the following channel, it is simply better suited to be processed offline rather than at run time. Having the option there is perfect and I will understand people wanted to have the flexibility.
 

[Steve Gase]

I recall from past discussions that there is more taking place than channel swapping.  There is also node blocking, to limit how many pixels will receive channel data to avoid overloading the circuits, and there may also be some control of the power level and/or chip communication.

by selecting one smart string type (flex, strings, strip, square, rectangle) it causes a number of optimizations to be applied.

[jnealand]

I think the original poster may be confusing programming the firmware versus programming the SSC for light and nodes.  One programs the chip and the other programs the use.  On needs the pickit and the other just goes thru the computer to active hub to SSC.

[fyb2000]

Steve,
I am fairly certain that there is other operations being done at run time as far as the way the channels are being handled by the firmware, some being global (independent of the type of strings being used) and some being specific to the type of string. This is the information I am seeking, finding out what process(es) are put in place at run time. If it turns out it is a wash, then it doesn't really matter which way you go (pre bake the swap to be done by your sequencer vs doing it at run time), the performance will be equivalent. If it isn't, then, I'll stick with a pre baked method rather than a run time one. That is great to have the flexibility, let everyone make their own decision based on their own knowledge base.
Jim,
I don't think there is a confusion about the two. The initial problem is the difference in configuration of the 'flex strings' vs the 'smart strings'. One ends up assigning the channels sequentially as GRB (channel 0,3,6...are Green, 1,4,7...are Red 2,5,8...are blue) and the other as RGB. There is (at least) 2 solutions to handle this. One involves setting up the SSC using RJ's 'smart string utility' (which by the way does ->not<- require the use of the pickit) and will swap the color channels on the fly at run time, the other is by prebaking the swap in the configuration of your controller in your sequencing program (LSP in my case).
I definitely am not asking for a modification or a rewrite of the firmware. It's awesome that this option is available, as it does help many people, me included. I am a 99% software guy and those are the kind of challenges I have been dealing with for the past 30 years. When I see one in front of me, I cannot help it but to start weighting the different solutions. This is just one of those cases. 

[dpitts]

Well the SSC firmware does the byte swapping already. There is no way to turn it off. When you select the node type that determines which path is taken in the firmware. No matter what you pick for node type a path through the swapping code will be taken.  Are you asking which path is the shortest so you can then use software swapping. I think the cycles saved by using the shortest path is negligible.   I have seen no difference in delay or anything else by selecting different node type. It just works.

 

[fyb2000]

Dpitts,
Thank you for the post, this is exactly the type of information that I am looking for. As with all software, it starts with a default setup, which most likely was RGB in this case, and builds on it. When a need to control different type of node/channels configurations came about, this was expended to allow for different settings. I do not know the difference between the different path, more specifically between the default one and the others. Some might require more work by the pic than others, some might be minimal and some might be expensive. I do not know. It works, there is no doubt about that, and as of today, there is no visual differences between the different configurations, and I am just trying to weight my options, because there is options. Yes, if it turns out that one path is shorter as far as data manipulation is concerned (on the firmware side) then I would definitely keep the the swizzeling within the sequencer, rather than at run time.

[jnealand]

I am really confused by all this.  I have both smart strings and flexstrips.  Both of them are RGB.  I do use RJs programming utility to set what type of smart device the SSC has connected to it. but I do not do anything else and all my light devices are RGB.  How do you get GRB if you are doing what we are told to do.

[dpitts]

I am really confused by all this.  I have both smart strings and flexstrips.  Both of them are RGB.  I do use RJs programming utility to set what type of smart device the SSC has connected to it. but I do not do anything else and all my light devices are RGB.  How do you get GRB if you are doing what we are told to do.

He stated in first post that he took a SSC that was programmed for String and connected to a Strip. So he had not configured SSC for strip as suggested.

[jnealand]

Got it thanks dpitts, I missed the part that it was set for a node string.