Thanks for sharing!

On Thu, May 15, 2014 at 9:25 PM, <[email protected]> wrote:

> Here is some code that works great with the Parallax Ping))) with the
> circuit in the file attached (thanks to Ytai):
>
> private int read(DigitalOutput strobe, PulseInput input, int inputPin) throws 
> ConnectionLostException, InterruptedException // Order of following 
> statements is very important...do not change
>       {
>               int distance = 0;
>               ioio.beginBatch();
>
>               strobe.write(true);
>               input = ioio.openPulseInput(inputPin, PulseMode.POSITIVE);
>               ioio.endBatch();
>
>               SystemClock.sleep(40);
>               strobe.write(false);
>               distance += (int) (input.getDuration() * CONVERSION_FACTOR);
>               input.close();
>
>               return distance;
>       }
>
>
> On Wednesday, April 30, 2014 10:25:27 AM UTC-7, [email protected]:
>>
>> I'll clean up the class and post it.  Hope other people can use it.
>>  Works very solidly with the Parallax Ping))) ultrasonic module.
>> Great suggestion to use only one pin for both input and output.  It would
>> even have saved me a part on the pc boards.
>>
>> On Sunday, April 27, 2014 8:24:19 PM UTC-7, Ytai wrote:
>>>
>>> Cool. If you can create a nice class for using the PING (where the ctor
>>> gets a IOIO and two pin numbers, and there's a getDistance() method) and
>>> share it on this forum, it would be a decent return for our efforts :) As a
>>> side note, since you're doing the open-close trick, you might as well use a
>>> single pin and open-close the digital output as well and not need the
>>> driver chip, so you can even further simplify both your code and your
>>> circuit.
>>>
>>>
>>> On Sun, Apr 27, 2014 at 8:19 PM, Vic Wintriss <[email protected]>wrote:
>>>
>>>> I finally got it to work using your last suggestion.  This code works
>>>> that you recommended works perfectly.  Thanks so much for sticking with us.
>>>>  We've got 30 or 40 kids using this code at the International Autonomous
>>>> Robot Competition (iARoC 2014) coming up at the end of June.  Check out
>>>> iaroc.org.
>>>>
>>>> triggerHigh();
>>>> in = openPulseInput();
>>>> sleep(20ms);  // wait until the pulse input module is ready for a pulse.
>>>> triggerLow();  // kick off a measurement (falling edge does not trigger
>>>> the pulse input)
>>>> duration = in.getDuration();
>>>> in.close();
>>>> return duration;
>>>>
>>>> On Sunday, April 27, 2014 11:36:53 AM UTC-7, Ytai wrote:
>>>>
>>>>> Let me shed some light on the internals of PulseInput:
>>>>>
>>>>>    - A timer is running on the IOIO set to 200Hz (5ms).
>>>>>    - As soon as the pulse input module is opened, and every time
>>>>>    after a pulse is captured the module will be put in the "ready" state.
>>>>>    - Every time the 200Hz timer triggers, each "ready" module will be
>>>>>    activated, i.e. put in a state where it is waiting for a new pulse.
>>>>>    - Once activated, the module will wait forever (or until closed)
>>>>>    for a pulse, then measure its duration, then sends the result to the
>>>>>    Android.
>>>>>    - So this means that effectively no matter what the actual pulse
>>>>>    rate is, you will never get more than 200 reports per second. This has 
>>>>> been
>>>>>    done on purpose to prevent a high frequency pulse train from 
>>>>> saturating the
>>>>>    connection between the IOIO and the Android. This also means that 
>>>>> there is
>>>>>    a potential "dead time" of up to 5ms after opening or between pulses,
>>>>>    during which a pulse would not be detected.
>>>>>    - On the Android side, every pulse report finds its way to your
>>>>>    PulseInput object. You can then read it in one of three ways:
>>>>>       - getDuration() will return the last report. It will generally
>>>>>       not block, then only exception is until the first report arrives.
>>>>>       - getDurationSync() will always block until a new report comes
>>>>>       in, then return it. So you can be sure that the report is new.
>>>>>       - getDurationBuffered() pulls pulses one by one from a queue.
>>>>>       When the queue becomes empty it behave like getDurationSync(), i.e. 
>>>>> waits
>>>>>       until a new report comes in.
>>>>>
>>>>> The Arduino approach cannot be directly applied to the IOIO API, since
>>>>> you have to take into account that because of the communication between 
>>>>> the
>>>>> Android and the IOIO, much of the IOIO API has been designed to be
>>>>> asynchronous in nature. If you were to bake the PING driver directly into
>>>>> the IOIO firmware, you can use a similar approach to Arduino's (although
>>>>> you'd probably want to implement it in a non-blocking way, since the IOIO
>>>>> allows everything to be used concurrently). The reason why I have not done
>>>>> that is because I tried to focus on generic use-cases rather than on one
>>>>> peculiar sensor interface.
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Apr 27, 2014 at 10:57 AM, Duane DeSieno <[email protected]>wrote:
>>>>>
>>>>>> My confusion is maybe over the way getDuration works.
>>>>>> Does it delay 5ms before looking for the pulse or does it look
>>>>>> immediately?
>>>>>> I put 555 timer on the input pin and set it up for 3.15hz and 25.4%
>>>>>> duty cycle or an 80.6ms pulse every 317.4ms.
>>>>>> I called getDuration roughly every 100ms.  It did not block and
>>>>>> returned the same value several times before the next pulse occurred(not
>>>>>> what I expected).
>>>>>>
>>>>>> Looked at the Arduino approach to using the PING and they use just
>>>>>> one pin, changing from output after sending a pulse to ping to an input 
>>>>>> for
>>>>>> their get duration call.
>>>>>> Since they don't impose a 5ms delay, they get the duration of the
>>>>>> return pulse.
>>>>>>
>>>>>> Thanks for you help on this.
>>>>>>
>>>>>> Duane
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>  --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "ioio-users" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to [email protected].
>>>>>> To post to this group, send email to [email protected].
>>>>>>
>>>>>> Visit this group at http://groups.google.com/group/ioio-users.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>  --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ioio-users" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> To post to this group, send email to [email protected].
>>>> Visit this group at http://groups.google.com/group/ioio-users.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>  --
> You received this message because you are subscribed to the Google Groups
> "ioio-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/ioio-users.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"ioio-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/ioio-users.
For more options, visit https://groups.google.com/d/optout.

Reply via email to