Hello, I recently purchased one of these to use in a DIY water tank level sensor. So far I’ve just been testing it on the bench with the sample code for the device found on the DFRobot website, for some reason I keep getting a consistently low distance reading, approx. 30% lower than what it should be. For example when placing the sensor at 65cm away from a wall with no obstructions around I will get a reading of 43cm.
I’m using an ESP8266 to control the sensor with a voltage divider (330 & 470 Ohm) between the ECHO output and the GPIO pin that’s receiving the output to get it down from 5V to 3V. I’m at a loss… would really appreciate some help with this one.
Cheers!
Hi Simon,
Welcome to the forum 
I’m not sure what could make the sensor consistently measure too short unless there was an error with the timing or the received timing was being interpreted wrong by the sample code.
Can you send us a photo of your setup? Just in case we can spot anything amiss which might be causing interference with your sensor.
Glad to hear you got the echo values scaled down with a voltage divider, but it might be worth considering adding a logic level converter in your final project as they’re inexpensive and more suited to that task.
Which of the 5 sets of sample code were you using?
1 Like
Hi @Trent5487676 thanks for the welcome and responding to my question.
Here’s a photo of my setup:
I’m using the Mode 0 sample code:
#define ECHOPIN 7// Pin to receive echo pulse
#define TRIGPIN 8// Pin to send trigger pulse
int distance;
void setup(){
Serial.begin(9600);
pinMode(ECHOPIN, INPUT);
pinMode(TRIGPIN, OUTPUT);
//digitalWrite(ECHOPIN, HIGH);
}
void loop(){
digitalWrite(TRIGPIN, LOW); // Set the trigger pin to low for 2uS
delayMicroseconds(2);
digitalWrite(TRIGPIN, HIGH); // Send a 10uS high to trigger ranging
delayMicroseconds(20);
digitalWrite(TRIGPIN, LOW); // Send pin low again
distance = pulseIn(ECHOPIN, HIGH)/58; // Read in times pulse
//Serial.println(distance);
Serial.print(distance);
Serial.println(" cm");
delay(50);// Wait 50mS before next ranging
}
One bit of info I didn’t mention previously is that I’m using the Sming framework on the ESP8266, perhaps there is something in that? I’ll try the same code with just Arduino and see if the results differ.
I’ll certainly consider getting a logic level converter when I’m ready to build the final device.
Cheers!
Hi Simon,
If you can try the sample code with just the basic Arduino setup it’s certainly worth a shot, just to rule out the chance that the Sming framework is contributing to the issue.
Let us know how you go with regular Arduino and we’ll go from there.
1 Like
Hi Trent, it looks like it is something to do with Sming getting a much better output with Arduino:
Still 2cm short but I think I read elsewhere on this forum that this is due to the length of the sensor housing or something like that.
I think the issue is something to do with Sming being event driven and me using delays within the event callbacks to fire the TRIG on the sensor. I only picked Sming because it provides easy MQTT and Wifi features, but I’m sure I could do the same with Arduino.
Hi Simon, Trent
Excuse for chipping in here but I was just interested.
Surely "
would transmit a 20µS pulse not 10µS.
Could be wrong.
Cheers Bob
Hi Bob, yes you’re right there, that’s a copy and paste from the DFRobot site I posted above, must be a mistake.
@Trent5487676 quick question, what’s the benefit of a logic level converter over a simple voltage divider in this circumstance?
Hi Simon,
For a lot of hobby projects you may be just fine with a voltage divider. The reason the voltage divider may not be ideal is that its impedance can negatively influence the circuit it’s connected to. Every circuit will have some small amount of stray capacitance (since there are no perfectly ideal circuits), when this capacitance combines with the resistance of the divider it can form an RC circuit, which is a filter.
This presents problems where you need to detect high frequency rising and falling edges of a digital signal because the RC circuit filters and smooths out the transitions to the point that your signal no longer looks like a binary 1 or 0 with a crisp edge.
Hi Simon
No matter what it is. It should be correct. I thought that maybe if you sent a 20µS pulse where the device was expecting 10µS it may have been sending the return signal while still receiving the 20µS pulse. I am not totally familiar with this particular device but was just a thought.
Cheers Bob
Thanks for the explanation @Trent5487676 , makes sense, particularly in an application such as this where the ECHO pulse timing is important to get an accurate measure of the travel time. Although admittedly this is just for a home project so doesn’t need to be super accurate
@Robert93820 I suspect what they have done is just copied the code from another sensor that doesn’t have waterproofing and forgot to update the comment as I vaguely remember reading that the 20µS trigger was important for this one.
Thanks guys! I really appreciate your help.
1 Like
Careless. Still, That seems to be the norm these days.
Cheers Bob
1 Like
