Vic posted some code earlier on this thread that is claimed to work and
looks pretty nice. Why are you not using that?

On Fri, Apr 10, 2015 at 3:36 PM, Daniel Brown <[email protected]> wrote:

> We have a project that uses 6 distance finders,  when we try to call
> .getDuration() on more then one all further reading freezes.
>
> protected void setup() throws ConnectionLostException {
>
> // front left pulse and echo
> echoPinfl_ = ioio_.openPulseInput(6, PulseMode.POSITIVE);
> triggerPinfl_ = ioio_.openDigitalOutput(7);
>  // front middle pulse and echo
> echoPinfm_ = ioio_.openPulseInput(2, PulseMode.POSITIVE);
> triggerPinfm_ = ioio_.openDigitalOutput(4);
>
> ...
>
> public void loop() throws ConnectionLostException, InterruptedException {
>  // updates front left sensor
> try{
> triggerPinfl_.write(false);
> Thread.sleep(5);
> triggerPinfl_.write(true);
> Thread.sleep(1);
> triggerPinfl_.write(false);
> echosecondsfl_ = (int)(echoPinfl_.getDuration() * 1000 * 1000);
> echoDistanceCmfl_ = echosecondsfl_ / 29 / 2;
> }catch (ConnectionLostException e) { throw e;}
>  // updates front middle sensor
> try{
> triggerPinfm_.write(false);
> Thread.sleep(5);
> triggerPinfm_.write(true);
> Thread.sleep(1);
> triggerPinfm_.write(false);
> // echosecondsfm_ = (int)(echoPinfm_.getDuration() * 1000 * 1000);  //if
> this line is commented in all further input stops
> // echoDistanceCmfm_ = echosecondsfm_ / 29 / 2;
> }catch (ConnectionLostException e) { throw e;}
>
> ...
>
> On Friday, May 16, 2014 at 11:03:20 AM UTC-6, Ytai wrote:
>>
>> 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]
>>> wrote:
>>>>
>>>> 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.
>

-- 
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