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.

Reply via email to