You need this test in the second loop that accumulates the samples -
otherwise you are reading a bunch of invalid samples.
But I would suggest you post a project for forum to look at. Note you also
do not need to use an array, just test if current value > last value, save new
value if it is, and do this over a few samples. Then reset and do again.
Use Internet Explorer or Firefox to post, Chrome does not seem to work.
3Vpp with 1V bias, that means some portion of the time, the input is clamped to 0V.
Would suggest to change the bias so that at no time would be the signal goes below 0. Best is to have it bias in the middle of your ADC range - If you want to use this method.
If the signal is a pure sine wave or a wave that you know the crest factor, you can use a diode or a perfect diode circuit and apply the rectified output that to a capacitor. This would give you the peak value of the signal and by scaling with the crest factor would give you the RMS value.
Another problem is the ADC used can only have a max. sample rate of around 5kSPS. Unless you have a sample and hold circuit, the reading of the ADC may not be what you expected, Most likely as if the signal be thru a low pass filter
Whenever possible will you please upload the complete project here, there are some settings that may affect the function of your conversion. To do so, use "Designer -> File -> Archive Project" and then attach the resulting file here (DO NOT use chrome, will not work, other browsers are OK).
The ADCINCVR is an integrating ATOD convertor. It integrates the input signal before converting it to a digital value.
Supposing you have set the resolution of the ADCINCVR to 13 bits. It would integrate the input for 16.384 milliseconds (as per your settings) and do a conversion. Within the 16.384 milliseconds you would have integrated about 63 cycles of your 3840Hz sinewave input. Hence you will get only the DC component for every measurement plus a small noise caused by a portion of a full cycle not completely covered by a measurement.
Set the sample window of the ADCINCVR to a fraction of a full cycle of your sinewave. Then you would get better results when measuring the maximum amplitude. The smaller the fraction, the more accurate the maximum amplitude wille be. As always this is a matter of tradeoffs. If you decrease the sample window, you will have to decrease the resolution. Even at 7-bits resolution, the ADCINCVR will integrate almost a complete cycle of your 3840 Hz input; hence you will need a faster ADC. Have you considered this?
Please tell us the resolution at which your are operating the ADCINCVR. And take care to test for data availability in the ADCINCVR before you proceed to read a sample, as suggested by Dana.
Another approach would be to use DAC and Comparator, basically feed Vx
into one side of comparator, DAC into other side, and slew DAC values until
comparator stops triping from one sample to the next, eg. DAC value is > Vx.
Delay DAC to DAC sample update for a few samples of input while monitoring
This works if input is fixed in amplitude, otherwise algorithm would have to take
care of AM modulation effects. Maybe delay between samples would effectively
integrate out the variation if AM is slow changing relative to Vx fundamental frequency.
Thank you all for the great ideas. I added the check to see if data is available(thank you Dana), and set the resolution to 7 bit. Sampath, your explanation makes perfect as to why I am only able to see the DC bias. I will be going over the ADCINCVR datasheet to adjust ADC. Would you suggest using a different ADC? Maybe DelSig?
I have attached the project.
PSOC_AMPLITUDE.Archive1.zip 522.7 K
If you stick to the ADCINC component you ought to change the "CalcTime" which you set to only 1. It should be 180clock-cycles at minimum and shall be expressed in dataclock cycles which is 1/4 of your CPU-clock. Thus it should be set to 45 to 50 be on the safe side. This will give a sample-rate of 21.3 ksps according to the datasheet.
When precision is not the first goal you might use an SAR with 6 bits precision which is far more faster.
Your column clock is a little high, 3 Mhz, limit is 2.67 Mhz. The datasheet has
conflicting info on this, it shows in other statements 8 Mhz. I will file a CASE to
get this clarified.
I see you commented out the delay after mux switching, that should stay in place.
There is no setlling time spec, but you could run a quick test bed to get a rough idea
of what it needs to be.
You might consider just one routine to handle average, min, max, just to save code
and MIPS since most of these involve a 20 iterations loop, put them all in one loop.
... additionally when looking into your source I realize that you are wasting a lot of your precious stack space:
All variables declared within a function are locals and will be allocated on the stack, and since main() is a function just the rx- and txData + TXTemp + outputstring take 160 bytes off your 256-byte deep stack.
Ways out are: declare the vars as "static" or make them globally.
Thank you for the respones, I will be adjusting stack usage as I get closer to the end of the project.
I switched to using the SAR6 and I am able to see .1 change in amplitude. With the 3840hz signal, would I be able to optimize the clocks to see a .01 change in amplitude?
PSOC_AMPLITUDE.Archive2.zip 492.9 K