RGB hue sweep

[TK.]

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: http://midibox.org/forums/topic/19619-alternative-to-led-encoder-rings-illuminated-red-green-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!
• In order to generate different hues, I use the HSV color model, and sweep H from 256..0 and V from 0..100% (S always 100%)
  See http://colorizer.org for the resulting colors
  Script: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Ftools%2Fgen_colour_maps.pl
• The generated R/G/B Maps are then used in a .NGC file:
  http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Frgb_4.ngc
  This example configuration shows, how the RGB hue can be controlled from a single encoder (or via incoming CC event)

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.

Best Regards, Thorsten.

Edited October 11, 2015 by TK.

[latigid on]

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 :). 

[norbim1]

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.

[TK.]

Can I ask the specs/datasheet of the LEDs you are using i.e. luminous intensity in mcd?

see http://www.ebay.de/itm/171931571912

R: 500-800mcd, G: 3000-5000mcd, B:2000-3000mcd

 you using current limiting resistors?

220 Ohm for R+G, 100 Ohm for B

 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!

E.g. this seems to be a nice one: http://www.ebay.de/itm/1m-60-RGB-LED-Strip-schwarz-mit-WS2812B-5050-SMD-LEDs-WS2811-Controller-WS2812-/371332277097?hash=item567520e369

Best Regards, Thorsten.

[latigid on]

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.

[latigid on]

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?

Now to look for a transparent tact switch :)

[TK.]

Yes, good news!

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. 

Best Regards, Thorsten.

[FantomXR]

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. :)

[TK.]

Code is ready for testing! :-)

-> http://www.ucapps.de/mios32/midibox_ng_v1_033_pre17.zip

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!!! ;-)

Technical details: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fws2812%2Fws2812.c

 

And for the blink: following GIF shows "ngr exec_meta RgbLedRainbow:9:20" 

Best Regards, Thorsten.

[FantomXR]

Whooohoooo! Awesome!!!! :-)

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.

Thanks TK!

Edited October 17, 2015 by FantomXR

[TK.]

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.

Here a new version which supports EVENT_RGBLED:
-> http://www.ucapps.de/mios32/midibox_ng_v1_033_pre18.zip

   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.

Here some usage examples:
http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Frgbled_1.ngc

Best Regards, Thorsten.

[FantomXR]

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?

Thanks! ;-) Can't wait to see it in action.

[TK.]

do you think that the LEDs will be even brighter with a more powerful power supply? They were already very bright ;-)

Just compare the brightness if only a small number of LEDs are enabled with fully brightness vs. all LEDs enabled at the same time.

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?

you could recompile the firmware with 

#define WS2812_NUM_LEDS 90

in the src/mios32_config.h file to allow the control of up to 90 RGB LEDs

Best Regards, Thorsten.

[FantomXR]

Thanks for the explanation! I'll do that ;-) But I'll need a few days to complete the build!

[Hawkeye]

Wow, great 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 :-)

Many greets!

Peter

[FantomXR]

Works perfectly! :-)

[ilmenator]

This technology breakthrough (and the affordable price for the LED strip) really kind of asks for a MIDI-IN based lightshow device :).

MIDIbox MKS 900  (an old Roland device, see here)

[FantomXR]

Dear TK,

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

Do you get the same message?

[FantomXR]

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.

Edited October 22, 2015 by FantomXR

[FantomXR]

I did some more testing:

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.

[TK.]

there is a little error message, which the terminal outputs as soon as I start the midibox:

ok, I've to shorten the label name in the next release

 And btw: Is there a chance so control the LEDs with the internal MIDI clock so it can act like an visual metronome? :-)

MIDI clock event handling is still on the TODO list - so, yes, could be possible sooner or later.

 //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. :)

the rainbow effect is handled in the background task. It's possible that it will be disabled from a higher prio task while new LED values are written, this results into the effect that you see. However, In the next release, LEDs should be cleared correctly.

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?

yes, it's plausible: timings are not ensured when functions (like the rainbow effect) are called from the background task. The AINSER module will cause some additional CPU load and this will slow down the rainbow effect.
Not critical from my point of view (assuming that we are talking about a testing feature)

Best Regards, Thorsten. 

[FantomXR]

Thanks for making some things clear ;-) 

It looks awesome... :-)

[TK.]

Yes, they do! 

Very good work! Finally you are able to display the keyboard split zones with different colors, right?

Best Regards, Thorsten.

[FantomXR]

Well... it would be possible. But you would need to send A LOT of MIDI messages on patch change. I had no idea yet how to get around this...

And finally: The distance between each LED is not the same as the keys... so not every key has it's LED. I have 71 LEDs on the lower board and not 88 :-) Anyway... it's already such a nice feature... I LOVE IT!! :-)

 

[latigid on]

 

Works well! (at least the LED part). Encoders are up next.