It's iARoC time again, and we are having ultrasonic problems again!  This 
year I am using only 4-pin sensors like you recommend and OTG.
I can't find any of the ioio.sync() methods.  What version of the ioiolib 
are they in?  All the robots have 3 or 4 ultrasonic sensors.

On Tuesday, April 12, 2016 at 3:09:22 PM UTC-7, Ytai wrote:
>
> Because there's no guarantee hour long it would take between when your 
> command executed on the Android and when the actual pin voltage changes. 
> What you're seeing when having a short (or no) delay between the commands 
> is that sometimes they would end up actually getting executed a very short 
> gap between them.
> Coming to think of it, if you only care about minimum duration, you can 
> add a ioio.sync() call after starting the pulse and before starting the 
> delay. This will guarantee that the delay begins after the pin has already 
> been set. This will allow you to set a 1ms sleep without the pulse 
> collapsing, but no guarantees on maximum width, it may come out wider than 
> 1ms.
> On Apr 12, 2016 3:02 PM, "Vic Wintriss" <[email protected] 
> <javascript:>> wrote:
>
> Ytai:
>
> Why can’t I use:
>
> strobe.write(true);
> strobe.write(false);
> input.getDuration();
>
> Vic
>
>
> On Apr 12, 2016, at 2:57 PM, Ytai Ben-Tsvi <[email protected] <javascript:>> 
> wrote:
>
> Good question. Currently the only way to ensure this level of sync is the 
> motion control API. Alternatively, if your time constants are coarse 
> enough, you can open multiple PWM channels running at slow rates and insert 
> delays between the open command (order of 10's of ms as you have seen with 
> your experiments). The ideal solution would have been a one-shot function, 
> which is easy to implement using an output compare module, but this doesn't 
> currently exist.
> On Apr 12, 2016 11:07, "Vic Wintriss" <[email protected] <javascript:>> 
> wrote:
>
>> How would you work the PWM with multiple sensors?
>>
>> On Tuesday, April 12, 2016 at 10:54:34 AM UTC-7, Ytai wrote:
>>>
>>> No threads involved and nothing asynchronous. You set the PWM once 
>>> during setup(), then you getDuration() whenever you please.
>>> On Apr 12, 2016 10:52 AM, "Vic Wintriss" <[email protected]> wrote:
>>>
>>>> I would rather run the ultrasonics asynchronously.  Also since the kids 
>>>> may not be be that advanced in our curriculum I prefer to stay away from 
>>>> threads.  The last code that I posted works fine.
>>>>
>>>> On Tuesday, April 12, 2016 at 10:37:52 AM UTC-7, Ytai wrote:
>>>>>
>>>>> Use PWM output to generate periodic, precisely timed trigger pulses.
>>>>> On Apr 12, 2016 10:36, "Vic Wintriss" <[email protected]> wrote:
>>>>>
>>>>>> I thought I was following your instructions.  I am using the 4-pin 
>>>>>> sensor as suggested and code that I thought was standard.  What did you 
>>>>>> tell me to do that I am not doing?
>>>>>>
>>>>>> On Monday, April 11, 2016 at 1:28:48 PM UTC-7, Ytai wrote:
>>>>>>>
>>>>>>> I feel like I gave you my best advice, but you seem to insist on 
>>>>>>> doing it in a way that's not supposed to work.
>>>>>>> On Apr 11, 2016 1:03 PM, "Vic Wintriss" <[email protected]> wrote:
>>>>>>>
>>>>>>>> When I use this code:
>>>>>>>>
>>>>>>>> ioio.beginBatch();
>>>>>>>> rightStrobe.write(true);
>>>>>>>> rightStrobe.write(false);
>>>>>>>> ioio.endBatch();
>>>>>>>>
>>>>>>>> I get this beautiful result:
>>>>>>>>
>>>>>>>>
>>>>>>>> <https://lh3.googleusercontent.com/-qyhO2zqtmoY/VwwBnL2vE7I/AAAAAAAAAAg/xyOLBnQBnuIvFhdp0IdprRb_qVvx6Hckw/s1600/bad.PNG>
>>>>>>>>
>>>>>>>>
>>>>>>>> But the code hangs up and I get no duration readings.
>>>>>>>>
>>>>>>>> If I use this code:
>>>>>>>>
>>>>>>>> rightStrobe.write(true);
>>>>>>>> SystemClock.sleep(10);
>>>>>>>> rightStrobe.write(false);
>>>>>>>>
>>>>>>>> rightDistance = (int) (rightInput.getDuration() * CONVERSION_FACTOR
>>>>>>>> );
>>>>>>>>  I get this awful situation, but it works. Anything less than a 10 
>>>>>>>> millisec sleep fails.
>>>>>>>>
>>>>>>>>
>>>>>>>> <https://lh3.googleusercontent.com/-WEm_XYa5PF8/VwwBBYuVQ9I/AAAAAAAAAAY/15jv4SAWC3ouxIcAW9EyO7GC-SEZgtSZA/s1600/works.png>
>>>>>>>>
>>>>>>>> On Monday, April 4, 2016 at 9:25:36 PM UTC-7, Ytai wrote:
>>>>>>>>>
>>>>>>>>> Sorry, I meant "output" from the IOIO's point of view.
>>>>>>>>> Let me make sure I understand you correctly: are you claiming that 
>>>>>>>>> you're emitting a shorter-than-10-ms trigger pulse, the pulse gets 
>>>>>>>>> emitted 
>>>>>>>>> correctly as verified by a scope, the echo pulse gets emitted 
>>>>>>>>> correctly as 
>>>>>>>>> verified by a scope, but your app is blocked on 
>>>>>>>>> waitPulseGetDuration()? If 
>>>>>>>>> that's the case, the only thing I can imagine is that the wait*() 
>>>>>>>>> method is 
>>>>>>>>> called after the pulse has already comes back.
>>>>>>>>>
>>>>>>>>> Have you considered using PwmOutput as trigger, as per my 
>>>>>>>>> suggestion? Then you can use getDuration() and never have to block. I 
>>>>>>>>> think 
>>>>>>>>> this is a rather elegant solution.
>>>>>>>>>
>>>>>>>>> On Mon, Apr 4, 2016 at 10:51 AM, <[email protected]> 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> The output pulse (echo pulse returning from the ultrasonic 
>>>>>>>>>> sensor) is correct...it is milli secs long and varies 
>>>>>>>>>> proportionately with 
>>>>>>>>>> the distance.  I am not using Bluetooth...the Android is directly 
>>>>>>>>>> connected 
>>>>>>>>>> to the ioio board.  It is the trigger pulse that must be long...more 
>>>>>>>>>> than 
>>>>>>>>>> 10 millisec...for the program to run.  It hangs up with smaller 
>>>>>>>>>> trigger 
>>>>>>>>>> pulses.  I can easily generate 10 microsec trigger pulses...as 
>>>>>>>>>> observed on 
>>>>>>>>>> scope...but then the program hangs up.  Ideas?
>>>>>>>>>>
>>>>>>>>>> On Friday, April 1, 2016 at 9:55:17 PM UTC-7, Ytai wrote:
>>>>>>>>>>>
>>>>>>>>>>> When you look at the waveforms, what do you see as the output 
>>>>>>>>>>> pulse? My guess would be that it is very narrow, in the order of a 
>>>>>>>>>>> couple 
>>>>>>>>>>> of usec perhaps, and if that's indeed the case, it is likely 
>>>>>>>>>>> because both 
>>>>>>>>>>> messages comprising the pulse got collapsed into the same packet 
>>>>>>>>>>> over one 
>>>>>>>>>>> of the slower connections such as Bluetooth. In short, trying to 
>>>>>>>>>>> achieve 
>>>>>>>>>>> precise timing of any sort at this time scale is a bad idea. It 
>>>>>>>>>>> would be 
>>>>>>>>>>> possible to add a one-shot feature to the IOIO to achieve that. If 
>>>>>>>>>>> you want 
>>>>>>>>>>> this reading periodically, consider using a PwmOutput to keep 
>>>>>>>>>>> triggering 
>>>>>>>>>>> the sensor without your intervention at very precise pulse widths 
>>>>>>>>>>> and 
>>>>>>>>>>> period. Another option would be to use a version of those sensors 
>>>>>>>>>>> that 
>>>>>>>>>>> emits an analog voltage corresponding to the distance.
>>>>>>>>>>> On Apr 1, 2016 9:38 PM, <[email protected]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> It's a new iARoC (International Autonomous Robot Competition) 
>>>>>>>>>>>> year (2016) and we are back to the ultrasonic sensor problem.  
>>>>>>>>>>>> This year I 
>>>>>>>>>>>> am using the 4-pin version.  The following code works:
>>>>>>>>>>>>
>>>>>>>>>>>> public void readRight() throws ConnectionLostException, 
>>>>>>>>>>>> InterruptedException
>>>>>>>>>>>> {//This code works with the 4-pin sensor...don't change 
>>>>>>>>>>>> anything!
>>>>>>>>>>>>     rightStrobe.write(true);
>>>>>>>>>>>>     SystemClock.*sleep*(10);
>>>>>>>>>>>>     rightStrobe.write(false);
>>>>>>>>>>>>     rightDistance = (int) (rightInput.getDuration() * 
>>>>>>>>>>>> *CONVERSION_FACTOR*);
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> But it will not work with less than a 10 ms long trigger 
>>>>>>>>>>>> pulse.  I don't understand this, because the ultrasonic sensor 
>>>>>>>>>>>> spec says 
>>>>>>>>>>>> that the trigger pulse should be around 10 micro sec.  Do you have 
>>>>>>>>>>>> any idea 
>>>>>>>>>>>> why I need such a long trigger pulse.  I verified the waveforms 
>>>>>>>>>>>> with a 
>>>>>>>>>>>> scope.  It seems to be the case with both the 4-pin and the 3-pin 
>>>>>>>>>>>> version.
>>>>>>>>>>>>
>>>>>>>>>>>> On Thursday, April 23, 2015 at 9:43:50 PM UTC-7, Ytai wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> You can add a TimerTask to interrupt the thread after some 
>>>>>>>>>>>>> timeout. Search the forum for examples if you need them. If you 
>>>>>>>>>>>>> don't want 
>>>>>>>>>>>>> to delay all the other 5 if one is stuck you can easily run 6 
>>>>>>>>>>>>> sensors on 6 
>>>>>>>>>>>>> different threads.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Apr 22, 2015 at 2:42 PM, Daniel Brown <
>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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 ioio-users+...@
>>>>>>>>>>>>>>>>>>>>>> googlegroups.com.
>>>>>>>>>>>>>>>>>>>>>> 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 https://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 https://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 https://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 https://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 https://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] <javascript:>.
>> To post to this group, send email to [email protected] 
>> <javascript:>.
>> Visit this group at https://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 a topic in the 
> Google Groups "ioio-users" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/ioio-users/3MDLEEKtejY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> [email protected] <javascript:>.
>
> To post to this group, send email to [email protected] 
> <javascript:>.
> Visit this group at https://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] <javascript:>.
> To post to this group, send email to [email protected] 
> <javascript:>.
> Visit this group at https://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 https://groups.google.com/group/ioio-users.
For more options, visit https://groups.google.com/d/optout.

Reply via email to