WS2812B + Propeller Issue

Jon Keinath

I recently purchased a 10-pack of the WS2812B modules and wired 3 of them up on a Propeller Professional Development Board. I downloaded the demo code from the downloads section and everything was working well. I then cycled power (and disconnected my USB connection). When they turned back on they did not light (or do anything else).

Troubleshooting already completed:
1] Reconnect USB - No difference
2] Verify 5V and 3V3 available on PPDB - Check
3] Re-program Propeller w/Demo Code - No difference

Troubleshooting needed.
1] Verify propeller is running by toggling a PPDB LED.
2] ???

Right now the first WS2812B sits at a dim red output and the others (2) are off.

Is there a way to "reset" them?

I have a few more modules that weren't hooked up yet, but I don't want the same thing to happen to them as well.

Thanks!

JonnyMac

Remember: You can program the Propeller without a crystal, but the WS2812s require at least an 80MHz system clock for the driver (I wrote it) to work. An easy test that you crystal is working is to include FDS with a moderate/high baud rate (I use 115200); output a message to the terminal (press F12 if using Propeller Tool). If you get good serial then the problem lies elsewhere. Double check your connections, and do keep the data connection to the first WS2812 module as short as possible.

Duane Degn

If you have multiple LEDs in a strand and you lose the ground connection all the current flowing through the LEDs comes back through the data line. This quickly burns out the first LED in the chain.

I'd suggest removing the first board from the chain and make sure the ground has a solid connection and try again. You've probably lost one of your WS2812B Fun Boards. May it R.I.P. (unless you try a LED transplant (I've done this several times)).

Edit: Check out the "Losing Ground" thread in the Similar Threads section.

JonnyMac

Wow, I've never experienced that but a friend did about a month ago -- will let him know. Thanks for the info, Duane.

Roy Eltham

Driving the WS2812B's with a 3.3v data line can be problematic. I generally use a 3.3v to 5v level translation between the Prop and my WS2812B chains. It seems to be more of an issue with long chains.

Duane Degn

Roy Eltham wrote: »

Driving the WS2812B's with a 3.3v data line can be problematic. I generally use a 3.3v to 5v level translation between the Prop and my WS2812B chains. It seems to be more of an issue with long chains.

I agree but Jon Keinath would likely see some activity with 3.3V logic (other than the dim red output on the first LED).

My bet is still a burned out chip in the first LED.

BTW, apparently these LEDs can use 3.3V as Vdd and when doing so don't have the communication problems associated with the mismatched logic.

T Chap

In another thread Jon has a schematic for the TC4427 line driver in one of the other WS2812B threads. For a quick off the shelf test today though you could try out a CMOS 4050 with the VDD at 5V, it will output 5V and accepts 3v3 inputs from the Prop, I have not tested it on the WS2812B but it is a cheap quick level translator.

JDat

Roy Eltham wrote: »

Driving the WS2812B's with a 3.3v data line can be problematic. I generally use a 3.3v to 5v level translation between the Prop and my WS2812B chains. It seems to be more of an issue with long chains.

No problems for me.
* Propeller supplied from FT232RL's 3.3V onchip regulator output(Pin 17 on SSOP packate) . Bad idea, but works perfectly.
* 128 WS2812b's supplied from ATX PSU +5V bus. No problems (max current ~6.5A) with asymmetrical load (+12V bus not connected to load).
* No level translator from propeller to LED board. Interconnection wire length ~ 20 centimeters (data+gnd).

Everything work like charm. I am testing software part right now.

tomcrawford

Anybody else having trouble uploading jpg files? Anyway, I am driving directly from a prop pin with a 4" wire with no problems at all. I have two strings of ten each. Would show a picture if I could.

Duane Degn

tomcrawford wrote: »

Anybody else having trouble uploading jpg files?

Not all the time. Just when a picture would be very helpful.

JonnyMac

For long connections I love the TC4427 MOSFET driver (this is great for long servo connections, too). Schematic attached.

Peter Jakacki

Roy Eltham wrote: »

Driving the WS2812B's with a 3.3v data line can be problematic. I generally use a 3.3v to 5v level translation between the Prop and my WS2812B chains. It seems to be more of an issue with long chains.

The quick and easy solution is to put a diode in the +5V line to the LEDs so that they receive a reduced supply voltage which also reduces the Vih level enough to work properly with 3.3V. The diode can even be a schottky and still have enough margin but a normal 1N4004 works well.

JDat

Peter Jakacki wrote: »

The quick and easy solution is to put a diode in the +5V line to the LEDs so that they receive a reduced supply voltage which also reduces the Vih level enough to work properly with 3.3V. The diode can even be a schottky and still have enough margin but a normal 1N4004 works well.

For 10 LEDs it's OK, but for long strips...
I'd prefer to use simple level shifter with 2 NPN transistors+3 resistors.

Peter Jakacki

JDat wrote: »

For 10 LEDs it's OK, but for long strips...
I'd prefer to use simple level shifter with 2 NPN transistors+3 resistors.

Remember that this is a "quick" solution, it lets you know if there is a level translation problem at least, and it's still fine for shorter lines or if you happen to have a TO220 Schottky handy. Remember that CMOS Vih min is 0.7Vdd and either we boost up the signal or lower the LED's Vdd, either way will work.

I state facts first independent of my personal preference so there is a real choice, then maybe my personal preference which in a PCB design would be for a simple 74HCT86 single-gate XOR configured as a level translation buffer. Stating a personal preference without backing up the pros & cons really doesn't help anyone make an informed choice. BTW, your simple "RTL" level shifter (circuit?) may not work too well at those higher speeds, have you actually tried it out before recommending it?

JonnyMac

For 10 LEDs it's OK, but for long strips...

Each WS2812 reshapes the input before presenting it to the output, hence if you can get one LED to work well, you can get 100 to work just as well. Remember that these LEDs can consume about 60mA when on full white, so be careful with your power supply.

Tubular

I've been using the Prop at 3v6 to get past the threshold problem, not that I ever saw it as a problem at 3v3. Furthermore I've been running lots of leds in the 6~7v dc region (deliberately, for heat output), and haven't had issues with data or thresholding.

I have heard a few accounts of first led failing though. I just haven't seen it myself.

One thing that could be going on is to do with the timing of the collapse of multiple rails. If the 5v rail collapses faster than the 3v3 prop output, due to all those leds taking so much current, depleting the 5v caps faster than the 3v3 ones associated with the prop, that leaves the 3v3 prop output trying to power the strip via the DIN pin and its body diode, although the 28 ohm prop fet impedance should help limit the damage. So, an external diode here between DIN and +5V might help.

Tubular

(afterthought)

An alternative to a pulse driver / voltage translator would just be to put a single WS2812 (or WS2811 ic) right next to the prop. The output from that is 5v reshaped as Jon points out.

The props 3v3 output always worked fine for me, but this would be an easy and cheap way to achieve the 5v signalling level without potential timing issues

Peter Jakacki

When it comes to 3.3V to 5V level translators I don't think you can beat the single gate logic in an SOT-23 pack, it's small, it's cheap at around 20 cents, and it's rail to rail and fast. I use an XOR to invert or buffer but for the same price you can also get configurable gates.

I would think too that the Din pin trying to power the chain during power sequencing or 5V loss would be solved easily with a resistor in series with the first Din, maybe around 1K or so.

Jon Keinath

After some more testing it appears somehow fried the chip inside all three LEDs. I tried another set of 3 and they work just fine.

I do know that I didn't have the ground connected right on the first LED of the first set of three (was wired to the wrong side of the breadboard power rails aka. no connection to anything), but after fixing this they worked fine. It was only after a power cycle that they quit working. I'll probably attempt a replacement of the LED on the burned out modules. Not a big deal. My final project is going to use a custom board with these LEDs directly on the board. They modules were just a quick way of testing.

Thanks for all the help!

JDat

JonnyMac!

Questin about Your "jm_ws2812_ss" library.
Why after 1st strip.execute(...) I am gatting green on 1st LED?
Bug in ws2812 ASM init part?

See code snippet below:

CON

        _clkmode = xtal1 + pll16x                                               'Standard clock mode * crystal frequency = 80 MHz
        _xinfreq = 5_000_000

        CLK_FREQ = ((_clkmode - xtal1) >> 6) * _xinfreq               ' system freq as a constant
        MS_001   = CLK_FREQ / 1_000                                   ' ticks in 1ms

pixelcount=100
WS2812bPin=25

txpin=30
rxpin=31

i2cSCL=28
i2cSDA=29
EepromStoreAddress     = $8000
OBJ
debug     : "FullDuplexSerial"
EEPROM    : "I2C PASM driver v1.4"        
strip     : "jm_ws2812_ss"

PUB Main

debug.Start(rxpin,txpin,%0000,115_200)

    EEPROM.start(i2cSCL,i2cSDA,400_000)                 'init eeprom
    readeeprom                  'read eeprom

    dumpram
    strip.start_b(pixelcount)          'init LED strip
    strip.execute(WS2812bPin,pixelcount,@liveframe)          'why after this I am getting green on LED 0?
    strip.execute(WS2812bPin,pixelcount,@liveframe)          'after executing the same command again everything is OK.

repeat
' debug parser
'write to eeprom by comand
'write byte to ram if nacessary.
'dump ram by command
'etc
pub readeeprom  
    eeprom.read_page(eeprom#eeprom,EepromStoreAddress,@eepromsavestart,@eepromsaveend-@eepromsavestart)
pub writeeeprom | i
  repeat i from 0 to (@eepromsaveend-@eepromsavestart)/128-1
    eeprom.Write_page(eeprom#EEPROM, EepromStoreAddress+i*128, @eepromsavestart+i*128,128)  
pub dumpram | i
  repeat i from 0 to @eepromsaveEnd-@eepromsavestart-1
    if (i//16)==0
      debug.tx(13)
      debug.hex(@eepromsavestart+i,4)  
    debug.tx(32)
    debug.hex(byte[@eepromsavestart][i],2)
  debug.tx(13)

DAT
eepromsavestart

liveframe  long $00_00_00_00[pixelcount]   'initially all zero, but we are loadin new data from eeprom

eepromsaveend

Seems that there are problems in ASM driver initialization part.

T Chap

_clkmode = xtal1 + pll16x ' 16x required for WS2812
_xinfreq = 5_000_000

Do you have a CON section with this in it?

JDat

Ohh. Sorry! Yes, I have. Forgot to paste in forum.

T Chap

jm_ws2812_ss

Where is this posted?

Just a guess since I can't test your code without that object _ss version, if it works the second pass then maybe the first pass is causing enough delay for the cog driver to launch. Try removing the first execute, and insert in it's place a waitcnt of some amount to insure the cog has launched and is running.

JDat

Latest from JonnyMac on OBEX:
http://obex.parallax.com/object/703

JonnyMac

Seems that there are problems in ASM driver initialization part.

I'll have a look. I'm pretty careful about testing before putting anything into ObEx, but I am human and may have erred.

JDat

JonnyMac wrote: »

I'll have a look. I'm pretty careful about testing before putting anything into ObEx, but I am human and may have erred.

It's OK. Your libraries are great. Thank you for your great! DMX in; DMX out (with my little patches ) Some bugs? Well that happens to everyone.
I'm just lasy and don't want to debug myself.

BTW, is ws2812b_ss asm compatible with PASD? I saw that you are using numbered references to registers... Or am I missed something...

PS: PASD debugger

JonnyMac

Now I'm confused... did you determine that the problem was in your code? I knocked up a little demo that didn't reveal any problems (it's attached -- note that neat formatting makes things MUCH EASIER to suss out).

Well that happens to everyone. I'm just lasy and don't want to debug myself.

Yes, that happens a lot: people claim my code is broken, but don't have the fortitude to show me where. I guess people assume that an unknown actor in Hollywood has very thick skin and they can sling unfounded Smile at will.

I saw that you are using numbered references to registers

I used to call my general-purpose work variables t1, t2, etc. -- I changed to r1, r2, etc. as this seemed to be a trend. It has nothing to do with PASD.

If you decide post your little DMX patches, please remove my name. I will be responsible for my own code, but not yours.

JDat

Well. I need to finish and test DMX out with patches. No problems about references your name.

Thank you for latest version. I am going to test it NOW!

JonnyMac

Okay, I have to ask: What did you find necessary to patch (fix) in my DMX code? Disneyland, Disney Imagineering, Legoland, and lots of professionals use my DMX code -- none of them have said that it needed to be "patched."

JDat

Quick test with latest ws2812b library. Works great! Thank You!

Well. It's diffrerent story for different topic. Sneak peek: I want to build enttec USB DMX Pro clone with propeller. So, I need to start and stop DMX correctly. Put DMX bus on idle state or switch from DMX out to DMX in. Configure on the fly (without reload ASM cog) DMX packet lenght and point to new data buffer. It's not completed now.

BTW: Full duplex parallel (ft245) library (in OBEX) have bugs in ASM. I will post fix one one day.

Duane Degn

JDat wrote: »

I will post fix one one day.

Why not today?

Or at least point out the bugs so others wanting to use the driver don't have to repeat your work?