[SOLVED] Puzzle over water meter .sensor
zboblamont last edited by Yveaux
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 last edited by
@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 last edited by
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