[SOLVED] Ultrasonic ranger sensor showing the same value

Hi all,

I have had my Ultrasonic working fine, but then it stopped working. Now it only shows the same value 680. I have tried different digital ports and restarted everything, but still nothing worked.

Any idea? Is that possible that the sensor got broken? I handle them very carefully always.


Hey Mmansur, have you tried returning to the original code for the sensor?

Does this give you the same value?

Thanks John for replying. Strangely it is now working again. I don’t recall anything that I have done besides plugging everything out and in again and reboot it.


I got a new GoPiGo2 starter kit a few days and I’m having the same problem that was originally reported by mmansur: The ultrasonic sensor was working in a the basic example, then I tried it a little later after a reboot and it stopped working. When I test with basic_test_all.py and the ‘u’ command, values near 684 (+/- 1) are always returned, no matter how far away the obstacle is.

Since mmansur said the problem went away when reconnecting, I powered off, unplugged the senor’s cable on both ends, waited a minute, plugged it back in, and tried again, but the behavior didn’t change.

Any ideas?


Hey @mark1,
Did you try the ultrasonic example that John has mentioned above. Can you try it out and paste the output that you get when you run it.

karan, thanks for your reply. I just tried running that test and it repeatedly prints Error.

I’m surprised that a GrovePi program would work with the GoPiGo. Note that on the GoPiGo the ultrasonic is connected to port A1, but this program mentions D4. I’m just starting, so I’m probably confused.


Hey @mark1,
Looks like we sent you the link for the GrovePi example by mistake, can you try out this example https://github.com/DexterInd/GoPiGo/blob/master/Software/Python/sensor_examples/grove_distance_sensor.py and see if it works for you.

Thanks Karan. I tried that and it repeatedly prints 0. Does that tell you anything?

In case this gives you a hint, I should also mention that even before it stopped working, it was working a little strangely. After first connecting it I tried the obstacle-avoiding example, and although it did stop before hitting an obstacle, it stopped at greatly varying distances from the obstacle – from 1 in to 2 ft. I only ran this program a few times, then shut the GoPiGo off, then later tried it again and that’s when it stopped working completely.

Hey @mark1: Can you follow this tutorial to generate a log for the GoPiGo and upload the log here. Can you also upload a screenshot of your setup and a closeup of your connections.

Sorry this taken so long, I’ve been swamped with work. Log and photos are attached.
log.txt (6.7 KB)

Hey @mark1 ,
It really looks like your the sensor is broken since everything else looks good. We have not seen a problem like this before. Thanks a lot for testing it out. I’m really sorry for the frustration.

Can you contact us here, under “General Questions and Feedback” and we will have a replacement shipped to you immediately.

Again, I’m really sorry to hear about this; we’ll make it right immediately.

Do let us know how the new sensor works for you when you get it.

Thanks for you help Karan. I filled out the form, and when I press Send it does it’s little animated dance, but then there is to “message sent” confirmation – hope this is normal.

Oops, I guess the Send button was working, sorry for all the duplicate emails.

Karan, thank you for sending a replacement. However, it is not working either, so perhaps the problem is in the GoPiGo board?

When I test with grove_distance_sensor.py, it always prints 0 as before. When I test with basic_test_all.py and the ‘u’ command, it always prints 690 or 691.

That is kind of puzzling, we have not seen the GoPiGo and the ultrasonic sensor behave like that before. Can you try downgrading the firmware to version 1.5 by running the firmware update script here.

Make the script executable:

sudo chmod +x firmware_update_15.sh

then run it:

sudo ./firmware_update_15.sh

and try out the basic_test_all or this example with the correct pin number.


I am currently dealing with the same problem here. Don’t know whether I should make another thread or just reuse this one. My setup is a Raspberry Pi with the GrovePi+.

Running the grove_ultrasonic.py script always returns values of 670. It is the version 2.0 of the ultrasonic sensor that I have but I believe from reading other posts that should not make a difference. Executing a flow in Node-RED reading the same ultrasonic sensor gives me the same value.

Anyone here who has an answer for this?

Kind Regards,


Hi @bpellens,

It’s better for posting it here. It makes sense since it’s the same issue. Another topic would be redundant and no one likes duplicates.
Thank you for thinking about it.

Could you do the following:

  1. Confirm you’re using this script: https://github.com/DexterInd/GrovePi/blob/master/Software/Python/grove_ultrasonic.py

  2. Show us a picture of your setup. We would like to see how it’s hooked up.

  3. Run the instructions found in this post at Step 3. Then attach the log.txt file here.

This is all for now.

Thank you!


Thank you for the quick reply. After I, a day later, booted the Raspberry Pi in order to do the things you suggested, the sensor seemed to be working. This is really strange as nothing has changed to the setup. Could it be possible that there was interference from other devices? I don’t see any difference with the way I ran things yesterday.

Anyways, it seems to be okay now. In a little while I will try to test it in the real environment. Hopefully it is still functioning there.

Kind Regards and thank you very much,


1 Like

Hi @bpellens,

The readings should have fluctuated provided there were bad contacts, interferences, etc. At least, that’s how I’m thinking.
It’s weird the values consistently stayed at 670.

Without more feedback, I can’t tell what was the reason for it to behave this way.

Please let us know how is going to work the following days.

Thank you!

1 Like