Anti-aliasing of pulse measurements?

hanskraayeveld | Wed, 10/12/2014 - 00:12 wrote
The last minute show... When I flush the toilet I always use 5,5 liter water. So in dash this should be 5 or 6 liter. In one minute 5 or 6liter,
Or most of the time, in 2 minutes.
The first minute 1, de second 4 or 5.
Or 2 and 3/4 3 and 2/3 And go on.
But... I see only the first minute. The last minute, flukso remembered, and 2 hours later you flush the toilet again, and you have used 2 hours long 0,05 liters/ minute! Or something like that. I want have the real live usage.

When my pulse counter counts on 19.15 5, in dash 5 liter on 19.15 or 2 on 19.15 and 3 on 19.16 should be counted!

Ryton's picture

I moved hans's comment about assigning flow of a pulse counter to the 'pulse timing only, instead of spreading it out over the period' here.
I labeled it "anti-aliasing" in the topic, since it is about unwanted smearing out of discrete data.

My comments:
* This may make sense for a low resolution sensor AND when usage patterns ONLY occurs in small, short burts, like you describe for your water usage during toilet flushing.
* However, most other longer water draws occur during more than one consecutive minute, not exactly following a whole multiplication of the meter constant per minute, for example a washing machine draw, leakage, shower or manual water draw the current method (average over previous time period) makes more sense. If you would assign pulses only to the minute when they occured, (your proposal) you will end up with very jumpy graphs (some minutes 5l/min, others 10l/min).
* Also for electricity or gas usage, which is are also often counted by pulses, and this is the typical use case for a fluksometer (water is a nice addition, not core business imho).

What "intelligent method" would you propose to decide to split the water usage ?
imho, for standalone or pulses, you never have an idea about how they should be assigned:
* Assign all of the pulse 'consumption quantity' to the previous pulse
(assume the new pulse was just the "drop" that triggered the volume count)
* Assign all of a pulse 'consumption quantity' to the reported period (then you may have huge reported consumption there)
* 50/50%, 75-25%, or another division?

Therefore, I understand the comment, but still support the current 'smearing out' of a pulse over the period from the previous pulse, till a better allocation technique is proposed.

hanskraayeveld's picture

Thanks for your comment. I understood and agree...