General 3D Printing

A01NYUB Ultrasonic Distance Sensor on pi 5 without Expansion Board?

userHead Jose.Sampson 2026-09-28 14:50:54 55 Views4 Replies

Hello,

I am trying to run the A01NYUB Ultrasonic Distance Sensor with my pi 5 directly (no Expansion Board).
I use the https://github.com/DFRobot/DFRobot_RaspberryPi_A02YYUW_driving directions library.
Unfortunately, I only get “No data!”.

Any suggestions?

2026-09-29 17:41:28

Reading raw bytes directly over serial is the best way to verify the signal first  

https://github.com/DFRobot/DFRobot_RaspberryPi_A02YYUW https://snowrider-2.io

userHeadPic jurya.bject
2026-09-29 17:39:59

Very accurate diagnosis by @Jason.Miao. The packet structure mismatch between A01NYUB and A02YYUW is definitely causing the driver to discard the incoming frames. https://github.com/DFRobot/DFRobot_RaspberryPi_A02YYUW snowrider

userHeadPic jurya.bject
2026-09-28 14:52:50

I am trying to run the A01NYUB Ultrasonic Distance Sensor with my pi 5 directly (no Expansion Board).
I use the https://github.com/DFRobot/DFRobot_RaspberryPi_A02YYUW_ library.
Unfortunately, I only get “No data!”.

Any suggestions?

driving directions

userHeadPic Jose.Sampson
Jason.Miao wrote:

hi,
First, raw-read the port directly. Open the serial port with raspi-config (Interface Options → Serial Port: disable the login shell on it, enable the serial hardware), then just read the raw stream at 9600 baud. Wave a hand in front of the sensor while you read.

If raw bytes appear while you wave → your wiring and power are fine, and the problem is inside the library (it isn't parsing the frames, or it's opening the wrong port/baud).If the stream stays completely empty → it's wiring, power, or the serial hardware isn't enabled - nothing to do with your code at all. This single trick cleanly tells you whose fault it is, so you don't waste time debugging the library when the wire is the problem.

Second, confirm which sensor you're actually holding. The repo you linked is for the A02YYUW - a different model from the one in your title. The A01NYUB actively reports its distance on its own, once every few hundred milliseconds, on a 9600 baud stream, with a different frame layout than the A02YYUW. If your part is the A01NYUB, you should use its own example and baud rate - wiring it up through the A02YYUW driver will throw the frames away, because it's expecting a different packet shape and won't recognize yours. That mismatch alone produces "No data!" even when everything is wired correctly.

2026-09-28 15:51:54
1 Replies