[SOLVED] Puzzle over water meter .sensor

[zboblamont]

I have Arduino 3v 16Mhz/RFM69 acting as Nodes which network I am building but hitting a ghost with one which is puzzling me.
The water meter node recently assembled uses the Elster PR6 pulse sensor on a V200 water meter (possibly known as the Honeywell Falcon in other areas). Nothing special on the sensor aside from the 6 core cable with highly detailed info on each core's purpose etc., the FET sinks up to 30mA on each 1 litre pass.
The sketch is no different to that I used for the Gas Reed switch which works flawlessy and tracks the meter every 10 pulses, both use a 3v pullup, but minus the debounce circuit in the case of the water meter which is a FET type switch.

I set up the Int1 with a standard LOW trigger to waken the device from Sleep, looping with a head on the loop doing a while check to ensure the pin had gone HIGH before sending a message then sleeping, exactly as the Gas Meter. The Gas meter is external I should add, so interference is limited to STATIC FROM the occasional scratching passing cat...

With several events recorded overnight which made no sense, I wondered whether a leak or false positive were in play. Disconnected the PSU reverting to battery backup power overnight which I found made no difference, still false positives in the morning. The meter reading had not changed....

Re-orientated wander socket onto the wall and read up on possible causes. The only one which made sense was that I had set too high an external pullup (200+k in this case from 3.22v in reality) on D3. Reduced to 10k and reinstalled, but still I am getting false positives. The meter is a Class D piston type, so the register does not move without flow, the sensor trigger will not pass unless the register moves...

The puzzle is now that I am no closer than 0.5m from any electrical source or potential EMI, yet short of sticking the node in a grounded diecast alloy box, not sure how I can eliminate the problem or I am missing something obvious...

I will leave it until the morning to quantify comparatively how many ghosts appeared overnight, then possibly reduce the external pullup to 4k7 to see if it makes any difference. I have a box full of ceramics I could pin to ground from D3 if that is worthwhile. The sensor I should add is well beyond 2m from any potential power source.

Any suggestions 'from the body of the kirk'?

[zboblamont]

@zboblamont For anybody who stumbles across this same issue using a Elster/Honeywell PR6 pulse sensor, herein the solution found.

Digging a little further into the documents, Elster recommends for logging etc that the pullup resistor be set to 2k2 connected to up to 30v.
The pullup was changed out to 2k2 and the Node put on battery power only, but this still continued to register false positives.
The Node was powered off completely and the PR6 detached from the meter to check mounting even if it was impossible to get wrong, part of the moulding fits under the hinge, and only two screws points clamp it to the meter face.

The original sensor core connected was CH2P (Red) as Elster recommended, this line compensates for reverse flow pulses (which should never happen on domestic meters anyway).
The pullup connection was changed to CH1P (Yellow), which outputs all pulses irrespective of flow direction, PR6 refitted, the Node powered up, and no ghosts registered overnight.

So problem solved...

[zboblamont]

BAD news, it is not solved...

It had been working fine on batteries when CH1P was connected instead of CH2P originally, but it is now echoing random false positives as before, despite running first on battery smoothly for over a day, but now with the USB power supply connected, cue Ghostbusters...

When CH2P was previously connected and the USB was connected, whether powered up or down, the false positives continued, whether the Node was on the wall next to the power outlet or parked on top of the washing machine spreadeagled.

I even changed the USB PSU for a Nokia spare, but I have now powered it down to follow this through. I cannot believe the physical proximity of a dead USB cable should have any effect on a FET drain line, or an Interrupt Line on an Arduino, but that is what I am staring at as possible cause...

Here is an example of two consecutive false positive reports to Domoticz, but note the time separation:
2017-11-22 17:00:01.854 (WN Gateway) RFXMeter (Water Meter Cumulative)
2017-11-22 17:00:01.863 (WN Gateway) RFXMeter (Water Meter Cumulative)
BUT, to add fuel to the puzzle...
1 - At max flow rates the pulses from the sensor as checked are 8-9 seconds apart on a 1 litre pulse.
2 - The minimum 'sleep' cycle in any condition on the sketch is 50ms.

Reports 9 milliseconds apart is impossible on a sensor in the circumstances, 80ms pulse width, so logically the origin can only be the node itself (Pro-Mini 16MHz , 3v). So it can is EMI, an effect of the cable, the cable from the PSU or the board itself? I checked the transmit periods so no coincidence there...

I detached the sensor for sags, and zero response, as expected.
I re-attached the sensor but detached the signal line from the sink FET on the sensor, zero response, as expected.
Only when everything is in combination do these curious triggers arise so any thoughts on suppression ?

What makes no sense in this is that although it is an inductive sensor, the sinking of the interrupt should be the only trigger to the FET in te sensor, there should not be any other influence...

I will experiment a little more to try to get to the bottom of this as it seems likely this is interference issues over the Pro-Mini or sensor cable proximity to 'something' such as the nearby power outlet or a buried power cable in the wall rather than the sensor, unless the sensor cable. It is also possible that since the USB power supply cross over the GND and Signal cores from the sensor, this may c

[A Former User]

@zboblamont Did you ever get this working? I'm struggeling with the same ghost pulses.

[zboblamont]

@avdhil No I didn't, only because I got diverted on more critical nodes and it has been on my to-do list ever since, aka forgotten...
It has been on batteries only and re-located, so external stray effects are nulled, but it still throws the oddball.
Spoke with Elster techs who advised it is impossible for the PR6 to signal in error, but being an Arduino tinkerer himself, suggested refining the program to verify the interrupt was a valid INT1 before incrementing the value.
I simply never got round to trying it, and as not able currently, perhaps worth a try....

[kimot]

Arduino 3V at 16MHz is out of specification. You cannot be surprised by no standart behavior.

[zboblamont]

@kimot You may be assured I never cease to be surprised, particularly by presumptions...
It is a "Whisper Node AVR", full blown 16MHz 3.3v Arduino with onboard booster and rfm69 etc, too clever for me to consider attempting to build at the time... Your apology is accepted.

[kimot]

@zboblamont
I'm sorry to let you know that you are using Atmega328p outside the manufacturer-guaranteed specifications.
My apology again
But your super "Whisper NODE AVR" with onboard booster is very nice, but this booster "boost" to 3,3V.
And 16Mhz is out of range for ATmega328p at 3.3V
It wants a lot of courage to sell such a product for boys from Wisen

Look at circuit diagram:
https://bitbucket.org/talk2/whisper-node-avr/src/bad0f4f997dc9bae952d9aafd13397e1015eb602/Documentation/Whisper_Node-AVR_0.3.pdf?at=master&fileviewer=file-view-default

I believe that it works in most cases, but there can be situations - noise, EMI, when a problem occurs for this reason.
Something like PRO-MINI with 8MHz is safer for me and I do not have problems with random events.

[zboblamont]

@kimot Ironic then is it not that the same "random event" I was chasing occurred whether using the Whisper, a 3v8MHz or a 5v16MHz Pro-mini?
I thought that rather narrowed causes to program or sensor, but hey, I'm no expert.

As you might note above I had also excluded EMI effects through experiment