WS2801 and ESP8266 NodeMCU Lua Amica Modul V2 issue

Dear all,
i am trying to use my WS2801 LED strip with a ESP8266 NodeMCU V2.
But i am not able to get anywhere.
I installed FastLED and tried to use the Blink exemple of the library.

Hardware setup:
5V - External 5V 2AMP Supply
ck - D7
sl - RX
GND - GND ESP8266 - GND External 5V 2AMP Supply

Sketch:

#define FASTLED_ESP8266_RAW_PIN_ORDER
#include <FastLED.h>

// How many leds in your strip?
#define NUM_LEDS 10

// For led chips like WS2812, which have a data line, ground, and power, you just
// need to define DATA_PIN.  For led chipsets that are SPI based (four wires - data, clock,
// ground, and power), like the LPD8806 define both DATA_PIN and CLOCK_PIN
// Clock pin only needed for SPI based chipsets when not using hardware SPI
#define DATA_PIN 3
#define CLOCK_PIN 13

// Define the array of leds
CRGB leds[NUM_LEDS];

void setup() { 
    // Uncomment/edit one of the following lines for your leds arrangement.
    // ## Clockless types ##
    FastLED.addLeds<NEOPIXEL, DATA_PIN>(leds, NUM_LEDS);  // GRB ordering is assumed
    // FastLED.addLeds<SM16703, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<TM1829, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<TM1812, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<TM1809, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<TM1804, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<TM1803, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<UCS1903, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<UCS1903B, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<UCS1904, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<UCS2903, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<WS2812, DATA_PIN, RGB>(leds, NUM_LEDS);  // GRB ordering is typical
    // FastLED.addLeds<WS2852, DATA_PIN, RGB>(leds, NUM_LEDS);  // GRB ordering is typical
    // FastLED.addLeds<WS2812B, DATA_PIN, RGB>(leds, NUM_LEDS);  // GRB ordering is typical
    // FastLED.addLeds<GS1903, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<SK6812, DATA_PIN, RGB>(leds, NUM_LEDS);  // GRB ordering is typical
    // FastLED.addLeds<SK6822, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<APA106, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<PL9823, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<SK6822, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<WS2811, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<WS2813, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<APA104, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<WS2811_400, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<GE8822, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<GW6205, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<GW6205_400, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<LPD1886, DATA_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<LPD1886_8BIT, DATA_PIN, RGB>(leds, NUM_LEDS);
    // ## Clocked (SPI) types ##
    // FastLED.addLeds<LPD6803, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);  // GRB ordering is typical
    // FastLED.addLeds<LPD8806, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);  // GRB ordering is typical
     FastLED.addLeds<WS2801, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<WS2803, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<SM16716, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);
    // FastLED.addLeds<P9813, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);  // BGR ordering is typical
    // FastLED.addLeds<DOTSTAR, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);  // BGR ordering is typical
    // FastLED.addLeds<APA102, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);  // BGR ordering is typical
    // FastLED.addLeds<SK9822, DATA_PIN, CLOCK_PIN, RGB>(leds, NUM_LEDS);  // BGR ordering is typical
}

void loop() { 
  // Turn the LED on, then pause
  leds[0] = CRGB::Red;
  FastLED.show();
  delay(500);
  // Now turn the LED off, then pause
  leds[0] = CRGB::Black;
  FastLED.show();
  delay(500);
}

Nothing is happening, some single LEDs are constantly showing in random colour.
Also i am getting some strange logs in Arduino IDE:

In file included from C:\Users\sgott\Documents\Arduino\libraries\FastLED\src/FastLED.h:67:0,
                 from C:\Users\sgott\AppData\Local\Temp\arduino_modified_sketch_13570\Blink.ino:2:
C:\Users\sgott\Documents\Arduino\libraries\FastLED\src/fastspi.h:145:23: note: #pragma message: No hardware SPI pins defined.  All SPI access will default to bitbanged output
 #      pragma message "No hardware SPI pins defined.  All SPI access will default to bitbanged output"
                       ^
Executable segment sizes:
IROM   : 233404          - code in flash         (default or ICACHE_FLASH_ATTR) 
IRAM   : 27068   / 32768 - code in IRAM          (ICACHE_RAM_ATTR, ISRs...) 
DATA   : 1248  )         - initialized variables (global, static) in RAM/HEAP 
RODATA : 692   ) / 81920 - constants             (global, static) in RAM/HEAP 
BSS    : 25008 )         - zeroed variables      (global, static) in RAM/HEAP 
Der Sketch verwendet 262412 Bytes (25%) des Programmspeicherplatzes. Das Maximum sind 1044464 Bytes.
Globale Variablen verwenden 26948 Bytes (32%) des dynamischen Speichers, 54972 Bytes für lokale Variablen verbleiben. Das Maximum sind 81920 Bytes.
esptool.py v2.8
Serial port COM3
Connecting....
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: 48:3f:da:4c:2b:49
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 266560 bytes to 195105...
Wrote 266560 bytes (195105 compressed) at 0x00000000 in 17.4 seconds (effective 122.3 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

Can maybe someone help? :frowning:
Thank you alot!

You have two lines with FastLED.addLeds; that might be the cause, not familiar with the WS2801.

That for sure is the cause. Comment out this line:

// FastLED.addLeds<NEOPIXEL, DATA_PIN>(leds, NUM_LEDS);  // GRB ordering is assumed

Your choice of pins is not the most practical, but not the issue.

Thank you for your answers.
Unfortunatelly still no luck.
I commented the recommended line in the sketch but no change to the outcome.
However i am still not sure about the wiring.

#define DATA_PIN 3
#define CLOCK_PIN 13

I do assume that DATA_PIN is the pin labeled with "sl" and CLOCK_PIN "cK" on the WS2801?
Based on the pinout i do assume that "3" means GPIO 3 which should be "RX" and "13" GPIO with should be "D7". Correct?
image

I do have this board:

Also i am not sure which side of the LED strip i do have to connect. I soldered cabels to one side which should make sense based on the arrow on the strip. However, there is also a connector on the other side. I tried both ends, both do not work.


Except the arrow there is no sign which side is correct:

Which pins would you recommend?

Thank you alot! :slight_smile:

You are driving a 5 V logic device with 3.3 V logic levels.

Code problems aside, it might work better if you use a 74HCT14 hex inverter powered by your 5 V supply as a level converter to provide the proper logic levels.

Use two gates in cascade to invert twice and buffer each of your clock and data lines. You can use other 74HCT gates but the HCT14 is the simplest and possibly cheapest. :+1:

I think you could do with a bigger breadboard to make the wiring simpler (and more reliable). :grin:

Thank you. But i want to avoid to bring new hardware to the system. I read whith short wires i can avoid a level shifter. The wires are only ~5cm long. Still need a level shifter or not necessary?

I think so, i had a look the first time and it seemed correct.

Again i think you've done that correctly

Well normally i would recommend not to use a pin that is used for Serial and the RX pin can also be used for that. On top that, GPIO 13 is one of the alternate pins for Serial. Any of the others really except for GPIO's 1(TX) , 2 (UART1-TX) , 0 (boot-mode select) 15 & 16. You can use any pin, but some special functions can only be performed with specific pins, and you may want to use those functions. You are free to choose of course.

Ah yes !!

Well it was definitely wrong to leave it like it was, though it may have worked. I am not completely sure why FastLED didn't throw an error for re-adding the same buffer pointer, but with a different method. As far as i know the buffer does get added to the object, which normally would result in it being send twice, but on the same pins ? hmmm anyway leave it commented out, best case scenario for the original code is, the buffer gets sent twice with the last set method, which may work, but still is a waste of time.

Won't know until you try it,

Did you now? :grin:

How much voltage do you think a longer data wire might lose?

Thank you guys alit for your answers!
So to be honest i do have this led strip laying around for roughly a year. I tried it at the beginng with a raspberry pi 3b+ and a raspberry pi zero. Same behaviour as currently. Before i put it in the trash i now want to test it with the arduino. I do have the concern that its just broken. If i do buy new hardware like a level shifter i want to be sure that its not just broken :slight_smile: is there a way to test it with out level shifter? In the end i want to use the WLED software. I read on the quick starter guide the following

if this wire cannot be kept short, use a level shifter/translator.

So i was thinking that using really short wires its not required.

Except this i see no error in the current setup except redo the soldering or use different gpios? What do you think?

do you have another controller or a 5v device that can be used as such.

That is possible. It could also be just the first LED of the strip.
To exclude the possibility of it being the logic voltage level that is the cause, the easiest would be to add the level shifter, a 74HCT14 can be bought for very little.

Unfortunately not :frowning:

I do agree. Problem with this cent items always is that its only available in 10+ packs or with 5x item as delivery cost or 1 month delivery time.

On the WLED page the SN74AHCT125N is recommended. Do you think its also fine?

You could do, but i use 74HCT04 or 74HCT14.

Yes it is, but only because of people with rather "concrete" thinking and blindly searching for a "buffer" function.

If it is just as readily available as the 74HCT14 and just as cheap, then great! Use it! But I suspect the 74HCT14 is easier to get. :sunglasses:

If you don't want to buy ICs, maybe you have a couple of transistors?
I haven't done with FastLED, just Adafruit_NeoPixel.h
I have used a NodeMCU to run an 8 x 64 matrix (WS2812) without anything else in between.
Others' results may vary - and that's OK.
To debug the rig, I would work with a sketch that turns on/off one LED satisfactorily and go scale up from there.

There is no difference on the logic levels between the libraries, but yes, it may work, but sometimes also not. With 5v logic levels it always does, One has to be able to eliminate a possible cause.

Ummm, of what use would they be? :astonished:

Ummm Level Ummm translation Ummm wiseguy.

Naturally, there's no 3V vs 5V library conflict. Just recounting my own experience. I only advocate that somebody get, or try to get, a very simple thing right first.

So - how would you propose to use them?

Do you have a circuit in mind?