PIXAXE-18 and the SRF04

[fishyghost]

I am having a few issues with the SRF04. I have followed the Devantech instructions for Picaxe chips - connect the do not connect pin to ground. But the variable that I set the pulsin to constantly stays as 0. Why?!


My Test Code

Symbol Tm = w0
Symbol RInches_10 = w1

Symbol TrigPin = 0    ' PICAXE Output
Symbol EchoPin = 7    ' PICAXE input


   Pause 1000			' allow system to settle when booting
   forward B

TOP:
   forward B
   PulsOut TrigPin,1
   PulsIn EchoPin,1,Tm
   If Tm= 0 Then OverRange
   backward B
   pause 400
   RInches_10 = Tm *  33 / 50   ' assumes 10 us per tick on pulsin
   Goto TOP

OverRange:
   forward A
   Pause 1000
   halt A
   Goto TOP

When turned on this code makes Motor B go forward and motor A turn on for a moment then off then on etc...

**broken link removed**

Supply is connected to my supply
Echo Pulse Output is connected to Input 7 (Positive Pin)
Trigger Pulse Input is connected to Output 0 (Positive Pin)
Do Not Connect is connected to Ground
0v Ground is connected to Ground...

Just as this page tells me to:
https://www.robot-electronics.co.uk/htm/srf04tech.htm

I am using the Toyota Challenge board.

 

[bloody-orc]

DO NOT CONNECT THE PIN THAT IS LABELED AS Do Not Connect!!!
If you have corrected that problem, then come back and tell us if it's working.

 

[dknguyen]

So it does! It says that there has been a recent modification so that if you DO connect the DNC pin to ground it adds a timing elay on the SRF04 ech output to allow slower uC more time to prepare for the return pulse. Before that it was only used to program the SRF04 firmware.

Im trying to understand your code and what's going on...are you even timing return echo (represented by the SRF04 as the amount of time that the echo pin stays high) of the SRF04? it looks like you are reading the output just once, instantly after a range reading which would always give you a zero.

The SRF04 requires an offboard MCU to take care of the time measurements. If you refer to the SRF04 Timing Diagram in the manual, you will see that if you read the echo pin once and too early you will get a zero. Here is the procedure:

1. Initiate transmit
2. Wait for echo line to go low->high
3. start the timing as soon as echo line goes high
4. stop timing when echo line goes low again
5. The length that the echo line was high represents the distance measured. Should a 36ms echo be measured, this is the SRF04's way of telling you that it timed-out and no echo was received.

Step 2 is where you are stalling. You are reading the echo line only once as soon as you initiate transmit. Because you are reading the line so fast and only once, you are capturing the low on the echo line which represents the SRF04 is still waiting/processing for the echo. You should be continuously reading the echo pin waiting for the line to go high, then continuously reading the echo line while it is high while timing how long it is high for. You only stop reading when the line has gone from high->low. (Instead of continuously reading the pin, you could use an uC pin that triggers an interrupt if the pin states changes if the PICAXE has those).

 

[fishyghost]

I don't know if this is right or not. But this is what I changed it to, The debug window sits waiting.

   forward B
Send:
   forward B
   PulsOut 0,1
   goto Sense
   
Ptt: debug w0
   If w0= 0 Then OverRange
   backward B
   w1 = w0 *  33 / 50   ' assumes 10 us per tick on pulsin
   Goto Send

OverRange:
   forward A
   Goto Send

Sense:
   PulsIn 7,1,w0
   if w0>1 then ptt
   goto sense

 

[dknguyen]

What does this command do:

PulsIn EchoPin,1,Tm

I assume it is:

PulsIn <Pin>,<Logic Value>,<Timer>

I am wondering what this does exactly. DOes it wait for a 1 before it starts timing or what? Because you have to wait for the echo line to go high while the SRF04 is ranging and then you have to measure the length of time the line is high to figure out how far the object is.

 

[bloody-orc]

pulsin's "Tm" is a defined variable, where the pulse lenght is stored. the wirst one is Pin and the second is logical value(as you stated before)

 

[dknguyen]

Oh okay. THen he is timing how long the pulse is high...hm...

Well....not sure then, but if something is overrange then the high pulse on the echo lins is >25ms long....not zero (you have tm = 0 for overrange).

 

[bloody-orc]

if the pulsing gets nothing, it stays 0. it starts mesuring the pulse when it vcomes and when it comes that's an echo, so everything is a ok.


also, you could try make a debugging program that just sends out a pulse and waits for it to come back end then send the variable vie debug cable back to programming editors debug terminal. see if this has any differents. also you could see the picaxes own manual on hof to use that sonar module. you might find something useful from there (sadly i cant remember the exact datasheet number or name).

 

[dknguyen]

if the pulsing gets nothing, it stays 0. it starts mesuring the pulse when it vcomes and when it comes that's an echo, so everything is a ok.

The data sheet says that the SRF04 returns a 36ms long high pulse when no echo is received and it times out.

 

[fishyghost]

I have tried using the Picaxe sample code, but it is basically a varient of my first code here...

 

[bloody-orc]

you could actually also try picaxe's own forum... they might know a bit better...