Archived Forum

Two possible causes spring to mind. If "Not being operated" means the relay contacts are open, then it has all the hallmarks of pickup on the cable. Look for sources of interference and maybe you need to add a small capacitor to remove what are hopefully spikes being picked up from adjacent cables. You could also wire the contacts in twin screened 'microphone' cable, earthing the screen. If it's when the relay is energised, it could also be vibration causing a momentary break. Clean contacts suitable for the very low current, i.e. gold flashed, might be the solution. If you can afford the current, then lowering the value of the pull-up/down resistor should help, both in reducing the input impedance when the relay contacts are open, and in providing a 'wetting' current for the relay contacts (especially if they are silver cadmium oxide or a material that's more suited for high current switching).

According to the data sheet, the IRQ pin is the same as the rest, so it should be switching at 0.3 V_cc and 0.6 V_cc, i.e. it sees a 'low' below 0.3 V_cc and a 'high' above 0.6 V_cc, so there should be no difference between pull-up and pull-down.

Which firmware are you running, and does it have any debouncing logic?   Good debouncing logic will usually  see off any actual contact bounces that occur at the time of the relay opening and closing and also any brief noise-induced spikes that occur when the relay is steady-state.

If you go the pull-down route, make sure the firmware hasn't enabled the internal pull-up on that pin.

Most of the time the relay contacts are open and that's when these spurious counts occur.

i have just measured the voltage on the IRQ terminal and it's normally 0.7V, rising to 4.69V when the relay closes for a short while, and it's wired pulldown.  If I drop the resistance, I suppose it will lower than resting voltage, and it should still rise to nearly 4.7V.  Sounds to me as if the normal voltage is too high.

Thank you for looking at the data sheet.  I wouldn't have known where to find that and it suggests to me that I need to reduce the resistor to drop the normal (contacts open) voltage.

The meter came with built in relay so it's impossible to see what specification it is, and the plumbing company is well set up for water queries and rather less so for such detailed physics materials questions!  If I make it a 2.7K resistor, I think the normal voltage will drop to < 0.2V and the contact closed current still only be 2ma so the emonPI should be all right with that (limit 20ma did I see somewhere?).

Make sense?

I'm no expert but I think the emonPi is a 3.3V system isn't it?   Are you sure the contacts on your meter are dry relay contacts and not some solid state output?  What exactly is the meter?

The emonPi is indeed a 3.3 V system, but there's only 5 V available on the RJ45 connector. That 5 V is NOT V_cc.

You should not be wiring relay contacts to apply 5 V to the input. If you haven't done so already, you're in grave danger of damaging the processor.

You should use a pull-up resistor (4.7 kΩ should be fine) and wire the relay to be 'active low', i.e. closed contacts = logical low on the input.

If it's a water meter, what makes you think it's a relay? Unless it has an internal battery or some other energy supply, it's more likely to be a reed switch operated by a magnet than a relay, and those are well known for contact 'bounce'.

I had not realised that the 5v was a different supply from Vcc.

i will modify the setup at once to remove any risk of the 5v on the IRQ [hangs head]

hidden traps for a newbie.

as for the water meter contacts, my loose language.  Yes, I'm sure it's a reed relay.  I expect contact bounce - my issue was the random pulses when the contacts wer just stationary normally open.

how do I tell whether my 2 week old emonPI has debounce enabled?  I saw so where it should have with a 110 ms period.

What brand is your meter?  I've seen some Elster meters fitted with the official Elster T-probe reed switch do what you're describing, while others work fine.   It's not a matter of bouncing contacts but more that if the meter happens to stop right where the reed switch opens (or closes) it becomes unstable and randomly flips between the two states for hours (or days if the meter remains in that position).    No amount of debouncing can fix that because the period of the spurious pulses are so long as to be indistinguishable from the real pulses.

Frustratingly the water meter doesn't have a maker's name.

Today, with IRQ wired to the junction of a 4.7k resistor to the 5V and a 10k to ground, I still had lots of spurious pulses when the reed contacts were open.  I therefore wired a .01mu capacitor across the reed contacts and the spurious pulses dropped enormously.

I am now monitoring to see how accurately the reed closures are counted.  That's when I will see whether I have a bounce issue.  Still not sure how to tell whether the new emonPI has debounce logic enabled by default.

Most importantly: thank you to those whose comments have helped me get to this stage.

 Still not sure how to tell whether the new emonPI has debounce logic enabled by default.

Nor am I.  We'll need someone familiar with OEM release procedures and version numbers to work that out.  I guess in the meantime you could try manually touching the IRQ pin to GND and see how many pulses that counts. If you can do that with only one pulse counted I'd say it's enabled... if you see 40 or 50, then probably not.

EmonPi's ATmega328 is 3.3v with internal chip pull ups enabled on irq input 

Glyn; and for the record, debounce logic ON by default?

Yes, min_pulse_width is set to 110ms

​// The interrupt routine - runs each time a falling edge of a pulse is detected
void onPulse()                  
{  
  if ( (millis() - pulsetime) > min_pulsewidth) {
    pulseCount++;                    //calculate wh elapsed from time between pulses 
  }
 pulsetime=millis();     
}

https://github.com/openenergymonitor/emonpi/blob/master/Atmega328/emonPi...

https://github.com/openenergymonitor/emonpi/blob/master/Atmega328/emonPi...

Currently tearing (what's left of) my hair out.  Good electronics skills as an A-level student (dates me) is too long ago.

Anything plugged into the RJ45 port of the emonPI seems to generate spurious pulses, even when it is just a shop sold temperature sensor.  Even with the pull-up 10k and pulldown 4.7k in place, my reed switch reading is doomed as an hour of open contacts will give me 30-50 pulses.  A .01mu capacitor across the switch contacts Reduces the incidence but does not eliminate.

i have tried a totally different switch: same result.

Wondering whether it is a glitch with the emonPI I have bought and tried the count into an emonTX: same result.

1.  This must be RFI must it not?

2.  Are the IRQ inputs really that sensitive?

3.  Has anyone on the forum found a simple preferably passive solution to eliminate those?

Hi

I had a similar problem. Discussed here:-

https://openenergymonitor.org/emon/node/5022

I solved it by using a Maxim 6816 hardware de bounce ic. (A bugger to solder, buy several!)

Regards

Ian

I shall take your advice and buy a debounce switch though the link was very helpful and I shall start with a simple hardware RC filter to test whether that's enough.

i do think my problem is probably interference so I will also have to look at using screened cable even though the cable run is only 1 metre.