TK.

RGB hue sweep

51 posts in this topic

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:

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 by TK.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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" 

rgb_leds.gif

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

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 by FantomXR

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 :happy: (an old Roland device, see here)

1 person likes this

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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 by FantomXR

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

Thanks for making some things clear ;-) 

It looks awesome... :-)

IMG_4194.jpg

Share this post


Link to post
Share on other sites

Yes, they do! :happy:

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

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

 

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

1 person likes this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now