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.
