User avatar
TerryC65
Posts: 151
Joined: Sat May 09, 2015 7:50 am
Location: Wimborne, Dorset, UK

Problem with False Detection Using wait_for_edge

Tue Mar 26, 2019 5:26 pm

Hi,

I have an ongoing project which involves controlling a model train which runs backwards and forwards over a short track. The train has to stop at four places over the track. I am using the following circuit (this is a fragment of the full diagram):
Underground_Railway_Circuit(V0.6).png
Underground_Railway_Circuit(V0.6).png (86.88 KiB) Viewed 547 times
The IR sensors have an open-collector output and I am pulling the signal line up to the supply voltage and decoupling the line to ground with a 10 nF ceramic capacitor (not shown in the circuit).

Within the code I am using the following lines to detect the train going over the sensor (just one sensor shown:

Code: Select all

sensor_b = 6
....
GPIO.setup(sensor_b, GPIO.IN, pull_up_down=GPIO.PUD_UP)    # set Sensor B as input.
....
GPIO.wait_for_edge(sensor_b, GPIO.FALLING, )       # Wait for Train to pass Sensor B (entrance to Tunnel on Out leg)
The problem is that an edge is often detected before the train gets to the sensor :( I have put a scope onto the sensor output line and it is quite clean with only about 30 mV of noise (this is a 70 MHz scope). I can only assume that the Pi is seeing some very fast spikes which are riding on its inputs.

I initially tried to use add_event_detect on the sensor pins, but that was causing multiple interrupts as the train passed over the sensor. I am also using wait_for_edge on the Guard Rail Button, which is used to start the sequence. That occasionally fires when unattended too, so the problem isn't confined to the sensors.

Can anyone suggest a better way to do this?

LTolledo
Posts: 2416
Joined: Sat Mar 17, 2018 7:29 am
Location: Anime Heartland

Re: Problem with False Detection Using wait_for_edge

Tue Mar 26, 2019 8:50 pm

Most would suggest putting a simple R-C debounce circuit for the triggers

I would recommend using a Schmitt Trigger debounce circuit (SN74HC14N together with the R-C circuit) for the triggers.
"Don't come to me with 'issues' for I don't know how to deal with those
Come to me with 'problems' and I'll help you find solutions"

Some people be like:
"Help me! Am drowning! But dont you dare touch me nor come near me!"

User avatar
TerryC65
Posts: 151
Joined: Sat May 09, 2015 7:50 am
Location: Wimborne, Dorset, UK

Re: Problem with False Detection Using wait_for_edge

Wed Mar 27, 2019 9:15 am

LTolledo wrote:
Tue Mar 26, 2019 8:50 pm
Most would suggest putting a simple R-C debounce circuit for the triggers
The problem is that it isn't bounce. The sensors haven't activated and when they do it's solid. The false triggers are coming from noise (I think) so I suspect that a debounce circuit, especially one using a Schmitt Trigger, would simply make the pulses bigger.

I have some ideas for testing that I'm going to try out this morning, so something might emerge

User avatar
joan
Posts: 14579
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Problem with False Detection Using wait_for_edge

Wed Mar 27, 2019 10:57 am

You could see if pigpio has the same problem.

http://abyz.me.uk/rpi/pigpio/examples.h ... monitor_py

sudo pigpiod
./monitor.py

User avatar
TerryC65
Posts: 151
Joined: Sat May 09, 2015 7:50 am
Location: Wimborne, Dorset, UK

Re: Problem with False Detection Using wait_for_edge

Sun Mar 31, 2019 9:02 am

Hi,

I completed integration of this project yesterday, so I thought I ought to share how I overcame the issue highlighted in this Topic.

As I suspected, noise was the problem. The main source of noise turned out to be the PWM controlling the train! When I monitored the sensor signal lines originally I neglected to have the train running at the time. :oops: With the train running it was possible to see square waves with quite sharp edges riding on the +12 V supply to the sensors. (They were still quite small, but the edges may not have been fully visible, so there could have been higher level spikes that the scope wouldn't reproduce.) This voltage came from the same PSU Brick that was providing +12 V to the Motor Drive Board driving the train and also to a DC/DC Converter delivering +5 V for the Pi. The Pi creates the PWM and the current surges as the PWM switched showed up on the supply. Obvious really :(

There were two possible solutions to the problem. The most efficient would have been to provide extra filtering on the 12 V supply to the sensors; an extra inductor in series and a fairly large electrolytic across the output to the sensors would have 'filled in' the gulps of current and the addition of a small ceramic across the output would have taken care of the edges. The problem is that would have needed a fairly major rework to the circuit board or the addition of an untidy 'inline' filter. As it happened, I also had to increase the voltage to the Motor Drive Board because the volt drop across the drive transistors meant that we could not get full speed from the train. A member of the team happened to have a +15 V PSU to hand, so the DC/DC Converter and the Motor Drive Board were supplied from that and the redundant +12 V brick was now available for the sensors.

At the beginning I mentioned that the main source of noise turned out to be the PWM controlling the train. I was also experiencing false triggering from less controllable sources, such as someone turning a mains heater on or off and other unidentified sources. In the end, I modified the code as follows:

Code: Select all

sensor_b = 6
....
GPIO.setup(sensor_b, GPIO.IN, pull_up_down=GPIO.PUD_UP)    # set Sensor B as input.
....
        i = 20                                          # Set the loop count for approximately 5 secs
        while i >= 0:
            if GPIO.input(sensor_b):
                i -= 1
                time.sleep(0.25)
            else:
                print ("Sensor B Activated")
                break
The effect of this is to repeatedly monitor the sensor signal line but not continuously. This means that during the 0.25 second delay noise events can occur which would be missed, but the delay is not long enough for the sensor event to be missed the next time round the loop. This code has the added bonus that it allows a timeout, so if the sensor event is missed, the train stops anyway; just a little later.

This system is now driving a model Underground train at the layout at our local Model Town and seems to be working OK so far (we opened for the summer season yesterday and I haven't had any phone calls yet :D ).

Hope this is helpful to others.

Return to “Other projects”