New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong red LED colour for WS2812 #90

Closed
flashyas1 opened this Issue Oct 29, 2014 · 19 comments

Comments

Projects
None yet
5 participants
@flashyas1

flashyas1 commented Oct 29, 2014

I'm working with a WS2812 strip and have tested it using the RGBCallibrate example program and the red LEDs are orange in FastLED V3.0.0.

They appear fine when tested with the Neopixel library. I then tested an old version of FastLED from http://www.tweaking4all.com/hardware/arduino/arduino-ws2812-led/ and the issue was fixed when running the same RGBCallibrate program.

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Oct 29, 2014

Member

What hardware are you using for a controller? Teensy? Uno? Something else?

Member

focalintent commented Oct 29, 2014

What hardware are you using for a controller? Teensy? Uno? Something else?

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Oct 29, 2014

Member

Also are you using 5v or 12v strips?

Member

focalintent commented Oct 29, 2014

Also are you using 5v or 12v strips?

@flashyas1

This comment has been minimized.

Show comment
Hide comment
@flashyas1

flashyas1 Oct 30, 2014

Arduino Leonardo, 5v strip. I'm powering it off a PC power supply so i belive it isn't a hardware issue.

flashyas1 commented Oct 30, 2014

Arduino Leonardo, 5v strip. I'm powering it off a PC power supply so i belive it isn't a hardware issue.

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Oct 30, 2014

Member

Ok - not sure I have a leonardo here to test with, I'll have to get a hold of one. (I'm not having any issues on the UNO, mega, due, or teensy's that I have here).

The timing in the 3.0 release is a lot tighter than the previous version (needed to be, to get brightness/dithering control woven in there) - but there have been a couple of places where that ends up causing issues (though, mostly with 3.3v chips and leds getting fed 5.3v power). I'll see about getting a scope to compare the signal differences between the library versions on a leonardo. It'll take some time for the order to ship to me.

In the meantime, you can try tweaking the timing values for the WS2812's in chipsets.h if you want to- around line 458:

class WS2811Controller800Khz : public ClocklessController<DATA_PIN, 2 * FMUL, 5 * FMUL, 3 * FMUL, RGB_ORDER> {};

try either:

class WS2811Controller800Khz : public ClocklessController<DATA_PIN, 3 * FMUL, 4 * FMUL, 3 * FMUL, RGB_ORDER> {};

or

class WS2811Controller800Khz : public ClocklessController<DATA_PIN, 1 * FMUL, 5 * FMUL, 4 * FMUL, RGB_ORDER> {};

(if either of those work for you, let me know?)

Member

focalintent commented Oct 30, 2014

Ok - not sure I have a leonardo here to test with, I'll have to get a hold of one. (I'm not having any issues on the UNO, mega, due, or teensy's that I have here).

The timing in the 3.0 release is a lot tighter than the previous version (needed to be, to get brightness/dithering control woven in there) - but there have been a couple of places where that ends up causing issues (though, mostly with 3.3v chips and leds getting fed 5.3v power). I'll see about getting a scope to compare the signal differences between the library versions on a leonardo. It'll take some time for the order to ship to me.

In the meantime, you can try tweaking the timing values for the WS2812's in chipsets.h if you want to- around line 458:

class WS2811Controller800Khz : public ClocklessController<DATA_PIN, 2 * FMUL, 5 * FMUL, 3 * FMUL, RGB_ORDER> {};

try either:

class WS2811Controller800Khz : public ClocklessController<DATA_PIN, 3 * FMUL, 4 * FMUL, 3 * FMUL, RGB_ORDER> {};

or

class WS2811Controller800Khz : public ClocklessController<DATA_PIN, 1 * FMUL, 5 * FMUL, 4 * FMUL, RGB_ORDER> {};

(if either of those work for you, let me know?)

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Oct 30, 2014

Member

Oh - also verifying - what version of the arduino software are you using? There are issues with the 1.5.7 and 1.5.8 versions that haven't been fixed yet.

Member

focalintent commented Oct 30, 2014

Oh - also verifying - what version of the arduino software are you using? There are issues with the 1.5.7 and 1.5.8 versions that haven't been fixed yet.

@ojjo

This comment has been minimized.

Show comment
Hide comment
@ojjo

ojjo Nov 7, 2014

Hello,

I'm using NeoPixel Stick - 8 x WS2812S (6-pin), Arduino UNO and FirstLight Sketch on A1 Pin.
Arduino IDE 1.0.5 on Linux Mint.

In FastLED V3.0.0:
Black and Red is green,
Green is yellow
and Blue is cyan

in the old version from flashyas1's link:
Black is black
Red is green
Green is red

No problem in Neopixel Library

ojjo commented Nov 7, 2014

Hello,

I'm using NeoPixel Stick - 8 x WS2812S (6-pin), Arduino UNO and FirstLight Sketch on A1 Pin.
Arduino IDE 1.0.5 on Linux Mint.

In FastLED V3.0.0:
Black and Red is green,
Green is yellow
and Blue is cyan

in the old version from flashyas1's link:
Black is black
Red is green
Green is red

No problem in Neopixel Library

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Nov 7, 2014

Member

So the reason for the Red is green and green is red in the "old version" is because FastLED allows you to change the RGB ordering (not all ws2811/ws2812 manufacturers use the same ordering of RGB data in the data stream) - see https://github.com/FastLED/FastLED/wiki/Rgb-calibration for more information (also more recent versions of FastLED provide the led type NEOPIXEL that pre-orders RGB appropriately for you).

My leonardo just arrived so hopefully I can take a look at what is going on with it this weekend.

Member

focalintent commented Nov 7, 2014

So the reason for the Red is green and green is red in the "old version" is because FastLED allows you to change the RGB ordering (not all ws2811/ws2812 manufacturers use the same ordering of RGB data in the data stream) - see https://github.com/FastLED/FastLED/wiki/Rgb-calibration for more information (also more recent versions of FastLED provide the led type NEOPIXEL that pre-orders RGB appropriately for you).

My leonardo just arrived so hopefully I can take a look at what is going on with it this weekend.

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Nov 8, 2014

Member

@ojjo - I just ran more tests with 3.0.0 on an UNO w/Arduino 1.0.5 and I'm having no issues, however my primary dev environment is OS X. In the meantime, I'm downloading a VMWare image of Linux Mint to see if their Arduino 1.0.5 is generating different code than what i'm running here. (The WS2812 code is fairly timing sensitive, and FastLED does much more in writing out each pixel than the NeoPixel code does (dithering, color correction, non-destructive brightness scaling) - but it means it's easy for a well meaning compiler to screw things up with my asm code).

Member

focalintent commented Nov 8, 2014

@ojjo - I just ran more tests with 3.0.0 on an UNO w/Arduino 1.0.5 and I'm having no issues, however my primary dev environment is OS X. In the meantime, I'm downloading a VMWare image of Linux Mint to see if their Arduino 1.0.5 is generating different code than what i'm running here. (The WS2812 code is fairly timing sensitive, and FastLED does much more in writing out each pixel than the NeoPixel code does (dithering, color correction, non-destructive brightness scaling) - but it means it's easy for a well meaning compiler to screw things up with my asm code).

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Nov 8, 2014

Member

AH! I see the problem @ojjo - unfortunately, while the version of arduino on Linux Mint is 1.0.5 - they've upgraded the avr compiler to gcc 4.8 - which I haven't yet ported the library to. I'll try to change the compiler warnings/issues to warn about this for now.

Member

focalintent commented Nov 8, 2014

AH! I see the problem @ojjo - unfortunately, while the version of arduino on Linux Mint is 1.0.5 - they've upgraded the avr compiler to gcc 4.8 - which I haven't yet ported the library to. I'll try to change the compiler warnings/issues to warn about this for now.

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Nov 8, 2014

Member

I believe this is fixed - at least for Unos. I'm going to leave this ticket open until I can test on a leonardo as well, however.

Member

focalintent commented Nov 8, 2014

I believe this is fixed - at least for Unos. I'm going to leave this ticket open until I can test on a leonardo as well, however.

@focalintent focalintent closed this Nov 8, 2014

@ojjo

This comment has been minimized.

Show comment
Hide comment
@ojjo

ojjo Nov 10, 2014

Works great. Thank you!

ojjo commented Nov 10, 2014

Works great. Thank you!

@grassm

This comment has been minimized.

Show comment
Hide comment
@grassm

grassm Sep 14, 2017

I have the same problem. It is a hardware problem from the stand point that some of the WS2812 chips show green when you tell it to show red. You can fix it by changing the color order from RGB to GRB. I've not come across any WS2812 that the blue isn't correct. So far.....if I buy the 30/m or 60/m I have to use the GRB sequence to get red and green to sequence properly. When I buy the 144/m I have to use the RGB sequence to get red as red and green as green.

grassm commented Sep 14, 2017

I have the same problem. It is a hardware problem from the stand point that some of the WS2812 chips show green when you tell it to show red. You can fix it by changing the color order from RGB to GRB. I've not come across any WS2812 that the blue isn't correct. So far.....if I buy the 30/m or 60/m I have to use the GRB sequence to get red and green to sequence properly. When I buy the 144/m I have to use the RGB sequence to get red as red and green as green.

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Sep 14, 2017

Member

@grassm it's not a hardware problem - it's just that different manufacturers use different data ordering - some use RGB, some use GRB, some use BGR - this is why the library allows you to change the color ordering when adding leds.

Member

focalintent commented Sep 14, 2017

@grassm it's not a hardware problem - it's just that different manufacturers use different data ordering - some use RGB, some use GRB, some use BGR - this is why the library allows you to change the color ordering when adding leds.

@ehsanhaleem

This comment has been minimized.

Show comment
Hide comment
@ehsanhaleem

ehsanhaleem Oct 23, 2017

Grassm
You save my life thank you

ehsanhaleem commented Oct 23, 2017

Grassm
You save my life thank you

@grassm

This comment has been minimized.

Show comment
Hide comment
@grassm

grassm Oct 24, 2017

@focalintent Hardware vs software problem. The difference IS THE HARDWARE! It's not something wrong with the software(ide, library, etc.), it is a difference between WS2812 hardware. Let's say we're buying AA cells and I buy some and the button end is + and the next ones I buy the button is -. Clearly the ones with the negative button end are wrong. It's a hardware problem. The same goes for any hardware part. 2n2222, IRF3408, etc. The PROBLEM is the hardware isn't the same, so it is a HW problem.

grassm commented Oct 24, 2017

@focalintent Hardware vs software problem. The difference IS THE HARDWARE! It's not something wrong with the software(ide, library, etc.), it is a difference between WS2812 hardware. Let's say we're buying AA cells and I buy some and the button end is + and the next ones I buy the button is -. Clearly the ones with the negative button end are wrong. It's a hardware problem. The same goes for any hardware part. 2n2222, IRF3408, etc. The PROBLEM is the hardware isn't the same, so it is a HW problem.

@grassm

This comment has been minimized.

Show comment
Hide comment
@grassm

grassm Oct 24, 2017

@ehsanhaleem Well, I don't think I saved your life, but if I did, then you are welcome.

grassm commented Oct 24, 2017

@ehsanhaleem Well, I don't think I saved your life, but if I did, then you are welcome.

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Oct 24, 2017

Member

It's a hardware consistency issue - but there's no standard way to order the color data for the led chips/chipsets - in fact, this is exactly why i put support in for changing the color ordering. But it's not something "wrong" with the hardware - it's more akin to the difference between cars that put the headlight controls on the left hand side of the steering wheel vs. cars that put them on the right. So - there's nothing wrong with the hardware - it's just done differently. Problem implies that something is wrong/broken.

Member

focalintent commented Oct 24, 2017

It's a hardware consistency issue - but there's no standard way to order the color data for the led chips/chipsets - in fact, this is exactly why i put support in for changing the color ordering. But it's not something "wrong" with the hardware - it's more akin to the difference between cars that put the headlight controls on the left hand side of the steering wheel vs. cars that put them on the right. So - there's nothing wrong with the hardware - it's just done differently. Problem implies that something is wrong/broken.

@grassm

This comment has been minimized.

Show comment
Hide comment
@grassm

grassm Oct 24, 2017

grassm commented Oct 24, 2017

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Oct 24, 2017

Member

Good luck getting any of the led manufacturers/factories to agree with you :) This was the case years before the WS2812 came out, and will likely continue to be the case for years to come.

Some of it comes from the controller chips themselves - all they know is they take in data, and use that data to drive PWM on 3 to 9 outputs (the TM1809 would drive 3 RGB leds from a single controller chip, the LPD8806 would drive two from one). What pins went to what color led depended heavily on the form factor the chips and leds were being put onto and how things were wired up, and so one led strip might have pin 0 wired to red, pin 1 to green, and pin 2 to blue, while another strip might have a different ordering, etc... etc... For that matter, i've had FastLED users who buy their own WS2811 controller chips and wire up the rgb leds to the chips on their own - and they can use whatever ordering they want! (hopefully it's consistent across their project, though :)

Also, WS2812B is almost a meaningless identifier these days - I've seen a number of led strips that are sold as WS2812 that, while they use the same protocol, are actually different (e.g. SK6812) - both in terms of ordering of RGB, but also in the exact timings being used. (I also once saw an APA102 clone being sold as WS2812B compatible). And then there's the fact that World Semi themselves changed the WS2812B but are still calling it WS2812B. Yippie!

To play off of your AA battery analogy - the situation with buying LEDs is more like you are buying something that is AA sized for a toy that takes 4 of them, and you just grab something based on the size and fit because it's cheap and delivers quickly. However, if you don't look closely enough at it, you may not realizing you're ending up with something wildly different, e.g. a Li-Ion 3.7v battery instead of the AA 1.2-1.5 volt battery you were expecting[1]. Toss four of those into your AA powered toy, and you're pumping nearly 15v through it instead of the 5-6v that it may be expecting.

So, basically, no matter what you get - do a quick test before you permanently wire/connect things up, so you know what you're putting in place. (You should be doing that anyway, to make sure you don't have any chips that are DOA - trust but verify and all that jazz)

[1] yes, these are real - https://www.amazon.com/Tenergy-Li-Ion-Cylindrical-Rechargeable-800mAh/dp/B003BHDP4C

Member

focalintent commented Oct 24, 2017

Good luck getting any of the led manufacturers/factories to agree with you :) This was the case years before the WS2812 came out, and will likely continue to be the case for years to come.

Some of it comes from the controller chips themselves - all they know is they take in data, and use that data to drive PWM on 3 to 9 outputs (the TM1809 would drive 3 RGB leds from a single controller chip, the LPD8806 would drive two from one). What pins went to what color led depended heavily on the form factor the chips and leds were being put onto and how things were wired up, and so one led strip might have pin 0 wired to red, pin 1 to green, and pin 2 to blue, while another strip might have a different ordering, etc... etc... For that matter, i've had FastLED users who buy their own WS2811 controller chips and wire up the rgb leds to the chips on their own - and they can use whatever ordering they want! (hopefully it's consistent across their project, though :)

Also, WS2812B is almost a meaningless identifier these days - I've seen a number of led strips that are sold as WS2812 that, while they use the same protocol, are actually different (e.g. SK6812) - both in terms of ordering of RGB, but also in the exact timings being used. (I also once saw an APA102 clone being sold as WS2812B compatible). And then there's the fact that World Semi themselves changed the WS2812B but are still calling it WS2812B. Yippie!

To play off of your AA battery analogy - the situation with buying LEDs is more like you are buying something that is AA sized for a toy that takes 4 of them, and you just grab something based on the size and fit because it's cheap and delivers quickly. However, if you don't look closely enough at it, you may not realizing you're ending up with something wildly different, e.g. a Li-Ion 3.7v battery instead of the AA 1.2-1.5 volt battery you were expecting[1]. Toss four of those into your AA powered toy, and you're pumping nearly 15v through it instead of the 5-6v that it may be expecting.

So, basically, no matter what you get - do a quick test before you permanently wire/connect things up, so you know what you're putting in place. (You should be doing that anyway, to make sure you don't have any chips that are DOA - trust but verify and all that jazz)

[1] yes, these are real - https://www.amazon.com/Tenergy-Li-Ion-Cylindrical-Rechargeable-800mAh/dp/B003BHDP4C

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment