devantech sonar module interfacing question

Archiver

hi folks,

has anyone had any experience interfacing a devantech SRF04 sonar module
with a bs/1? I didn't have any problems connecting one to a BS/2, but when
I tried using a BS/1, I noticed that it seems to ping (I can hear the clicks
from the transducers), but it keeps coming back with a 0 (zero) distance
measurement.

I used example code from the manual that I modified for the BS/1:


.
.
.
PING_LOOP:
pulsout 0, 1 'p0, 10us pulse to initiate ping
pulsin 1, 1, wdist 'p1, measure positive pulse, put into wDist
debug wdist
pause 10 'wait 10ms to allow sonar to settle
goto PING_LOOP
.
.
.

wdist (which contains a time value proportional to the distance to the
target) always comes back with 0.

again, this is for a BS/1.

thanks,


d...




**************************************************************************
* David Okagaki dokagaki@w...
*
* "The light at the end of the tunnel is that of the on coming train!"
*
**************************************************************************

Archiver

Dave,

I have not worked with the Devantec SONAR but I am working on
building my own. The code looks right (from the appnote), but since
it worked on the BS2 and not on the BS1 this is what I can offer.

From PUSLIN definition:

"You can think of Pulsin as a fast stopwatch that is triggered by a
change in state (0 or 1) on the specified pin.
...If the state of the pin doesn't change–even if it is
already in
the state specified in the Pulsin instruction–the stopwatch
won't
trigger. Pulsin waits a maximum of 0.131 seconds for a trigger, then
returns with 0 in resultVariable."

So you see, the likelyhood is that the BS1 is not seeing the 0-1
state change. If we take it a bit further, the BS2 is much faster
than the BS1 (i.e. command execution is faster -> 2x instruction, 5x
clock). The SRF04 takes about 0.1ms to pulse out. There is probably
some delay after this but the PULSIN command seems to trigger from
the beginning of this (0-1 transition) to the end of the ECHO return
(1-0). The BS2 is about 0.2ms/instruction (just makes it, probably
with some zero-returns), the BS1 is about 0.5ms/instruction (no
chance in hell it will make it).

In summary, the BS1 will never start the timer. So after 0.131
seconds it returns a big fat ZERO. You have a timing problem my
friend. A quick research shows a possible workaround (from
http://www.acroname.com/robotics/info/examples/srf04-1/srf04-1.html):

"Note: The execution time of the pulsin instruction will be slightly
different for different pins. If you change the pin assignments, the
pulsin command in the sr_sonar subroutine above may miss the rising
edge of the ECHO input and return some readings of 0. Using rctime
instead of pulsin may fix this problem. Another trick is to
introduce a small delay with a dummy command before measuring the
echo time with the rctime command. This is illustrated in the
alternate subroutine sr_sonar_2 . You may need to experiment to
determine the best code for your application."

I truly hope this helps, if I come up with something easier I'll post
it (btw, I am an avid PIC user because of timing issues like this).

languer.


--- In basicstamps@yahoogroups.com, "Dave" <dokagaki@w...> wrote:
> hi folks,
>
> has anyone had any experience interfacing a devantech SRF04 sonar
module
> with a bs/1? I didn't have any problems connecting one to a BS/2,
but when
> ... SNIP ...
> I used example code from the manual that I modified for the BS/1:
> .
> PING_LOOP:
> pulsout 0, 1 'p0, 10us pulse to initiate ping
> pulsin 1, 1, wdist 'p1, measure positive pulse, put into
wDist
> debug wdist
> pause 10 'wait 10ms to allow sonar to settle
> goto PING_LOOP
> .
> .
> .
>
> wdist (which contains a time value proportional to the distance to
the
> target) always comes back with 0.
>
> again, this is for a BS/1.
>
> thanks,
>
>
> d...

Archiver

thanks for the reply, and you're absolutely right, it did turn out to be a
timing problem caused by the bs/1's slower execution speed. It seems like
adding a dummy-command delay would actually make the problem worse; if the
bs/1 starts out being too slow to catch the 0-1 ECHO line transition,
wouldn't adding a delay make it miss it by that much more? I ended up using
a using an rc-network and an AND gate to introduce a 200us hardware delay to
the ECHO line before it reached the bs/1. This gave the bs/1 plenty of time
to cycle to the command to read the echo. Since I was only trying to get
relative distances, and not absolute values, the introduced error wasn't a
problem.

thanks again,


d...

>

---

Original Message

---

> From: languer [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=O-eHmOO1jIcvuyxs_ZpUX3CX0djABJcaNHV7JN49mN7iX2yIkdDDpoReiH3UkUStYi-af4Z5zGUgfn6nLx_wFWImXQ]langue_rodriguez@m...[/url
> Sent: Monday, July 21, 2003 7:01 PM
> To: basicstamps@yahoogroups.com
> Subject: [noparse][[/noparse]basicstamps] Re: devantech sonar module interfacing question
>
>
> Dave,
>
> I have not worked with the Devantec SONAR but I am working on
> building my own. The code looks right (from the appnote), but since
> it worked on the BS2 and not on the BS1 this is what I can offer.
>
> From PUSLIN definition:
>
> "You can think of Pulsin as a fast stopwatch that is triggered by a
> change in state (0 or 1) on the specified pin.
> ...If the state of the pin doesn't change–even if it is
> already in
> the state specified in the Pulsin instruction–the stopwatch
> won't
> trigger. Pulsin waits a maximum of 0.131 seconds for a trigger, then
> returns with 0 in resultVariable."
>
> So you see, the likelyhood is that the BS1 is not seeing the 0-1
> state change. If we take it a bit further, the BS2 is much faster
> than the BS1 (i.e. command execution is faster -> 2x instruction, 5x
> clock). The SRF04 takes about 0.1ms to pulse out. There is probably
> some delay after this but the PULSIN command seems to trigger from
> the beginning of this (0-1 transition) to the end of the ECHO return
> (1-0). The BS2 is about 0.2ms/instruction (just makes it, probably
> with some zero-returns), the BS1 is about 0.5ms/instruction (no
> chance in hell it will make it).
>
> In summary, the BS1 will never start the timer. So after 0.131
> seconds it returns a big fat ZERO. You have a timing problem my
> friend. A quick research shows a possible workaround (from
> http://www.acroname.com/robotics/info/examples/srf04-1/srf04-1.html):
>
> "Note: The execution time of the pulsin instruction will be slightly
> different for different pins. If you change the pin assignments, the
> pulsin command in the sr_sonar subroutine above may miss the rising
> edge of the ECHO input and return some readings of 0. Using rctime
> instead of pulsin may fix this problem. Another trick is to
> introduce a small delay with a dummy command before measuring the
> echo time with the rctime command. This is illustrated in the
> alternate subroutine sr_sonar_2 . You may need to experiment to
> determine the best code for your application."
>
> I truly hope this helps, if I come up with something easier I'll post
> it (btw, I am an avid PIC user because of timing issues like this).
>
> languer.
>
>
> --- In basicstamps@yahoogroups.com, "Dave" <dokagaki@w...> wrote:
> > hi folks,
> >
> > has anyone had any experience interfacing a devantech SRF04 sonar
> module
> > with a bs/1? I didn't have any problems connecting one to a BS/2,
> but when
> > ... SNIP ...
> > I used example code from the manual that I modified for the BS/1:
> > .
> > PING_LOOP:
> > pulsout 0, 1 'p0, 10us pulse to initiate ping
> > pulsin 1, 1, wdist 'p1, measure positive pulse, put into
> wDist
> > debug wdist
> > pause 10 'wait 10ms to allow sonar to settle
> > goto PING_LOOP
> > .
> > .
> > .
> >
> > wdist (which contains a time value proportional to the distance to
> the
> > target) always comes back with 0.
> >
> > again, this is for a BS/1.
> >
> > thanks,
> >
> >
> > d...
>
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the
> Subject and Body of the message will be ignored.
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Archiver

Good,

You're right, adding the delay would only work using RCTIME and that
is only available in BS2. Your solution is actually very good.

--- In basicstamps@yahoogroups.com, "Dave" <dokagaki@w...> wrote:
> thanks for the reply, and you're absolutely right, it did turn out
to be a
> timing problem caused by the bs/1's slower execution speed. It
seems like
> adding a dummy-command delay would actually make the problem
worse; if the
> bs/1 starts out being too slow to catch the 0-1 ECHO line
transition,
> wouldn't adding a delay make it miss it by that much more? I ended
up using
> a using an rc-network and an AND gate to introduce a 200us
hardware delay to
> the ECHO line before it reached the bs/1. This gave the bs/1
plenty of time
> to cycle to the command to read the echo. Since I was only trying
to get
> relative distances, and not absolute values, the introduced error
wasn't a
> problem.
...SNIP...