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

ws2813 new version with different timing #449

Open
redPanther opened this Issue May 8, 2017 · 13 comments

Comments

Projects
None yet
2 participants
@redPanther

redPanther commented May 8, 2017

Hi,
I had ws2813 running smoothly for a while with driver implemented in current fastled. Now I have another ws2813 and it doesn't work - it flickers all the time. I found out it works with 2812b driver, but I think this is only a lucky coincidence.
I got the new datasheet for the stripe and - oh suprise - the timing is changed.

old:
ws2813_old

http://www.szledcolor.com/download/WS2813%20LED.pdf

new: (revision april 2016)
ws2813_new

datasheet:
WS2813 IC LED information.pdf

can you also support the new version of ws2813?
thx!

edit: there is also a new datasheet from oct 2016. http://www.world-semi.com/DownLoadFile/114
but timming is same as april version

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Apr 1, 2018

There now seems to be another revision of the timings.

http://www.world-semi.com/DownLoadFile/136

ghost commented Apr 1, 2018

There now seems to be another revision of the timings.

http://www.world-semi.com/DownLoadFile/136

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Apr 2, 2018

Member

This is annoying - one of the things i'm doing to the clockless drivers as part of the RGBW/16-bit re-write is making it easier to define timings based on what's in the datasheets, so people can quickly/easily try different timings, for cases like this when datasheets/timings change...

Member

focalintent commented Apr 2, 2018

This is annoying - one of the things i'm doing to the clockless drivers as part of the RGBW/16-bit re-write is making it easier to define timings based on what's in the datasheets, so people can quickly/easily try different timings, for cases like this when datasheets/timings change...

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Apr 2, 2018

I'm not sure how you'd select the appropriate timings other than experimentally.
I started looking into this because a set of WS2813 leds running from pjrc's Octows2811 code were flickering sometimes. So far, the only explanation I've found is that the timings are at the limit of some specs and the LEDs were cold.

ghost commented Apr 2, 2018

I'm not sure how you'd select the appropriate timings other than experimentally.
I started looking into this because a set of WS2813 leds running from pjrc's Octows2811 code were flickering sometimes. So far, the only explanation I've found is that the timings are at the limit of some specs and the LEDs were cold.

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Apr 2, 2018

Member

Eventually, as part of the addLeds specification, people will be able to adjust their timings e.g. be able to say something like:

// define timings in nanoseconds - total per bit, T0H, T0L, T1H, T1L, reset
class my_WS2813_timings : ClocklessController<1100,350,750,750,350,300000>;
...
void setup() { 
  FastLED.addLeds<my_WS2813_timings, DATA_PIN, BGR>(leds, NUM_LEDS);
}
...

I don't have the specific details worked out, but it's become clear to me over the past couple years that I need to make it easier for people to try alternate timings.

Member

focalintent commented Apr 2, 2018

Eventually, as part of the addLeds specification, people will be able to adjust their timings e.g. be able to say something like:

// define timings in nanoseconds - total per bit, T0H, T0L, T1H, T1L, reset
class my_WS2813_timings : ClocklessController<1100,350,750,750,350,300000>;
...
void setup() { 
  FastLED.addLeds<my_WS2813_timings, DATA_PIN, BGR>(leds, NUM_LEDS);
}
...

I don't have the specific details worked out, but it's become clear to me over the past couple years that I need to make it easier for people to try alternate timings.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Apr 2, 2018

The Octows2811 code allows changing of the 'high' length of 1 and 0 bits (and the reset time), which doesn't seem enough to meet the specs but probably is. I wonder what difference the 'low' time makes, when the high is defined and the cycle time is also apparently fixed.

The leds I had trouble with produced regenerated bit times of 330 and 650 ns. It could be interesting to see if that has a temperature dependence.

ghost commented Apr 2, 2018

The Octows2811 code allows changing of the 'high' length of 1 and 0 bits (and the reset time), which doesn't seem enough to meet the specs but probably is. I wonder what difference the 'low' time makes, when the high is defined and the cycle time is also apparently fixed.

The leds I had trouble with produced regenerated bit times of 330 and 650 ns. It could be interesting to see if that has a temperature dependence.

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Apr 2, 2018

Member

It might be enough to just define the total and high times, and let the low times be determined automatically working backwards from that. The main reason I'd consider also having the flexibility for defining both high and low times for both 1 and 0 bits is I have seen data sheets where the timings for 1 and the timings for 0 don't add up : ) But you're right, there'd probably also be a simpler version that simply defined bit time, high times for 1 and 0, and reset time.

Member

focalintent commented Apr 2, 2018

It might be enough to just define the total and high times, and let the low times be determined automatically working backwards from that. The main reason I'd consider also having the flexibility for defining both high and low times for both 1 and 0 bits is I have seen data sheets where the timings for 1 and the timings for 0 don't add up : ) But you're right, there'd probably also be a simpler version that simply defined bit time, high times for 1 and 0, and reset time.

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Apr 2, 2018

Member

I've also found that the timings that the leds worked with could be "tweaked" by adjusting the voltage going into the leds ... it all ends up being very hand wavey, and makes me wish clock+data controllers/chips were more common!

Member

focalintent commented Apr 2, 2018

I've also found that the timings that the leds worked with could be "tweaked" by adjusting the voltage going into the leds ... it all ends up being very hand wavey, and makes me wish clock+data controllers/chips were more common!

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Apr 2, 2018

You can be sure setup and hold specs would be just as vague !

I started using the 2813s because I had a lot of single-led failures in a batch of 2812s with the resulting loss of the rest of the strip. But I'm unsure how much they help. I'm sure they don't test the leds individually, so I wonder how many leds in a strip are already using their 'fallback' data when shipped ?

ghost commented Apr 2, 2018

You can be sure setup and hold specs would be just as vague !

I started using the 2813s because I had a lot of single-led failures in a batch of 2812s with the resulting loss of the rest of the strip. But I'm unsure how much they help. I'm sure they don't test the leds individually, so I wonder how many leds in a strip are already using their 'fallback' data when shipped ?

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Apr 2, 2018

Another interesting possibility is to receive the data from the far end of the strip and check for corruption.

ghost commented Apr 2, 2018

Another interesting possibility is to receive the data from the far end of the strip and check for corruption.

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Apr 2, 2018

Member

Writing avr code to catch the data at the other end is ... tricky :)

Member

focalintent commented Apr 2, 2018

Writing avr code to catch the data at the other end is ... tricky :)

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Apr 2, 2018

Yes :)
Could do it for a specific test (wait for rising edge, read repeatedly, analyse results) but not as a general error check. Maybe the Uart could be tricked into doing it.

ghost commented Apr 2, 2018

Yes :)
Could do it for a specific test (wait for rising edge, read repeatedly, analyse results) but not as a general error check. Maybe the Uart could be tricked into doing it.

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Apr 2, 2018

Member

The trick would be getting the timings to line up right - I don't think you'd want to do it on something running at only 8Mhz -- you'd probably want something running at a higher rate that gave you
a prayer of telling you what your output timing was looking like as well...

Member

focalintent commented Apr 2, 2018

The trick would be getting the timings to line up right - I don't think you'd want to do it on something running at only 8Mhz -- you'd probably want something running at a higher rate that gave you
a prayer of telling you what your output timing was looking like as well...

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Apr 2, 2018

Yes, you want to look at the regenerated lengths and choose something halfway between

ghost commented Apr 2, 2018

Yes, you want to look at the regenerated lengths and choose something halfway between

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