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]<javascript:> > > 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] <javascript:>. >> To post to this group, send email to [email protected]<javascript:> >> . >> 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.
