LED VU Meters, Encoders and SSD1306 Displays

Hi, I’m gonna dig this one back up… I’m hell bent on getting metering working here, and I have some equipment coming to help. Unfortunately, it appears that the popular thing to do in this situation is to make up an LED matrix for external metering. Well, I’ve seen alot of people work with it and their projects, but I think there is another way… tell me if this is absurd…

 

In the past, the only way to have real “analog” metering was to output each channel of audio to each channel, and use an “analog” VU meter, be it the needle kind or the LED kind. There’s got to be another way. I am using the HUI protocol, and there is documentation showing what exact midi messages are being sent for 8 channels of metering. HUI only supports 32 channels, in groups of 8. Now, let say my DAW (Pro Tools) is outputting 8 channels of metering data via MIDI. I should be able to convert those MIDI messages to any type of message I want, but I need to get it out of the MidiBox NG and into a voltage. A variable voltage.

 

The metering data ‘velocity’ is what changes, so theoretically, a low velocity could output a low voltage, or hi velocity could output hi voltage to say… the AOUT NG, which would drive an analog meter. For some reason I can see this working. Any thoughts?

Hi ibaman555

Sounds like a great NG project that you are starting! Im just not so shure what a analog VU that is converted from Digital brings on advatage…

The attack time will be delayed even more and the AOUT will defenetly smothen the small steps in between but this may not satisfy as you whant because the precisenes of the meter will be related to the digital steps that are sent from your DAW…

With midi thats normaly (please correct me if im wrong…) i think 8bit.

Even trough it will defenetly look great!

For the possability you need to ask TK. If the Matrix Metering is already prepared…

Best regards

Novski

Thanks for the positive outlook Novski! The advantage of course would be that I would have the external metering, but as you mentioned, there would probably be the disadvantage of latency, first with the MIDI output and then any latency from the AOUT. In the same respect, I could just as easily connect an analog VU meter as well, if that was something I wanted to do. Either way, I am curious to see how this would work out.

 

I’ve attached a schematic of the metering circuits themselves, right now this will work if connected to an audio source. The PIC16F88 is used with CD4094’s to allow anywhere from 20 or more LED’s at a time on a bar graph. The other option I am trying to understand, is that since there is a microcontroller in play, maybe I could do away with the CV portion of this project.

 

Could the PIC16F88 be programmed to receive the MIDI metering data (or that data translated to serial data) instead of the actual audio to drive the meters? I personally don’t know yet, but I imagine it’s possible. This could possibly give me more accurate metering and reduce latency. Right now, I am converting my controllers RS232 output to MIDI and back again, so I know this is an option.

 

I hope TK has some input as well, I’m still new to all of this but learning a lot quickly.

Hey all,

I am branching off of the plan a little, after doing some research regarding LED matrices. I was unaware at first, that using the Midibox NG is capable of handling a 2,048 LED matrix! Since this is possible I may truly be able to produce a viable product for those of us who rarely need it.

I am still not entirely familiar with how I would set this up, I’m still learning. Given the fact that I can chain 8 DOUTx4, I can have 32 stereo channel meters, which is most ideal. Ultimately it would be a 32x64 LED matrix. Some have said this is a cheaper and more effective approach. I will be trying this against my CV method as well.

I have a few concerns however. Using this specifically programmed matrix for metering, I would need to have consistent brightness regardless of how many LEDs are lit. And if I wanted all 2,048 LEDs lit at the same time (this won’t ever happen), that needs to happen as well. I see that the DOUTx4 uses the 74hc595 as serial registers, but read that a better option for handing the current required would be the hef4794. This would require a redesign however. What are your thoughts?

http://discourse.midibox.org/t/topic/8269

I can confirm that ULN2803 helps to get consistent brightness.

http://discourse.midibox.org/t/topic/17220

 

For best brightness results, consider to use 8x16 matrices (each matrix outputs 8 meters, each with up to 16 LEDs), and not a 16x16 matrix, because than more meters share the same row SRs, than less time per meter to display the pattern!

 

Best Regards, Thorsten.

Great! I will look into integrating the 2803 into my circuits to assist in proper brightness. Additionally, would it help for me to provide +5 voltage to the circuits from an AC or DC power supply (toroidal) to help the current draw?

You’ll need to excuse my noobiness, but what I am looking to achieve here is a meter 32 leds tall. Times 64 of those. When you say “8x16” or “16x16”, you are referring to the number of LEDs high X wide, correct? Later this evening I will sketch up a diagram of what I hope to achieve using the 8 (or 3?) DOUT boards.

The reason I ask is because I can place 32 LEDs on one DOUT board. Then, Make the matrix using another DOUT board giving me 1,024 LEDs, in theory. Then add an additional DOUT board across, giving me the total 2,048 LEDs capable. So, 64 meters across, 32 LEDs tall. Is this possible, or am I configuring this the wrong way??? Thanks for your help!

Additionally, would it help for me to provide +5 voltage to the circuits from an AC or DC power supply (toroidal) to help the current draw?

 

The current draw isn’t that high, because LEDs are time-multiplexed.

A 1A PSU should be enough, this can be delivered from a USB hub based PSU.

 

but what I am looking to achieve here is a meter 32 leds tall.

 

The firmware doesn’t support LED matrices with 32 LED rows, 16 LEDs per row is the limit (and I can’t change this anymore due to conceptional reasons).

 

 

The reason I ask is because I can place 32 LEDs on one DOUT board. Then, Make the matrix using another DOUT board giving me 1,024 LEDs, in theory.

 

It isn’t a good idea to construct a matrix this way (and similar to the 16 LEDs per row max limit, also the column selection lines are limited to 16 for good reasons).

 

E.g. if a matrix has 8 selection lines (as proposed above), each LED row will display a pattern for 12.5% of the reload period.

With 16 selection lines (possible, but not so bright anymore), each LED row will display a pattern for only 6.25% of the reload period anymore. The pattern is still visible, but it’s very dimmed.

With 32 selection lines (your idea…), each LED row will display a pattern for only 3.125% of the reload period. I guess that with such a short duty cycle nothing will be visible anymore!

 

Instead it’s better to use multiple matrices (meanwhile up to 16 matrices are supported) with 8 selection lines each.

Each matrix will require 3 DOUT SRs (one for 8 selection lines, two for the 16 LED pattern)

 

Best Regards, Thorsten.

 

 

Ok. Thanks for explaining this… back to the drawing board…