Smoothing for WS2811/WS2812

[TJ-91]

So I've seen there are discussions about implementing smoothing for Adalight devices. I've also seen the attempt to provide smoothing in Prismatik.

I have a setup with WS2812B LEDs and use this program based on FastLED on my Arduino clone.

Now my thoughts were that implementing software based smoothing in Prismatik is kind of flawed since you'd have to send new color information in very short intervals. Which makes communication a bottleneck, I suppose. Instead I thought I'd do it on the Arduino itself.

Here is my fork with my first attempt: https://github.com/TJ-91/adalight_ws2812

Unfortunately it has some problems/drawbacks. I'll put this part at the end of my post and first describe the results:

It works very well if the prismatik frame time is set high enough (I'm currently using 180ms). This means there will be some delay. However the smooth transition means that there is a delay anyway. Also the smooth transition makes up for the fact that there are only 5-6 frames per second. To be honest, when I compare the result to a video of a Philips TV with ambilight it's not worse than that :) So for movies I think it's fine but for desktop usage some more fps (less delay) couldn't hurt, I think.

If anyone can help me with the problems below that would be very welcome! It's working but I know I could make it much better.

Problems

My idea is to do smooth transitions while waiting on data from Prismatik. Obviously this induces some constraints. The maximum achievable fps has to be cut down since otherwise there would be no time for showing the intermediate colors between two colors. This should only become an issue for high frame rates or very long LED strips.

However there is another problem that I've encountered. I seemingly have to make sure that my color transition is fast enough to fit between two color frames that are received from Prismatik. If I take too long with the smooth color transition then it will show artefacts (completely wrong colors).

I'm not quite sure how to solve this problem. The problem is not that I'm reading wrong values from a malformed color frame. The program should still be reading valid frames due to reading a valid Ada-header first. So there should be no wrong color information even if we start reading in the middle of one frame. In this case the second half of the current frame would be thrown away and the next frame would be processed normally. All of this assumes that a full serial buffer results in the behaviour that I think it does.

I am not very familiar with serial interfaces (or any kind of low level communication for that matter). So maybe there is something to consider that I ignore out of ignorance.

You can see in my implementation that I tried to read all serial data in between the color transition and buffer the last frame. The thought was to start with the newest color information instead of waiting for the next frame after the transition is done. Also I thought that clearing the serial buffer could help with any strange glitches (it doesn't so I commented that part out). My final goal was to go one step further and always take the most recent color information and throw the old one away even while in the middle of a color transition.

Maybe I'll be able to achieve all of this by cleverly working around any timing issues. But I feel there has to be a better and more robust solution.

If you have any questions, please just ask.

PS: I've thought about using another color space than RGB to calculate more accurate color transitions. In RGB the distance between two color vectors does not accurately represent the distance between the perceived colors. Also currently I'm adding/substracting a fixed number to each of the RGB values per step. This is very rudimentary. However this solution really seems to be good enough and I'm not sure if there is any need to improve it.

[AsmodeusZ28]

I've recently tried modifying adalight to take the serial data into a buffer and update the led array by repeatedly interpolating between the current state and the buffer. I think it works rather well with both fast and slow update times. Why don't you take a look at it.

[TJ-91]

Oh, interesting, so you've had a similar idea at the same time as me.

I'd very much like to try it out but what is your SENSOR_PIN? I only have my WS2812B strip connected to the Arduino Nano.

[AsmodeusZ28]

I have a potentiometer connected to pin 10 of my pro micro so that I can adjust the smoothness of the lights, I find that I prefer different levels for screen grabbing and sound visualization. If you don't want to connect one to your own setup, you can comment out the five lines reading the analog value of the potentiometer and hard-code smoothing to something between 200 and 254.

[zomfg]

@TJ-91 little question on the side: which serial chip does your Nano have? mine with a CH340G, can't cope with Prismatik for some reason

[TJ-91]

@AsmodeusZ28 neat idea with the potentiometer. I've hardcoded the value and set the Baudrate to 115200 which I use in Prismatik.

However when I test your program it doesn't work for me. I get the same effect that I describe in my first post: Random colors. I suppose this is again because somehow doing FastLED.show() while serial data is received leads to unintended behaviour. My first approach in my program was very similar to yours (update colors while serial is not available) and it didn't work. I already tried stuff like disabling interrupts for FastLED (see Interrupt problems on the FastLED page).

It's strange that I seem to have the problem and you don't. This is the reason why I've wasted many hours on my project to get it to work despite it being something that's actually very easy (calculate intermediate colors, update, no big deal ...).

I'm not sure what the problem is and how I can debug it. If it works for your board maybe it's a flaw with mine. Or just different behaviour that I don't understand because I'm unexperienced in that field. I could try getting a different board, I guess.

@zomfg It's the CH340. Did you try different baudrates (and made sure they match with the setting in Prismatik)?

[dmadison]

The solution to having a frame show up earlier than expected is to have a three-frame buffer:

• Buffer 1: LED frame values
• Buffer 2: Goal frame values
• Buffer 3: Next frame values (serial buffer)

On each update "tick", apply a linear interpolation from the LED values towards the goal frame values based on your # of steps, then store the results back into the LED buffer and push to the strip. Once the next frame of data has been fully received, calculate the step change amounts for each channel and then copy the "next" frame values to the "goal" array (you can use pointers to avoid copying, but that's the logic). Because you're always working off of the current LED values, the next frame (no matter when it's received) will just change the direction and magnitude of each channel adjustment.

The big obvious downside is that you need the memory to store 3 copies of LED data, which can be a problem on the typical Arduino boards when using large numbers of LEDs.

I haven't looked at your implementation, but the usual cause for weird colors is a sync error between the PC's data stream and what the microcontroller expects. Some Adalight w/FastLED implementations use the original ring buffer and don't handle mismatched LED counts, others don't flush the serial buffer and buffer a portion of the header before resetting their byte counters. I need to get around to re-writing it, but I have my own Adalight implementation here that works well if you want to give it a try.

I still think that trying to get the smoothing on the microcontroller itself is the wrong way to do it, though. The PC has much more processing power and can tweak the smoothing parameters without having to reflash the firmware, not to mention that it would work with all 3rd party devices and not just that specific firmware flavor.

And for WS2812B there's another issue with having smoothing on the microcontroller: the device can't receive serial data while it's writing to the LEDs. So if it's expecting 5-6 frames per second and it receives a few bytes of data while writing an interpolated frame to the LEDs, you lose that entire frame. Which also means that if it's receiving data you can't write to the LEDs until the transmission is complete and may make the output choppy for long LED runs.

[AsmodeusZ28]

I believe the difference between our experiences is due to how our controller handle communication. The atmega32u4 at the heart of my pro micro has a built in USB controller, which makes it handy for USB-based applications. Although I don't have any experience with other boards I gather that boards with different microcontrollers will handle USB communication differently.

I think there could be some relief by reducing the time spent sending data to the LEDs, thus reducing the window for conflict with serial communication. that would mean cutting back on transitional updates.

In my first attempt at smoothing, I only ran the interpolation loop once per frame, then returned to the original loop to wait for serial data. While this did see smoother lighting, It didn't work as expected unless I unticked the "Send data only if colors changed" checkbox in Prismatik, otherwise it would stop the transitions when Prismatik stopped sending. It's not the best, but it might work for your board if it can get back to the wait loop before Prismatik begins sending the next frame.

[TJ-91]

@dmadison

The solution to having a frame show up earlier than expected is to have a three-frame buffer:

I have 3 buffers in my implementation because that was exactly my thought. Unfortunately it doesn't work. I guess it's because FastLED.show() (which takes some time) and receiving of serial data conflicts. And I can't really work around the issue other than making sure that I only compute/show intermediate color updates between two frames from Prismatik. I have some ideas to try to improve my implementation with these constraints but it's not ideal.

but I have my own Adalight implementation here that works well if you want to give it a try.

Sure, I'll take a closer look at it later. At first glance, though, it doesn't seem to include smooth color transitions, right? In that case I'm not sure if it helps much since simply receiving and setting the colors is not the issue.

I still think that trying to get the smoothing on the microcontroller itself is the wrong way to do it, though.

It's not ideal. But for me it seems like the most reasonable approach. Yes the PC has more processing power but I think that my Arduino has enough for a good result. It avoids communication bottlenecks that you might have with a PC implementation and you'd still have the overhead of setting the LEDs to their respective colors. I didn't do the math, maybe it's possible on PC.

As for tweaking parameters without reflashing: That's easily possible. I already tried this (on a local branch) where I added a new "Ada-Header" that indicates that this is not a frame containing RGB data but "command data" e.g. change a parameter. I'm not sure how easy it would be to make a backwards channel (so the actual parameters can be read from Prismatik). This would be beneficial in case a command-frame gets dropped and the parameter has not changed. But that's just low priority in the back of my head.

And for WS2812B there's another issue with having smoothing on the microcontroller: the device can't receive serial data while it's writing to the LEDs.

That's probably the main problem which causes the flawed behaviour that I observe. I'd need a way to handle this case without bugs. I initially thought in the worst case scenario I'd have a missed frame but currently I have the aforementioned problems.

Which also means that if it's receiving data you can't write to the LEDs until the transmission is complete and may make the output choppy for long LED runs.

I know that but for me personally it's only 53 LEDs. I'm willing to see how far I can take this approach. I just don't see any other reasonable and easily doable alternative at the moment.

@AsmodeusZ28

I believe the difference between our experiences is due to how our controller handle communication

That might very well be. I'm not experienced with low level communication stuff. When I find the time I should probably read up on the specifics.

I think there could be some relief by reducing the time spent sending data to the LEDs, thus reducing the window for conflict with serial communication. that would mean cutting back on transitional updates.

Yeah if the issue itself can't be fixed I'll have to work around it like this.

It didn't work as expected unless I unticked the "Send data only if colors changed" checkbox in Prismatik

For me Prismatik showed the same fps with ticked and unticked setting. So I disregarded the setting. I should have a look at it again. But yeah, it'd be nicer if it worked independently of this anyway :)

[dmadison]

I have 3 buffers in my implementation because that was exactly my thought. Unfortunately it doesn't work. I guess it's because FastLED.show() (which takes some time) and receiving of serial data conflicts.

You could add a timeout value. For a given baud rate you can calculate the amount of time it takes for a byte to arrive. If you receive a byte and are expecting more for the given frame, hold off for X amount of time for the next byte before sending any data to the LEDs. If you receive another byte, reset the timer.

Sure, I'll take a closer look at it later. At first glance, though, it doesn't seem to include smooth color transitions, right? In that case I'm not sure if it helps much since simply receiving and setting the colors is not the issue.

It doesn't include smoothing, no, but it will fix any issues you may be having with serial communication. If you switch the timeouts to use microseconds and reference the last byte time (see above) you could also stick your smoothing functionality directly in the "timeouts" function.

It avoids communication bottlenecks that you might have with a PC implementation

There's always going to be a bottleneck somewhere. If the Arduino is just dealing with serial data and pushing colors to the LEDs you can get a much higher framerate than doing color fading on the microcontroller. Plus you don't have to dance around the serial interrupt problem.

As for tweaking parameters without reflashing: That's easily possible.

If you write support in the firmware yes, but that may very well break Prismatik's support for other existing Adalight firmwares. The protocol wasn't designed to support custom settings and a number of implementations will break if you send more bytes than expected.

[zomfg]

If you write support in the firmware yes, but that may very well break Prismatik's support for other existing Adalight firmwares. The protocol wasn't designed to support custom settings and a number of implementations will break if you send more bytes than expected.

If we use a different Magic Word ("Cfg" ?) on Prismatik side for settings, all current firmwares will skip over that data, I think. Just have to be sure the new kind of message wont contain "Ada" in it, I guess...

Or maybe make Prismatik test the feature set of the board before anything else: send "Fset" string or something and if nothing comes back it works as before.

Would that work?

[dmadison]

At that point I think you're better off spinning your custom version as a different protocol all-together.

In theory yes, if you don't include the 'Ada' keyword the firmware should skip over it. But there are a lot of different versions out there that don't follow the rules to the letter. The sketch I originally found didn't buffer the header information correctly. The version @TJ-91 is using doesn't deal with the LED count properly. It's not much of a leap to think that if you're adding new unstandardized features you might break some people's projects.

[TJ-91]

If you switch the timeouts to use microseconds and reference the last byte time (see above) you could also stick your smoothing functionality directly in the "timeouts" function.

Yeah that's a good idea. I've thought about something like that, already. I'll probably try this approach. It's not really pretty but it should give good results. I was hoping that the issue can be fixed but from what we've been discussing I assume it's just the way my Arduino handles communication.

There's always going to be a bottleneck somewhere. If the Arduino is just dealing with serial data and pushing colors to the LEDs you can get a much higher framerate than doing color fading on the microcontroller

True. But since someone already tried software based smoothing in Prismatik and it didn't work too well, I thought - without looking too much further into it - there's a communication bottleneck. I'd have to look closer at it and probably just test it.

As for the compatibility issue for sending command frames: Exactly what @zomfg said. It should be disregarded by any sane implementation and I can't be dealing with problems of broken implementations. Also if a firmware doesn't support it ... Why should Prismatik (or any other software) send these non-standard frames in the first place? It can be made completely optional so I see no problem there. And even if there was a problem, no one has to use my code and it doesn't have to be in any official repo/build for all I care. But if it works and if it's the best solution I'm happy to share the code.

Edit: Thanks for the hint with the LED count. I didn't even know that was the purpose of the two bytes following the header. But that doesn't really matter. Edit2: To clarify, of course it's best to adhere to all standards but hardcoding and ignoring the LED count is reasonable enough. It doesn't break any functionality that the firmware is intended for. I could rewrite that part but I think it's fine leaving it just as it is.

[dmadison]

I was hoping that the issue can be fixed but from what we've been discussing I assume it's just the way my Arduino handles communication.

It's actually due to the WS2812B timing requirements. The timing is so strict that most interrupts will throw it off and corrupt the transmitted data, so the LED libraries disable interrupts when latching to the LEDs. No interrupts = no serial data.

The boards with native USB support typically use full speed virtual serial, so they just get data faster. You can always up the baud rate on the Nano, although that introduces its own set of problems.

Also if a firmware doesn't support it ... Why should Prismatik (or any other software) send these non-standard frames in the first place?

That's what I'm saying. The firmware isn't inherently broken, it only breaks when you do something unexpected. When you start sending non-standard frames - testing for feature support, sending config information etc. - not every implementation will handle it.

That's why I think that if you want to dedicate yourself to making this work on the microcontroller, you'd probably be better off defining it as its own custom protocol.

[TJ-91]

so the LED libraries disable interrupts when latching to the LEDs. No interrupts = no serial data.

Are you sure? I think that's what the #define FASTLED_ALLOW_INTERRUPTS 0 is for. And I don't use it - and if I do it and it doesn't change anything.

corrupt the transmitted data

Is it corrupted on a level that will create wrong serial buffer contents? My implementation should only read correct frames but if it's corrupted on this level it's hopeless. It would explain my problems at least.

You can always up the baud rate on the Nano, although that introduces its own set of problems.

I can experiment with this to see where it leads.

testing for feature support, sending config information etc. - not every implementation will handle it.

Well you may be right. I'll have to think about it. I think it's fine but you are ideologically right but I think simply naming it differently also doesn't magically solve everything. Also I don't think testing for features is necessary. Add a checkbox in advanced settings to enable the extended protocol features and then it comes down to "know what you do" :)

[dmadison]

Pretty sure. See here: https://github.com/FastLED/FastLED/wiki/Interrupt-problems. I can't speak to that define, I've never worked with the FastLED internals.

You can test it yourself. Write some code to parrot a string back over the serial bus while attempting to write data to a long string of LEDs. When the timing lines up you should see skipped bytes. Easier to do if you have access to a second microcontroller to trigger the timing. Even better if you have a logic analyzer to see the raw data.

When I say corrupt the transmitted data I'm referring to the LED data line, meaning that the colors on the LEDs won't match what you think was sent to them. It won't corrupt the data in the microcontroller's memory.

but I think simply naming it differently also doesn't magically solve everything

I don't mean change the name, I mean define it as a different protocol (+name) within Prismatik. Then you can add whatever other options to your heart's content.

[zomfg]

@zomfg It's the CH340. Did you try different baudrates (and made sure they match with the setting in Prismatik)?

@TJ-91 I tried 9600 and 115200 and the Nano struggles real hard, then I tried with an external usb ftdi-based adapter, same result. I am using adafruit's lib with SK6812 RGBW strip, which works perfectly fine with Leonardo. So just now I tried going back to FastLED and it seems to be working ok with the Nano+WS2812B combo... go figure...

[TJ-91]

I can't speak to that define, I've never worked with the FastLED internals.

On the page you linked it says that with this define you can "fully disable interrupts while writing out led data".

When I say corrupt the transmitted data I'm referring to the LED data line, meaning that the colors on the LEDs won't match what you think was sent to them. It won't corrupt the data in the microcontroller's memory.

Ah, that makes a lot more sense :) So in summary I can't make it work the way I intend to? Either interrupts destroy the delicate timing that is needed for setting the LEDs or I get skipped bytes which leads to random looking colors as well. This leads me to your next suggestion:

I don't mean change the name, I mean define it as a different protocol (+name) within Prismatik. Then you can add whatever other options to your heart's content.

I could indeed make a completely new protocol. The interrupt problems page suggests asking for new data when the device is ready. That's probably my best bet. Or, like you suggested, try calculating all the intermediate frames in Prismatik and then just sending them over.

[dmadison]

On the page you linked it says that with this define you can "fully disable interrupts while writing out led data".

Right, I just mean I have no experience with the internals personally so I can't say what effect it would have on your results.

So in summary I can't make it work the way I intend to?

You can work around the limitations, you just have to be mindful of them. It's a single-threaded 16 MHz processor with 2 kB of memory - you just have to pace your expectations a bit.

Another benefit of doing the calculations in Prismatik is that it will work for all 3rd party devices, not just ones with your specific firmware.

[TJ-91]

You can work around the limitations, you just have to be mindful of them.

What I mean with that, I'm just not sure whether it's a clean solution. Can I really make sure that I'm always ready to read when there's serial data to read? It might even be out of Prismatik's control to offer precise timing if some underlying mechanism has to buffer / delay a frame and then two frames are sent within a shorter than usual interval.

it will work for all 3rd party devices

That's true. I'll give this approach a closer look as it should be fairly easy to implement.

Thanks very much for your help and offering your insights.

[dmadison]

You could institute some sort of flow control (see #117) to delay frames until you're ready to process them, but I never got around to playing with that myself so you may have to fight Prismatik's buffering process a bit to make sure you're not queuing frames and building up a delay.

Absolutely, I hope my feedback was helpful. Good luck!

[zomfg]

While we are on firmware/protocol/serial subject.. What's the reason behind all third party sketches sending "Ada\n" string on init? As far as I can see Prismatik opens WriteOnly connections for those.

[dmadison]

Prismatik isn't the only game in town. I think the Adafruit Processing sketch that was bundled with the original kit looks for the "Ada\n" string.

[TJ-91]

I am finished with my first working solution for smooth color transitions in Prismatik. It works really well in my opinion. You can find it on my fork of Prismatik on the ftr_softsmooth branch. There are two values that can be tweaked: Time between two intermediate color frames and the total number of intermediate color frames until the final color is reached. For the smooth color transition I convert the colors to lab color space. In lab color space the distance of two color vectors also represents the distance in perceived color (as humans perceive it). I calculate the distance between two color vectors and then add (1 / number of intermediate colors) * distance vector in each iteration. Every time a new frame is grabbed, the target color (and thus the distance vector) is updated. I currently use a 20ms interval and 15 intermediate colors. Which results in about 300ms delay until the final color is displayed.

So far it's implemented for the LedAdalightDevice class only. Values are still hardcoded (they should be in the settings). Nothing is exposed to the GUI. Also in terms of efficiency there definitely is slightly more load on the CPU now. I (hopefully) avoided reallocating memory for every transformation but of course the calculations (lab to rgb) have to be done every time there is an update to the colors.

The PrismatikMath color transformations that were already there were not exactly what I wanted to use: 12-bit RGB and lab with only 1 byte per value instead of floating point numbers. So I copied some other piece of code for that (and slightly adjusted it to remove over / underflows for RGB values). This means there is some doubled functionality now.

I'm willing to tackle the above stated issues to fully and properly integrate this into Prismatik. It might take me a while to get to it, though. If anyone else is interested in doing it, just let me know. Also I can only test my specific setup, so help in this regard is welcome.

@dmadison thanks again for setting me on this path. I had disregarded doing it in Prismatik completely after seeing there already was a failed attempt. Initially I thought one would need to send more data which was why I was expecting a communication bottleneck. But the results are very good with a moderate amount of frames already.

[zomfg]

I currently use a 20ms interval and 15 intermediate colors. Which results in about 300ms delay until the final color is displayed.

Is it a constant 300ms? That looks similar to what I had with a (single) Hue bulb on a v1 bridge on my own ambilight thing attempt. It was nice indeed for slow activities but very distracting with videos (action scenes etc). It would be awesome if it detected fast changes and paused smoothing until a slow down in changes!

The PrismatikMath color transformations that were already there were not exactly what I wanted to use: 12-bit RGB and lab with only 1 byte per value instead of floating point numbers. So I copied some other piece of code for that (and slightly adjusted it to remove over / underflows for RGB values). This means there is some doubled functionality now.

Should be solvable by templating prismatik og functions and maybe an optional parameter for resolution.

[TJ-91]

Is it a constant 300ms?

Yes, currently you set the variables at compile time and they don't change. But don't make the mistake and compare this to anything you can do with Hue bulbs. There you got additional delay that comes on top of the transition time. Also you can only send like 10 updates per second so it can not even show fast paced color changes in the first place.

Also note that in my implementation I will always use the most recently grabbed frame as new target (where the current color transitions to).

It would be awesome if it detected fast changes and paused smoothing until a slow down in changes!

I'm very open for good suggestions that improve the experience. It'd probably be great to have a video that we can use as a reference which covers many different scenarios.

To your suggestion itself: I don't think that is a good approach. You do smoothing because you don't want to have fast changes. Well at least not too fast. Now with your suggestion you would have slow color transitions for colors that are similar anyway (you don't notice it very much) but for completely opposite colors you'd have fast changes (that you want to reduce in the first place). So I guess if you feel like the transition is too slow you should simply reduce the 300ms to something lower.

Edit: I've tried some other configurations. For example a 20ms interval and 7 color transitions (resulting in 140ms total) still looks smooth but it's much faster.

Should be solvable by templating prismatik og functions and maybe an optional parameter for resolution.

Good idea. Yeah it's nothing that's hard to solve. I just need to take a look at it. When writing my code it was simply more convenient to copy a working solution instead of solving this issue :)

[Benik3]

How it looks with the smoothing in the Prismatik? Will it be merged to official build?

A played with smoothing just for fun on receiver. If you have ESP8266 you can try this: https://github.com/Benik3/Adalight_WS2812_ESP8266_Non-blocking

Smoothing around 200ms, grab interval 16ms. Video here: https://photos.app.goo.gl/CkVEc3pvxMv3EzPY6 (colours are slightly shifted to purple on the video) The time is not constant, because the LinearBlend method takes different time (+- 0,5ms per interpolation)

EDIT 25.12. Changed to Rgb Blend because of speed, merged to main version as optional choice. I'm pretty happy with the result :)

[psieg]

I'm not particularly happy with the software smoothing PR because the smooting depends on the rate of updates. With "send colors only if data changes" the transition will be slower than without. On the other hand, the LP hardware also suffers from this I think.

[Benik3]

Yeah, the smoothing must be "async". That's how I solved it in my SW. When new frame come, I start smoothing from the previous one (for 200ms I make 50 interpolations - one take about 4ms). But when new frame come before finishing the smoothing, I start over from he point where previous smoothing ended to the new frame. I tested it with 16ms grabbing on 200ms smoothing as I wrote above and it worked pretty nice. But I don't know how to do it in PR...

[oleost]

Any updates on this ?

Got a SK6812 on Arduino, that could use some smoothing.

[Benik3]

Unfortunately development of the Prismatik looks dead :( But you can try the implementation in ESP8266 which I posted above. I recommend to use ESP over Arduino with WS2812/SK6812 anyway...

[oleost]

@Benik3 Ok, I can see there is an PR for software based smoothing in Prismatik, but its getting old yeah..

Are you still using that implementation and are happy with it?

Do you know if your version could support RGBW SK6812 ? ( I'm currently using a version with Adalight Neopixel instead of Fastled, giving by @zomfg in this issue https://github.com/psieg/Lightpack/issues/278 )

[Benik3]

I use no smoothing, but I used the implementation for a while when I made it and I was pretty happy with it :) NeoPixelBus support RGBW, but I don't have any strip to test. Just change the feature to NeoGrbwFeature. Then of course you must also change all the RgbColor to RgbwColor and add the 4th color in the definitions (like RgbwColor(255, 0, 0, 0).

Does your actual code use the white LEDs or it just ignores it and use only the RGB LEDs?

[zomfg]

The little firmware I provided does use the W pixel when RGB value is close enough to white, but it's calibrated to my Warm White SK6812 strip, so it might need some tuning for another strip (Neutral, Cold...,but even another Warm could be different).

In my experience it's rarely engaged, but that's probably due to me using a Warm White version. And it can be distracting if the light is not diffused enough because the light shifts the position slightly when going from RGB to W and back, but I might be paying too much attention because of working on it.

[Benik3]

I see. Hmm the calibration must be little hard to make a smooth transition and ideally calibrate the white temp (by mixing with the RGB slightly)...

[zomfg]

Color matching was not thaaat hard, I opted for a certain tolerance percent, otherwise you'd have to find the exact RGB value for your white, which would barely match anything in real usage (unless it happens to be 255,255,255 of course). But the jump I was talking about is the physical offset between RGB LED cluster and the W LED, they are on opposite ends almost, and when the switch happens you see the light source move a tiny bit. So yeah, I was not impressed by RGBW for ambilight usage.

You could widen the active W range by using 1 RGB strip with 1 WWA strip (cold white, warm white and amber), but the physical offset would be even bigger so it might require even better diffusion (or something like Y shaped light channels hmm...there are also edge lit strips, maybe putting one over the other would work).

[Benik3]

Yeah, the separation can be problem...
BTW can you test how HslColor acts on NeopixelBus with RGBW? If it count the white or not...

[sahelboy]

@Benik3 I tried uploading your Arduino file to my ambilight strip (Ambilight Twist) for smoothing with Prismatik, but I get this error: Arduino: 1.8.13 (Windows 10), Board: "Arduino Uno"

C:\Program Files (x86)\Arduino\arduino-builder -dump-prefs -logger=machine -hardware C:\Program Files (x86)\Arduino\hardware -tools C:\Program Files (x86)\Arduino\tools-builder -tools C:\Program Files (x86)\Arduino\hardware\tools\avr -built-in-libraries C:\Program Files (x86)\Arduino\libraries -libraries C:\Users\sahel\Documents\Arduino\libraries -fqbn=arduino:avr:uno -vid-pid=1A86_7523 -ide-version=10813 -build-path C:\Users\sahel\AppData\Local\Temp\arduino_build_506494 -warnings=none -build-cache C:\Users\sahel\AppData\Local\Temp\arduino_cache_6773 -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.arduinoOTA.path=C:\Program Files (x86)\Arduino\hardware\tools\avr -prefs=runtime.tools.arduinoOTA-1.3.0.path=C:\Program Files (x86)\Arduino\hardware\tools\avr -prefs=runtime.tools.avrdude.path=C:\Program Files (x86)\Arduino\hardware\tools\avr -prefs=runtime.tools.avrdude-6.3.0-arduino17.path=C:\Program Files (x86)\Arduino\hardware\tools\avr -prefs=runtime.tools.avr-gcc.path=C:\Program Files (x86)\Arduino\hardware\tools\avr -prefs=runtime.tools.avr-gcc-7.3.0-atmel3.6.1-arduino7.path=C:\Program Files (x86)\Arduino\hardware\tools\avr -verbose C:\Users\sahel\AppData\Local\Temp\Rar$DIa3740.21061\Adalight_ESP\Adalight_ESP.ino

C:\Program Files (x86)\Arduino\arduino-builder -compile -logger=machine -hardware C:\Program Files (x86)\Arduino\hardware -tools C:\Program Files (x86)\Arduino\tools-builder -tools C:\Program Files (x86)\Arduino\hardware\tools\avr -built-in-libraries C:\Program Files (x86)\Arduino\libraries -libraries C:\Users\sahel\Documents\Arduino\libraries -fqbn=arduino:avr:uno -vid-pid=1A86_7523 -ide-version=10813 -build-path C:\Users\sahel\AppData\Local\Temp\arduino_build_506494 -warnings=none -build-cache C:\Users\sahel\AppData\Local\Temp\arduino_cache_6773 -prefs=build.warn_data_percentage=75 -prefs=runtime.tools.arduinoOTA.path=C:\Program Files (x86)\Arduino\hardware\tools\avr -prefs=runtime.tools.arduinoOTA-1.3.0.path=C:\Program Files (x86)\Arduino\hardware\tools\avr -prefs=runtime.tools.avrdude.path=C:\Program Files (x86)\Arduino\hardware\tools\avr -prefs=runtime.tools.avrdude-6.3.0-arduino17.path=C:\Program Files (x86)\Arduino\hardware\tools\avr -prefs=runtime.tools.avr-gcc.path=C:\Program Files (x86)\Arduino\hardware\tools\avr -prefs=runtime.tools.avr-gcc-7.3.0-atmel3.6.1-arduino7.path=C:\Program Files (x86)\Arduino\hardware\tools\avr -verbose C:\Users\sahel\AppData\Local\Temp\Rar$DIa3740.21061\Adalight_ESP\Adalight_ESP.ino

Using board 'uno' from platform in folder: C:\Program Files (x86)\Arduino\hardware\arduino\avr

Using core 'arduino' from platform in folder: C:\Program Files (x86)\Arduino\hardware\arduino\avr

Detecting libraries used...

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "C:\Users\sahel\AppData\Local\Temp\arduino_build_506494\sketch\Adalight_ESP.ino.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE

Alternatives for NeoPixelBus.h: [NeoPixelBus-master@2.6.0]

ResolveLibrary(NeoPixelBus.h)

-> candidates: [NeoPixelBus-master@2.6.0]

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "-IC:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src" "C:\Users\sahel\AppData\Local\Temp\arduino_build_506494\sketch\Adalight_ESP.ino.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE

Alternatives for SPI.h: [SPI@1.0]

ResolveLibrary(SPI.h)

-> candidates: [SPI@1.0]

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "-IC:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI\src" "C:\Users\sahel\AppData\Local\Temp\arduino_build_506494\sketch\Adalight_ESP.ino.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "-IC:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI\src" "C:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src\internal\Esp32_i2s.c" -o nul -DARDUINO_LIB_DISCOVERY_PHASE

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "-IC:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI\src" "C:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src\internal\HsbColor.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "-IC:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI\src" "C:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src\internal\HslColor.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "-IC:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI\src" "C:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src\internal\HtmlColor.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "-IC:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI\src" "C:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src\internal\HtmlColorNameStrings.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "-IC:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI\src" "C:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src\internal\HtmlColorNames.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "-IC:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI\src" "C:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src\internal\HtmlColorShortNames.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "-IC:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI\src" "C:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src\internal\NeoEsp32RmtMethod.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "-IC:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI\src" "C:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src\internal\NeoEsp8266UartMethod.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "-IC:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI\src" "C:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src\internal\NeoGamma.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "-IC:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI\src" "C:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src\internal\NeoPixelAnimator.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "-IC:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI\src" "C:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src\internal\NeoPixelAvr.c" -o nul -DARDUINO_LIB_DISCOVERY_PHASE

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "-IC:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI\src" "C:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src\internal\RgbColor.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "-IC:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI\src" "C:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src\internal\RgbwColor.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "-IC:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI\src" "C:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src\internal\SegmentDigit.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "-IC:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI\src" "C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI\src\SPI.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE

Generating function prototypes...

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "-IC:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI\src" "C:\Users\sahel\AppData\Local\Temp\arduino_build_506494\sketch\Adalight_ESP.ino.cpp" -o "C:\Users\sahel\AppData\Local\Temp\arduino_build_506494\preproc\ctags_target_for_gcc_minus_e.cpp" -DARDUINO_LIB_DISCOVERY_PHASE

"C:\Program Files (x86)\Arduino\tools-builder\ctags\5.8-arduino11/ctags" -u --language-force=c++ -f - --c++-kinds=svpf --fields=KSTtzns --line-directives "C:\Users\sahel\AppData\Local\Temp\arduino_build_506494\preproc\ctags_target_for_gcc_minus_e.cpp"

Compiling sketch...

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avr-g++" -c -g -Os -w -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -MMD -flto -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10813 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard" "-IC:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master\src" "-IC:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI\src" "C:\Users\sahel\AppData\Local\Temp\arduino_build_506494\sketch\Adalight_ESP.ino.cpp" -o "C:\Users\sahel\AppData\Local\Temp\arduino_build_506494\sketch\Adalight_ESP.ino.cpp.o"

Adalight_ESP:23:28: error: 'NeoEsp8266Uart1Ws2812xMethod' was not declared in this scope

NeoPixelBus<NeoGrbFeature, NeoEsp8266Uart1Ws2812xMethod> strip(PixelCount, PixelPin);

                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

C:\Users\sahel\AppData\Local\Temp\Rar$DIa3740.21061\Adalight_ESP\Adalight_ESP.ino:23:28: note: suggested alternative: 'NeoAvrWs2812xMethod'

NeoPixelBus<NeoGrbFeature, NeoEsp8266Uart1Ws2812xMethod> strip(PixelCount, PixelPin);

                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

                        NeoAvrWs2812xMethod

Adalight_ESP:23:56: error: template argument 2 is invalid

NeoPixelBus<NeoGrbFeature, NeoEsp8266Uart1Ws2812xMethod> strip(PixelCount, PixelPin);

                                                    ^

C:\Users\sahel\AppData\Local\Temp\Rar$DIa3740.21061\Adalight_ESP\Adalight_ESP.ino: In function 'void setup()':

Adalight_ESP:29:10: error: 'class HardwareSerial' has no member named 'setRxBufferSize'

Serial.setRxBufferSize(SERIAL_RX_BUFF);

      ^~~~~~~~~~~~~~~

Adalight_ESP:31:9: error: request for member 'Begin' in 'strip', which is of non-class type 'int'

strip.Begin();

     ^~~~~

Adalight_ESP:32:9: error: request for member 'Show' in 'strip', which is of non-class type 'int'

strip.Show();

     ^~~~

Adalight_ESP:35:9: error: request for member 'ClearTo' in 'strip', which is of non-class type 'int'

strip.ClearTo(RgbColor(255, 0, 0));

     ^~~~~~~

Adalight_ESP:36:9: error: request for member 'Show' in 'strip', which is of non-class type 'int'

strip.Show();

     ^~~~

Adalight_ESP:38:9: error: request for member 'ClearTo' in 'strip', which is of non-class type 'int'

strip.ClearTo(RgbColor(0, 255, 0));

     ^~~~~~~

Adalight_ESP:39:9: error: request for member 'Show' in 'strip', which is of non-class type 'int'

strip.Show();

     ^~~~

Adalight_ESP:41:9: error: request for member 'ClearTo' in 'strip', which is of non-class type 'int'

strip.ClearTo(RgbColor(0, 0, 255));

     ^~~~~~~

Adalight_ESP:42:9: error: request for member 'Show' in 'strip', which is of non-class type 'int'

strip.Show();

     ^~~~

Adalight_ESP:44:9: error: request for member 'ClearTo' in 'strip', which is of non-class type 'int'

strip.ClearTo(RgbColor(0, 0, 0));

     ^~~~~~~

Adalight_ESP:45:9: error: request for member 'Show' in 'strip', which is of non-class type 'int'

strip.Show();

     ^~~~

C:\Users\sahel\AppData\Local\Temp\Rar$DIa3740.21061\Adalight_ESP\Adalight_ESP.ino: In function 'void loop()':

Adalight_ESP:120:15: error: request for member 'SetPixelColor' in 'strip', which is of non-class type 'int'

     strip.SetPixelColor(i, color);

           ^~~~~~~~~~~~~

Adalight_ESP:122:13: error: request for member 'Show' in 'strip', which is of non-class type 'int'

   strip.Show();

         ^~~~

Adalight_ESP:127:13: error: request for member 'ClearTo' in 'strip', which is of non-class type 'int'

   strip.ClearTo(RgbColor(255, 0, 0));

         ^~~~~~~

Adalight_ESP:128:13: error: request for member 'Show' in 'strip', which is of non-class type 'int'

   strip.Show();

         ^~~~

Using library NeoPixelBus-master at version 2.6.0 in folder: C:\Users\sahel\Documents\Arduino\libraries\NeoPixelBus-master

Using library SPI at version 1.0 in folder: C:\Program Files (x86)\Arduino\hardware\arduino\avr\libraries\SPI

exit status 1

'NeoEsp8266Uart1Ws2812xMethod' was not declared in this scope

Can you help me, please?

[Benik3]

Hi. First: please don't post log like this, it's unreadable. Second: You are trying to upload sketch for ESP8266 on Arduino UNO. If you really use Arduino UNO (I don't recommend that with WS2812 and similar LEDs without clock) you must change the method to Neo800KbpsMethod.
Arduino UNO also doesn't have Serial.setRxBufferSize. You must comment it and instead of it you can try to use #define SERIAL_RX_BUFFER_SIZE SERIAL_RX_BUFF in the definition part of code.

[sahelboy]

@Benik3 Sorry I'm a noob when it comes to this stuff :p. I use this product: https://www.rgbtwist.com/

What board should I use with this?

[Benik3]

What grabbing SW does this kit use on PC? The LED strip have 3 or 4pin connector?
A assume that the current RGB twist box is just Arduino UNO inside?

[sahelboy]

@Benik3 I use Prismatik to screengrab on PC. Only problem I have is that it's too fast and not smooth enough. Makes my monitor look like a disco lol. I have no idea if it's 3pin or 4pin. I only know that the lightstrip has 60 leds per meter and high color accuracy (as advertised).

[Benik3]

OK, you can simply try this project on the box (I suppose that there is Arduino UNO inside, but is also possible that the board will not have bootloader, so you are not able to flash it with Arduino IDE through USB. You must try it). You will see if it will be OK. In worst case the LED strip will be "slow" (low FPS).

Well the strip must be connected somehow to the box, here you can see how much pins it have.

[sahelboy]

@Benik3 I tried uploading the Arduino file you posted in this thread, but I got error messages in Arduino and nothing changed.

[Benik3]

What messages?

[sahelboy]

@Benik3

Adalight_ESP:23:28: error: 'NeoEsp8266Uart1Ws2812xMethod' was not declared in this scope

NeoPixelBus<NeoGrbFeature, NeoEsp8266Uart1Ws2812xMethod> strip(PixelCount, PixelPin);

                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

C:\Users\sahel\AppData\Local\Temp\Rar$DIa3740.21061\Adalight_ESP\Adalight_ESP.ino:23:28: note: suggested alternative: 'NeoAvrWs2812xMethod'

NeoPixelBus<NeoGrbFeature, NeoEsp8266Uart1Ws2812xMethod> strip(PixelCount, PixelPin);

                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

                    NeoAvrWs2812xMethod

Adalight_ESP:23:56: error: template argument 2 is invalid

NeoPixelBus<NeoGrbFeature, NeoEsp8266Uart1Ws2812xMethod> strip(PixelCount, PixelPin);

                                                ^

C:\Users\sahel\AppData\Local\Temp\Rar$DIa3740.21061\Adalight_ESP\Adalight_ESP.ino: In function 'void setup()':

Adalight_ESP:29:10: error: 'class HardwareSerial' has no member named 'setRxBufferSize'

Serial.setRxBufferSize(SERIAL_RX_BUFF);

  ^~~~~~~~~~~~~~~

Adalight_ESP:31:9: error: request for member 'Begin' in 'strip', which is of non-class type 'int'

strip.Begin();

 ^~~~~

Adalight_ESP:32:9: error: request for member 'Show' in 'strip', which is of non-class type 'int'

strip.Show();

 ^~~~

Adalight_ESP:35:9: error: request for member 'ClearTo' in 'strip', which is of non-class type 'int'

strip.ClearTo(RgbColor(255, 0, 0));

 ^~~~~~~

Adalight_ESP:36:9: error: request for member 'Show' in 'strip', which is of non-class type 'int'

strip.Show();

 ^~~~

Adalight_ESP:38:9: error: request for member 'ClearTo' in 'strip', which is of non-class type 'int'

strip.ClearTo(RgbColor(0, 255, 0));

 ^~~~~~~

Adalight_ESP:39:9: error: request for member 'Show' in 'strip', which is of non-class type 'int'

strip.Show();

 ^~~~

Adalight_ESP:41:9: error: request for member 'ClearTo' in 'strip', which is of non-class type 'int'

strip.ClearTo(RgbColor(0, 0, 255));

 ^~~~~~~

Adalight_ESP:42:9: error: request for member 'Show' in 'strip', which is of non-class type 'int'

strip.Show();

 ^~~~

Adalight_ESP:44:9: error: request for member 'ClearTo' in 'strip', which is of non-class type 'int'

strip.ClearTo(RgbColor(0, 0, 0));

 ^~~~~~~

Adalight_ESP:45:9: error: request for member 'Show' in 'strip', which is of non-class type 'int'

strip.Show();

 ^~~~

C:\Users\sahel\AppData\Local\Temp\Rar$DIa3740.21061\Adalight_ESP\Adalight_ESP.ino: In function 'void loop()':

Adalight_ESP:120:15: error: request for member 'SetPixelColor' in 'strip', which is of non-class type 'int'

 strip.SetPixelColor(i, color);

       ^~~~~~~~~~~~~

Adalight_ESP:122:13: error: request for member 'Show' in 'strip', which is of non-class type 'int'

strip.Show();

     ^~~~

Adalight_ESP:127:13: error: request for member 'ClearTo' in 'strip', which is of non-class type 'int'

strip.ClearTo(RgbColor(255, 0, 0));

     ^~~~~~~

Adalight_ESP:128:13: error: request for member 'Show' in 'strip', which is of non-class type 'int'

strip.Show();

     ^~~~

[Benik3]

You still didn't change the method NeoEsp8266Uart1Ws2812xMethod as I wrote earlier.
Also don't forget to change number of LEDs and right data pin (this you must find by opening your Twist box). Adalight_UNO.zip

[sahelboy]

Sorry I have zero experience with coding and I don't understand what you're saying :p. Do you mean changing this line " //NeoPixelBus<NeoGrbwFeature, NeoEsp8266Uart1Ws2812xMethod> strip(PixelCount, PixelPin);" to: "//NeoPixelBus<NeoGrbwFeature, Neo800KbpsMethod > strip(PixelCount, PixelPin);" ?

Earlier you also wrote "You must comment it and instead of it you can try to use #define SERIAL_RX_BUFFER_SIZE SERIAL_RX_BUFF in the definition part of code." I have no idea what this means.

I don't see any screws on the box, so I'd rather not risk damaging it. All I can see in the inside of the box is 4 red lights. I don't know if this indicates the amount of data pins? Is there any other way, besides opening the box, to find out the right amount of data pins?

[Benik3]

Well then I recommend to not try to flash it :D
The uploaded Adalight_UNO.zip is already edited. The data pin can't be detected without opening. The Arduino has 14 pins and you must specify in the program on which concretely is the LED strip connected. Also there are two types of LED strip - with and without clock. This also must be specified in the program correctly and if the LED strip is with clock you must again specify Arduino pin for it...

[giofrida]

@TJ-91 I am sorry to bump this old thread. I recently installed a DIY ambilight but the too abrupt color variations really make my head hurt. I think a temporal low pass filter could be very useful for Prismatik in order to smooth out these fast transients. Before spending too much time implementing it (as well as configuring the required tools to compile it) I would like to see how your solution works, so to understand if it is worth it. Would it be possible for you to provide a compiled binary for Windows? Thank you

[TJ-91]

@giofrida if you're talking about the adalight_ws2812 code for the Arduino, you can easily compile and flash it with the Arduino IDE. I also might try it out again, since I've forgotten about it and I am currently not sure in what state it is.