3 colour 10 LED bargraph

[andyfromdenver]

Hi Ian et al,

When I saw your thread title, I couldn't resist sharing my most cherished scratch build from a few years back.  Used LM3914 and 15 chips, though if redoing, I would just use quad opamps for ease of fine tuning and experimenting.
Thanks!
Andy

 

[tk@halmi]

I have wondered for a long time why we are stuck on large swinging needles and long LED bars. My ideal indicator would say if my level is on under, on the target, or over what I need.

Three lights could tell you which way to twist or slide the level control. Make the target adjustable with a switch such as -4dB, 0dB or 4dB.

 

[Ricardus]

I have wondered for a long time why we are stuck on large swinging needles and long LED bars. My ideal indicator would say if my level is on under, on the target, or over what I need.

Three lights could tell you which way to twist or slide the level control. Make the target adjustable with a switch such as -4dB, 0dB or 4dB.

Inexpensive Allan & Heath consoles have a  4 LED meter on each channel strip. A green LED that registers signal on that channel (no idea what the threshhold is),  2 yellow LEDs, one for 0, and one for +6, and a red LED for PEAK.

Having worked on various types of meters, including these, give me a long LED meter all day long.  Unless the gear is vintage-ish, then give me swinging needles.

 

[JohnRoberts]

IMO a little meter is better than no meter, while full meters on every audio path inside a complex mixer is easily too much information.

One of the later mixer/consoles I designed used bi-color LEDs on EVERY audio path, this was not overwhelming and IMO very useful, in addition to the standard meter bridge with meters on every sub bus and master L/R.

The bicolor LED effectively indicated green for signal present and red for near clipping. I spent some time trying to come up with a both-on color for another level threshold but it did not make an effective display so I settled on dark, green, or red as the 3 options. The red had a hold time built in because momentary transients can clip but be hard to see.

Often you are searching for is a) the signal getting to where you want it, and b) not distorted...? 

JR

 

[ruffrecords]

Nice one JR.

A good lesson in economy (of information not money).

Cheers

Ian

 

[Piedwagtail]

https://electricdruid.net/led-bargraph-audio-level-display/

I've burnt his recent PIC designs with success - stomplfo etc.
Used an ebay burner(£5); PICs are cheap but needed PICkit 3 Plus (£25) as Microchip are unfathomably contemptuous of non-coding hackers.

R

 

[ruffrecords]

https://electricdruid.net/led-bargraph-audio-level-display/

I've burnt his recent PIC designs with success - stomplfo etc.
Used an ebay burner(£5); PICs are cheap but needed PICkit 3 Plus (£25) as Microchip are unfathomably contemptuous of non-coding hackers.

R

Thanks for the link. I have been vaguely into PIC programming for a few years so I have the PCIkit. I have toyed with this approach but abandoned it for several reasons.

1. I do not like the idea of MHz clocks inside my mixers.
2.. The current draw on the LED supply varies with signal level and I do not wish to risk this getting into the audio signal path (the  Soundcraft comparator plus constant current source technique I favour draws a constant current no matter how many LEDs are on).
3. I am a very old hand at microcontroller design. I have learnt to be very careful in interpreting output port current sink capabilities. They are always quoted in isolation i.e without regard to what any other outputs are doing. Running 10 outputs sinking perhaps as much as 20mA each could be problematic (maybe micro design has come a long way since I first started with them but the basic laws of physics remain unchanged).

I loved this quote "I did a lot of experiments to see if adding filtering to the rectified waveform helped since that’s what genuine VU meters do, but I didn’t like the results. It makes the output very laggy, and it reduces the number of LEDs that light up."

Yup, that's what VU meters do.

Cheers

Ian

 

[PRR]

If this is a tube mixer, shouldn't the blinking lights be Neons??

RCA started monitoring film-sound in the 1920s with a box of neons and tubes. The Russians made IN-9 bargraph tubes for such purposes. Video.  Tips. But a bajillion cheap tape recorders just had one neon "overload" blinker.

At one time I rigged an FM tuning indicator out of two transistors and two *green* neon lamps. Worked good, better than the tuner.

 

[ruffrecords]

If this is a tube mixer, shouldn't the blinking lights be Neons??

As far as the audio path is concerned yes. I am prepared to allow sand based devices elsewhere.

Cheers

Ian

 

[JohnRoberts]

https://electricdruid.net/led-bargraph-audio-level-display/

I've burnt his recent PIC designs with success - stomplfo etc.
Used an ebay burner(£5); PICs are cheap but needed PICkit 3 Plus (£25) as Microchip are unfathomably contemptuous of non-coding hackers.

R

Here is a PIC based meter I designed for a friend's console company (APB), years ago.  I display peak as a dot, and VU as a bar.

JR

 

[JohnRoberts]

Thanks for the link. I have been vaguely into PIC programming for a few years so I have the PCIkit. I have toyed with this approach but abandoned it for several reasons.

1. I do not like the idea of MHz clocks inside my mixers.

The modern PICs provide an internal free running clock, so no external MHz lines.  (FRC runs at something like 8Mhz and you can multiply that inside for more MIPS)

2.. The current draw on the LED supply varies with signal level and I do not wish to risk this getting into the audio signal path (the  Soundcraft comparator plus constant current source technique I favour draws a constant current no matter how many LEDs are on).

There is no reason why you couldn't do that with a micro, but I didn't.  We used 5V HCT(?) logic shift registers to latch the LEDs, Now I would use a dedicated LED latch/driver that can accept 3V logic and unregulated PS.  I had issues reliably interfacing the 3.3V processor to the 5V digital logic. Of course I got it sorted eventually but easier to use a dedicated latch/driver IC.

We were able to see clock noise from the SPI serial data in the console noise floor, I pushed the SPI clock rate up high enough that even WFO noise floor listeners wouldn't "hear" anything. I expect the dedicated latch/driver would probably be even quieter thanks to a more compatible low voltage logic level interface. I had to use a stiffer pull up resistor on the open gate logic to square up the clock line feeding the 5V shift registers to reliably pass data. Noise on a slower rising clock edge caused multiple data bites corrupting the data. This stiffer 5V pull up may have been our dominant clock noise corruption. 

3. I am a very old hand at microcontroller design. I have learnt to be very careful in interpreting output port current sink capabilities. They are always quoted in isolation i.e without regard to what any other outputs are doing. Running 10 outputs sinking perhaps as much as 20mA each could be problematic (maybe micro design has come a long way since I first started with them but the basic laws of physics remain unchanged).

yes, modern lower voltage processors have limited port drive capability (sink and source). My first drum tuner used a 5V PIC that had robust port drive capability  and I directly multiplexed a few tens of LEDs in a 8x5 array. Of course LED noise was not a concern in that design.

For that later 3.3V PIC meter design I needed to directly drive one LED mode indicator from the PIC and they will have one or two ports capable of reasonable current. I may have even doubled up 2 ports, just to be confident.

I loved this quote "I did a lot of experiments to see if adding filtering to the rectified waveform helped since that’s what genuine VU meters do, but I didn’t like the results. It makes the output very laggy, and it reduces the number of LEDs that light up."

Yup, that's what VU meters do.

Cheers

Ian

I like the ability to apply precision time constants to metering in the micro environment. I even coded up a RMS algorithm but abandoned it when I didn't see any difference (between RMS and simple average) on complex music using similar att/rel time constants. It might have been interesting to experiment further with RMS for side chain use in dynamics processing, but for metering the complexity of the RMS algorithm did not seem worth the processor overhead (I had to code up my own square root operation,) while I could have used a RMS look up table for a meter with finite output levels.

Sorry about my typical TMI..

JR

 

[tk@halmi]

IMO a little meter is better than no meter, while full meters on every audio path inside a complex mixer is easily too much information.

One of the later mixer/consoles I designed used bi-color LEDs on EVERY audio path, this was not overwhelming and IMO very useful, in addition to the standard meter bridge with meters on every sub bus and master L/R.

The bicolor LED effectively indicated green for signal present and red for near clipping. I spent some time trying to come up with a both-on color for another level threshold but it did not make an effective display so I settled on dark, green, or red as the 3 options. The red had a hold time built in because momentary transients can clip but be hard to see.

Often you are searching for is a) the signal getting to where you want it, and b) not distorted...? 

JR

I really like  your approach of simplicity. When you have a eight channels of 30 LED bars the Xmas light show  becomes more of a distraction.

I was thinking going as far as having just one RGB LED that shows under target blue, on target green and close to clipping red.

 

[JohnRoberts]

I really like  your approach of simplicity. When you have a eight channels of 30 LED bars the Xmas light show  becomes more of a distraction.

I was thinking going as far as having just one RGB LED that shows under target blue, on target green and close to clipping red.

Try that and see how it looks, when I tried to make a third color out of both red and green, it wasn't different enough IMO to be effective. RGB by definition should all be different enough.

I managed my dual threshold detector, bicolor driver, and hold circuit with one op amp, but there were a handful of discrete glue components.

JR   

 

[Winston OBoogie]

When I did the Universal Audio 2108, I also used a bi-colour led mounted behind a translucent vintage looking mini jewel.

The signal present threshold started off green and would increase in brightness before changing to amber, and then finally red. 
The light was switchable between my J-Fet cascode input stage or the 1176 output amplifier the 2108 used..  Thresholds were obviously set differently for whatever was selected and, when monitoring the input stage, the brighter amber and red did not indicate clip but the point at which soft saturation would begin and hence more 2nd Harmonic etc.

I kinda thought it was gimmicky while I was first putting it together (it wasn't my idea) but folks seemed to like it and, after a while, I did too. 

 

[CBVB]

When I did the Universal Audio 2108, I also used a bi-colour led mounted behind a translucent vintage looking mini jewel.

The signal present threshold started off green and would increase in brightness before changing to amber, and then finally red.
The light was switchable between my J-Fet cascode input stage or the 1176 output amplifier the 2108 used.. Thresholds were obviously set differently for whatever was selected and, when monitoring the input stage, the brighter amber and red did not indicate clip but the point at which soft saturation would begin and hence more 2nd Harmonic etc.

I kinda thought it was gimmicky while I was first putting it together (it wasn't my idea) but folks seemed to like it and, after a while, I did too.

DJH, The 2108 is at the center of my drum recordings, with my drum kit overhead being a Coles 4038 fed into the 2108. During playback recently, the sound on the Coles track was choppy -- cutting out, getting quieter, and so on. I tried changing cables and swapping out the Coles for an SM57, but the same thing happened: choppy audio. I turned the 2108 on and off, and then on again, which corrected it for the next take. However, the same issue happened during another recording. Do you have any ideas about what could be happening?