Devantech SRF04 with Basic Stamps
Recently I have purchased a few SRF04 sensors through Acroname on-
line. I came across Devantech's website where they mention the
following:
"On the SRF04, the users host processor is required to time the
returning echo. This has been an issue when using the Stamp, as it
does not treat all I/O lines equally. This is an internal problem
with the Stamp and was discovered by Jim Fry of Lynxmotion."
On one of my robot projects I will be using 2 SRF04's possibly 3 at
most, and I was wondering if this was true about the Basic Stamps?
I have seen "some" workarounds, including the addendum from Acroname
about this, however I was thinking about using one of the PAK'S from
AWC electronics to handle the job.
Any ideas?
Thanks
line. I came across Devantech's website where they mention the
following:
"On the SRF04, the users host processor is required to time the
returning echo. This has been an issue when using the Stamp, as it
does not treat all I/O lines equally. This is an internal problem
with the Stamp and was discovered by Jim Fry of Lynxmotion."
On one of my robot projects I will be using 2 SRF04's possibly 3 at
most, and I was wondering if this was true about the Basic Stamps?
I have seen "some" workarounds, including the addendum from Acroname
about this, however I was thinking about using one of the PAK'S from
AWC electronics to handle the job.
Any ideas?
Thanks
Comments
Devantech will return a distance of zero and fool your code if you don't
measure using 3 or 4 pings.
Original Message
> Recently I have purchased a few SRF04 sensors through Acroname on-
> line. I came across Devantech's website where they mention the
> following:
>
> "On the SRF04, the users host processor is required to time the
> returning echo. This has been an issue when using the Stamp, as it
> does not treat all I/O lines equally. This is an internal problem
> with the Stamp and was discovered by Jim Fry of Lynxmotion."
>
>
> On one of my robot projects I will be using 2 SRF04's possibly 3 at
> most, and I was wondering if this was true about the Basic Stamps?
>
> I have seen "some" workarounds, including the addendum from Acroname
> about this, however I was thinking about using one of the PAK'S from
> AWC electronics to handle the job.
>
BS2. I have not tried multiple SRF04's however. I used various pins also,
and saw no problems.
The Stamps do not multitask, so I don't see a problem with you reading one
SRF, then a 2nd SRF and then a 3rd. I do use the 2nd section of code for the
Devantech. The revised code posted by acroname. I never could get the
original first section code to work.
The following is some short code to play a speaker sound based on the range
the SRF detects. You could use this as a test on your sensor's and I/O lines
to be sure you are getting valid readings. it saves being hooked up to a
Debug window, or an LCD display.
'3/27/2001
'devantech SRF04
'Init pin on 4
'echo pin on 5
' conversion factors 74 for inches, 29 for centimeters
wdist var word
wdistold var word
sound var word
hz var word
init con 4
echo con 5
convfac con 74 'conversion factor for inches
speaker con 1
MAIN
gosub sr_sonar
'debug dec wdist, cr
freqout 1,200,sound
pause 200
goto main
SR_SONAR
pulsout init, 5 '10us init pulse
output init
rctime echo,1,wdist
wdist = wdist/convfac 'convert to inches
if wdist < 10 then object
'wdistold = wdist
sound = wdist * 100
pause 10
return
OBJECT
for Hz = 1 to 4000 step 1000
freqout speaker,70,hz,4000-hz
next
goto main
At 12:30 PM 9/10/02 -0000, you wrote:
>Recently I have purchased a few SRF04 sensors through Acroname on-
>line. I came across Devantech's website where they mention the
>following:
>
>"On the SRF04, the users host processor is required to time the
>returning echo. This has been an issue when using the Stamp, as it
>does not treat all I/O lines equally. This is an internal problem
>with the Stamp and was discovered by Jim Fry of Lynxmotion."
>
>
>On one of my robot projects I will be using 2 SRF04's possibly 3 at
>most, and I was wondering if this was true about the Basic Stamps?
>
>I have seen "some" workarounds, including the addendum from Acroname
>about this, however I was thinking about using one of the PAK'S from
>AWC electronics to handle the job.
>
>Any ideas?
>Thanks
>
>
>
>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/
>
>
>
Very respectfully, your obedient servant.
Kerry
Admin@M...
WWW server hosting [url=Http://mntnweb.com]Http://mntnweb.com[/url]
Kerry Barlow
p.o. box 21
kirkwood ny
13795
607-775-1575
how it works.
thanks again
--- In basicstamps@y..., Kerry Barlow <admin@m...> wrote:
> I have used a single srf04 and have never had a problem with
timing on the
> BS2. I have not tried multiple SRF04's however. I used various
pins also,
> and saw no problems.
> The Stamps do not multitask, so I don't see a problem with you
reading one
> SRF, then a 2nd SRF and then a 3rd. I do use the 2nd section of
code for the
> Devantech. The revised code posted by acroname. I never could get
the
> original first section code to work.
> The following is some short code to play a speaker sound based on
the range
> the SRF detects. You could use this as a test on your sensor's and
I/O lines
> to be sure you are getting valid readings. it saves being hooked
up to a
> Debug window, or an LCD display.
>
> '3/27/2001
> 'devantech SRF04
> 'Init pin on 4
> 'echo pin on 5
> ' conversion factors 74 for inches, 29 for centimeters
> wdist var word
> wdistold var word
> sound var word
> hz var word
> init con 4
> echo con 5
> convfac con 74 'conversion factor for inches
> speaker con 1
>
> MAIN
> gosub sr_sonar
> 'debug dec wdist, cr
> freqout 1,200,sound
> pause 200
> goto main
>
> SR_SONAR
> pulsout init, 5 '10us init pulse
> output init
> rctime echo,1,wdist
> wdist = wdist/convfac 'convert to inches
> if wdist < 10 then object
> 'wdistold = wdist
> sound = wdist * 100
> pause 10
> return
>
> OBJECT
> for Hz = 1 to 4000 step 1000
> freqout speaker,70,hz,4000-hz
> next
> goto main
>
>
>
>
> At 12:30 PM 9/10/02 -0000, you wrote:
> >Recently I have purchased a few SRF04 sensors through Acroname on-
> >line. I came across Devantech's website where they mention the
> >following:
> >
> >"On the SRF04, the users host processor is required to time the
> >returning echo. This has been an issue when using the Stamp, as
it
> >does not treat all I/O lines equally. This is an internal problem
> >with the Stamp and was discovered by Jim Fry of Lynxmotion."
> >
> >
> >On one of my robot projects I will be using 2 SRF04's possibly 3
at
> >most, and I was wondering if this was true about the Basic Stamps?
> >
> >I have seen "some" workarounds, including the addendum from
Acroname
> >about this, however I was thinking about using one of the PAK'S
from
> >AWC electronics to handle the job.
> >
> >Any ideas?
> >Thanks
> >
> >
> >
> >To UNSUBSCRIBE, just send mail to:
> > basicstamps-unsubscribe@y...
> >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/
> >
> >
> >
>
> Very respectfully, your obedient servant.
> Kerry
> Admin@M...
> WWW server hosting [url=Http://mntnweb.com]Http://mntnweb.com[/url]
> Kerry Barlow
> p.o. box 21
> kirkwood ny
> 13795
> 607-775-1575
>SRF, then a 2nd SRF and then a 3rd. I do use the 2nd section of code for the
>Devantech. The revised code posted by acroname. I never could get the
>original first section code to work.
You can fake it by having all the trigger lines in the 8 low bits of
the IO word, and all the data lines in the high 8 bits. This lets
you trigger up to 8 SRF04's with a single assignment to OUTL, and you
can read in the state of all the sensors with a single read of INH.
The caveat is that the Basic Stamp is not fast enough to loop
checking all the bits. So what you do is repeatedly store INH into
an array, and after you've read in as many bytes as possible, you
count bits in the bit columns to get a sensor value. You don't get
as fine resolution as you would measuring the pulse width of a single
sensor at a time, but you do get a much faster update rate.
You can adjust the resolution of each "step" in the counting by
changing the length of time each assignment takes, as follows:
b00 = INH ' smallest possible range increment
b00 = INH | INH ' takes longer
b00 = INH | INH | INH ' etc
On caveat: you have to be a little careful about crosstalk between
sensors (ie: sensor B picking up the echo emitted by sensor A before
the real echo of the pulse emitted by sensor A comes back. In our
application (a Battlebot), we had 8 sensors in 4 pairs, and would
alternately trigger the left and right sets (front and back). This
gave us redundancy; if the transmitter of one of a pair of sensors
(say, the left front pair) died, it would still pick up the echo of
the pulse from its redundant spare. In fact, we could lose the
transmitter on one sensor and the receiver on the other, and it would
still work.
We ended up with a bot that could autonomously attack and avoid other
robots and the walls of the battlebox (watching it pingpong around
the test box was hilarious), but our first battle was against a robot
only 4" high so we couldn't get good pings. Oh well...
R
--
===========================================================
Robert Woodhead, CEO, AnimEigo http://www.animeigo.com/
===========================================================
http://selfpromotion.com/ The Net's only URL registration
SHARESERVICE. A power tool for power webmasters.