By never sent - are you saying the results i am receiving are not real? The sensor is not sending and not receiving? I am just dreaming or making it up?
Or do you mean sent by a quirk, that should not work, but just happens to be working?
let me try to explain the reasoning by breaking down the various options that have been discussed:
- when you toggle bcm31, there is nothing at the end of that line.
- when you toggle bcm6 and you are using the Explorer output 1, even if the HC-SR04 is hooked up to it, you are not sending any voltage to the sensor by actuating it, with same result, the sensor never was instructed to send data back.
- when you toggle bcm8 (CS on the Explorer HAT Pro) then yes, the pulse you are sending should trigger a request from the sensor.
ā¦ so, apart from the last scenario, I would have no idea what the data you get from Explorerās input1 is. Iām not saying youāre making it up, but besides electrical noise I canāt see what would generate it, and I would not put much value on its integrity.
does the data seems sensible based on your movement towards obstacles? it could be that at first glance it seems plausible, but is it accurate? it could be, but Iām puzzled why the sensor would be even speaking back to the Pi.
1 - yes i can see no logic or reason for it.
2 - Put simply the data i get back i is 100% correct. It changes as objects are moved back and forth infront of it. The actuall measurement in CM is 85% accurate (as accurate as when using BCM8 CS). Using BCM31 behaves exactly as it does with BCM8.
How, Why, What - i do not know. it simply does.
They also both behave identically with the USB to Battery issue.
My theory is that the sensor is working on Echo (receiving the signal and notifying).
My Theory is that BCM 31 is glitching and actually working as BoardPin 31 (BCM6) and somehow it is leaking through and working.
It does defy logic, but what else could it be?
I do have an Explorer pHAT, powerbank and a tonne of HC-SR04s scattered around if another head will help?
1 Like
yes, please Tom, as time permitsā¦ right now Iām interested to know if there is a difference in behaviour depending on whether the ECHO is hooked up to Explorer or straight to a pin on the Pi.
[quote=ānevsie, post:43, topic:641ā]
My Theory is that BCM 31 is glitching and actually working as BoardPin 31 (BCM6) and somehow it is leaking through and working. It does defy logic, but what else could it be?[/quote]
is the earth flat?
more seriously, there is no need to involve bcm31, in my view the sensor is sensing data without request. I would suspect that not even hooking up TRIG would get you some results (probably sensible too).
ā¦ perhaps the HC-SR04 gets initialised with one type of power source or not the other and that is the difference in behaviour observed?
Okayā¦ Could it beā¦
Run my range finder scriptā¦ it polls through perfectly.
1 - if i pull out the trig wire from the breadboard, it stops sensing
2 - if i pull the trig wire from the BCM8 hole, but leave it connected to the trig bread board. It continues to work.
Is it receiving some interferance, radio/electrical perhaps from the explorer hat? Enough to create the signal it needs?
any loose wire will pick up interferences yesā¦ it basically acts as an antenna quite willing to pick up any noise, not just from the Explorer but anything from its surrounding.
Just saying that it is also working with that wire as an antenna.
Either connected to BCM8 or as an Antenna.
Earthed, live, any other pin, or disconnected from breadboard it fails to function.
I thought it might have helped your diagnosis. But iāll let you think about it as my beginner ideas are not helping.
basically, you need to secure the state of the pins when they are not being driven - as I stated much earlier in this topic.
you can either achieve this will external pull up or down resistors, or use the built-in ones. see the following link which may help:
(and remember the TRIG is an input on the HC-SR04, you need to tie it low)
my best guess as to why there is a difference between PSU and battery is that the PSU generates enough electromagnetic interference to induce the pulse, the battery powered solutions donāt.
Just had a bit of an experiment (took a while to dig out an unused Pi0).
Running through the Explorer pHAT 5V tolerant input, Iām getting slightly jittery data which is off by about 3cm(+/- 1cm) from measured.
Running through GPIO directly (with a voltage divider on ECHO) Iām getting fairly accurate data which is off from the measured data by less than +/-0.5cm.
Gonna grab some dinner now, but let me know if thereās anything specific you want testing.
yes, I suspect the buffer on the input will ultimately have an impact on accuracyā¦ doesnāt seem too bad, but thatās a definite downside going through the Explorer.
ā¦ that is sort of where this (very old) topic started off, good to have a more recent report on that front in any case. Thanks Tom!
No worries, finally meant using my Explorer pHAT which has been patiently waiting to be used while I finish other projects.
Iāll take your word on buffered inputs, another software engineer over here š
Iāll grab a more detailed data set later so we can compare.
1 Like
So hereās the test setup:
Iāve set up a board 10cm away from the sensor.
And the results:
On the left we have the voltage divider and on the right the Explorer pHAT inputs. The Ep inputs arenāt terrible, just seems to be a bit more swing in values.
cheers for that. yes, better than I expectedā¦ clever programming could alleviate most of the potential mishaps I reckon.
I have mine working fine now on battery power. As you can see in my photo I have soldered a cable directly to BCM 17. I write to this pin and read from BCM 23 (input 1).
Thanks for the help with this guys :)
Code I used to test it
import RPi.GPIO as GPIO
import time
import explorerhat
GPIO.setmode(GPIO.BCM)
TRIG = 17
ECHO = 23
print āDistance Measurement In Progressā
GPIO.setup(TRIG,GPIO.OUT)
GPIO.setup(ECHO,GPIO.IN)
GPIO.output(TRIG, False)
print āWaiting For Sensor To Settleā
time.sleep(1)
while True:
GPIO.output(TRIG, True)
time.sleep(0.00001)
GPIO.output(TRIG, False)
while GPIO.input(ECHO)==0:
pulse_start = time.time()
while GPIO.input(ECHO)==1:
pulse_end = time.time()
pulse_duration = pulse_end - pulse_start
distance = pulse_duration * 17150
distance = round(distance, 2)
#print "Distance:",distance,"cm"
if distance < 20:
explorerhat.motor.one.backwards()
explorerhat.motor.two.forwards()
else:
explorerhat.motor.one.forwards()
explorerhat.motor.two.forwards()
time.sleep(1)
GPIO.cleanup()