LOR Pixie controller in XLights not working right

[brichi]

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

[Ebuechner]

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)

[brichi]

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

[Gilrock]

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.

[Gilrock]

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.

[Gilrock]

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".

[brichi]

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

i guess cause it 1.27 and not 1.31

[Gilrock]

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

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?

[brichi]

yeah maybe, who knows, LOL

[Gilrock]

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

[Ebuechner]

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.

[brichi]

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.

[Gilrock]

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.

[brichi]

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

[Gilrock]

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?