[sorry for late reply, I worked on this all, and now it looks ok :)]


Olin Lathrop ha scritto:
> The method I thought you were referring to was finding the negative and
> positive peaks, low pass filtering each of those seperately, then using the
> difference between the two filter outputs to be the line voltage.  This
> can't work now since the processor can't see the negative peaks.

Hmm, wouldn't I measure the heigth of a half-sinewave? wouldn't it just 
change my scale? (anyway it don't matter since I'm using the other 
approach..)



>> ok, my idea was to make this peak-measurement every 20mS, and average
>> it
>> with the previous one. Resimulated the peak method, and it fits in the
>> 1.2% error indeed.
> 
> You are still sampling at 1KHz to find the peaks, right?  The 1.2% error I
> mentioned comes from the 1KHz samples missing the peak by as much as 500uS.

Yes, my (and your) simulation show that.



>> I also implemented this, storing 20 samples and grabbing the 3
>> highest, and averaging them.
> 
> Hmm.  I'm not sure what that does to the worst case error.  You still don't
> know where the peak was in time any better than before.  It may be that you
> get a little less variation in the output as the sample frequency shifts in
> phase with respect to the signal being sampled.  The constant to go from
> this result to the input line voltage would also need to be a little higher
> since you're never getting exactly the peak voltage.


I did some simulation and also tested it in real. I adapted the scaling 
factor, and the readout is stable enough, +-2 units with continous (say, 
every 100mSec) readout.
I first stored the 20 samples and every 20th made a pick and average of 
the 3 highest; then I chose to store the max 3 on the fly - IMO an 
improved approach.



> This is where simulation is probably easier than going thru all the math.
> Try a bunch of cases, each differing only in the phase between the 1KHz
> samples and the input signal.  When using a single peak sample, the results
> will be over a 1.2% range.  If you get a lower variation by averaging the
> top 3 samples, then that sounds like a easy way to get a little less error.
> The simulation can also tell you what the center scale factor is.  However,
> I would worry about the effects of random noise on this method.


It all looks good enough. I'll check the result of random noise on the 
field...
I'll possibly also add a filtering capacitor at the PIC's input in next PCB.


>> Still have to try it on both simulation and
>> hardware. What would you suggest, if you can point me to an
>> "algorithm", in depth?
> 
> At this point I would probably apply a little low pass filtering to the raw
> 1KHz samples before doing anything more with them.  Two poles with a filter
> fraction of .25 (2 bit shift) looks about right.  Every filter output sample
> then is a function of a bunch of recent raw input samples, with random noise
> attenuated by a factor of 16.  Let this do the "averaging" for you.  Now you
> can pick off the peaks of the filtered signal and use them times a fixed
> scale factor to get input line voltage.  Since each of these peaks will be a
> function of a bunch of input samples, the result will have less variation
> due to sample phase, in addition to having some noise immunity.

:) I know I can probably find it "anywhere" but.. can you show a 
pseudocode for this filter like you mention it?
I did average every "cooked" readout (the 20th - peak - value) with the 
previous one, to just smooth it. Maybe I can do more :)



> You got me curious, so I create a quick hack program to simulate this.  I
> simulated one second plus one cycle.  You can see the result at
> http://www.embedinc.com/temp/dario.csv.  The filters were still initializing
> for the first cycle, so ignore that one.  I made the sample period 1.001 mS
> so that the phase would change thru one whole cycle over the simulated
> second.  You can see that the peaks of the filter output vary very little
> over the full phase difference.  http://www.embedinc.com/temp/dario.gif
> shows the cycle in the middle, when the input peak is straddeled evenly with
> two sample.  Note that the top of the red curve doesn't quite reach 1.0.
> That's the 1.2% error I was talking about before.


thanks for that - in fact it makes perfect sense. It's similar to the 
Excel table I had made up in the beginning.


> However, you'd be using the peaks of the cyan curve.  Those vary much less
> with the phase because each of those samples is a function of a bunch of
> recent raw input samples.  Look in the CSV file at the peak at 0.5085
> seconds and the one at 1.009 seconds.  These are at the worst case opposites
> of the phase.  The difference is less than 1/2 percent, so you can just
> ignore it according to your ealier specs.
> 
> The program that generated this CSV file is at
> http://www.embedinc.com/temp/dario.pas, although there is nothing really to
> see in there.



yeah. again, thank you very much :)

Dario
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist