Issue with Ping driver?

Code for robot waits for ping reading to be less than 12 inches and then do something.

But, a loop that only calls ping driver does not work...
    if j<12
       (do something)

The Ping LED doesn't even turn on if you do this...

Adding a delay to the loop seems to fix the issue.

Maybe that's a "feature", but I'm tempted to call that a bug...
Prop Info and Apps:


  • Mike GreenMike Green Posts: 22,923
    edited 2017-10-31 - 01:04:51
    The library PING))) driver is very simple and written completely in Spin (about a dozen lines). How do you have the PING))) wired? It should be running off 5V and the signal line should have a 3.3K resistor between it and the Propeller I/O pin. What's your system clock?
  • RaymanRayman Posts: 9,929
    edited 2017-10-31 - 10:09:58
    I'm using the P17 header on the WX Activity Board.
    The jumper is set to 5V.

    But, come to think of it, I didn't have this issue running the same code on an old Activity Board...
    Prop Info and Apps:
  • The servo headers already have 3.9K series resistors. You shouldn't have additional resistance in series.
  • Not using any series resistors... Counting on the ones already part of the Activity Board...

    There must be some difference between old Activity Board and Activity Board WX.
    Or, maybe I have a bad WX board...
    Tried two different Ping modules, so I don't think there's a problem there...

    I tried both P16 and P17 headers on the WX board and they both have this issue.
    This isn't horrible, I just insert a delay and then it seems to work.

    Still, left me scratching my head...
    Prop Info and Apps:
  • If your ping is SPIN code then there are 11 code lines in it.
    In your loop there are only 3 code lines, so it's much faster.
    What happens when you call ping over and over before it's done with the first result?
    Taken from: & nid = 454
    Yes Frida is my watchdog!
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,474
    edited 2017-10-31 - 20:09:20
    The Ping))) requires a minimum 200uS delay between the end of one measurement and the beginning of the next. Most program examples show a 100ms delay.

    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • RaymanRayman Posts: 9,929
    edited 2017-10-31 - 21:47:55
    Adding a 50 us delay in the loop makes it work.

    But, I'm 99% sure my old Activity Board worked without this delay.
    (Wish I hadn't just gave it away now).

    I suppose it's possible that I remember wrong and had some debug code in there that I removed and thereby broke the code...

    If that's the case, then I'm back to thinking there should be a, say, 100 us delay added to the driver.
    Or, some note that a delay is needed...
    Prop Info and Apps:
  • I would recommend an even longer delay, say the 100ms that example programs use. The reason is that you want secondary echoes to die out before taking a new sample, as they could register as primary echoes in a sample requested too soon.

    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
Sign In or Register to comment.