Reading 6 pulse sensors

Jonathan

HI All,

I am working on a project that needs to read 6 water flow sensors that output one pulse for every .1/cubic foot of water. The maximum pulse rate would be about 13 pulses per minute. I don't need to know the length or frequency of the pulses, just count them. As the sensor revolves about 1/3 of the time the output is high, 2/3 it is low, so quite likely one or more sensors will be inactive and remain high at any given time.

I can think of a couple of ways to do this but my solutions are kludgy, I'm quite sure there is an elegant and simple solution that is beyond my abilities using the counters or some such. Any tips towards a simple scheme to read these sensors?

Thanks!

kwinn

For such a slow data rate the simplest method would probably be to read all 6 input pins and increment a count for each pin whenever the state of the pin changes. That will give a 2 x count that can be shifted to divide it by 2.

What language are you using?

Peter Jakacki

Look for a change of state of the 6 inputs as one group by maintaining a copy of previous sample and XOR with the current sample. The XOR is a compare but also gives you a result.
At this speed you can have a simple loop just XORing the previous and current sample, when it's non-zero you can find out which ones changed by shifting bit by bit and maybe ANDing with if you are only interested in low to high edges etc. BTW, the WAITPNE instruction could be used but it's just as easy to use a simple loop too.

011001 <- PREVIOUS SAMPLE
011001 <- CURRENT SAMPLE
000000 <- XOR

011001 <- PREVIOUS SAMPLE
001011 <- CURRENT SAMPLE
010010 <- XOR non-zero indicates change of state
000010 <- ANDing the XOR with the current sample can indicate low to high edges

wmosscrop

You may need to take debouncing into account, depending on how the sensors handle transitions. Otherwise you may get counts that are too high due to fluctuations at the time of transition.

In your case you could probably sample every second or so and record a change of state only when the desired state exists twice in a row.

Mark_T

Such sensors usually use hall-switches which don't bounce, but yes, its something to check for. You
can elect to ignore any change that happens within N milliseconds of the last change you registered.

Ariba

Spin return 0 or 1 as value for a pinstate if you use INA[pin].
It occured to me you can detect a positive edge just with:

   if currentState > previousState

only if currentState is 1 and previousState is 0 the 'greater than' is true.

So here is a simple code that detects pos edges of 6 sensors:

CON
  _clkmode  = xtal1 + pll16x
  _xinfreq  = 5_000_000

OBJ
  ser : "FullDuplexSerial"

VAR
  long  flowcount[6]
  byte  currentState[6]
  byte  previousState[6]
        
PUB Main : i
  ser.start(31,30,0,115200)
  repeat i from 0 to 5
     currentState[i] := ina[sensorpin[i]]         'init states first

  repeat
     repeat i from 0 to 5
        previousState[i] := currentState[i]
        currentState[i] := ina[sensorpin[i]]      'get new state
        if currentState[i] > previousState[i]     'pos edge?
           flowcount[i]++

        waitcnt(clkfreq/2 + cnt)                  'sampe rate: 2 per second

        ser.str(string(13,"Flowsensor "))         'show one sensor
        ser.dec(i+1)
        ser.str(string(" = "))
        ser.dec(flowcount[i])

DAT
sensorpin   byte 0,1,2,3,4,5                      'sensor pin numbers

Andy

Jonathan

Thanks everybody! My day got hijacked yesterday. Andy, I started something along the lines of what you wrote but yours is better. I'm going to go try yours now.

Tracy Allen

About bounce. here is a pathological case I consulted on a couple of weeks ago. This signal came from a major brand agricultural flow meter (Seametrics AG3000). The simple count of flow was way too high, but a simple debouncer did not work well. As it turned out, someone skilled finally visited the site with a Saleae signal analyzer. Attached is the awful mess that came out.

There are obvious high and low levels, but at the ttl setting, the Saleae detects a huge number of transitions at the ostensibly low level. A conventional debouncer, one that looks for a long period of stability at one level, is likely to fail due to the frequent spikes. A closer view shows that the spikes consist of "bell claps" about 20µs long separated by quiet intervals of 20 to 100µs. The solution we came up with, a firmware patch, was a digital low-pass filter, basically looking for a preponderance of either high or low levels.

Don't ask... Of course the best thing would be to get to the root cause of the noise, but this system is located at a hard to access site and was wired up by someone unknown, and came as a given, wires emerging from a conduit. Sometimes you just have to deal with it.

These particular flow meters have an isolated output, an optoisolator with both the collector and emitter of the output NPN available. So it takes a pullup or pulldown resistor to complete the circuit. That presents a fairly high impedance to the line. I suspect that there was some other nasty signal running parallel in the same conduit, crosstalk ensuing.

Mark_T

The standard configuration of diode-clipper, RC-lowpass filter, 74HC14 schmitt-trigger
would probably have worked well for that signal - the noise is all high frequency. Looks
like the wires run alongside wires from a motor controller or other high power PWM signal.

DigitalBob

I was wondering what is the output of the sensor square wave, ttl etc. You could use a batch counter where you accumulate pulses over a time period.

Tracy Allen

Mark, you're right that a hardware RC combination would probably have worked well for that signal, but in this particular situation a hardware patch wasn't an easy option. It does look like something induced from a motor driver, and poor wiring. Even though flow sensors these days mostly(!) have hall effect instead of bouncing reed switches, this shows they may be subject to other external disturbances.

Peter Jakacki

This reminds me of the horrible noise problem I was asked to investigate that nobody had ever manage to fix. I found out it was partly due to a ground loop problem and also a lot of injected noise. My solution was to use 2 Prop I/O as logic inverters with RC filters to fix it. The original thread here was from 2010.

Tracy Allen

I found out a bit more about the situation with the noisy signal. The flow meter is maybe 5 feet away from a variable frequency drive pump that supplies up to 360 gallons per minute, but mostly runs at night. That plus the fact that certain people had to be present for site visits made the troubleshooting problematic. The flow meter wiring and the pump wiring were NOT in the same pvc conduit, however, the flow meter cable shield was evidently not joined through several junction boxes. Someday, someone will be able to make a site visit and correct that.

DigitalBob

Use a signal conditioner at the flow meter to convert it to a 12v square wave. I have some designs for magnetic pickup and RF carrier

DigitalBob

Those VFD drives produce a lot of switching noise. Key is grounding and they have line filters you can put on the VFD.