Avatar for AkosLukacs

AkosLukacs

Member since Dec 2015 • Last active Feb 2019
  • 3 conversations
  • 22 comments

Most recent activity

    • 17 comments
    • 267 views
  • in Electronics
    Avatar for AkosLukacs

    @Robin Of course I was wrong about the wrong order in the struct. Same behavior (GRB) with STM32.

  • in Electronics
    Avatar for AkosLukacs

    @Gordon I think checking for 3 or 4 byte length, and throwing an error if the array length doesn't match the expectation is a valid. I guess 99% it's a programming error. Ran into it myself when messing with these LEDs. :)
    Getting a clear error (IMO) is way better than debugging or blaming LEDs / the library / sample code.

    @Robin Well, there are four colors per chip, so trying 4 bytes per pixel felt a good guess. Add some trial and error, and got them working.

    (Edit: I was wrong, same behavior on the STM32) Regarding RGB / GRB: There is something that looks strange in the NRF driver

    typedef struct
    {
        uint8_t   green; // Brightness of green (0 to 255)
        uint8_t   red;   // Brightness of red   (0 to 255)
        uint8_t   blue;  // Brightness of blue  (0 to 255)
    } rgb_led_t;
    

    The first color in the struct is green, that might be the reason for the strange color order.

    I will try it with an STM Espruino tomorrow.

    Or simply it's banggood, the item and description is not expected to match perfectly...
    Sometimes they list half a dozen part numbers in the name, and drop in the words like "replacement" or "upgraded"...
    Watched some youtube videos about RGB and RGBW strips, and they mentioned that the color order may change between manufacturers and batches. They might be RGB, GRB, or RGBW, GRBW, etc. So if you plan on creating a long strip, better buy it together...

    @allObjects Yes, mine are async ones. 4 pins on the LEDs, and the strips have 3 wires: GND, VCC, and Data in. Data out on the other end, and no clock signal.

  • in Electronics
    Avatar for AkosLukacs

    Thanks for the comments! I guess didn't make it clear: it's working fine. Sorry for the confusion!

    Just couldn't find any info in the docs or in the forum (TIL forum search doesn't search in message bodies). Not knowing the proper chip type didn't help either. So I thought just post what I found. Just to find out later, that info was already posted in different threads. These are nothing new after all...

    @allObjects Didn't try, because it is working with neopixel.write. :)
    That issue didn't affect me, because I use an NRF52.

    But now I know more about these LED chips, thanks everybody!

  • in Electronics
    Avatar for AkosLukacs

    Ok, there are more things to RGB / RGBW leds that I knew :)

    The "RGBW WS2812B" Leds are from banggood. So maybe the seller knows what exact chip it usess...
    For example (on MDBT42Q module):

    require("neopixel").write(D14, [50,0,0,0, 0,50,0,0, 0,0,50,0, 0,0,0,50, 50,50,50,50, 50,50,50,0]);
    

    produces green, red, blue, and three "white"s. Not visible on the image, but the uC is at the green side.

    But the library throws an exception if I try to write a single RGBW pixel, because the array length is not divisible by 3:

    require("neopixel").write(D14, [50,0,0,0]);
    

    My writeRGBW idea would be simply a write that works with multiples of 4 bytes out of the box :)

  • in Electronics
    Avatar for AkosLukacs

    (edited with some clarification) Just got a strip with "RGBW WS2812B" Leds from banggood. The good news is, the neopixel library it just works! If the number of LEDs is divisible by 3, or you pad it.
    For example (on MDBT42Q module):

    require("neopixel").write(D14, [50,0,0,0, 0,50,0,0, 0,0,50,0, 0,0,0,50, 50,50,50,50, 50,50,50,0]);
    

    produces green, red, blue, and three "white"s.
    But the library throws an exception if I try to write a single RGBW pixel:

    require("neopixel").write(D14, [50,0,0,0]);
    

    Tried to dig into the c code, and create a writeRGBW method, initially I thought it's just checking for different length :) But that rabbit hole is a bit deeper with all the device specific drivers...

    @Gordon you have done a great job documenting the build process, had a custom build for the MDBT42Q module in a couple of minutes!

    Do you plan to modify the library for official support? Or just add the workaround to the docs?

  • in The Place for Patreon Patrons
    Avatar for AkosLukacs

    Hi, I guess the list is outdated again :)

    Another question (that probably should go somewhere else): Do you have aliexpress / amazon / banggood / geargbest / etc affiliate link?

    If others are like me, maybe they too order random stuff from all around the world, and a few% of that could help. Or maybe not, don't know how reliable are these...

  • in JavaScript
    Avatar for AkosLukacs

    @allObjects Thank you for the explanation, I guess now I understand the why as well!

  • in JavaScript
    Avatar for AkosLukacs

    Thanks a lot @allObjects for confirming it!

    One thing: the module code does work on the Pixl.JS!
    If I just copy-paste the whole module code "on the right hand side", without require-ing it, it can display all the measurements on the LCD too without any problem.
    Had it running with 1 second refresh for a couple of hours, without any problems.

    I suspect the issue is indeed with the require part, so yes, @Gordon will have some fun puzzle after he comes back from his holiday :)

Actions