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,
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,
DT
Hmm, thats very clever. I think is faster too!
Hands on experiment!
Thanks Darrel.
Ioannis
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
************************************************** ***********************
Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
************************************************** ***********************
IF there is the word "Problem" in your question ...
certainly the answer is " RTFM " or " RTFDataSheet " !!!
*****************************************
mmm, kinda mix with embedded strings in your code space and lookup table...
So the Excel sheet would have to pack it in 14Bit and later you use DA.
How's that sound? pretty bad to me as the unpacking method will certainely be slightly longer to execute than reading a single Byte for a DT, DW table ...
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
Hi, Steve
Yess ... the packing method could work great if we had a 1 value to 1 Value "translation"
I think the problem is a bit more complicated than we think at first ...
we have to convert a 256 values log scale ( I do not want to think to 10 bits !!! ) to a 60 values lin scale ...
so, many input values have the same output result ...
Much,much room left !!!
What's the ADC resolution needed if we want a 1 dB precision output, even @ - 40 dB ???
Much,much,much,much,much,much room left !!! ... 255 values limit fully exploded !!!
Could we think to a BIG Select Case statement with 59 times " Case is < $xx or $xxxx" ... I do not know about the CPU time used ...
but it seems a lot easier to write and calculate.
Alain
************************************************** ***********************
Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
************************************************** ***********************
IF there is the word "Problem" in your question ...
certainly the answer is " RTFM " or " RTFDataSheet " !!!
*****************************************
I've been playing with the NCD/DCD with excel, and there's something I can't seem to work in there.
Granted, I'm relying on 30 year old memories from when I was working on microwave radios in the air force. But if memory serves me right, then a change of 3 db is double the power, and -3 db is half the power. And since the impedance is constant, it also means the voltage is either doubled or halved.
So let's assume the signal is scaled so that the (maximum A/D reading +1) corresponds to +7 dbm. Then half of that would be 512 or +4 dbm.
If you keep dividing that down, since there's only 10 bit's, you end up with a minimum of -23 dbm with an A/D input of 1.
And it appears that it would take a resolution of 16-bits to be able to get down to -40 dbm.
I think this applies to however you do it. Lookup, calculate, ...
ADDED: And any noise or offset voltages will Obliterate the low end.
But then, maybe I've got it all wrong? ??
<br>
Last edited by Darrel Taylor; - 22nd June 2007 at 04:51. Reason: Obliteration.
DT
Hi, Darrel
Looks you're perfectly right ... the PIC ADC does not have the 60 dB dynamics(? ... I meant range !!!) our friend Ioannis looks for.
IF you were involved in radios ... may be the ref. "CA3089" will remind you some Vu-meter designs ... ( Use of pin 13 ...)
So, If we used such a Log amplifier to translate from Log to lin scale ... we could easily get this 60 dB Scale ... may be more !!!
Of course ... the drawing is in my Dataroom ... and I still must have a PCB somewhere !!! ( Was a very old Elektor application for an Audio Level-meter ( Sonometer) ... as the CA3089 can work with audio frequencies ... )
Read you soon
Alain
PS: found another with a NE604 Chip ...70 dB covered !!! ... heeuuuuuu file weights ... 325 kB DAMNED !!!
Hi, Savnik
+ 3 dB means the double ... for whatever you want.
but + 6 dB for Power means +3 dB for corresponding voltage
Last edited by Acetronics2; - 22nd June 2007 at 08:23.
************************************************** ***********************
Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
************************************************** ***********************
IF there is the word "Problem" in your question ...
certainly the answer is " RTFM " or " RTFDataSheet " !!!
*****************************************
I was always taught (having worked in the audo industry on digital mixin consoles, and having spent years designing synthesisers and samplers as a hobby) that the actual figure is around 6dB per bit, so 10 bits gives you 60dB, but in reality it's more like 4.5dB. I might be wrong but this is what I've always been told. Surely all you have to do is shift the levels?
Bookmarks