LCD BARgraphs

[Darrel Taylor]

Ioannis,

Interesting problem.
I looked at the emesys site, and the idea of using NCD/DCD for the log function is really interesting (and I think, workable).

I'll see what me and Excel can come up with. (might take a few days, so don't wait if you're in a hurry).

Are those voltages what the PIC is seeing? -40db = 20mv etc.
Or is that before an RMS-DC conversion?
And if not, what does the PIC see?
<br>

[Ioannis]

Hi, Ioannis

I just wrote a 255 values lookup table ( convert a LOG pot to lin response ) ...
...
I use a small old Casio FX-880P personnal Computer ... programmed in BASIC ... WOW !!!
Alain

Hmm, a log pot to table? Interesting idea!

I have such a Casio too (the PB-410 model). It helped a lot in the past!

Ioannis,

Interesting problem.
I looked at the emesys site, and the idea of using NCD/DCD for the log function is really interesting (and I think, workable).
...
Are those voltages what the PIC is seeing? -40db = 20mv etc.
Or is that before an RMS-DC conversion?
And if not, what does the PIC see?
<br>

Thanks Darrel. No, I am not in a hurry. I am trying to make it as fast as possible in response. The program is doing other things too so cannot affort delays in tables to choose one of 60.

Yes the NCD/DCD is clever idea. Trying to comprehand...

The 0db as seen on most old cassete recorder is the standard audio level of 1mW at 600ohm. That is about 0,775V rms. If a real VU-meter is checked, the dynamic range is more than 40db. On good ones, it extends even more. So, a log scaling has to be utilized, in order to make good use of the LCDBargraph. Just ADC and displaying makes for nearly 16-19db range!

The -40db is 7.75mV rms or 22mVp-p. These voltages have to scaled and converted with rms converter or active rectifier. Max range would be +6dbm. That is 1.55Vrms or 4.36Vp-p.

I intend to scale the 1.55Vrms to 4Vdc max (or somthing near) for the PIC to be happy.

Ioannis

[Darrel Taylor]

I am trying to make it as fast as possible in response. The program is doing other things too so cannot affort delays in tables to choose one of 60.

Ouch.

I think tying to calculate it is going to take a lot longer than a Table Lookup. (I do mean A LOT)

Maybe Alain's way might be better.

Up to you, if you want to try.
<br>

[Acetronics2]

Hi, Ioannis

Nothing Quicker than a lookup table ... ( PbP lookup not slower than ASM ... cause it's written quite the same !!! )

That's the way used for automobile ignitions ... where we count the µs ...

Alain

[Ioannis]

Thanks. I will see which way I am going to choose. After all precision is not important when displaying audio levels, isn't it? So a table might be better.

Ioannis

Edit: That post was meant as an answer to Darrel, but it came 1 min after yours Alain. But it fit both! Mysterious ways this forum works!

[Darrel Taylor]

Sorry, just another Shameless Plug.

Here's a way you might be able to implement the Lookup Table.
http://www.picbasic.co.uk/forum/show...php?t=3891#LAB

Quietly blushing,

[Ioannis]

Hmm, thats very clever. I think is faster too!

Hands on experiment!

Thanks Darrel.

Ioannis

[Acetronics2]

Hi, Ioannis

this will be smaller ... but not faster. ( operations are still the same ...)

Smaller ??? not sure ... still need 14 bits per value ...

BUT ...

as only 6 bits used per value, could try Value.Highbyte and Value.lowbyte to place 2 values in 1 location ...


just an idea ... but really fun a table loading !!!

mmmm, stupid idea: if you have 60 ( ? ) free locations in the RAM ( You did not tell us about the processor ...), you could download from the EEPROM to the RAM at each power-up ... and use a "simple" 60 values Array.

no faster way !!!

If you want to get a bit more precision ... you can linearize between two points ( "ax+b" line ) doesn't use much CPU ...

that will be "less false" ... LOL

Alain