Sean Meighan
Software => LOR => Topic started by: brichi on January 19, 2018, 09:16:28 AM
-
Hey guys, so in my efforts of maybe using XLights over LOR this year I am attempting to use a LOR Pixie4 with xlights and its not working 100% , here is what I got
1, 4 channel pixie 4 running with the red high speed LOR usb dongle. I have 1 50 pixel (150 channel) ribbon connected to port 1 and another to port 2. When I open xlights I have nothing set, clean slate so I hit Add USB, Network type is LOR, selected the dongle under PORT, then I notice the baud rate maxes at 96 channels in LOR mode when I need 150, so how do I add this correctly? I tried switching the jumpers on the pixie4 to DMX mode but no luck getting it connected.
I searched and most videos are for older versions and don't apply to my setup.
thanks!
-
That note about 96 channels is really old so I have no idea if its true. I'd ignore it and just test it out.
-
thank you, I have been testing but its weird, I get the strip to light up but after node 12 on the strip it stops no matter how many channels I add past 12. the 13th turns red
-
I keep meaning to test the LOR output at higher channel counts. I have CCRs I can use and I have the non high-speed LOR dongle.
-
yeah, it seems pretty straight forward yet I cant get it working right, lol
-
heres some shots of my settings and what the controller and lights look like
https://www.dropbox.com/s/84guc5l9ju4qiuu/Screen%20Shot%202018-01-19%20at%2011.30.21%20AM.png?dl=0 (https://www.dropbox.com/s/84guc5l9ju4qiuu/Screen%20Shot%202018-01-19%20at%2011.30.21%20AM.png?dl=0)
https://www.dropbox.com/s/j7cz76gdc5key69/Screen%20Shot%202018-01-19%20at%2011.30.46%20AM.png?dl=0 (https://www.dropbox.com/s/j7cz76gdc5key69/Screen%20Shot%202018-01-19%20at%2011.30.46%20AM.png?dl=0)
https://www.dropbox.com/s/irl25ud7omcek00/IMG_0654.JPG?dl=0 (https://www.dropbox.com/s/irl25ud7omcek00/IMG_0654.JPG?dl=0)
https://www.dropbox.com/s/ru5q5ogt19ttvia/IMG_0655.JPG?dl=0 (https://www.dropbox.com/s/ru5q5ogt19ttvia/IMG_0655.JPG?dl=0)
-
Do you have a way of testing the strip other than the Lor controller?
I only mention this because my first thought is maybe the strip went bad at that node.
-
the strips are good, if I open LOR and run my show everything works great as it should
-
The 96 channel soft limit comes from the inefficiencies of the lor protocol we use. Every channel carries a 5 byte overhead. When combined with slow serial that kills you.
-
The 96 channel soft limit comes from the inefficiencies of the lor protocol we use. Every channel carries a 5 byte overhead. When combined with slow serial that kills you.
So my question is how is LOR getting away with it? They run the same protocol from a PC and it works.
-
If it was me I would run it and DMX mode.
I don't know that controller but I'm sure you'll probably have to make a crossover cable DMX is pin 1 and 2, Lor uses pins 5 and 6.
Pin 1 to pin 4, and pin 2 to pin 5.
-
its one or LOR pixie 4's that uses the dongle to convert usb to ethernet cord, it has a dmx pinning you can do on the board but it wasn't working either
-
Are you running any other E1.31 controllers?
Most any of the other controllers out there will output DMX.
You could go from the E1.31 controller to the pixie 4 and skip the dongle, this would be a better setup.
-
all 8 controllers I use in my show are Pixies but I just got a Alphapix but it doesn't have dual ethernet ports and I don't think I can run a pixie controller off a network switch
-
No you can't run a Pixi off of the network but your alphapix should be able to Output DMX.
-
yes, the alpha works great but I really didn't want to have to open $1000 in controllers to replace all my LOR pixies to use XLights
-
The 96 channel soft limit comes from the inefficiencies of the lor protocol we use. Every channel carries a 5 byte overhead. When combined with slow serial that kills you.
So my question is how is LOR getting away with it? They run the same protocol from a PC and it works.
My assumption is they send a fade as one instruction rather than an intensity every frame
-
yes, the alpha works great but I really didn't want to have to open $1000 in controllers to replace all my LOR pixies to use XLights
I'm not suggesting at all that you open those controllers.
What I'm trying to say is that your Lor stuff can run from the alphapix in DMX eliminating the need for the dongle.
So the data path would be from your computer using E1.31 to the alphapix, then the alphapix will output a DMX signal that can be used by your Lor controllers.
The beauty of this setup is then you only need one cable coming out of the house to run everything.
-
Another thing that affects LOR usage is that you can run more channels as long as they aren't changing much. The inefficiency comes in if more than 1/6 of your channels are changing at the same time. If fewer channels are changing then you are saving bytes on the wire by only updating changed channels.
-
OK so I hooked up a LOR CCR to a standard LOR RS485 dongle and captured some USB packets. I created a simple 3 second sequence that turned everything on red for 1 second, green 1 second, then blue 1 second. I could see the heartbeat bytes going out every 500ms. For the data when the sequence started there was an initial packet of 6 bytes immediately followed by 60 bytes. One second later there was a packet of 60 bytes on the change to green. One more second later there was a packet of 60 bytes when it changed to blue. Then when the sequence ended there was a packet of 7 bytes with 41 bytes 10ms later. If you look at xLights trying to perform the same sequence it appears to pump out boatloads of bytes and then the interface seems to quit transmitting. I also had it blue screen my PC when I shut off output to lights.
-
Gil, can you post that LOR USB capture somewhere? I thought I heard they had a newer protocol so maybe it can support multiple channels in one packet. Also please note how many channels this was.
-
Yeah I'm trying to do a lot of different tests to decipher the protocol. Made some good headway and capturing it in a Word document.
-
Here's what I've got so far. I haven't completely figured it all out. I've got one screenshot where I detailed what I believe some of the parts of the command packets mean. I did some testing with a 16 channel AC controller and others with a CCR. Where you see multiple lines of bytes they all came in as a big block and I just tried to place each section of the packet on its own line to align the commands. Not sure why they have several spots where they will have one or two sets of 7 0x00 bytes. The commands for the colors get even more confusing. If you or anyone wants to decode it please share your observations. Also I can run any scenario you want.
-
Oh and by the way for the original poster.....do you know if you are running in the new high speed protocol? I hear that protocol is very different from this protocol I've been working out and that's its even more convoluted.
-
Oh and by the way for the original poster.....do you know if you are running in the new high speed protocol? I hear that protocol is very different from this protocol I've been working out and that's its even more convoluted.
hey sorry for the late response, been a crazy few days
I am not sure what protocol I am running, I am using S5 as you know and have the high speed red LOR dongle. How can i check for the info you need?
-
Well what's I've found is that even with the old LOR protocol xLights does not work with a 150 channel color CCR. I've pretty much figured out a fair bit of the protocol and I'm working on creating a new output type that will use the optimized format. I just believe there is another completely different protocol for the high speed interfaces so I wouldn't be able to figure that out without the hardware. To figure this one out I'm having to use USB packet capture software.
-
That sounds like a lot of work, lol
I won't be able to really use XLights unless there is eventually a way to get my S5 LOR sequences to XLights so don't go too crazy based on my account.... thank you!!
-
I guess you are stuck with LOR then. Sometimes you just have to start over with your sequences. That's what I did I now have zero data in my shows that came from my early LOR days.
-
exactly, i would love to start over and redo them but i would also want to change out the controllers then to Falcon, Alpha,,etc... so the money would be up there for 8-9 controllers
-
But I think you should be able to run the LOR controllers in DMX mode. I know you had issues but they've supported DMX in controllers for a long time.
-
right, i did switch the jumpers over on the Pixie4 to DMX but still couldn't get it running at all. I was still using the USB to HS RS adapter, not sure if thats the right way. there isn't much instruction wise from LOR (from what i found anyway) on using these controllers in DMX mode with other software being they obviously want to stick in their system
-
When you switch the jumpers on the Pixie it switches the input pins from pins 4 & 5 to pins 1 & 2 for DMX operation at that point it won't be able to talk to the Lor dongle.
You could buy a falcon controller or another type of E1.31 controller and use that to bridge to the Pixi controllers.
-
The LOR dongle might work if you use a crossover cable after you change the jumpers and then you gotta pick a serial DMX output in xLights.
-
If he's going to use the Lor dongle set up in xlights as a serial DMX output he should be able to use a straight through cable and leave the jumper set to Lor Network.
I'm pretty sure like most of the Lor controllers the firmware picks up if it's getting an Lor or DMX signal on Startup.
He could certainly try this it wouldn't hurt anything.
-
Hmm....well I got the hardware to try that.
-
Here's what I've got so far.
On your screenshot with the parts breakdown, the value that is sometimes 0x13 and sometimes 0x03 are the command which on the intensity set commands indicates how to interpret the channel fields. 0x13 indicates that it is a 2-byte bitmask of channels. A value of 0x03 is what we currently use in xLights and FPP and that indicates that the field actually contains the actual zero-based channel number OR-ed with 0x80. That must be how they send more than 16 channels to the 24-channel controller, they could use 0x03 with an actual channel number 0-23 or possibly there is a different code other than 0x13 which has 3 bitmask fields for the channel numbers.
For the CCR testing, here are some observations:
CCR all white for 3 seconds
00 02 51 49 3F
00 02 51 08 FF FF
00 02 51 07 FF FF
00 02 51 06 FF FF
00 02 51 05 FF FF
00 02 51 04 FF FF
00 02 51 03 FF FF
00 02 51 02 FF FF
00 02 51 01 FF FF
00 02 11 FF FF 00 00
The "00 02 51" lines are setting the channels to apply the value to. Were you using all 50 pixels or just 45? On each of the first nine lines, it looks like we are addressing a 'bank' of 16 channels, going from bank 9 down to bank 1. The first line might seem to indicate that we are only looking at a bank of 8 channels. This would add up to 135 channels or 45 pixels. For banks 1-8, all channel bits are turned on via the 0xFF 0xFF. The last command is the "all on" command as noted at the top of the doc.
The second CCR sample seems to agree with the analysis above.
First 10 channels red
00 02 51 C9
00 02 51 C8
00 02 51 C7
00 02 51 C6
00 02 51 C5
00 02 51 C4
00 02 51 C3
00 02 51 C2
00 02 51 01 24 09
00 02 11 49 92 00 00
In this, the "00 02 51" command is sent with a "C9", "C8", etc. which appear to be clearing the bits on those banks of channels. Then, it sends a "00 02 51 01 24 09" which would set the red channels 3,6,9,12 since the two bytes are reversed when looking at the 16-channel bitmap. It looks like when you said you wanted 10 channels, it actually did 12 since it sees them as RGB triplets. I'm uncertain what the "00 02 11 49 92 00 00" is at the end.
-
Yeah I've actually figured quite a bit of it out last night. For the CCR testing the value after the 0x51 is the shift byte. So that very last command was actually turning on the first 16 bits. Then the line above it was shifted over 16 bits so it has the 0x01. All the way up to the top line that has "00 02 51 49 3f" is turning on the last 6 bits. The "4" part of the 0x49 indicates that the command only has 1 more byte instead of 2. And if you are turning these on with a color instead of white the 0x51 becomes a 0x53 and the 0x11 becomes 0x13.
I figured it all out once I reorganized the commands from this test where I turned on the first 30 out of 50 as purple. The first set of commands is turning the channels off that need to be off. So I believe the "C" part of the "0xC9" means turn the channels off and the 0x9 is the offset i.e. 9 * 16.
50 pixels with first 30 purple last 20 black
00 02 51 C9
00 02 51 C8
00 02 51 C7
00 02 51 C6
00 02 13 80 49 92 Red
00 02 53 80 01 24 49 Red
00 02 53 80 02 92 24 Red
00 02 53 80 03 49 92 Red
00 02 53 80 04 24 49 Red
00 02 53 80 45 92 Red
00 02 13 F0 92 24 Green
00 02 53 F0 01 49 92 Green
00 02 53 F0 02 24 49 Green
00 02 53 F0 03 92 24 Green
00 02 53 F0 04 49 92 Green
00 02 53 F0 05 24 FD Green
00 02 13 01 24 49 Blue
00 02 53 01 01 92 24 Blue
00 02 53 01 02 49 92 Blue
00 02 53 01 03 24 49 Blue
00 02 53 01 04 92 24 Blue
00 02 53 01 05 49 02 Blue
-
You could buy a falcon controller or another type of E1.31 controller and use that to bridge to the Pixi controllers.
I have an alphapix4 but how would you use that as the bridge being it only has 1 ethernet port?
-
First off the Pixie uses a serial connection so don't confuse that with the ethernet connection even though they're the same plug.
I believe the alphapix has a screw terminal block for the DMX output.
You could use that output to connect to the pixie controllers and if I remember right you claimed that you're already using it for something else so you would just need to extend what you already have connected until you run out of channels.
To be honest I really think your best option would be to sell the pixie controllers because they're very limited and what they can do.
I have a couple of pixLite 4 controllers I'm not using that I could sell you that would work with xlights and Lor, these controllers work just like your alphpix you would just use a cheap network switch to hook them up.
If you're really looking to use the Pixie controllers I also have a DIY LED Express 6 Port Bridge that I'm replacing with one of the new Falcon controllers. ( you should really confirm if the pixie controllers will run off of DMX)
-
First off the Pixie uses a serial connection so don't confuse that with the ethernet connection even though they're the same plug.
I believe the alphapix has a screw terminal block for the DMX output.
You could use that output to connect to the pixie controllers and if I remember right you claimed that you're already using it for something else so you would just need to extend what you already have connected until you run out of channels.
To be honest I really think your best option would be to sell the pixie controllers because they're very limited and what they can do.
I have a couple of pixLite 4 controllers I'm not using that I could sell you that would work with xlights and Lor, these controllers work just like your alphpix you would just use a cheap network switch to hook them up.
If you're really looking to use the Pixie controllers I also have a DIY LED Express 6 Port Bridge that I'm replacing with one of the new Falcon controllers. ( you should really confirm if the pixie controllers will run off of DMX)
I agree with selling them too but i like to make things work out of curiosity, lol... So if i DMX out of the alpha like i already am for a DJ uplight, how do i wire that into the Pixie? sorry to keep bothering you
-
I had my CCR running pretty good last night. Getting really close on reverse engineering the secret LOR protocol.
-
I had my CCR running pretty good last night. Getting really close on reverse engineering the secret LOR protocol.
Do you think he should hold off until you have this figured out?
It wouldn't make much sense for me to walk him through hooking up his pixie to DMX if you're going to have this available soon.
And I hate to open this can of worms, could there be any legal repercussions from Lor for you reverse engineering this and making it available?
-
and i have no problems holding off, i am in no rush as i am more working on my P10 matrix right now. I have been playing in XLights setting up some stuff and one thing i love (correct me if I'm wrong) is, Is it really this east to download a tree sequence from lets say holiday coro and import the SUP under effect and its done? I know the channels will have to match based on my pixie16 if/when i get it working with XLights
-
I would just continue to make your Pixie work on DMX mode. I don't have one so I have no idea if there are any pieces I'm missing to make things work on them.
-
What's funny is that everyone immediately thinks that LOR doesn't want me to figure out how to talk to their hardware but I get the feeling Dave at Falcon doesn't want me to figure it out either. He would rather people just dump LOR and buy Falcon cards. We have people that have already made the decision to move to xLights but have this Pixie hardware as well as CCRs and USB dongles and they would rather not switch everything to DMX. If I help make that happen it probably means more people would buy Pixie cards because they are rather inexpensive. So maybe LOR should just give me the protocol. :)
-
exactly, if i could get these pixies to easily work with Xlights then maybe i would start to program little by little in it. It seems so much easier and more fluent when doing things, in LOR right now (and i know they are working on improvements), it tales so long to do a lot of things including just opening a sequence with video and a lot of channels, up to 3-4 minutes just to open on a very good laptop, i duplicated this in xlights and its ready almost immediately
Even doing simple things like deleting 1ms of a video clip tales up to a minute to render the change before i can play it again vs you guys just having sliders and such and everything is instant
S5 is still in beta and i know they are going to improve a lot so I'm still staying hopeful but if it remains like this being they say not many of their users are pixel based then i would love to pay if S5 could be converted to XLights, lol
-
Brichi I think we would need to First make sure that the Pixies will work in DMX but you're going to need more DMX outputs than what you currently have.
From what I understand each Pixi is capable of 300 channels between it's for outputs and I think you said you have four of them.
Each DMX output is going to be capable of up to 512 channels so we kind of have a math problem you're not going to be able to run more than one pixie per output.
I can probably help you out but I've never had one of those Pixies in my hand to test.
As I said before I have one item here that I could sell you that might make everything easier it's a DIY LED Express 6 Port Bridge it takes a E1.31 input and then converts it to 6 DMX outputs. ( and I could even make up Lor crossover cables for you if needed)
-
Thanks! I'm going to see what happens in XLights and LOR for now, the crossover cables i can easily make but thank you for the offer, i appreciate it. I believe the pixie4 is 150 channels per output and theres 4 outputs on it, I have 5 pixie 4's, a pixie 8 and 2 pixie 16's along with the new alphapix4 i bout just to play with and learn the DMX end of adding lights
-
Yeah if I look at the Pixie on the LOR website it doesn't mention anything about having DMX support. Maybe I missed it but has anyone claimed to have run these cards in DMX mode? They say they appear as 4 unit ID's to the software. Also I see the Pixcon talking about supporting 16 strings of 170 pixels in LOR Enhanced Mode. I haven't tried it but this "enhanced" mode could be a completely different protocol. What's funny is when you see how nice a show can work using E1.31 to distribute DMX packets the LOR stuff starts to remind me of everything Microsoft used to do to maintain support and work around the 640K barrier.
-
Thanks! I'm going to see what happens in XLights and LOR for now, the crossover cables i can easily make but thank you for the offer, i appreciate it. I believe the pixie4 is 150 channels per output and theres 4 outputs on it, I have 5 pixie 4's, a pixie 8 and 2 pixie 16's along with the new alphapix4 i bout just to play with and learn the DMX end of adding lights
I just looked up the Pixie4 so I know it's 300 channels per output. 4 100 pixel strings.
-
I just checked again and on the main page describing the Pixie product line it states that they DO NOT support DMX. I just ordered a Pixie4 so there's a good chance I will have it running in xLights but I can't promise how fast. Kinda depends on whether what I've figured out already will work or whether it uses a completely different "enhanced protocol".
-
I wonder why they have DMX jumpers then on the pixie4,8,16 if it doesn't support it
https://www.dropbox.com/s/4eouwdwxesk5t5l/Screen%20Shot%202018-01-24%20at%2011.09.33%20AM.png?dl=0 (https://www.dropbox.com/s/4eouwdwxesk5t5l/Screen%20Shot%202018-01-24%20at%2011.09.33%20AM.png?dl=0)
i guess cause it 1.27 and not 1.31
-
I wonder why they have DMX jumpers then on the pixie4,8,16 if it doesn't support it
https://www.dropbox.com/s/4eouwdwxesk5t5l/Screen%20Shot%202018-01-24%20at%2011.09.33%20AM.png?dl=0 (https://www.dropbox.com/s/4eouwdwxesk5t5l/Screen%20Shot%202018-01-24%20at%2011.09.33%20AM.png?dl=0)
i guess cause it 1.27 and not 1.31
Yeah I forgot about the jumpers. You got me on that one I have no idea. Is just to be able to use a DMX cable but not the DMX protocol?
-
yeah maybe, who knows, LOL
-
What I have determined and I have an algorithm that implements most of this:
First byte: Leading zero
0x00 bytes mean nothing...there is always a 0x00 byte before a unit id byte to start command....sometimes blocks of 0x00 bytes (usually 7) are sent as padding between commands. Not sure if that is necessary every so often to allow hardware to process some number of commands before proceeding.
0x00 0x00: A pair of zeroes always at the end of a series of commands
Second byte: Unit ID
Unit ID stays the same for a device when set to Native mode
Unit ID increments every 16 channels when in Legacy mode
Unit ID has 2 IDs when set to CCB split mode
Third byte: Command byte
0x41 Turn Off first 16 channels of device
0x11 Turn On first 16 channels 100% based on 2 byte bitfield
Ex. 0x11 0xFF 0xFF turns on all 16 channels
0x13 Turn On first 16 channels to a value
value byte that follows calculated by: value = (228 - (i * 2)) where i = 0% to 100%
exception to value equation: 0% = 0xF0 and 100% = 0x01
Examples:
0x13 0xBC 0xFF 0xFF turns on 16 channels 20% (the bytes following the value are in the order LSB byte then MSB byte)
0x13 0x80 0x49 0x92 turns on all red channels to 50%
0x13 0xF0 0x92 0x24 turns off all green channels (0xF0 is a 0% value code)
0x13 0x01 0x24 0x49 turns on all blue channels to 100% (0x01 is a 100% value code)
0x33 Turn On first 8 channels to a value
Ex. 0x33 0xBC 0xFF turns on 8 channels 20%
0x23 Turn On last 8 channels of a 16 channel block to a value
Ex. 0x23 0x80 0xFF turns on last 8 channels 50%
0x17 The "7" part indicates a Shimmer
Ex. 0x17 0xFF 0xFF shimmer all 16 channels
0x37 0xFF shimmer first 8 channels
0x27 0xFF shimmer last 8 channels
0x16 The "6" part indicates a Twinkle
Ex. 0x16 0xFF 0xFF twinkle all 16 channels
0x36 0xFF twinkle first 8 channels
0x26 0xFF twinkle last 8 channels
The "4" part of the following commands means its a ramp command (don't have this completely worked out yet)
Examples to figure out:
00 01 14 F0 01 80 AA FF FF Ramp 16 channels 0 to 100% in 3 sec
Lead byte of 0x00, unit id 0x01, 0x14 means ramp, 0xF0 is 0%, 0x01 is 100%, 0x80 and 0xAA must be duration, 0xFF 0xFF for 16 channels
00 01 14 01 F0 02 37 FF FF Ramp 16 channels 100% to 0 in 3 sec
All bytes look same as above but why does 3 seconds now appear to be 0x02 0x37?
00 01 14 F0 80 80 50 FF FF Ramp 16 channels 0 to 50% in 3 sec
00 01 14 F0 80 80 77 FF FF Ramp 16 channels 0 to 50% in 2 sec
00 01 14 F0 80 01 09 FF FF Ramp 16 channels 0 to 50% in 1 sec
00 01 14 80 F0 80 50 FF FF Ramp 16 channels 50% to 0 in 3 sec
The "5" part of the following commands means there is a shift byte which specifies the number of 16 bit shifts to do for channel alignment
0x51 if the shift byte starts with 0xC0 then its a command to turn Off that channel bank
otherwise the 0x01 part of the command means turn the channels fully on to 0xFF
if the shift byte starts with 0x40 then only the LSB byte follows
a normal shift byte of like 0x04 would means shift these bits 4*16
Examples:
0x51 0xC9 turn off all 16 channels shifted up 9*16
0x51 0x47 0x1E turn on all 8 channels shifted up 7*16 based on bitfield LSB(0x1E)
0x51 0x02 0xDB 0xB4 turn on all channels shifted up 32 based on the bitfields LSB(0xDB) and MSB(0xB4)
0x53 means that there is an intensity value byte before the shift byte and bitfields
Examples:
0x53 0x80 0x03 0xC9 0x24 set channels 50%(0x80) shifted up 3*16(0x03) based on the bitfields LSB(0xC9) and MSB(0x24)
More examples with unit id of 0x01:
0x00 0x01 0x36 0x0F First 4 channels Twinkle
0x00 0x01 0x13 0xF0 0xF0 0xFF Last 12 channels Off:
0x00 0x01 0x37 0xFF First 4 channels Shimmer
0x00 0x01 0x26 0xFF Last 4 channels Twinkle
-
This is about where I was a few years ago trying to get the Lor stuff to play well with others.
It was at this point that I decided to get out before I got too heavily invested in Lor, and I couldn't be happier that I did it.
-
with the new new release imalmost there, I added a LOR pixie4, baud rate 250 (tried others too) and set it for 300 channels per output
plugged in a 3M roll of leds, 50 pixels, 150 channels
added an arch in layout with 50 nodes and it worked but if I add 4 arches then ports 3 and 4 on the pixie 4 do not work
whats weird too is with the 4 arches doing a chase in the preview, pixie4 output 2 is doing what preview arch 3 is doing. something on my end must be wrong with the numbers or something im missing.
-
Yeah its pretty clear. You told it you had 300 channels per output and then only hooked up 150 so you only filled up the first 2 outputs when you created 4 arches unless you changed the start channels of the arches to be 1, 301, 601, and 901. But expecting 1200 channels at 250Kbaud at 50fps is probably expecting too much.
-
i guess what I'm confused about then is thats what the controller runs at, each output handles 300 channels according to LOR (100 pixels/unit ID (300 chanels per ID)) so thats what i put in the initial setup of pixie 4 at 300 channels
if i have to put the exact amount of pixels like 150 at the initial setup adding the controller then i can't do 300 on lets say output 4? i don't keep the same exact amount of pixels on each port. one has 150 pixels, 2 has like 60, 3 has 110 and 4 has 125
or do i have to setup in the setup window a new LOR type per output? so for a pixie 4 i have to manually add 4 "types". I assumed it would like pick a pixie4, set it to 300 per output and XLights knows its unit ID 1,2,3,4 that can handle up to 300 channels per output based on the layout config
-
Yes I believe the Pixie does have that limitation where every port must be defined with the same number of pixels. Sure what you assumed would be correct if you run a high enough baud rate. I think 512K would be the minimum you should run for 1200 channels and depending on how complex of an effect you are putting on the channels it could still lag. You can also configure it as 4 different lines if you want and just put in the 4 unit ids. That would allow you to send less traffic and would be more efficient. No reason to be trying to send 300 channels on a port that is only using 150. You may not have bought the best dongle either. Does it say it can run at 512K?
-
thank you
Yes i can run 512 and there is not a limit that i have to run the same amount of pixels on every channel being in LOR i can run a pixie4 and have random amounts on each port with no issues
-
You misunderstood. There is a limitation. You cannot tell the controller different sizes for each output. Also you claim "no issues" but usually its because the average LOR user has no idea how much lag they have until they run in DMX mode.
-
in LOR each output can have up to 300 channels, in the layout you tell it how many pixels are on each output so where is the limitation?
right now on a pixie 4 in LOR i have the following for my star configured in preview manager
output 1 - 100 pixels (300 channels)
output 2 - 100 pixels (300 channels)
output 3 - 70 Pixels (210 Channels)
output 4 - 80 pixels (240 channels)
so how would I set that up in XLights with the new added LOR button in config? I can do separate outputs like we said and make 4 manually but i wanted to see if there was another way like for a pixie16 vs having to manually make 16 entries vs 1 saying this is unit ID 30 and Xlights knows this is ID 30-46 allowing up to 100 pixels to be added per ID
and you are correct that in DMX its horrible, i added almost 130 P10 panels which I'm sure you know take up a TON of DMX universes and right now LOR lags like crazy, they said they are working on an update though so we shall see
-
The LOR hardware utility only allows you to specify one value for pixels per port for the entire card. There is not an entry for each port.
You can define the Pixie cards as 1 entry as long as you want to allocate the same number of channels to every port. If you want to assign it the max and then use less that may work.
I never said DMX is horrible. The best option is to run LOR controllers in DMX mode being fed by another controller like a Falcon with DMX outputs or an E1.31 bridge.
-
What you may not realize is that the LOR protocol falls apart if you have a different pixel value on each channel. At that point DMX is always better than the LOR protocol. The only time the LOR protocol runs better is when you are doing more simple effects where the data is common among many channels or you are doing predefined ramps. If you create effects where every channel has a different value and changes in a non ramping fashion the LOR protocol ends up with many more bytes than DMX protocol.
-
ahhhhh i misunderstood what u meant about the DMX part, i thought u meant that the lag is even worse in DMX
trust me I'm kicking myself that i went with Pixies, i should've went all DMX. I have a alphapix4 that i know i can send dmx from that to a Pixie4 but thats a whole other project for me figuring out how.
tonight ill have more time to mess with XLights and the pixie4 to figure out the channel configs and such, last night i gave up cause i knew i had other crap to do.
-
this config seemed to work so far if i have 5, 50 pixel led strips at 150 channels each, This i guess is how we are supposed to setup a Pixie4?
https://www.dropbox.com/s/1v908rykuggqa0o/LOR%20XLIghts.jpg?dl=0 (https://www.dropbox.com/s/1v908rykuggqa0o/LOR%20XLIghts.jpg?dl=0)
-
If you have 150 channels defined for all 4 outputs you can define it with 1 line exactly like I did in my video. Just choose Pixie4 and enter 150.
-
If you have 150 channels defined for all 4 outputs you can define it with 1 line exactly like I did in my video. Just choose Pixie4 and enter 150.
but if im going to do 4 different amounts then the way i posted is the best way right? I did 150 on each quick as a test but i know when i go for real each output with be different