RISING & FALLING

[fishwolf]

Hi @fishwolf, it's tricky for us to track down the solution but it's also hard for you without more data (as you are finding). My approach would be a) try to find exactly what happens each time the switch makes or breaks. That's what my previous post was, basically run as simple a program as possible and see what you get (this is a slightly modified version to make a smaller file).

Code: Select all

#! /usr/bin/python
import time 
import RPi.GPIO as gpio
gpio.setmode(gpio.BCM)
#PinStart = whatever you're using 
gpio.setup(PinStart, gpio.IN, pull_up_down=gpio.PUD_DOWN)
with open('log.txt', 'w') as f:
  last_state = 0
  for i in range(10000000):
    state = gpio.input(PinStart)
    if state != last_state:
      f.write('{} -> {}\n'.format(time.time(), state)
    last_state = state
#finally gpio tidy up

b) if there are lots of changes as the switch makes or breaks then I would use the system you already do but b.1) delay the re-measurement of the pin state b.2) keep track of the previous state and only count changes from 0 to 1 i.e. 1 to 1 would be ignored. c) if the changes happen randomly when the switch is either off or on then I would check the wiring, also bits of wire can act as aerials and pick up voltage fluctuations from the 'ether'. These random fluctuations should be filterable by delayed re sampling in the callback function.

1511209962.263492 -> 1
1511209962.264796 -> 0
1511209962.6437123 -> 1
1511209962.6450381 -> 0
1511209962.7736838 -> 1
1511209962.7749689 -> 0
1511209962.9237957 -> 1
1511209962.9248245 -> 0
1511209963.0734184 -> 1
1511209963.0742624 -> 0
1511209963.1900215 -> 1
1511209964.1405602 -> 0
1511209964.9820774 -> 1
1511209966.6762125 -> 0
1511209966.8334801 -> 1
1511209966.834763 -> 0
1511209966.8734715 -> 1
1511209966.8747513 -> 0
1511209967.2129457 -> 1

[paddyg]

Hi, are all those changes from random events or are some caused by you switching? It looks like it's steady when it's 1 but when it's 0 it jumps to 1 for a very short time (the opposite of your picture).

A simple way to filter short blips would be exponential smoothing with an up threshold and a down threshold. As @Davies suggests this might be better done by having a constantly running loop in a different thread something along the lines of this pseudo code

Code: Select all

def monitor():
  global state, changed_flag
  new_state = 0.0
  while True:
    new_state = SMOOTH * gpio.input(PIN) + (1.0 - SMOOTH) * new_state
    if new_state > UP_THRESH and state == 0:
      state = 1
      changed_flag = True
    elif new_state < DOWN_THRESH and state == 1:
      state = 0
      change_flag = True
  time.sleep(0.05)
...
t = threading.Thread(target=monitor)
t.start()
state = 0
changed_flag = False
...
  #in main loop
  if changed_flag:
    changed_flag = False
    if state == 1:
      on_count += 1
  ...

switch.jpg (25.64 KiB) Viewed 645 times

[pcmanbob]

The bit I don't understand is why the OP is using rising edge detection which is working and then as part of the call back reading the input state of the GPIO pin in question again, surly if you have a rising edge detected then you know you have a high on the input so why go read it again ?

[paddyg]

I suppose the problem is that the spurious spikes have a falling edge (which can be ignored) but also a rising edge a few ms later (or visa versa), which triggers the gpio callback. I must say, I think the problem might possibly be solved more satisfactorily with some combination of smoothing capacitor, more solder, thicker/shorter wires, newer switch and beefier power supply. But the RPi is all about tinkering so where's the fun in making things easy for yourself?