element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Raspberry Pi
  • Products
  • More
Raspberry Pi
Raspberry Pi Forum Crosstalk between raspberry Pi GPIO inputs
  • Blog
  • Forum
  • Documents
  • Quiz
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Raspberry Pi to participate - click to join for free!
Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • Replies 10 replies
  • Subscribers 665 subscribers
  • Views 3530 views
  • Users 0 members are here
  • rasberry_pi_3_b_plus
  • raspberry_pi
Related

Crosstalk between raspberry Pi GPIO inputs

colporteur
colporteur over 6 years ago

Are there any known issues of crosstalk between GPIO inputs?

 

I am using Python module RPi.GPIO to event detect on GPIO pins. One program monitors GPIO 2 pin 3 and the second program monitors GPIO 3 pin 5. I am using GPIO.event_detected to detect events within the programs. In the GPIO 2 monitor program, when  GPIO 2 is pulled low, I get a trigger event for GPIO 2 and GPIO 3. In the GPIO 3 monitor program, when  GPIO 3 is pulled low, I get a trigger event for GPIO 3 and GPIO 2.

 

I have seen this pattern of across three different Pi's. On two of Pi's the crosstalk is across GPIO 2, 3 & 4. After obtaining the same results across a Pi 2 & Pi 3, I opened a new Pi 3B+ never used and got similar results.

 

I am using the python script below substituting the pin 3 & pin 5.

 

# setup GPIO
GPIO.setwarnings(False)

GPIO.setmode(GPIO.BOARD)  # set option to reference physical pins
# Set GPIO function
GPIO.setup(5, GPIO.IN, pull_up_down=GPIO.PUD_UP)  # set GPIO input
GPIO.add_event_detect(5, GPIO.BOTH)

try:

   while True:

   if GPIO.event_detected(5):

   print("5 Triggered")

 

except KeyboardInterrupt:  # if ctrl+c pressed exit cleanly
   GPIO.cleanup()

except:  # this catches ALL other exceptions including errors.
   GPIO.cleanup()

finally:  # cleanup GPIO on normal exit
   GPIO.cleanup()

 

My test cases target the suggestion, I have a bad Pi(s). I have extended this same test to three new Pi 3B+ just removed from the package and get the same results. All show crosstalk between GPIO 2,3  with some being GPIO 2, 3 & 4. This suggests I am at fault and not the Pi's.

 

Can anyone share their insight?

 

Sean

  • Sign in to reply
  • Cancel
  • Gough Lui
    Gough Lui over 6 years ago

    What is more important is what do you have connected on those pins?

     

    If the answer is "nothing", then that is expected behaviour. Generally speaking, input pins are "high impedance" and will basically react to environmental noise, mains hum, capacitive coupling between adjacent pins, static electricity (which can kill them) etc. When your GPIO pins are being driven by an input, they would have a lower impedance and be able to sink/source enough current to maintain the pin at the "intended" level. If this is not the case, then maybe your peripheral has insufficient drive strength and a buffer amplifier might be necessary.

     

    Perhaps you can try this experiment - connect a 33k resistor from the pin you're receiving crosstalk on to ground ... the crosstalk should disappear.

     

    - Gough

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • Cancel
  • colporteur
    colporteur over 6 years ago in reply to Gough Lui

    Thanks for the response. I discovered the issue with the Pi connected to a bi-direction login level converter module. https://cdn.sparkfun.com/datasheets/BreakoutBoards/Logic_Level_Bidirectional.pdf

     

    My initial reaction was I toasted some GPIO's. After isolating the Pi by removing the converter, I began to see the anomaly I described. Currently the inputs are floating, (i.e. nothing connected) but I will try your resister suggestion and report back.

     

    I assumed configuring the GPIO to use the pull-up would eliminate the floating input issue. Is this assumption incorrect?

     

    Sean

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • Cancel
  • Gough Lui
    Gough Lui over 6 years ago in reply to colporteur

    I must have overlooked that - if you are running internal pull-up, then it may pay to look at the signals on the lines with an oscilloscope during one of these cross-talk events, as there could be a potential that those may be fried or leaky. ESD damage can occasionally cause funny things too, due to leaky ESD protection diodes. The current on each GPIO pin is very limited, so they can sometimes be inadvertently damaged.

     

    In the case using external resistors of some value helps eliminate it, it could be that the internal pull up/pull down isn't quite strong enough to overcome the stray coupled voltage. If you're using the GPIO, normally it will be attached to a circuit that drives it with a fairly low impedance, so it may not be a big issue in reality.

     

    Other times it might just be a sign you've got a lot of electrical noise around ... Cheap USB chargers sometimes can cause the touchscreens on phones to malfunction for similar reasons.

     

    - Gough

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • Cancel
  • DAB
    DAB over 6 years ago

    Hi Sean,

     

    I too have seen some interesting behavior with Rpi I/O lines.

    I found that the tristate outputs can vary all over the place unless you either pull them up or pull them down to make sure of where they begin.

    Clearly I suggest that you always use some sort of termination on the pins you use. Do not assume they are at a stable voltage, they will not be what you expect.

     

    DAB

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • Cancel
  • rew
    rew over 6 years ago

    If you just configure "input" without any pullup, the pin is "floating" and can easily float to any zero-or-one that it likes. For example, a short "zero" when a neighboring pin changes state. This is called "high impedance".

     

    But when you configure a pin with pullup an internal resistor is connected, and that dramatically lowers the impedance. So now you would be at about 50k. (I remember finding the number for raspberry pi, and that it was different from this number that holds for Atmel, but it didn't differ by more than a factor of two. So for raspberry pi the acutal number is between 25 and 100k).

     

    Still a very fast transition on a neighboring line will cause a short spike. And as you've asked the hardware to take a look say 200 milltion times per second, even a very, very short pulse will cause the triggered message.

     

    So... as a solution you can do several things. Not knowing what you intend to connect I can't tell you what would be preferred.

     

    You can lower the impedance even further. Attach an external 1k resistor to +3.3V to the input pin.

     

    You can slow down the output pin that causes the crosstalk. The pi has configurable output speeds. Lower the speed.

     

    You can add a capacitor on the input pin. About 10nF should do, but up to 100nF won't do any harm. Maybe 1nF will already suffice. Use whatever you have on hand if you're experimenting today, if you need to order, consider ordering all three: shipping cost will be more than the component costs. (even if you get free shipping, only then THEY are paying for the shipping).

     

    You can add a capacitor on the output pin. This has a similar effect as configuring the pin to be slower.

     

    I'm pretty good with electronics, but I have no idea what a "bi-direction login level converter module" is.

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • Cancel
  • Gough Lui
    Gough Lui over 6 years ago in reply to rew

    I believe colporteur was trying to drive a Sparkfun Bi-Directional Logic Level Converter from the GPIO. This is a break-out module with a few FETs on it that is designed to allow you to run protocols like I2C through it, allowing you to intermix 3.3V and 5V logic level devices.

     

    image

    image

     

     

    - Gough

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Cancel
  • rew
    rew over 6 years ago in reply to Gough Lui

    That's not a board that I would trust to beginners. In some circumstances, like I2C it will work, but in others it might not do what you want. That said: Those boards have an inherent (variable!) 5k or 10k pullup. The low level is always actually driven by the side that drives the signal. The side that drives the signal will see a 5k (2x10k in parallel) pullup.  On the other hand, when one side drives the signal HIGH, the other side will see a slow pullup by the 10k resistor. (Now 10k, no longer 5k!).

     

    Stuff like leaving open the supply voltages on the board also has funny effects.

     

    That said...

     

    The code is OK.

    The pi is fine.

    the pi+code is seeing an actual (short) signal on that input, that is the result of crosstalk between your physical wires.

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • Cancel
  • Gough Lui
    Gough Lui over 6 years ago in reply to rew

    I definitely agree with your analysis - that's why I asked whether anything was connected to the pins, as I know from experience that what is "driving" the pin can very much affect the behaviour. I wonder what happened with my suggestion to see what the behaviour was if just a simple decent pull-down was connected from the pin to ground instead of relying on internal pull-up.

     

    - Gough

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • Cancel
  • colporteur
    colporteur over 6 years ago

    G'Day,

    Instead of responding individually to feedback, I thought I would do this summary. First I like to thank you for the responses. I miss the white napkin sketches and coffee time chats with technical people, that was lost in my retirement. That forum provided the opportunity to sound ideas and hear experience. This forum is reminiscent of those times. 

     

    My formal education background is Electronic Engineering Technology. For half of my 37 career years I worked in electronic installing ground based navigation and communication equipment for aircraft control. The other half was IT design, development and implementation of telecommunication management computers.  Similar to tupperware, I think Pi's bred, as I have close to 20 of them. According to my spouse I am more than a dabbler in raspberry Pi's because of the proliferation of the SBC's.

     

    I have done some work with GPIO's or they have done some work for me in simple projects. I am discovering both my legacy electronic knowledge and my recall of that knowledge are not as current as I seem to think they are. As I begin to explore more complex projects, my understanding of the GPIO is being challenged. The suggestion "it should work" is coming under some scrutiny.

     

    That being said, I have discovered both the knowledge needed and some things I have done that contribute to the crosstalk problem. While waiting for responses on my post for this forum, I culled the forum at raspberrypi.org to see if GPIO crosstalk provided any search hits. Low a behold it did. The long and the short of it suggests, don't rely on the internal GPIO pull-ups. Use external pull-ups or pull-downs. Nice to know. Using 10K resisters as pull ups on the open inputs eliminated the crosstalk on the basic test. The internal pull-ups just didn't to the trick.

     

    Next I discovered not all bi-directional level converters are the same. My test bed has the sparkfun units above and some CJMCU-401 TXB0104 4-Bit Bidirectional Voltage Level Translators that technical reviews insists were better.  It seems this level converter (can't find schematics) doesn't use a pull-up and has a latch effect. Using them continue to result in crosstalk no matter what configuration I use. This begs the question, better than what?

     

    The biggest crosstalk contribution was caused by my own contribution in using a resistor/diode pairing to provide a visual indication on the channels. Yeah, it appears if that was a good idea the sparkfun board would have included the feature. The BSS138 bi-directional boards have pull-ups for the GPIO's. By removing my visual option, I remove the crosstalk.

     

    I am considering this issue closed. Lesson learned, use external resistor for all pull-up and pull-down requirements on GPIO's.  I have gone back to the drawing board and removed the visual enhancements. The exercise did give me the impetus to develop some python test scripts that will come in handy in the future. Again, thank you for your contributions.

     

    Sean

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • Cancel
  • Problemchild
    Problemchild over 6 years ago

    Although the inputs may be high impedance and capable of floating which ever way they don't normally start going wild unless you have other parts of  the circuit doing other stuff or long wires to devboards etc.

    How about posting a picture of the setup and also a circuit diagram even if scribbled down so the guys can help you better.

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube