HC-SR04

#1
Hello.
I'm using the HC-SR04 rangefinder, can't seem to get it working.
Perhaps it's the pins I'm using.
Code:
symbol trig = C.1 			; Define pin for Trigger & Echo (All M2, X2 parts)
symbol range = w1 			; 16 bit word variable for range

main:	pulsout trig,2 			; produce 20uS trigger pulse (must be minimum of 10uS)
	pulsin trig,1,range 		; measures the range in 10uS steps
	pause 20			; recharge period after ranging completes

	; now convert range to cm (divide by 5.8) or inches (divide by 14.8)
	; as picaxe cannot use 5.8, multiply by 10 then divide by 58 instead

	let range = range * 10 / 58	; multiply by 10 then divide by 58
	debug range			; display range via debug command
	goto main			; and around forever

	; Note that X2 parts operate at 8MHz instead of 4MHz and so modify the calculation
	; let range = range * 10 / 58 / 2 ; multiply by 10 then divide by 58 then divide by 2
This is simply the example on picaxe.com - but uses the SR05.
How is the SR04 different?

Thanks
 

g6ejd

Senior Member
#2
That module has a trigger and echo pin unlike the 05 variant that uses just one pin, that's why your code does not work. You need an output and input. You have already coded the trigger and inputs just add a new definition for the input pin and change your code for that line, it should then work.

Add symbol echo = c.2
Add a new cable and connect it to the echo pin.

Change to pulsin echo,1,range
 
Last edited:

hippy

Technical Support
Staff member
#3
The echo comes back sooner after triggering using HC-SR04 than SRF005 so you might have to run at a faster operating speed using SETFREQ. You also have to adjust range calculations accordingly.
 
#5
Thanks guys, after posting this it occurred to me that the "trigger" may trigger the module to 'search' and the "echo" was the echoing of any object, thus giving a signal back, making an input and an output. You confirmed it,

E- I have a mac ;) - no PE :(

Thanks again
 
#6
Snip

E- I have a mac ;) - no PE :(

Thanks again
Well, nobody's perfect. :)

However, there must be a way to download the
PE "samples" folder somewhere.

There is a great deal of useful code in those programs, including
Code:
' Sample program for SRF04 ultrasonic range finder
' Note the NC pin on the module must be connected to 0V
' or else the SRF04 will not work with PICAXE.
symbol trig = 3            ' Define output pin for Trigger pulse
symbol echo  = 6           ' Define input pin for Echo pulse
symbol range = w1          ' 16 bit variable for range (remember w1 = b2 + b3)
main:
    pulsout trig,2         ' produces about 20uS pulse (must be minimum of 10uS)
    pulsin echo,1,range    ' measures the range in 10uS steps
    pause 10               ' SRF04 mandatory 10mS recharge period after ranging completes
' now convert range to cm (divide by 6.2) or inches (divide by 14.9)
' as picaxe cannot use fractions, multiply by 10 then divide by full number
' e.g. range x 10 then / 62 is the same as range / 6.2
    let range = range * 10 / 62 ' multiply by 10 then divide by 62 
    debug range   ' display range via debug command
    goto main            ' and around forever

e
 
#7
It may also be worth looking at the manufacturers website for more information:
http://www.robot-electronics.co.uk/htm/srf04tech.htm
Update - May 2003
:
:
All SRF04's manufactured after May 2003 have new software implementing an optional timing control input using the "do not connect" pin. This connection is the PIC's Vpp line used to program the chip after assembly. After programming its just an unused input with a pull-up resistor. When left unconnected the SRF04 behaves exactly as it always has and is described above.
When the "do not connect" pin is connected to ground (0v), the timing is changed slightly to allow the SRF04 to work with the slower controllers such as the Picaxe.
And 2003 would have been a time when PICAXE chips were likely limited to 4 MHz or at best 8 MHz clock speed.
 

g6ejd

Senior Member
#9
Yes, I've got an HC-SR04 and it's definitely not an SRF04, different electronics for sure. Broadly the same operation though.
 

Technical

Technical Support
Staff member
#12
Try this for that particular HC-SR04 sensor, works here at 4MHz on 08M2 with just one i/o pin.

Connect echo to trigger with a 1K8 or similar, then connect trigger to a single PICAXE pin e.g. C.2

Then simply use:
Code:
High    C.2
PulsIn  C.2, 1, w0
This works as pulsin converts the pin to input again, and the pull down resistor on the module on the trigger pin pulls the trigger low again at that time.
It also means the pulsin command is immediately ready to catch the echo.
The 1K8 resistor means the echo output is not damaged by the trigger pulse from the PICAXE.
 

erco

Senior Member
#13
Great info on implementing one-pin mode, Technical. I tried it on a BS2 (8 MHz), which worked with both the HC-SR04 and -SR05 units. I had a fair amount of zero readings returned, both in one- and two-pin modes. I got fewer zeroes by replacing your High (pin) command with Pulsout (pin),10 which outputs a 20 uS pulse.
 

Technical

Technical Support
Staff member
#14
That is not a good general modification, as the trigger signal then goes low before the pulsin command starts to be processed, increasing chances that the start of the echo pulse is missed. The main key to this solution is using the pulsin command to also bring the trigger pin low again, so that pulsin is *immediately* ready to receive the fast echo pulse. If you need a longer trigger pulse simply use high-pause-pulsin instead, which will even work with 4MHz parts.
 

hippy

Technical Support
Staff member
#15
The main key to this solution is using the pulsin command to also bring the trigger pin low again, so that pulsin is *immediately* ready to receive the fast echo pulse.
Just to add to that; it's the falling edge at the end of the trigger pulse that sets things in motion, not the leading, rising edge.

Using PULSIN turns the output from high to an input, the echo being at zero pulls the trigger low through the 1K8 between echo and trigger and causes the ultrasound pulse to be issued, the PULSIN then immediately starts monitoring the echo for its pulse, so it's always ready for the pulse as soon as it is triggered.

Code:
                       ____
Pin as output      ___|    |___________________
                   ___:    :___________________
Pin as input          |____|           
                      :____:   
Signal to Trigger  ___|    |___________________              
                      :    :   ____________
Signal from Echo   ___:____:__|            |___

                      :    :
                  HIGH:    :PULSIN
Once the echo pulse completes, the pin remains an input, the 1K8 from echo keeps the trigger pulled low, until the next HIGH sets it high and primes it for another activation.

The echo pulse does appear on the trigger input whilst it is being generated, but the sensor micro is busy generating the echo pulse so ignores this. And it will be gone as soon as the echo pulse finishes, and before the sensor micro starts looking for another trigger activation, so does not adversely affect operation.

It's quite a clever trick using PULSIN pin becoming an input to activate the triggering and ensures it is immediately ready for the echo pulse which starts fairly soon after the trigger on the HC-SR04, much sooner than it does on the SRF04 or SRF005.
 
Last edited by a moderator:
#17
hello guys i have an ir sensor at the moment but i want to replace it with a hc sr04 echo sensor but i dont know where the trigger and echo wires must go please help
thank youy in advance
you can answer me here or email me at [email removed]
 
Last edited by a moderator:

Technical

Technical Support
Staff member
#18
Connect echo to trigger with a 1K8 or 2K2 or similar resistor, then connect trigger to a single PICAXE pin e.g. B.2. That would be the row of pads directly between the 2 chips on the AXE020.

Then use
Code:
High    B.2
PulsIn  B.2, 1, w0


 

erco

Senior Member
#19
Somewhat related: http://forums.parallax.com/showthread.php/153735-Pulsin-Timeout-and-HC-SR04-problems

A very interesting thread about this sensor. Its timeout duration is longer than the 20 ms servo refresh rate, which caused problems for "another processor". Not sure if that would cause a problem with the M2's servo commands. Anyhow, at the end of the thread, guru Tracy Allen comes up with a simple external RC circuit to fake a shorter timeout duration, which solved the servo refresh problem.
 
Top