Problem with ATmega8 & HC-SR04

Community General Discussions
1

I am getting garbage results trying to control a HC-SR04 sonic distance sensor from a Dagu Mini Driver board (ATmega8). The wires to the SR04 are being monitored with a scope and/or logic analyser and look ok. The TRIG and ECHO timing appear reasonable and change proportional to distance to hard flat object…

I suspect the problem is with the ISR. It often tPmodDIN1imes has the endTime set to something resembling the current time in usec while the startTime variable remains at 0. To me this indicates the the ISR reacted to just the negative going ECHO pulse.

Update 4/2/15:

It appears that the root cause of my problem is a defective cable connector. I used a connector that splits the input to both male and female output pins. I can the readily attach logic analyser or scope probes. Just checked and Digilent is no longer carrying the PmodDIN1 adapter.

Now that I am getting reliable connections the true nature of the beast is emerging. I bought 5 for $13US and feel cheated.

  1. Any movement at either sensor or target gives a series of invalid results.
  2. The size and shape of the target is critical. I have an 11x21 cm box as the target. At 10cm, 20cm, 40cm & 50cm it returns fairly accurate results. At 30cm it usually reports 68cm (sometimes 30cm). Flip the box to a larger target and 30cm comes back steady.
  3. The absence of an echo, timeout when using pulseIn(), means the ECHO line is still high for quite some time.

It is possible that there are multiple manufactures of this unit and I got the worst. Judging by the comments on the internet I am not alone. I can see no use for a distance sensor on a mobile robot that give garbled output while moving.

I had to remove the code do to this update because the paragraphs were getting merged when using “Purified HTML” and switching to Markdown" jumbled the Arduino code.

Moving forward I need to get a more reliable splitter and get better sonic sensors. I also want to examine the ECHO signal at the processor.

Thanks for the feedback.

2

I would do a test.

I always like to do tests with other methods when I run into issues like these.

I would do two quick ones.  

No ISR code on your side for either.

Method one: pulsein

#define microsecondsToCentimeters(microseconds) (unsigned long)microseconds / 29.1 / 2.0
unsigned long ping ( )
{

// Trigger the uSonic sensor (HC-SR04) to send out a ping

digitalWrite (TRIGGER_PIN, LOW);

delayMicroseconds (5);

digitalWrite (TRIGGER_PIN, HIGH);

delayMicroseconds (10);

digitalWrite (TRIGGER_PIN, LOW);

// Measure how long the ping took and convert to cm’s

return (microsecondsToCentimeters (pulseIn (ECHO_PIN, HIGH)));

}

Method two: while echo pin is high.

Excuse the Lua code, but I can’t find my RPI sonic code right now.  The method will be the same:

function read_usonic ( )

local pulse_start = 0

local pulse_end = 0

– Send out the trigger signal to the sensor

gpio.write (8, gpio.LOW);

delay_us (5)

gpio.write (8, gpio.HIGH);

delay_us (10)

gpio.write (8, gpio.LOW);


– Wait for echo to go HIGH

while (gpio.read (7) == 0) do

pulse_start = tmr.now ( )

end


– Wait for echo to drop LOW again

while (gpio.read (7) == 1) do

pulse_end = tmr.now ( )

end


– Return centimeters

return ((pulse_end - pulse_start) / 58)

end

From there maybe you can get a better feel if it’s the ISR or not.  Hope this help some.