Help connecting my permanent Trimlight lights to a Pixie8

[MNLights]

I recently hired a company (Trimlight - https://www.trimlight.com/) to install permanent RGB smart pixels on my roof line as I am getting to old and fat to climb up on my roof anymore.  Knowing the plan was to connect these lights to my LOR show I made sure the lights they use (square 12V WS2811) were compatible with the LOR S5 software and the 12V Pixie8 control box which they are compatible.  To verify they would work I was able to get four short strands of the WS2811 lights (15-20 pixels per strand) from Trimlight so I could test them with S5 and my Pixie8 box to make sure my sequences worked with their lights and all four sections worked just fine when testing them in my house using the short testing pixels.  However, when I connect the lights on my roof to the Pixie8 controller the closest smaller section (50 pixels) to the box works fine but the other three sections (80, 25 & 110 pixels) that are farther away from the box have two issues.  First, the lights that do work flicker like there is not enough power or not enough data strength and second, some of the lights are blue at the end of the 80 and 110 pixel sections.  I made sure I counted each pixel per section and entered this into my preview in S5 and none of them are over 110.  I figure either there is data signal loss or the power has dropped too low which is why they are flickering but the Trimlight box runs the lights just fine (they did install power injection to the 110 pixel section farthest away from the box).  Here are a few things I tried that have not worked

1. used the power and power injection from the Trimlight box and only used the data wire from the Pixie8 but did not work

2. used the power and data from the Pixie8 and used the power injection from the Trimlight box and that did not work

3. connected all 4 ports to the close short area and all four work on that section but not the other sections

Any ideas of what I can try or what I am missing would be helpful.  I am new to smart RGB so I am assuming it is user error at this point.,  Thanks for any help.

 

Below is the Trimlight box and Pixie 8 box for reference.  They are both 12V

 

[MNLights]

Here are the pixel count of each section.  The boxes are in the small garage at the bottom left of the picture.

[canadianchristmas]

 

42 minutes ago, MNLights said:

1. used the power and power injection from the Trimlight box and only used the data wire from the Pixie8 but did not work

 

This won't work because you need the ground (gnd) to be connected to the controller. Everything you do needs to share a common ground.

Personally what I would try is to use the existing trimlight box, and power supply, and just run the gnd and data into the pixie. Leave the positive lines as is, running directly into the meanwell power supply.

I would add fuses to the positive lines as a protective measure though. 

 

The other thought I have is that the trimlight controller may have a slightly higher data signal voltage than the pixie. You may want to introduce null buffers or null pixels, or best yet an IC to boost your data output voltage like the 74HCT125N.

 

Another thought would be turning down the intensity of the lights... The trimlight controller may be running them at a lower intensity that is preset in the controller. So they can do longer runs with less power injection. However if you run them at 100% it may expose they're power injection short comings (lack of power injection).

 

Those are just some ideas of the top of my head.

Cheers!

[MNLights]

Thanks for the reply. I will try to run everything from the Pixie controller plus add the power injection wires (did not do this yet) to the Pixie power supply that way everything has the same ground. I did lower the intensity to 30% and that is when the lights actually worked even if they were flickering. I forgot about that try.  Null pixels is another good suggestion. Thanks again. 

[dibblejr]

2 hours ago, MNLights said:

Thanks for the reply. I will try to run everything from the Pixie controller plus add the power injection wires (did not do this yet) to the Pixie power supply that way everything has the same ground. I did lower the intensity to 30% and that is when the lights actually worked even if they were flickering. I forgot about that try.  Null pixels is another good suggestion. Thanks again. 

Null pixels will not work with pixie controllers

JR

[canadianchristmas]

1 minute ago, dibblejr said:

Null pixels will not work with pixie controllers

JR

Just saw this.....

All I can say is LOL, what are you talking about? Sorry I don't mean for that to sound offensive... But for real..

Null pixels will work with ANY pixel controller and I mean ANY!!!

All a null pixel is a normal pixel that you don't turn on, used as a data repeater.

Regardless of if the controller has null pixel configuration settings or not, you just define it in the sequencer (or controller if you can) and don't turn it on.

If your string is 50 pixels plus a null pixel at the beginning it's 51 pixels.

 

And if you don't want to go to the trouble of accounting for null pixels you can use a pixel data buffer like the one I linked from Hanson, which isn't counted as a pixel.

You could also just use the TI IC I listed, which IMHO would be the best. Neither the IC or the pixel buffer are counted as channels.

Feel free to send me a pixie and I'll have null pixels and data buffers everywhere haha, all while running in xlights or with dare I say madrix.

The reality is that pixel data is one way SPI data.. It is a one way communication protocol, it doesn't give a crap what you do to the signal once it's left the controller. 

[dibblejr]

2 hours ago, canadianchristmas said:

Just saw this.....

All I can say is LOL, what are you talking about? Sorry I don't mean for that to sound offensive... But for real..

Null pixels will work with ANY pixel controller and I mean ANY!!!

All a null pixel is a normal pixel that you don't turn on, used as a data repeater.

Regardless of if the controller has null pixel configuration settings or not, you just define it in the sequencer (or controller if you can) and don't turn it on.

If your string is 50 pixels plus a null pixel at the beginning it's 51 pixels.

 

And if you don't want to go to the trouble of accounting for null pixels you can use a pixel data buffer like the one I linked from Hanson, which isn't counted as a pixel.

You could also just use the TI IC I listed, which IMHO would be the best. Neither the IC or the pixel buffer are counted as channels.

Feel free to send me a pixie and I'll have null pixels and data buffers everywhere haha, all while running in xlights or with dare I say madrix.

The reality is that pixel data is one way SPI data.. It is a one way communication protocol, it doesn't give a crap what you do to the signal once it's left the controller. 
 

As a pixie controller Beta tester and maybe a little more than an average pixie user, instead of LMAO at you ignorance I will just tell you to search!

Submit a HD ticket and ask the question LOL.

Its been tested since beta - by whom- myself and others. I believe I will trust LOR over you.

Hech, last I knew you can’t even get a pixie to work in your xlights software. Bet you wish you could.

Read, read and read and maybe you will learn something here.

[k6ccc]

Hate to tell you this JR, but CanadianChristmas is right.  There is not a pixel controller on the planet that can't be used with null pixels.  Whether it has a setting for null pixels or not does not matter.  In the very worst case, build your preview (using S5 terminology) with 52 pixels in the string and only sequence the last 50.  The first two pixels are your null pixels.

 

[canadianchristmas]

@dibblejr Your post was formatted weirdly so I couldn't quote it properly, so here you go.

Ok.... Where do I even begin.. The amount of BS in your post is going to give me an aneurysm lol.. In all seriousness though thank you for the laughs, again not trying to be rude, but I have found this to be hilarious. 

I'm going to break up your post and answer it bit by bit..

Quote

As a pixie controller Beta tester and maybe a little more than an average pixie user, instead of LMAO at you ignorance I will just tell you to search!

Submit a HD ticket and ask the question LOL.

 

So just like how LOR says that power injection isn't supported on pixie controllers? Which isn't true.

I suspect that they make these general blanket statements to try and deter technologically illiterate people from attempting more complex setups as it can make troubleshooting more challenging if the person doesn't know what they are doing, it also raises the risk of user error. Furthermore if the person who doesn't know what they are doing wires something wrong, they could cause damage or outright ruin their controller, power supply, pixels or all three at once. 

LOR doesn't want to be blamed, or have controllers sent in for repair due to someone's incompetence, fixing avoidable problems that were caused by the end user. 

So really these types of general statements are just to cover their ass.

 

Another note would be that pixel controllers have to comply with the pixel IC manufacture's specifications on their data sheets for timing signals. So all pixel controllers that want to support WS2811 have to work the same way as the standards that are dictated by world semi, not LOR.

This reminds me when world semi increased the WS211 reset timing from 50us to 250us-300us a few years ago. Which meant that older WS2811 pixels could work with the newer ones that had a longer reset interval, but Newer ones could not work with older controller firmware versions as the reset interval was too short for it to register given the new standard. 

This meant that controller vendors everywhere had to release firmware updates to correct the reset interval.

So to sum it up: LOR does not dictate the standards for these IC's they only comply with manufacture specifications. They can't just say: "Oh we made our own standard that doesn't support null pixels". 

 

The one thing I do find curious though is this thread. 

 

The problems this user is experiencing seem to be indicative of a low signal voltage on the data pin.

I suspect that LOR may have a lower data signal voltage than other controllers.

This could either be a design flaw (which should have been sorted out before it left beta lol).

Or it could be done intentionally to try and prevent damage to the controller. For a personal example: Sandevices recommends leaving their "test" jumper in place on the E6804's which limits the data voltage to around 3v I believe. They recommend this to try and prevent damage to the controller if the V+ and data lines at a port get shorted specifically when using 12v pixels.

Really though, that is too low for a lot of pixels, and it can result either in them not turning on at all because the signal is too low, or it can cause flickering and erratic behaviour.

Most pixels run with 5v on data. So hopefully you can see how using too low of a data voltage could be problematic.

I think regarding the thread I linked where holiday coro said that their pixels do not support LOR pixies, they know all of this, and they know the LOR pixies are putting out a weak data signal. But it is easier just to say it's not supported rather than getting into the specifics.

 

HOWEVER, all of this can be remedied with again... Something like the 74HCT125N Or any non-inverting buffer or hell even some transistors FFS. How many times must I repeat this, did you figure it out yet? You need to actively boost the voltage coming out of your controller's data port if it is too low. As it seems to be with the pixies. 

This is also what you need to do if you want to drive pixels with something like a raspberry pi on the GPIO pins. The voltage is often too low, so you use a buffer of some sort to boost it.

It's really not that hard.

 

Quote

Its been tested since beta - by whom- myself and others. I believe I will trust LOR over you.

Lol good for you bud...

As for who you trust I really don't care. I just don't like to see information I know is wrong posted as fact.

 

Quote

Hech, last I knew you can’t even get a pixie to work in your xlights software. Bet you wish you could.

As far as I am aware you can.. Gill put a lot of work into third party implementation for it... You can even use a Pi as a budget pixielink if you wanted to with an HS dongle. And even if the native implementation has since broke, I could always use a pixie link to send E1.31 if I wanted to.

 

But I'll play devils advocate, lets say for argument sake that it doesn't work in xlights/fpp...

I'd ask you if that's something to be proud of? Because that means you're stuck with hardware running a proprietary closed source protocol. You are effectively at LOR's mercy then, you are- to put it bluntly in a cage. What happens if or when LOR goes out of business? Who would give you support then? Your pixies would be no better than door stops at that point. 

So you should be championing third party development and support as it gives you a plan B at the very least. Never put all your trust and faith into one single company, person, entity, etc.. You get the point. This goes for everything in life, Always leave your options open and try not to limit yourself.

Just because you feel secure in LOR's ecosystem today it doesn't mean, or guarantee it will be here tomorrow.

Quote

Bet you wish you could.

Hahahahaha.... 

Yes, I am so jealous of the controller that has a 50-170 pixel per port limit depending on the model.

Yes, I really want a controller that I have to externally buffer the outputs if I want to drive certain kinds of pixels, or pixels that require a higher voltage on the data line.

Yes, I want a controller that I have to use LOR's hardware utility and software to configure settings for (on windows never the less).

Yes, I really want a pixel controller that runs LOR's proprietary serial protocol so I can have a big nightmarish mess of HS dongles like you hanging everywhere like a spider web.

Well I think you've convinced me! Time to sell all my stuff and get pixies!

_________________________________________________

In all seriousness check these controllers out.

That is a 4 output open source E1.31 controller based on the ESP32.

You can buy a fully assembled and soldered board with a ESP32 and ethernet module for $49 USD.

And the best part about those controllers is that you can drive up to 800 pixels per port at 40hz. That is 40FPS on a 4 port $49 controller. You can go over a thousand per output but you obviously can run at 40hz when you go higher.

You can even just buy the custom ESP32 module with LAN, for $14... I don't think there are many controllers that can rival that at this point for price to performance.

I am just stating this, as I think it's a comparable controller to the pixie 4 with it's price point.

 

Quote

Read, read and read and maybe you will learn something here.

Oh I do... It's also why I keep coming back, I like helping people when I can too. I have been doing holiday shows and theatrical lighting design for nearly three times as long as you have been on these forums.

I think I know my stuff, and I enjoy sharing what I know.

I would suggest to you though, not to post so many absolute statements without knowing the answers definitively.

 

Anyways I am done writing this book. I hope this was able to help someone.

Take care everyone.

I would also like to say that I don't hate LOR if anyone gets that impression from this post. I really do like their AC controllers. I just think the pixies are dumb.

Edited February 2, 2022 by canadianchristmas
spelling

[MNLights]

I appreciate everyone’s feedback as I am learning a lot from the responses. I do think the issue is either low power or weak data since the test pixels work fine when they are connected to the Pixie board. I will try to boost the data a day when it is a little warmer as it is -2 out in the garage where the box is mounted right now. 

[Jimehc]

Thanks CC...

It is about time someone else stated the obvious in such regards....

 

[MNLights]

UPDATE: I added a pixel right by the Pixie board with hopes the data from that pixel would send a stronger signal to the next pixel in the roof and it worked (kind of). Now the issue is the two ports that have more than 50 pixels stop working (actually the lights turn blue) after the first 50. I double checked the pixel count in S5 and I have the total pixel count set correctly. Will the Pixie8 only work on the first 50 pixels or is there something that can be changed to make the rest work?

[Jimehc]

If you strings have turned "Blue" then I have to assume you are using Holiday Coro Pixels - see note above....

Holiday Coro Pixels turn "Blue" to indicate a "No Data Received" fault..

Dave recently stated that they have changed fault indicator from Blue to Black - thus New Holiday Coro Pixels will just remain off if no data received..........

Edited February 3, 2022 by Jimehc

[TheDucks]

1 hour ago, MNLights said:

UPDATE: I added a pixel right by the Pixie board with hopes the data from that pixel would send a stronger signal to the next pixel in the roof and it worked (kind of). Now the issue is the two ports that have more than 50 pixels stop working (actually the lights turn blue) after the first 50. I double checked the pixel count in S5 and I have the total pixel count set correctly. Will the Pixie8 only work on the first 50 pixels or is there something that can be changed to make the rest work?

Depending on the LENGTH of the cable, Null Pixels should be near midpoint  (so no pixel is more than 15-20' from an output). This DOES NOT compensate for POWER (voltage drop) issues. It just regenerates (squares things up) the Data signal

[MNLights]

I went back to one of the posts above and they suggested adjusting the pixel count in the hardware configuration utility to 50. It was set to 50 but I updated it to 115 and all of the lights work now. Just need to add a null pixel to the other 3 ports to eliminate the flickering and I should be good. 

[canadianchristmas]

1 hour ago, Jimehc said:

If you strings have turned "Blue" then I have to assume you are using Holiday Coro Pixels - see note above....

Holiday Coro Pixels turn "Blue" to indicate a "No Data Received" fault..

Dave recently stated that they have changed fault indicator from Blue to Black - thus New Holiday Coro Pixels will just remain off if no data received..........

A lot of pixels do that.. I would guess that Holiday coro gets their pixels from Ray, Paul, Tom, Scott, or any of the other seemingly billions of Chinese vendor middlemen.

My point with the post above was to show someone who was struggling, trying to use pixels that needed a higher data voltage than the pixie was able to provide. It has nothing to do with holiday coro.

42 minutes ago, TheDucks said:

Depending on the LENGTH of the cable, Null Pixels should be near midpoint  (so no pixel is more than 15-20' from an output). This DOES NOT compensate for POWER (voltage drop) issues. It just regenerates (squares things up) the Data signal

Indeed, this is correct, but you may also need some sort of buffer on the output of the controller if the signal is weak to begin with. But a rule of thumb is null pixels should always be in the middle of your wire run.

Or you can use multiple null pixels at a spaced interval, such as every few feet.

 

I would also be curious how long your wire runs are from the garage to the start of each pixel string are, and what type and gauge of wire are being used.

Also what kind of conductors meaning copper, copper clad, aluminium, etc.. Are being used as all of these factors can play a role in how the lights receive the data signal regarding resistance.

 

Another handy thing to know would be what each of the controllers are outputting.. What do their signals look like? What is the output voltage of each too?

You would need to check both the trimlight controller and the LOR pixie with an oscilloscope and compare.

 

UPDATE: I wrote all of this but the OP seems to have it sorted before I posted this.. LOL. But I'll post this anyways for anyone who may find it helpful.

Good job! @MNLights

[MNLights]

I want to thank everyone for your help solving my issues.  I tried for weeks reading posts, watching YouTube video's and learning quite a bit about Smart RGB Pixels but in the end this group help get it done.  It turns out all I needed was one pixel for each port in the Pixie8 controller to strengthen the data to stop the flickering and change the pixel count from 50-115 in the hardware utility configuration to make sure all pixels connected turned on.  The power seems to be fine with making no adjustment.  I was even able to move the dimming curve back to 100%.  Thanks again for your help.

Edited February 3, 2022 by MNLights
Spelling

[toddmx]

Hi MNLights. I know it has been over 1.5 years since you last posted, but I just purchased Trimlight lights and I'm trying to get them working with my LOR Pixie8 controller. I'm not sure I understand what your final resolution was. Can you share more details on how you finally got it to work?