Today I did some experiments with RGB LEDs, e.g. to evaluate Andy’s idea to use a single RGB LED as replacement for LED rings around encoders:
Outcome:
a LED matrix configuration doesn’t give us enough brightness levels. E.g. I tried a 4x8 matrix which allows 8 brightness levels for each color, but it turned out that dim values above 4 (50%) don’t make a big difference anymore, accordingly the actual resolution was only 2 bit (4 brightness levels)
therefore I connected the R/G/B LEDs directly to DOUT pins, which gives us up to 16 dim levels and higher brightness (since no multiplexing takes place). Results where much better!
Conclusion: if LED rings should be replaced by RGB LEDs, we need 3 dedicated DOUT pins per LED, makes 48 pins for 16 RGB LEDs = 6 DOUT SRs
Line drivers are not required, since the DOUT SRs are strong enough to drive the LEDs.
Thanks for the tests! Can I ask the specs/datasheet of the LEDs you are using i.e. luminous intensity in mcd? And when you say “directly to DOUT pins” were you using current limiting resistors? I think these will be needed to smooth out differences in brightness one often sees with RGB LEDs, not to mention the lower forward voltage for the Red die.
Without matrix connections the PCB will also be much simpler to route :).
What about RGB LEDs with embedded controller? WS2812B based RGB LEDs or LED strips are quite cheap on ebay. Even a long strip or LED chain can be controlled via one wire. As I analyzed the protocol I think DOUT isn’t fast enough to drive it, but they might be controlled via direct SPI with some trick. I planned to test it, but didn’t have enough time so far. It can be a much easier solution for RGB button LED matrix too.
What about RGB LEDs with embedded controller? WS2812B based RGB LEDs or LED strips are quite cheap on ebay.
Hm! How could I overlook this! Actually I intended to try out this chip some months ago, but I totally forgot about this possibility!
The SPI usage would be too expensive for this purpose, especially since most MBHP_CORE_* modules only have 3 integrated SPIs which are already assigned to other peripherals.
But a 800bps rate (output only) can be easily achieved via bitbanging, e.g. if a DMA transfers the prepared pin access patterns triggered by a timer.
I will try this soon, because it will be a much better solution for RGB LEDs!
Interesting solution! But we have to consider how the illumination will work with the hardware too. There’s one option using a clear shaft encoder but it only has a 4mm hole. Maybe through hole addressable LEDs bent over a PCB hole could do.
Good news is that these WS2812B 5050 LEDs will probably fit (just!) underneath the clear shaft encoders I have, everything on the top PCB layer. No cutouts will also make the PCB routing easier, this was a challenge with the BLM.
One caveat that I read about these is that the sample clock must be very accurate (to within 150 ns). Seems like the F4 should handle this though?
140 nS should be feasible if bitbanging is handled by a DMA channel with highest priority.
I ordered the LED stripe that I linked above and will test this weekend.
If it works like expected, MBNG will get a new EVENT type which will allow to access the LEDs with 8bit resolution.
Whoopwhoop! I’m very curious about it … I also just ordered such a strip (2m but I just need 1,30m). It should be here tomorrow. I didn’t plan to control it with the MIDIbox… but if it would be possible… awesome…
But: Keep in mind that those strips draw a lot of current. In purewhite they draw 60mA each which makes 3,6A per meter with 60 LEDs. So be sure your power supply is sufficient.
Currently only meta commands are provided, more control (such as EVENT_RGBLED) will be available later:
o support for WS2812 LED strips (currently only for the MBHP_CORE_STM32F4 module).
The data input has to be connected to J4B.SC, ground to J4B.VS and +5V to an external PSU (required, since
each RGB LED can consume up to 20 mA!)
Following meta event commands are available:
- RgbLedClearAll (clears all LEDs)
- RgbLedSetRgb:<led>:<r>:<g>:<b> (led=1..64, r/g/b=0..255)
- RgbLedSetHsv:<led>:<h>:<s>:<v> (led=1..64, h=0..359, s=0..100, v=0..100)
- RgbLedRainbow:<speed>:<brightness> (speed=1..255, brightness=0..100)
Most simple way to test a LED strip: enter following command in MIOS Terminal
ngr exec_meta RgbLedRainbow:9:100
(don't forget to wear sunglasses, or start with brightness 20!!! ;-)
My strip came today but I don’t have a power supply that is strong enough.
So, in theory every LED could be adressed individually… right? The meta only says LED 1-64… that’s why I ask.
As long as you don’t enable all LEDs with full brightness, the power consumption is much lower, so that you could supply the strip via J4B
The meta description says “LED 1-64”, because in the driver only 64 LEDs are enabled (each LED consumes 48 bytes, therefore I’m careful).
However, if somebody wants to drive more than 64 LEDs, I could increase the number.
o added EVENT_RGBLED
See cfg/test/rgbled_1.ngc for usage examples
o .NGR file: added "set_hsv" command which allows to control the hue parameters of a RGBLED
Note that the meta commands that I introduced yesterday writes into the RGB LED RAM directly, while a EVENT_RGBLED will store the value in the patch and will overwrite this value on any update. That’s also the reason why we need a “set_hsv” command which allows to change the HSV value of a RGBLED event which remains in the patch.
As long as you don’t enable all LEDs with full brightness, the power consumption is much lower, so that you could supply the strip via J4B
Ah, thanks! Today I found a power supply, that has 2A and I connected it to a 2m strip with 60 LEDs / m. Every LED worked also if I set them to full white. But I didn’t control it with STM but with another RGB controller. I expected that not all LEDs will work with 2A… do you think that the LEDs will be even brighter with a more powerful power supply? They were already very bright
The meta description says “LED 1-64”, because in the driver only 64 LEDs are enabled (each LED consumes 48 bytes, therefore I’m careful).
However, if somebody wants to drive more than 64 LEDs, I could increase the number.
My strip has 120 LEDs but I will cut it to fit an 88 keyboard. So it will be around 90 LEDs. Will then only 64 LEDs work?
This technology breakthrough (and the affordable price for the LED strip) really kind of asks for a MIDI-IN based lightshow device :). E.g. listening on the end of a few MIDI-thru chains of synthesizers, visualizing the Note On/Off events of the different MIDI ports/channels with some Blinkenlights, while otherwise providing a hue-controllable moody ambient lighting for the synths that can slightly flash to the beat
there is a little error message, which the terminal outputs as soon as I start the midibox:
[15857.189] AUTOLOAD ‘DEFAULT’
[15857.189] [MBNG_LCD] no response from CLCD #1.1
[15857.189] [MBNG_LCD] no response from CLCD #2.1 [15857.213] [MBNG_FILE_L:23] ERROR: ‘EVENT std_rgbled’: label too long, should be 8 chars maximum!
[15857.214] [MBNG_FILE_L] 1 error has been found while generating the .BIN file - please fix DEFAULT.NGL!
[15857.223] [MBNG_FILE_S] snapshot #0 not stored in /DEFAULT.NGS yet
[15857.223] Patch ‘DEFAULT’ loaded from SD Card!
[15857.227] [MBNG_FILE_R] /DEFAULT.NGR (optional run script) not found
And btw: Is there a chance so control the LEDs with the internal MIDI clock so it can act like an visual metronome?
//edit: just discovered another “bug”. When I set the rainbow on and run after that RGBLedClearAll not always all LEDs will go off. Sometimes (random) a few of them are still on in different colors (no rainbow effect). I’d need to use the command twice in this case to shut off all LEDs.
//edit2: And finally I recommend to use a shielded cable which goes from the output of J4B to the strip. I didn’t use one and I wonder why my pitchwheel outputs values all the time. I found out that it behaves normal when I disconnect J4B. I’ll try the shielded cable tomorrow.
1.) Using a shielded cable doesn’t help. I’ll try to experiment with aluminium foil to shield the pots of the mod/pitchwheels
2.) The LED-strip seems to be directly connected to the AINSER-command. Create an empty NGC and put this code in:
RESET_HW
SRIO num_sr=2
now run ngr exec_meta rgbledrainbow:9:20. Now look at the speed of the LEDs changing.
Now create another NGC and paste this code:
RESET_HW
AINSER n=1
SRIO num_sr=2
The rainbow effect should still go on when you change between those two NGC files. But you an see that the speed differs. Is this meant to be like this?
And also changing the number of num_sr=x will change the speed drastically.
