Shop OBEX P1 Docs P2 Docs Learn Events
Devantech SRF04 with Basic Stamps — Parallax Forums

Devantech SRF04 with Basic Stamps

ArchiverArchiver Posts: 46,084
edited 2002-09-11 02:25 in General Discussion
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

Comments

  • ArchiverArchiver Posts: 46,084
    edited 2002-09-10 13:31
    I've had no problems with the Stamp as far as timing. Occasionally the
    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.
    >
  • ArchiverArchiver Posts: 46,084
    edited 2002-09-10 14:12
    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@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
  • ArchiverArchiver Posts: 46,084
    edited 2002-09-10 17:24
    Okay thanks, I am going to try using the RCtime with them and see
    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
  • ArchiverArchiver Posts: 46,084
    edited 2002-09-11 02:25
    >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.

    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.
Sign In or Register to comment.