I am not interfacing with spinning disk type meters. I deal with sub-metering where the metering function of the meters is not great. These meters are all electronic. Furthermore, I don't care if the readings are kW or kVAR as the calculations would be the same to calculate demand.
And you are correct that the meters can perform volts, amps, and kW, but many times do not produce kWh readings. And if they do, the kWh readings are sufficient for once a month readings but not 1 minute periodic readings because of the depth of the resolution.
Ok, so to summarize, I have determined that I should take one minute or quicker readings of kVA or kW and log them to a database. I would then do the following on the data:
-15 minute kW demand is calculated by measuring the kWh used in 15 minute periods and multiplying by 4. In other words, 20 kWh consumed in one 15
minute period equals 80 kW demand. If this is calculated once every 15 minutes, this is the block demand.
-If you store the kWh readings every minute, look back in memory for the reading 15 minutes ago, subtract the two and divide by 4, this is a sliding or rolling demand.
These two methods sound very easy to implement from a software side. But these mathematical methods don't simulate the old elecro-mechnical demand meters: do they? Is this method legal for billing calculations?
Paul mentioned a "with a time constant that approximates a 15 minute demand". Is there someplace this constant formula is documented? I believe what you are referring to is the 90% reading after fifteen minutes to simulate thermal demand. Is this method not used for billing calculations anymore?
Also mentioned, I can take the readings fairly quickly but there are other considerations like bandwidth between the meter and computer. Also, the local computer/collector may not even be a full computer with a lot of power.
formatting link
I agree however, that taking the readings as fast as possible will allow more accurate readings.
Thanks for all the help. I am new here but this seems to be a very helpful newsgroup.
Chuck