Unusual behaviour from HC-SR05 Ultrasonic Distance Sensor

Hello,

I have a HC-SR05 Distance Sensor, more exact this one: Velleman VMA306

I've been using the NewPing library, but it seems my sensor is behaving differently and not compatible with that library.

Problem #1 - Two pin mode don't work with default config (ONE_PIN_ENABLED=true)

When using the library with the default settings and using two pins, the trigger signal is always 5V and therefor creates and endless loop of measurements so the trigger signals becomes useless (see upper part of this image):

Seems to be the same issue being raised here: teckel12 / Arduino New Ping / issues / #53 - Trigger pin set to "input" ? — Bitbucket.

It appears the library is supposed to work with default config (ONE_PIN_ENABLED=true) even when you run with two pins. So I don't know if this becomes a problem for me because my sensor is always looking for 5V signal on the trigger instead of only looking for a 5V raise from ground?

Has anyone seen this problem or behaviour before? It seems to be an odd behaviour as it isn't compatible with the NewPing library.

Code:

#include <NewPing.h>

// SONAR
#define TRIGGER_PIN  13
#define ECHO_PIN     5
#define MAX_DISTANCE 450
NewPing sonar(TRIGGER_PIN, ECHO_PIN, MAX_DISTANCE);
long distance = 0;

// Periodic running of code
unsigned long lastTimestamp = 0;
const int period = 500;

void setup() {
  Serial.begin(9600);
}

void loop() {
  if ((millis() - lastTimestamp) >= period) {
    lastTimestamp = millis();

    distance = sonar.ping_cm();
  }
}

Problem #2 - Echo 5V signal isn't starting until the sonar response is received

In the NewPing library code, it seems to assume the echo signal is starting directly after the sonar pulses are sent. But looking at my sensor, it starts the echo 5V signal AFTER the sonar pulses have returned. You can see that there is always a wait before the echo signal that is the same width as the echo pulse afterwards:

see second part of image above, couldn't post more than 1 image

This means many assumptions in the NewPing library are wrong for my sensor. For example, you can find this in the code:

Maximum time we'll wait for ping to start (most sensors are <450uS, the SRF06 can take up to 34,300uS!)

Sounds like the code writer is surprised by the 34,300uS value, but if it works like my sensor, it makes sense as that is equal to a distance of ~5.8 meter which maybe makes sense to measure with that sensor. So maybe it is just that SRF06 is behaving like mine, that is waiting for the sonar pulses to return before starting the echo signal (which then is ~34ms long).

This also means that when measuring long distances of the max distance of 4.5m, you need to have ~60ms between pings (measuring 4,5m @ 53ms + some margins), or double the time vs a sensor starting the echo signal directly.

I haven't found this issue/behaviour discussed anywhere, so wanted to check in here if anyone has run into it before or if my sensor is unique.

Maybe @teckel knows something.

Thanks!

I did some more investigation on this.

The first surprise was that the library still worked even if my sensor have a long delay (could be up to ~26ms before echo 5V signal starts after trigger at 4.5m distance. Because it has this setting:

#define MAX_SENSOR_DELAY 5800 // Maximum uS it takes for sensor to start the ping. Default=5800

So you expect it would wait 5.8ms for the echo signal to start, otherwise give up. But looking at the code using this:

_max_time = micros() + _maxEchoTime + MAX_SENSOR_DELAY; // Maximum time we'll wait for ping to start (most sensors are <450uS, the SRF06 can take up to 34,300uS!)

It seems it is prepared to wait 5.8ms PLUS _maxEchoTime (~26ms for 4.5m) = ~32ms. So this doesn't make sense and probably a bug in the NewPing library, so I assume I was lucky it worked as it is supposed to time out at 99cm (~5.8ms round trip).

In summary it would mean I would need to change ONE_PIN_ENABLED, MAX_SENSOR_DELAY and PING_MEDIAN_DELAY for my Sensor to work by default with the library which strengthens my hypothesis that my sensor is a bit different from all the ones @teckel have used to test the library.

Anyone that has ran into a sensor like this waiting for the sonar pulses to return before even starting the echo 5V signal?

  1. If you set ONE_PIN_ENABLED to false, it will set the trigger pin to OUTPUT and it will never change. It sounds like you have ONE_PIN_ENABLED set to true.
  2. It seems the understanding of the MAX_SENSOR_DELAY is incorrect. That's the time from the trigger to when the ping starts. It's added to _maxEchoTime as that would be the entire time for the ping to complete (start delay + actual ping time).
  3. For NewPing support, please open an issue in BitBucket: teckel12 / Arduino New Ping / issues — Bitbucket. It's also best practice to create an issue for a single problem.

Thanks for the answer @teckel ! I think there are some misunderstandings though. The main topic of the post is to focus on the behaviour of my HC-SR05 sensor and I want to see if anyone have run into this kind of version of the sensor where it waits for the sonar signals to return before it starts the echo 5V pulse. I'm using your NewPing library as reference (as it seems to be the most used library and you have put a lot of effort into making it fit multiple type of sensors) and the fact that it doesn't seem to be designed around my sensor's behaviour.

To address your points:

Yes, that is what I'm trying to explain that I have ONE_PIN_ENABLED=true, but it seems by the documentation that it should be working anyway with two pins. And that fact makes me wonder if my sensor behaves differently with a constant HIGH trigger signal vs other sensors if the other ones seem to work anyway.

No, my understanding is in line with what you are saying. And what you are saying makes sense, but that's not how it is in the code currently. The code is divided into two separate waits. While waiting for the ping to start, it sets the waiting time to:

_max_time = micros() + _maxEchoTime + MAX_SENSOR_DELAY; // Maximum time we'll wait for ping to start

Which should be only MAX_SENSOR_DELAY. Because then after the ping started and waiting for it to end, THEN it re-assigns the value with:

_max_time = micros() + _maxEchoTime; // Ping started, set the time-out.

Which makes sense. So the only bug is the first wait where it should only wait the MAX_SENSOR_DELAY, and not add the _maxEchoTime as well.

This post is not about NewPing support, I know what the problem is with the library in regards to my HC-SR05 (and can fix it pretty easy myself). I'm just trying to figure out if my HC-SR05 is special in some way as it is waiting for the sonar pulses before starting the ping.

Given your interest in understanding the diverse behaviours of different ultrasonic sensors, I thought that you would sit on some knowledge on the topic plus you might be interested in understanding if there are sensors out there with diverging behaviours.

And as a small bonus I happened to run into the bug as I was deep diving into understanding your code and the assumptions it is doing about sensors.

It wouldn't be surprising at all if your sensor was different. There's a ton of different Chinese companies making these sensors, all with slightly different hardware (to reduce cost) and cloned firmware (or mostly cloned, or an old version cloned). It's the wild wild west with sonar sensors, which is surprising as they cost like $1, so it's amazing there's profit.

Anyway, if you need to report a problem or bug with the library, please do on Bitbucket.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.