• GeneralSolved

  • Controlling an LED with variable colours using Bela and SuperCollider

Hi @PFaivre, thanks for your contribution, what part numbers does YF923F5F8 refer to?

11 days later

giuliomoro This assumes BelaMini is used and the neopixels are driven from pin P2.25. To enable that you'll need to run config-pin P2.25 spi after each reboot ( this can be automated later if needed).

Hi, Could you maybe elaborate on automating this? I could not get this to work with the "user command line arguments"...

      you'd need to do something along the lines of what you see here.

      is that clear enough?

      noah automating this?

      The solution linked above is probably the easiest if you are using supercollider or Pd or Csound. But if you are using C++, you can do it in a simpler way.
      Put this line at the top of the file:

      #include <stdlib.h>

      and then in setup() add this:

      	system("config-pin P2.25 spi");

        Perfect, thanks so much!

        6 months later

        Hijacking this thread again:
        I've got some WS2812B 4x4 matrices and I've basically got them running quite well on a Bela mini, however, I still do get the occasional quirks (random single LEDs flashing in random colors every 20 or so seconds). I do think it's not HW related, as I have checked all connections, but it could still be some GND issue I assume.

        I also don't know the exact manufacturer of the matrices, so I don't have a datasheet, but I think the standard WS2812B times you also used are working well.

        I slowly don't know how to approach this issue anymore. @giuliomoro you wrote about the leading zeros and resulting random flashing if not done correctly. How did you determine those numbers (e.g. kSpiLeadingZerosNs)? I tried playing around a bit with those and I do think there are improvements, but as long as there are random flashes it's really hard to tell a difference between improvement and coincidence...

          How many LEDs are you driving at once? Where are they powered from?

          I'm driving 64 LEDs (usually not more than 32 at once). They're powered from a 5V/2A supply, Bela is currently powered from my Laptop, but was also already running powered from the same power supply. While bela is powered from my laptop, I have connected the supply's GND to Belas GND, this was necessary to get the SPI working correctly.

            Things have evolved a bit since the code you've been using: I made a stand-alone OSC-to-Neopixel bridge, see https://forum.bela.io/d/3001-control-neopixel-with-pure-data/6 .

            OSC format is as simple as sending to /leds/setRaw/rgb a set of floats or ints: offset gain led0r led0g led0b led1r led1g led1b... where offset is the offset from the first LED, gain is an overall gain control and then the rest are the values for each LED's red, green or blue components. If you want to send single-component data, use, e.g.:/leds/setRaw/g followed by offset gain led0g led1g led2g (same for r or b);

            A simple Sc example to interact with it would be:

            ~displayOSC = NetAddr.new("bela.local", 7562);
~displayOSC.sendMsg('/leds/setRaw/rgb', 0, 1, 255, 0, 0,    0, 255, 0 );

            Values for LEDs should normally be betwen 0 to 255 and gain should be between 0 and 1. However, you may find it easier to have LED values betwen 0 and 1 and having gain between 0 and 255. Either way, these two values are multiplied. So the below is equivalent to the above:

            ~displayOSC.sendMsg('/leds/setRaw/rgb', 0, 255, 1, 0, 0,    0, 1, 0 );

            Now, I am not sure this fixes any of the issues you are observing, though some bugs may have been fixed in the process, but at the very least it allows us to start form a more modern and maintainable common ground and also perform some extra tests. For instance, you could have O2L running on the board, no Bela program running on the board and Sc running on the host, sending messages to O2L: does the issue still present itself?

            noah I'm driving 64 LEDs (usually not more than 32 at once). They're powered from a 5V/2A supply, Bela is currently powered from my Laptop, but was also already running powered from the same power supply. While bela is powered from my laptop, I have connected the supply's GND to Belas GND, this was necessary to get the SPI working correctly.

            That looks OK.

              Thanks for the link! I was about to integrate your AddressableLeds class from your O2L project in my (C++) project some days ago, but decided to stay with a modified version of the LedStripSpi class by PFaivre that you can find in this thread above (I basically update my LEDs colors constantly in an auxiliary task with a custom refresh rate).

              PFaivre i have encapsulate them in a class for easy usage

              Latency and performance are quite crucial in my project and unfortunately I also don't have a lot of time to spare anymore, which was the reason I originally decided not to switch to your AddressableLeds class.
              I assumed that the Spi implementation was not very different in your O2L project, but it might be worth a try.

              Thinking about performance, would I implement your class with send() in a looped auxiliary task? What would be your approach to implement this in C++ without OSC?

              thanks for your help.

                  There are several possible reasons why the project may not behave as desired and give pseudo-random flashes, due to the system operating out - or nearly out of - specs. Not knowing the maker of your LEDs doesn't really help in figuring out the issue.

                  1- many WS2812B-style LEDs expect a digital input voltage - according to the datasheet - that is at least 0.7 * Vcc. Now, when the LEDs are powered from Vcc=5V, this means that in principle the 3.3V from the Bela's SPI output are not enough (though they work in many cases). See possible solutions here https://forum.bela.io/d/3001-control-neopixel-with-pure-data/25
                  2- timing (and tolerance of the timing) can also vary quite a lot among parts, see same post as above . You may want to get a few datasheets from parts that are likely to be on your boards and see if fine-tuning the T0L, T0H, T1L, T1H helps removing the issue.
                  3- I assume that the Linux driver will service buffers that are between 160 and 4096 bytes in length via a single DMA transaction. IIRC, I inferred this back in the day by looking at signals generated on a scope. I therefore assume that any CPU load on the board will only affect the delay between asking the transaction to start and the moment it is started, but it shouldn't affect inter-byte timing, which is what is critical here and could be the cause for the sort of behaviour you are seeing. It may be that what you are seeing is the effect of me being wrong on this assumption and in that case, having O2L running on its own reacting to OSC messages would put you in a situation where you can test that for yourself as there would be no load on the board except for the program responsible of parsing OSC and sending out SPI data. For this test, we'd need to also increase the priority of that thread (e.g.: running once in that thread:

                      struct sched_param p = {
        .sched_priority = 90,
    };
    pthread_setschedparam(pthread_self(), SCHED_FIFO, &p);

                  )

                  noah How did you determine those numbers (e.g. kSpiLeadingZerosNs)

                  Most numbers come from reading the datasheet, e.g.:

                  alt text

                  The first four should be used for TH and TL in the code, while RES should be used for kSpiLeadingZerosNs. From this specific datasheet, you'd get

                  	const T_t TH[2] = {
		{.min = 220, .max = 380}, // T0H
		{.min = 580, .max = 1000}, // T1H
	};
	const T_t TL[2] = {
		{.min = 580, .max = 1000}, // T0L
		{.min = 580, .max = 1000}, // T1L
	};
	static constexpr double kSpiLeadingZerosNs = 280000;

                  You'll notice these are different from what's in the code right now, which goes to show the importance of knowing the device at hand.

                  Anyhow, in your case you may want to try and increase kSpiLeadingZerosNs to something like 300000. Unless you are using an inverting FET on the output, in which case it should be set to 0 (see linked thread).

                    noah Thinking about performance, would I implement your class with send() in a looped auxiliary task? What would be your approach to implement this in C++ without OSC?

                    Just call send() from an auxiliary task, sure.