Looks a neat project, Link. I use the CCS compiler for all my PIC projects. You soon get the feel of what codes efficiently and what does not. The big thing to be aware of it how much bank switching goes on when accessing local variables, global variables and device registers. It pays to study the listing output from the compiler and then juggle the use of local versus global variables in procedures to minimize the bank swapping.

In your circuit, you will have to choose a TVS clamp with a low leakage so as not to cause inaccuracies in the digitized data, but there is quite a wide choice available. Are you deliberately rectifying the signal at the input of the PIC using the TVS diodes? If not, you could connect the PIC's analog inputs to the mid-point of a resistive divider from the power rail to ground with the signal from the TVS capacitatively coupled to it to get the full signal waveform into the PIC.

I like that idea it will give me a fixed center point. Thanks very much for that Boswell!

here is some quick photos

The code is now mostly working, I had to install a few updates from CCS, as they had not played with the PIC16F1947 yet....they don't have debug mode working yet but I can flash the chip at least now. So now I am working making the LED appear 'on' more solidly, what do you guys do average the reading and/or slow down the display speed?

For VU amd PPM displays, you need to follow the standard algorithms, which do include some averaging. However, if this is a level meter for digital inputs, you need to respond to and hold the input peaks so you can have a chance of seeing short excursions that could overload an ADC. I tend to like bar displays that leave a "max" LED on for a certain time while the others in the bar continue to show the current level. The "certain time" should be settable as either around a second or indefinite if you need to leave the unit and come back to see if there have been any overs.

So CCS now has debug mode working. I am still messing with the led smoothness. When I switch to my peak mode the leds flicker, like LM3914 without a rms converter in front of it. Which is essentially what I am doing, removing that in software, so I am not sure if I would use that mode..... I would like to write a real time averaging routine that does not require an array....any thoughts there?

wow..I need to keep studying...Every day I see something I've never seen before in this forum...This looks pretty sweet

Link555, post: 355269 wrote: .... I would like to write a real time averaging routine that does not require an array....any thoughts there?

I suggest low-pass filtering is the thing to use rather than true averaging. You could try a single-pole algorithm of the sort y' = x * a + y * (1 - a), where x is the new input sample, y the previous output and y' the new output. a is a constant in the range 0 to 1 that determines the position of the pole as a fraction of the sampling rate. This needs two multiplies, and probably multi-byte precision to make it work usefully. However, it's easy to simulate in QBASIC or some other friendly language, and you might be able to find values of a that give an acceptable time-constant while lending themselves to shift-and-add operations rather than full multiplies.

Sorry I just saw this response,

I like that approach, so as 'a' nears 1 the new data has greater influence on the output. Conversely as 'a' nears 0 the old data has more influence on the output.

Is that correct?

This is the type of thing I was looking for. Thanks yet again Boswell!