I’m a relatively new user of OpenEnergyMonitor gear, and so far it’s absolutely brilliant apart from 1 problem. I have an emonTx with Optical Pulse Sensor and it works fine, however I’ve just purchased an emonTH with a similar Optical Pulse Sensor and the sensor is extremely sensitive. It records multiple random counts for only one light pulse - the led is permanently on when in semi-shade (compared to the emonTx sensor which is only ever on when the electricity meter flashes). The emonTx/TH hardware is identical as far as the sensor is concerned (ie direct connection to PD3/INT1 on the ATMEGA328). Does this sound like a dodgy sensor, or is there a config variable that needs to be changed? An external pull-up or pull-down resistor maybe?
There is certainly no configuration variable available. The optical “pulse” sensor is actually a linear device, that’s just overdriven (despite mention of “TTL” etc in the description), and sadly all the information we have is published, I think on the shop page, if not there’s a blog post somewhere.
The only suggestion I can make is you put a hood over the meter. When investigating (very briefly), I found that light was leaking in via the hook-and-loop tape of the fixing. But this (depending on your meter) might not be the only path for ambient light to get in.
(A multimeter reading voltage and hung on the output could be useful while you experiment.)
Thanks - I took some extra precautions to shield out ambient light and it looks ok now. I’ll also experiment with an extra external pull-up resistor - ie the sensor will need to be driven harder (more light) to reach the same threshold voltage, albeit at the expense of increased current drain
I found a pull-down on the signal line worked rather than pull-up. Also, a 0.1uF capacitor can help with debouncing.
Debouncing is associated with mechanical switch contacts.
The capacitor is acting as a spike suppressor. 
Same results, different name.
Aha, you are right. I related the term to the digital input, which is not a correct use 
Filtering the input is more accurate.
Sweet - hadn’t thought of a filter. Will try that and let it run few a few days then compare pulse counts to the meter readings. Thanks for the help
It probably won’t be what makes the most difference, but it I know it would have helped for the setup I had on an Elster.
I had to enable 130ms worth of ‘software debouncing’ to get reliable pulse counts. Equivalent to a small cap, thus, I’d recommend a cap.
It could’ve been the power cables near my optical sense lead were giving off a lot of noise, I’m not sure of why my setup needed so much ‘software debouncing’.
Seems like light leakage could have been your problem, out of interest, is there anything near your cables that could be giving off lots of noise?
Thanks - looks like there were a few problems which are all now resolved:
- Light leakage - being more careful with installation is the answer.
- Noisy connection - just moving the emonTH from the workshop to the meterbox caused thousands of pulses. Wiped the (new) RJ45 plug in it’s socket a dozen times and now perfect.
- Multiple pulse counts - only evident when ‘testing’ with a torch, but left me feeling a bit nervous. A 0.1 uF cap from IRQ to ground improved it, but fully resolved when a 33 k external pull-up resistor was added as well.
Nothing obviously noisy too close, however a meter box will never be the best environment for what is effectively an unshielded lead running directly to an unisolated interrupt.
Great stuff.
I’m interested in this pull-up/down situation now, as I used a pull-down on my signal line. My reasoning was that it’s normally meant to have no output, and then driven high by a light event. A pull-up would increase the sensitivity. Now I’m confused again about my setup
I notice in the emonTH v1.5 hardware there’s no pull-up/down on the board. In the firmware the internal pull-up is enabled, so the signal line is being pulled up. @glyn.hudson design the board? Anyone else got any info on this?
Glyn has tried to get more information - as I mentioned. If you search carefully, you’ll probably find his post about it, with a photo of the inside of the sensor. Short of taking one apart completely to find out what components are inside and drawing out the circuit diagram (even if that’s possible), it seems that no more definitive information will be forthcoming.
The only alternative that I can think of is to do a ‘black box’ series of tests on it and from that develop an equivalent circuit that behaves more or less the same way.
That makes sense. Thank you.
Found one page, but it doesn’t reference the sensor we’re currently using.
The picture is now on the shop page, but I’m reasonably certain there were words with it saying that Glyn had tried to find more information, but the supplier/manufacturer was not cooperative.
Can’t find it. I tried various search methods.
I know I’ve seen it - it was when it was introduced into the shop. It probably became a casualty of the move to Discourse.
Incidentally, enabling the internal pull-up of the interrupt input prevents spurious triggering in the absence of a connection, and bear in mind any mechanical switch can also be used, which will require a pull-up or pull-down, depending on how the switch is wired.
I don’t doubt you. Must be around somewhere.
I think enabling the pull-down would do the same?
According to the device data sheet, there is only an internal pull-up.
You have a data sheet? What Chinese vault did you break into for that?
So a pull-up inside the device might mean it works off the back of a conventional LDR.
I’ll revisit this in the future… Keen to test the effect of a pull-up vs pull-down.
The Atmel one - and I didn’t think it was Chinese. I’m talking about
Oh! I thought you meant the sensor internals
OK good to know…