if one PulseInput pin is open or has not received a pulse and you call 
getDuration() it will block you from reading all other PulseInput pins 
until it has received at least one pulse. We have found that one bad sensor 
will stop you from reading any other sensor.

On Friday, April 10, 2015 at 6:59:52 PM UTC-6, Daniel Brown 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.

Reply via email to