ruffrecords
Well-known member
For a microcontroller based LED audio meter application I am wondering what is the best way to emulate PPM characteristics (or at least something approximating them).
At the moment I have 44KS/s audio data from an ADC. My current algorithm emulates the usual diode RC circuit with a 0.6mS attack (PPM standard) which turns out to be surprisingly easy. I just keep a variable called Vcap which represent the voltage on the cap. The current sample from the ADC is rectified in software and then held in a variable called Vin. If Vi > Vcap the diode conducts and Vcap is increase by (Vi - Vcap)/24 (because there are 24 * 44K samples in 0.6mS). The math is all integer and I cheated by shortening the time constant so I could divide by 16 rather than 24.
I have now been surfing the web to see what other solutions people have come up with. I was not able to find many but one did catch my eye. In this version, they do not rectify the input or apply an RC time constant (directly). Instead they just take a burst of 50mS worth of samples and keep running values of max and min input samples. At the end of the 50mS period they just calculate max - min. This will clearly catch any transient in the 50mS period no matter how fast it is and every 50mS is plenty fast enough to update the display and the code is pretty trivial.
Edit: The second method has an advantage in that it does not lose one bit of resolution due to rectification.
In both cases release would be a separate function.
Thoughts?
Cheers,
Ian
At the moment I have 44KS/s audio data from an ADC. My current algorithm emulates the usual diode RC circuit with a 0.6mS attack (PPM standard) which turns out to be surprisingly easy. I just keep a variable called Vcap which represent the voltage on the cap. The current sample from the ADC is rectified in software and then held in a variable called Vin. If Vi > Vcap the diode conducts and Vcap is increase by (Vi - Vcap)/24 (because there are 24 * 44K samples in 0.6mS). The math is all integer and I cheated by shortening the time constant so I could divide by 16 rather than 24.
I have now been surfing the web to see what other solutions people have come up with. I was not able to find many but one did catch my eye. In this version, they do not rectify the input or apply an RC time constant (directly). Instead they just take a burst of 50mS worth of samples and keep running values of max and min input samples. At the end of the 50mS period they just calculate max - min. This will clearly catch any transient in the 50mS period no matter how fast it is and every 50mS is plenty fast enough to update the display and the code is pretty trivial.
Edit: The second method has an advantage in that it does not lose one bit of resolution due to rectification.
In both cases release would be a separate function.
Thoughts?
Cheers,
Ian
