SRF05

nevil010

Member
I tried to read range using srf05 in debug mode...but it always show the same range
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 comm
goto main
why is it like this..i am not using sig mode..
 

hippy

Ex-Staff (retired)
I tried to read range using srf05 in debug mode...but it always show the same range
And what value of range does it show ?

If it's zero then this could be a timeout of the PULSIN returning zero, meaning it's not receiving an echo signal. If it's non-zero it indicates PULSIN is returning a value and it is seeing some pulse.

Post a circuit diagram so we can see how your module is wired up, and a photo will let people check you have got that correct.

It's always worth saying which PICAXE type you are using and what hardware as that may give a clue as to what may be wrong; if connected through a Darlington Driver then that won't work for example. It also allows others to test the same set-up to see how it works for them.
 

westaust55

Moderator
As hippy requested in post 4 to help us better:
1. please advise which PICAXE chip you are using,
2. post you schematic
3. A clear photo taken straight on/perpendicular (not at an angle) so we can trace the wiring
4. What supply voltage are you using for (a) the PICAXE and (b) the SRF05

Can you try a test using separate pins for the trigger and return pulse to see what the result is.

Your program code is from the older datasheet.
See the newer datasheet here for the dual pin code example: http://www.picaxe.com/docs/srf005.pdf
 

nevil010

Member
and when i debug,as the time in debug increases the led in srf05 also flashes..supply voltage is 4.5v and i tried 5v then the led on the backside of srf flashes faster...
 

Attachments

hippy

Ex-Staff (retired)
In your second photo it looks like the trigger/echo signal goes to C.2 while your program in post #1 expects it to be on C.1.
 

hippy

Ex-Staff (retired)
i was just checking with it..
It might explain why you started to get a reading of zero. Did you change the code to match the hardware change ? If not then it would likely read zero.

Have you moved the connection back to C.1 ? Is that still reading zero or has it returned to working as it previously did ?

It always helps to provide code, circuits and photos of what you have, which correlate with each other or the lack of correlation will usually be seen as being something wrong with what you have.

For future reference it's also best to photograph against plain backgrounds to provide high contrast as that makes it easier to distinguish what things are and can help the camera to auto-focus. A sheet of white paper behind a board is often good enough.
 

eclectic

Moderator
CHI035 board and 18M2


Code:
#Picaxe18M2
#terminal 4800
symbol trig = C.1    
symbol range = w1    
main: pulsout trig,2   
 pulsin trig,1,range  
 pause 20   ;
 let range = range * 10 / 58 ; 
 
 Sertxd (#range," ")
 
goto main
e
 

Attachments

nevil010

Member
from c.1 to c.2...not it is not working and when i tried this code

Code:
#Picaxe18M2
#terminal 4800
symbol trig = C.1    
symbol range = w1    
main: pulsout trig,2   
 pulsin trig,1,range  
 pause 20   ;
 let range = range * 10 / 58 ; 
 
 Sertxd (#range," ")
 
goto main
the input buffer shows like
 

Attachments

eclectic

Moderator
Run the program again.

Watch the screen

Move your hand in front of the sensors.
Move your hand away.

What happens?
 

hippy

Ex-Staff (retired)
The reported 522 (cm) represents a raw PULSIN reading of around 3000, which would be a 30ms pulse from the SRF005 which is what it would be expected to give if it finds no object has bounced back an echo.

On the positive front this means the hardware system is doing what would be expected, but the bad news is it sounds like it's either not outputting a sonic pulse, or not detecting the echoed pulse.

That would unfortunately seem to put it into the 'broken' category but it might be worth checking no stray wires are shorting anything on the board.
 
Top