DiyLightAnimation
Hardware => Lynx Smart String => Topic started by: fyb2000 on October 17, 2012,
-
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.
-
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.
-
+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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Got it thanks dpitts, I missed the part that it was set for a node string.
-
While RJ will assist you in writing software, he does not release source code or design documentation for his devices. Also, there is a general prohibition against making firmware for other people's hardware unless you have been given permission to do so.
The ssc has its own processor, so there is no contention with anything going on with the scheduler host machine.
As far as the order swapping in firmware goes, you need not have any concerns. There is no Microsoft junk in the firmware to cause bizarre operation for no apparent reason. There is no need to reduce the workload in the ssc as there is plenty of horsepower left after doing the conversion from pixelnet to the 180x bitstream for the pixels.
My guess is that the ssc starts counting data bytes after the 170 marker until it gets to its start address. Then it starts storing those bytes based on the node type setting such that the data in memory is ordered rgbrgbrgbrgb... The bitstream is at slightly slower data rate than the pixelnet string, so you could have a simple delay of 3 or 4 pixel times after the start address is reached to start an bitstream out process that will run until the maximum number of pixels in the string is transmitted, then stop. The pixelnet receive process would be allowed to interrupt the bitstream out process to write each byte of data it receives to the data buffer.
I'd guess that the code running the lynx express is far more complicated, and it runs on the same type PIC micro controller/processor.
-
I have not, and I am still not asking for the release of any software, modification of the firmware or anything of the sort. I am just trying to figure out, when faced with 2 different solutions to solve one common problem, what the best approach is for ->my<- own setup, based on as much information I can gather. I am not saying there is a problem with any of the goodies we have to play with, or that their design was missing something. I am not asking anyone to work anymore than they are willing to, modify something they have designed or give the keys to the whole thing when they are not willing to. Again, as I said several times, there is 2 solutions to solve the same issues, I just like to be able to judge which is more efficient for my own use and that will be the one I'll adopt. In no way have I implied that the current firmware was causing delays leading to artifacts, with the current configurations and the general use.
To be 100% clear, I am neither asking for a rewrite of the firmware, nor planning of reverse engineering the current one and rewrite it and distribute it to 3rd party or use it myself. There is several ways to write the part you gave a guess to, I appreciate your input and wil assume that you have knowledge of the way the firmware is written. If this is the case, could you just tell me if, when selecting a flex string (or square...) rather than the default smart string in the utility, the firmware ends up spending more cycles at run time due to the swizzeling operation or not. That is really all I want to know so I can setup my system based on my own preferences.
Thanks,
Francois
-
Whoa whoa whoa, I think you took what i said wrong.
I didn't mean to offend, just point out that the cycles you want to save are a moot point.
it was also a good opportunity to remind everyone of DLA policies and rules before this headed down the wrong path. There are lots of new folks and I don't think everyone reads the rules... I know I tend to give too much technical detail, which helps some and just confuses others. We want this hobby to be accessible to all.