Which mode for which job
Four modes, and for most projects the right answer is the one that needs no soldering at all. Here is the short version: GPIO unless you are short of a pin, on a long cable, or already committed to a bus.
Pick the job, not the protocol
The cell worth studying is the one with no winner.
The limit that shapes everything
One sensor per I2C bus. The address is fixed at 0x57 — there is no
address pad and no configuration register — so two of these on one bus is two
devices answering simultaneously and a reading that belongs to neither.
That single fact rules I2C out of most of the projects people reach for an ultrasonic sensor for, because those projects usually want several. A robot with a sensor front, back and each side is four sensors, and the answer for it is four pairs of GPIO pins, or four single pins in 1-Wire mode — not a bus.
UART has the same shape of problem for a different reason: one port per sensor, and most microcontrollers have one or two.
What each one is actually for
GPIO is the default and it is fast — 50 ms a measurement against 100 ms on either bus, with no library and no fixed wait. Use it unless something below applies.
1-Wire buys you one pin. That is all it buys, and it is worth having when pins are genuinely scarce. The catch is the wiring: the data pin is TRIG, not ECHO.
I2C is worth it when the sensor joins a bus that already exists — a display, an expander, a real-time clock — because then it costs no pins at all. One sensor on a bus of its own has spent two pins to replace two pins.
UART is the one for distance. A 9600-baud serial line is far more tolerant of a couple of metres of cheap cable than a fast digital edge is, and more tolerant than I2C, whose pull-up resistors have to charge the whole cable's capacitance on every bit.
The rate nobody plans for
Whatever you pick, this is not a fast sensor. 50 ms is the floor in GPIO mode and 100 ms on a bus, and pushing past it does not fail cleanly — the previous burst is still bouncing around the room when the next goes out, and those late echoes arrive as short readings that look like an object appearing and vanishing.
Twenty readings a second is plenty for a robot that moves at walking pace. It is not enough to measure something vibrating, and no choice of mode changes that.
Five boards
The pack is the reason none of this has to be decided today. Leave most of them as they came, commit one to a bus when a project genuinely needs it, and keep the spare for the one you eventually cook with an iron.
When it does not work
Give each one a pair of GPIO pins, or a single pin each in 1-Wire mode. Do not reach for I2C: the address is fixed at 0x57, so four sensors on one bus is four devices answering at once. Four pairs of ordinary pins is boring, cheap and works.
Yes, by about half. A GPIO measurement cycle is 50 ms and a bus one is 100 ms, and the supported library adds a 150 ms wait on top of that. If you want readings as fast as the part can produce them, leave both jumpers open.
Not on its own — it is still four wires to the sensor. What it saves is pins on the microcontroller, but only if something else is already on that bus. One sensor on a bus of its own has used two pins to do what two GPIO pins were already doing.
None, until a project asks. A bridge is difficult to remove and there are five boards in the box; the sensible pattern is to leave most of them in GPIO mode and commit one or two when a build actually needs a bus.
Edit this page — content/books/ultrasonic-sensor/which-mode-for-which-job.mdx
Questions about this product
See what other owners have asked, and read their solutions.
Ultrasonic Distance Sensor
Loading discussions…
Discuss this article
Ask about this page. The answer stays here, on the page it belongs to, for whoever hits the same wall next.