Pulse counting - a sanity check

Getting Started
1

I have a new system, EmonTx + RFM69Pi, arrived from the OEM shop yesterday. Seems to work nicely on a spare Rpi-3B with newly downloaded emonSD image (the EmonTx has AC V monitor, one CT on the mains supply, and an optical pulse counter on my SMETS2 meter).
After warming up by reviewing historic smart meter data I’d uploaded to Emoncms, I tried comparing pulse counting results with fresh smart meter data. I am puzzled to find a few % extra pulses are counted.
For example in 10.5 hours last night, 2.419 kWh were registered by the meter, but 2484 LED pulses were counted. The numbers look random - taking the smart meter data half-hour by half-hour, a scatter plot looks like:

image-20210821155144365
image-20210821155144365874×482 31.4 KB

I also correlated actual times (UTC + 1hr) of pulses that I observed (over a 9 minute period) with the pulse counts logged by Emoncms. Sure enough, 36 pulses were counted when I saw only 33 pulses (I can confirm that the sensor green LED pulses when/if and only if the meter red LED pulses, and that the extra 3 pulses came +2 in one 10 s interval and +1 in another 10 s interval. In all other intervals the pulses were counted correctly.
I’ve read at Learn | OpenEnergyMonitor that
image
This is all happening in a dim basement, so I doubt that ambient light is a problem, but the “logic high output without the green LED lighting” comment suggests to me that the sensor is prone to counting extra pulses that aren’t there.
I’ve also read elsewhere that electrical interference can be mitigated by adding a capacitor here or changing a resistor there. (I think I understand the basics of filtering/smoothing, but electronics isn’t my thing - I’m a theorist by training. I don’t have an oscilloscope but can handle a multimeter and do very simple soldering.)
The last clue I can offer is that the +2 extra pulses happened right when (the compressor in) one of our fridges came on:
image
image1440×736 57.4 KB

but nothing obvious happened (in our house at least) to cause the +1 extra pulse. (I chose the range of this plot to match the period over which I was watching and timing LED pulses.)

Is there anything else I can do towards diagnosing the cause, or should I just psych myself up to do the capacitor/resistor mod?

Thanks in advance for any feedback offered.
Otherwise, may I say what an amazing and delightfully collaborative project this OEM is, even if I am a little daunted by the task of finding my way around the facilities Emoncms has, not least for data analysis.

2

I’m afraid it really does sound like interference that’s being picked up somewhere along the line (metaphorically and physically).

The first thing is to move the sensor cable as far away from any mains wiring as you can. And yes, I know it’s right by all the cables, but don’t run it next to them for neatness, for example.

If that doesn’t help (or you can’t), the next simplest is to add a capacitor.

The sensor output - despite what we call it - isn’t a true pulse, it’s just the light level over a very limited range, so slowing it down with a capacitor isn’t going to have a major effect unless the capacitor is far too big and the pulses very frequent. As the sensor is (presumably) plugged into the emonTx using the RJ45 connector, it’s easy enough to add a capacitor at the screw terminals of the emonTx. I suggest about 100 nF connected between terminals 3 & 4, as a starting value. Hopefully, that will damp down the switching spikes enough, but you could go higher if needs be. I’d expect you might start missing pulses if you go too high - not above 2.2 µF. If it’s an electrolytic capacitor, the negative end (usually marked with a stripe) to terminal 3 (GND), and minimal voltage rating - you don’t need more than 10 V.

I can understand that - and not just inside emonCMS. Finding your way around the website is - shall we say - challenging. But we were all there once, so don’t be afraid to ask.

1 Like
3

Many thanks for picking that up so quickly, @Robert.Wall - and you’ve pitched your suggestions at just the level of detail I think I need.
I’ll try to have a go at this tomorrow.
Perhaps it doesn’t help that there’s both a fridge and a freezer within a metre or two of the SMETS2 meter and the EmonTx, and they’re both powered from outlets which are right next to the AC adapter of the EmonTx.

4

Not to mince words, but that 100 nF helped (and I’m of a mind to try just a little more):

image
image872×475 27.4 KB

Unlike the earlier graph, this linear fit is not constrained to pass through zero.
A simpler summary is that the number of excess pulses counted, per half hour metered period, has mean 0.63 and standard deviation 0.72
Obviously the ideal would be 0.0 ± 0.0, and I’m curious to see the effect of different sized capacitors (and possibly also pull up/down resistor values).
The inclination to treat myself to a scope, so I can look at the signal directly is growing…

5

I thought it might be on the low side - especially when you revealed that you have two induction motors right next to it, but it’s better to start there and work upwards. I’d go for rather more than “just a little” - 470 nF or something like that.

6

I’ll try that. But tomorrow.

7

Check out this thread as well. The earlier scope traces are about switch contact bounce, not relevant in your case, but the later traces show what a nearby motor can do to the signal.

8

Thanks for that link, @dBC, a lot of helpful explanations there (and for posting a nice account of your own investigation of motor-induced interference.