Community
OpenEnergyMonitor

OpenEnergyMonitor Community

Adjusting sensitivity of Optical Pulse Sensor

Thanks - looks like there were a few problems which are all now resolved:

  1. Light leakage - being more careful with installation is the answer.
  2. 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.
  3. 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 :slight_smile:

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.

https://openenergymonitor.org/forum-archive/node/79.html

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? :slight_smile:

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 :slight_smile:

OK good to know…

Further investigations with Optical Pulse Sensor connected to emonTH. No external pull-up or pull down resistor connected for these measurements, but a 0.1 uF capacitor left connected between IRQ and Gnd.

  1. Vcc = 3.346 V
  2. Virq with sensor in darkness = 0.745 V
  3. Virq with sensor illuminated = 3.333 V BUT the LED on the sensor can be misleading ie in partial illumination Virq varies with light level but the sensor LED remains off. In partial illumination Virq can be as high as 3.330 V (ie high) and the LED still off. I expect this is one reason I was getting spurious counts – as I moved the sensor the LED said it was in darkness but was still getting enough light to be seen as a high.
  4. Pulse count only increments on a positive edge of the IRQ. IRQ is normally low when the sensor is plugged in, and goes high when there is light on the sensor. This initially threw me, since if the sensor is unplugged the internal pull-up raises Virq to 3.336 V.
  5. Using a 1 k ohm resistor connected from IRQ to ground, with the sensor illuminated, 2.58 mA of current was drawn. Voc = 3.333 V therefore the internal source resistance = 292 ohm.
  6. Using a milliameter connected from IRQ to ground, with the sensor in darkness, 0.08 mA of current was drawn. Voc = 0.745 V therefore the internal source resistance = 9.3 k ohm (ignoring meter internal impedance). Similar source impedance is seen if testing from IRQ to Vcc.
  7. Looking at the numbers above, an additional external pull-up or pull-down resistor is not needed for noise elimination, but I still think will influence sensitivity – hard to go further without a circuit diagram. I’ll still keep the 0.1 uF cap to try and filter any spurious noise.
  8. Have run with the 0.1 uF cap for a few days, and pulse counts align with meter readings. Have only used a few kWh so need to let it run for a bit longer.

[Update - June 2020: A circuit diagram of the sensor is available: First try with EmonPi - Pulsecount stuck at 1 - #16 by Robert.Wall - RW]

2 Likes

:slight_smile:

I’m interested how the sensor works at all since the Arduino HIGH trigger voltage is about 0.6V.
EDIT. Correction from further on in thread: High trigger is 0.6Vcc, for 3.33V supply that’s 1.98V.

Would you be up for a couple more tests I could suggest? I don’t have a sensor where I am these days.

No it isn’t, you’ve misread the data sheet:

It says 0.6 × VCC, not 0.6 V.

Or about 1.98 V.

I did miss read it.

Isn’t the Vcc for the Arduino Uno for example at 5V?

That’d be a high trigger of 3.0V.

Yes, but Robert Bates (@Kempson) is using an emonTH, which has a 3.3 V supply.

1 Like

That is a very comprehensive and useful analysis. Thank you for this contribution. I too had noticed that the visible LED was not a reliable indication of operation (Directly connecting to Optical Pulse Counter with RPi? - #59 by Robert.Wall and First try with EmonPi - Pulsecount stuck at 1 - #16 by Robert.Wall)

I’d add - for the benefit of anyone less experienced in these matters who is reading this, that those ‘resistances’ you’ve calculated are probably non-linear, and probably vary quite a lot from device to device. You also found that between the ‘on’ and the ‘off’ states, there is a more or less linear region where the output is proportional to the light intensity. So there are not two distinct output states as the manufacturer’s description seems to imply, but rather a ‘low’ state that corresponds to very low light levels, a ‘transition’ state where the output is some function of the light level, and a ‘high’ state where the sensor is saturated.

My take-away point from all of this is, if the sensor can see any ambient light at all, ignore the LED on the back and check the output voltage for correct operation.

1 Like

Thanks everyone for their assistance. As an aside, I have run the same type of sensor connected to an emonTx for 4 weeks on two different commercial premises (several thousand kWh - a friend who was concerned about his high bill and wanted to look at different tariffs) and the pulse count lines up exactly with the revenue meter register. The switchroom in question was a locked room, lights normally off hence pretty dark. Once again comes back to the comments on installation care and ambient light shielding

1 Like

And thank you for the checks and test!

For a future design note which I hope will be taken into account because the light leakage issue is recurring.

Bearing in mind the testing did not check the effect of pull-down/up at low/high light levels (and thus I make an assumption on the varying impedance) that in a signalling application such as this it’s fairly obvious a pull down and cap are necessary. The cable is one meter long, installed along side potentially high amperage cables, and clearly the device doesn’t have the function of sinking much current at low light levels.

I would like to be proven wrong if possible, as I keep learning.