Report Power Factor and Crest Factor?

[wci68]

As a feature request:

The GEM currently reports true RMS voltage, current, real power, and energy in its output packets,

Would it be possible to report power factor and crest factor as well? Granted this may need a new packet format to accommodate the new values, but would it be possible?

Alternately, would it be possible to report apparent power, allowing at least power factor to be calculated (real power/apparent power)? Again, it is understood that perhaps a new packet format would be required.

[ben]

As a feature request:

The GEM currently reports true RMS voltage, current, real power, and energy in its output packets,

Would it be possible to report power factor and crest factor as well? Granted this may need a new packet format to accommodate the new values, but would it be possible?

Alternately, would it be possible to report apparent power, allowing at least power factor to be calculated (real power/apparent power)? Again, it is understood that perhaps a new packet format would be required.

You can calculate power factor given the values you already have, volt, amps, and watts.

Watts = VA*PF
PF = Watts/VA

The one issue here though is Volts/Amps sent are instantaneous, so unless using a high packet send interval, these values won't be exact (on the DashBox, we accumulate then average each sample at the end of the minute).

We likely won't be able to integrate these into the GEM packet format itself. But we can look into adding an option to send averaged Amps/Volts instead of instantaneous.

[wci68]

The one issue here though is Volts/Amps sent are instantaneous, so unless using a high packet send interval, these values won't be exact (on the DashBox, we accumulate then average each sample at the end of the minute).

We likely won't be able to integrate these into the GEM packet format itself. But we can look into adding an option to send averaged Amps/Volts instead of instantaneous.

Yes that is what I am looking for, to match averaged values with averaged values or instantaneous with instantaneous.

If feasible, an option to send averaged values for volts and amps similar to watts should indeed fit the bill (thanks)

[ben]

The one issue here though is Volts/Amps sent are instantaneous, so unless using a high packet send interval, these values won't be exact (on the DashBox, we accumulate then average each sample at the end of the minute).

We likely won't be able to integrate these into the GEM packet format itself. But we can look into adding an option to send averaged Amps/Volts instead of instantaneous.

Yes that is what I am looking for, to match averaged values with averaged values or instantaneous with instantaneous.

If feasible, an option to send averaged values for volts and amps similar to watts should indeed fit the bill (thanks)

What software are you using to data log? If feasible, I'd try sending packets every second to it for now.

[sub3marathonman]

If feasible, an option to send averaged values for volts and amps similar to watts should indeed fit the bill (thanks)

What software are you using to data log? If feasible, I'd try sending packets every second to it for now.

I am also hoping for the Power Factor to be displayed.

I am using btmon with emoncms. With the help of people here, I've gotten the btmon program set up to send the amperage and voltage to be logged.

I am having the GEM send packets every ten seconds. From reading elsewhere, sending every second might not be the best, at least on a long-term basis. I'm not sure how much more accuracy would be provided with every five seconds as opposed to every ten seconds. I suppose it reduces the chance of misinformation from instantaneous data vs. averaged data, but it still apparently won't be completely accurate. And it may already be accurate enough, but I can't tell because I don't know the true power factor number.

A bit off-topic, but with the GEM sending packets, and the computer receiving packets, is it a situation that if both are set for say 10 seconds, yet off by a half-second or so, that the computer won't receive the data? So if the GEM is sending every ten seconds the computer should be looking every six or eight seconds so that the times will before too long be synchronized? So is it just too much overhead for the GEM if the program asks the GEM for the data every five or six seconds, as opposed to the GEM just broadcasting on a regular basis? I've always wondered about this, while I've just followed the instructions I never knew why. And how much time does it actually take the GEM to send one packet of information?

[ben]

If feasible, an option to send averaged values for volts and amps similar to watts should indeed fit the bill (thanks)

What software are you using to data log? If feasible, I'd try sending packets every second to it for now.

I am also hoping for the Power Factor to be displayed.

I am using btmon with emoncms. With the help of people here, I've gotten the btmon program set up to send the amperage and voltage to be logged.

I am having the GEM send packets every ten seconds. From reading elsewhere, sending every second might not be the best, at least on a long-term basis. I'm not sure how much more accuracy would be provided with every five seconds as opposed to every ten seconds. I suppose it reduces the chance of misinformation from instantaneous data vs. averaged data, but it still apparently won't be completely accurate. And it may already be accurate enough, but I can't tell because I don't know the true power factor number.

A bit off-topic, but with the GEM sending packets, and the computer receiving packets, is it a situation that if both are set for say 10 seconds, yet off by a half-second or so, that the computer won't receive the data? So if the GEM is sending every ten seconds the computer should be looking every six or eight seconds so that the times will before too long be synchronized? So is it just too much overhead for the GEM if the program asks the GEM for the data every five or six seconds, as opposed to the GEM just broadcasting on a regular basis? I've always wondered about this, while I've just followed the instructions I never knew why. And how much time does it actually take the GEM to send one packet of information?

Unfortunately, it's unlikely that the GEM will be sending power factor.

If there's someone familiar with Python, it could easily be coded into the btmon.py EmonCMS packet. PF = Watts/(Volts*Amps), and add a conditional to make sure it's not greater then one (due to the instantaneous values, it can happen on occasion).

EDIT: Actually, you could probably have EmonCMS calculate this also.

[wci68]

Yes it would be relatively easy to do this in EmonCMS but using single "instantaneous" pair of values for VA and an averaged value for Watts wouldn't be the most accurate.

For the actual sampling device, such as the GEM, PF may even be measured from the phase shift of the current vs voltage waveforms.

This shift is why real power (W) and apparent power (VA) diverge for loads that are not purely resistive, with a corresponding change in reactive power (var), and using trigonometry given any two values (W, VA, PF, phase shift, var) the others may be calculated. Active non-linear loads additionally distort the waveforms also impacting PF and this would be partly, if not largely, missed by using an instantaneous VA with an average W. LED and fluorescent lighting, electronic dimmers, and switching-mode power supplies are all rather common and all potentially significantly impact PF depending on any correction that may or may not be used.

Time (seconds) and energy (watt-seconds) are easily represented with counters but it is not clear how similar could be done for voltage (or current) to represent an "average" that would be useful for use in PF calculation. However reporting such a counter or average in a relationship to the power/energy values should be sufficient to calculate PF if it could not be reported directly.