FlexRMS seems to assume a sine wave in the calculation.
I ran the following 60 Hz PWM with 50% duty cycle out of FIO0:
MB.W(44900, 0, 0)
MB.W(44901, 0, 1)
MB.W(44904, 1, 1333333.3333333333)
MB.W(44900, 0, 1)
MB.W(44000, 1, 0)
MB.W(44100, 1, 0)
MB.W(44200, 1, 0)
MB.W(44300, 1, 666666.6666666666)
MB.W(44000, 1, 1)
So that's a nice balanced ~3.3 volt square wave. The RMS voltage of a square wave is equal to the peak to peak voltage:
https://en.wikipedia.org/wiki/Root_mean_square
However, the values returned are Vrms = 2.302 and Vpk-pk = 3.250. Note that they are exactly different by a factor of sqrt(2), the amount one would expect to see for a sine wave RMS to peak voltage.
Other thoughts:
The frequency measured with a Fluke DMM is 59.98 Hz.
The Period never seems to get updated in Kipling? I haven't tried through the AIN_EF_READ_D registers yet in software, just in the Kipling GUI.
I've tried a few different combos of Num Scans, Hysteresis and Scan Rate; the default seems fine for 60 Hz signals.
I'm using 3 channels at the moment with FlexRMS enabled, what is the limit and how does this processor load translate into command response time?
Overall I think that FlexRMS is a fantastic extended feature and I would love to see a bit more development and documentation. I've yet to play with the RMS_Auto.
Thanks,
- Jason
Noticed that if I use a differential input it seems to give a correct reading (also noticed that my first comment on square wave RMS was a bit incorrect as written above).
I'm curious what the allowable crest factors would be in a 60 Hz application and how accuracy relates to sampling rate, number of samples and hysteresis. I use a lot of SSR based phase angle power controllers driving transformers which can end up with some pretty ugly waveforms...
I finally figured out this issue. It is not a problem of calculation, but rather classification.
The PWM generated by the DIO_EF is a Pulse train, not a square wave. To be a square wave it must have positive and negative amplitudes of equal magnitude.
The wiki page that you linked seems to agree.
Thanks, that makes sense now. Especially with the differential input reading ending up at what I thought I should get initially