Explorer pHat Impedance Mismatching


Hello there buccaneers! I’m in need of some assistance from some electronics-wizards and Explorer pHat experts (I’m looking at you @Gadgetoid).
I’ve been attempting to hook up my HC-SR04 ultrasonic distance sensor to the Explorer pHat for a little bit of robotics, but I’ve been hitting a few walls (mainly my head against them).
With the sensor wired up on a breadboard, I can get the Explorer pHat to take a distance measurement using this code, but it has a very strange requirement. The input reads low constantly on the Envirophat until I plug another jumper cable into the ground slot on the breadboard and smack my finger against it repeatedly. Doing so seems to erratically allow the input to come back to a high value and take a (correct, mind you) distance reading!
I originally thought that my sensor was broken or that my connections were faulty in my breadboard, however, upon further testing using solely the GPIO on both an RPI 3 and the Zero W, I find that the sensor works impeccably!
Consulting with some engineers (namely my farther), I hear that something called “Impedance” may be causing a problem due to a mismatch between the sensor and the pHat, though being a software man myself, I get a headache from diagnosing these kinds of problems.

So, tl;dr: since it works now-and-then when I touch my finger to the ground connection, is the problem something to do with mismatched impedance between the sensor and the pHat, and if so, any ideas on how to measure these impedances and/or fix it entirely?

I thank you for your help! Any necessary pictures etc. I shall be happy to provide as soon as I find a working light!


Doing a little further testing I find it has the same problem even when connected directly to the RPIs GPIO pins that stick out of the top of the hat; this could be due to the hat affecting not only the impedance value of itself but the Raspberry Pi as a whole, but I need to check whether I get the same behavior with the sensor connected to the underside of the RPI with the hat still connected.


Oh wow I’m not even sure where to begin with this one. It made my head hurt :D

The HC-SR04 seems to be a troublesome blighter with the Pi, but more typically due to timing issues and power consumption than anything as mysterious as this.

Which GPIO pins have you tried connecting it to?

How are you powering it?

What code are you using to read the sensor?


Haha, at least I’m not the only one!
It works perfectly fine when connected to the RPI 3 and Zero W directly using the physical pins 2 (5V), 6 (GND), 16 and 18, however, it doesn’t work when connected directly into the hat through the “input 1” and “output 1” pins. It also doesn’t work when connecting to physical pins 16 and 31 (which are corresponding to “input 1” and “output 1” according to your pinout page) when soldered directly onto the RPIs GPIO pins that stick out of the top of the hat. I chose 16 and 31 when doing it that way in order to prevent anything mismatching and going wrong when the pHat was attached.
I’m mostly powering it through your standard USB class portable charging battery, rated at 3.6V 2600mAh/9.36Wh with an output of 5V DC at 1A, however, I have also tried it whilst running it straight off of an official Raspberry Pi power supply, but to no avail.
The code I am using is this: https://github.com/RaspberryPicardBox/ExplorerpHat-Distance-Sensor/blob/master/range_finder.py which I modified from ModMyPi’s tutorial found here, although I modified it appropriatley using RPi.GPIO in order to test it when it is directly connected to any GPIO pins.
Oh, and I forgot to mention: the voltage divider is using a 2.2 K resistor to dump the load back to ground rather than a 2 K resistor as the tutorial suggests, though I’m informed that it shouldn’t make too much difference (informed that is from an electronics amateur similar to myself).
Phew… HC-SR04 really is not a nice sensor!


Ah that will be because “Output 1” is via a current-sinking ULN2003A Darlington Array. This is a pair of transitions that, when fed a “HIGH” signal from your Pi, switch on and connect the “Output 1” pin to Ground. It effectively acts as a NOT gate turning a HIGH into a LOW. Although it does not turn a LOW into a HIGH unless accompanied by a pull-up resistor.

I suspect when you connect directly to the GPIO pins backing “Input 1” and “Output 1” then the 5V tolerant buffer chip used for the “Input” (SN74LVC125APWR Eeek that’s a heck of a name) is messing with your signal by fighting with the HC-SR04 about which way the pin should be pulled.

You might get some success if you hold “Output 1” LOW (by… uh… setting it to HIGH… this isn’t confusing at all, honest) and then trigger the HC-SR04 by releasing it (setting it to LOW). You will need a pull-up resistor (one of your 2.2k ones will probably do for experimentation) on the output side of “Output 1” to “pull it up” to 5v. Thus inverting the inverted pin back to its original state.

Electronics are fun :D

Explorer pHAT’s Inputs and Outputs are - for the sake of protecting your Pi - much more complex than they first appear.

A question about the touch phat

Urrm… OK! Electronics is fun until you get a headache understanding ^ this ^. :D
By this:

I’m not sure whether I described my circuit very nicely. Either that, or I don’t understand a word of what’s written there! I’m connecting to pins 16 and 31 at this point here:

which, in my understanding, connect straight to the Pi, which should completely miss the darlington array, right?
You’re (probably) perfectly right with your theory for when I’m running straight through the pHat’s input and output ports, which in the end is my goal, but should the sensor not work when I’m using my makeshift voltage divider straight into the Pi’s pins rather, completely bypassing the 5v tolerant buffering IC?
Am I making any sense here? I only just understand myself here. :)


It’s definitely not completely bypassing it, since both devices are still connected in parallel. For the sake of argument, imagine the 5V tolerant buffer IC as a 0Ohm link resistor connecting the IO pin directly to ground. Now if you try to assert a signal on that pin it’ll never be read by the Pi, since it’s a short to ground.

While this probably isn’t an accurate model of what the buffer is doing (although it’s certainly not outside the realm of possibility that it pulls the pin low when it’s not got a high input value) it’s a good way to visualise how you can’t really bypass something that’s actively asserting a pin.

In this case your HC-SR04 might be trying to set that pin high, but if the IO buffer is pulling it low at the same time, then it’s probably going to win the fight.


Ahh, that makes much more sense now. Dankeschon! Simply me getting confused. :) Now that we’ve finished with that electronics lesson…
My circuitry is in my shed at the moment, and I’ll probably need some more assistance at some step, so I’ll let you sleep for tonight and have another go tomorrow.

Quick question: since the Explorer pHat doesn’t seem to use physical pins 11 and 13, could I simply use those pins as I/O for the sensor for now, completely bypassing the pHat and any ICs that may be interfering? It’s not the nicest solution, but it might give me a chance to get my object sensing scripts written whilst I’m still figuring out the rest of the electronics!


Yes you could use 11 and 13 and it should work fine!

Your pin 11/13 approach will be the path of least resistance- while other methods may work (and be moderately educational) there’s no use fighting with buffers and whatnot when you don’t need to.

Note: Careful that the output signal of the HC-SR04 isn’t 5v that you shouldn’t be connecting directly to a 3.3v pin. Although I’m guessing that’s taken care of by your mention of a voltage divider?


I’ve had some success with these sorts of sensors, you definitely want a divider on the echo (output) pin. The trigger pin however should be fine from 3V3.

I’ll have to dig up the last thread where we had issues using the Explorer pHAT outputs/inputs - they definitely did something to the measurements. You should however be fine with hooking up to the Pi GPIO.

Here’s a board I use to control 6 of them:


Ah, thank you.

Yep; I’m just using a couple of resistors to dump the 5v signal back down to somewhere close to 3.3v.


Looks good!
I’m afraid I’m a bit pushed for space on my Polulu chassis set, but if I decide to make a bigger base I may be enquiring to you about resistor values and what not. ;)


Sucess! It works perfectly fine using pins 11 and 13, if a little on the inaccurate side, though that’s just down to the sensor, Timing issues are a real pain…


I’ve had good success using Proto pHats, https://shop.pimoroni.com/products/adafruit-perma-proto-bonnet-mini-kit (bonnet I guess?) and Proto Hats, https://shop.pimoroni.com/products/adafruit-perma-proto-hat-for-pi-mini-kit If you have the room. They give nice access to the GPIO pins etc. For sensor breakout boards I soldered on 90 degree male headers and used female to female jumpers. It helps if you have to take things apart or redo it. Or testing, no having to unsolder something, just unplug it. I use a tall stacking header, https://www.adafruit.com/product/1979 instead of the ones that come with them. The just plug it inbetween my Pi and Phat/Hat. Adafriut also has the correct taller standoffs for them, https://www.adafruit.com/product/2337. Pimoroni has one that will work with the normal sized headers but I can’t find a link at the moment.


That Proto-bonnet looks like just what I need!
I’ve currently got everything wired up in “thin-air”, with jumper cables soldered to resistor legs and all sorts; an ugly sight to be sure. I had planned to cut down a bit of copper board to fit on the chassis, but that pHat just looks so much better.
I’ll probably end up including that in my next shipment of jumper cables! Thanks for the suggestion. :)


I used the bigger Proto Hat to add a RTC and other bits to my Pi Sense Hat project. There are pictures here, https://1drv.ms/f/s!AjOYwiwlwDtpgq8_0VrdS3_H5xL_AA I also have the Proto Bonnet (want to call it a pHat, lol) mounted in my Pirate Radio. Nothing wired up to yet though so I haven’t taken any pictures. I will eventually wire up some arcade buttons to the GPIO for volume up down etc. I don’t have easy access to the actual buttons on the pHat Beat now that its in my own case. Have to order the buttons and some other bits. These boards have made my life so much easier. Gives a nice professional look to a project too.


I have been using one of these HC-SR04 sensors directly on an ExplorerHAT Pro, connected to the 5V and Ground pins for power to the sensor, the trigger is connected to the 3.3V pin lablled ‘PWM’ down the side of the breadboard, and the echo is connected directly to one of the 5V safe inputs on the HAT. No resistors required and it appears to work fine this way.


Explorer pHat doesn’t have a PWM Pin. It doesn’t have any of those 3.3V Only PINS, It only has the 5V safe ones.


As far as I know, those 3.3V pins on the Pro version are just breaking out some of the GPIO pins from the Pi header. The main point is that the 5V safe inputs appear to work fine to read the echo pin from the sensor without needing any additional resistors to lower the signal voltage.


The problem with the 5V safe inputs isn’t that they need the voltage divider, but that the IC they use (this Darlington Pair thingy) creates an inverting issue, which requires you to do some fiddling around in the Python script in order to get it to understand the signals it’s actually receiving.

You have to use a pair of resistors if you’re connecting directly to any of the GPIO pins that aren’t used by the board, since they don’t get interrupted by the 5V buffer (causing issues), meaning you need to use a voltage divider to lower the input voltage from 5V to 3.3V.
Even if you connect the sensor to those 3.3V pins that appear to connect straight to the GPIO headers, they are still acted upon by the 5V buffer, since they’re on the board itself, which would give you the odd inverted signals again.

Well, that’s on the Explorer pHat at least! I presume the Explorer Hat Pro might use some different chips, or, as you said, an extra PWN pin, if you’re able to get an HC-SR04 working on there nicely.