Yeah, I see. Well, since you're going to be ignoring the value anyway, you
can simply remove the mode check.

On Thu, Aug 31, 2017 at 6:32 PM, Maximillian <[email protected]>
wrote:

> Hi Ytai,
>
> Sorry I think the logic is ok.
>
> It's just we cannot use *getDurationBuffered()* along with
> *PulseMode.FREQ_SCALE_16*,
> We can only use *getDurationBuffered()* when in *PulseMode.POSITIVE* or
> *PulseMode.NEGATIVE*.
>
> Then the question is, how to apply the scaling as you mentioned earlier?
>
> On Monday, August 28, 2017 at 11:15:05 AM UTC+7, Ytai wrote:
>>
>> You can use getDurationBuffered() and apply scaling (to reduce the pulse
>> rate)
>>
>
>
> On Friday, September 1, 2017 at 8:07:51 AM UTC+7, Maximillian wrote:
>
>> Hi Ytai,
>>
>> Maybe the logic checking is wrong?
>>
>> IncapImpl.java line 108
>>
>> @Override
>> public synchronized float getDurationBuffered() throws InterruptedException,
>>       ConnectionLostException {
>>    if (mode_ != PulseMode.POSITIVE && mode_ != PulseMode.NEGATIVE) {
>>       throw new IllegalStateException(
>>             "Cannot wait for pulse when module was not opened in pulse 
>> mode.");
>>    }
>>    checkState();
>>    while (pulseQueue_.isEmpty()) {
>>       safeWait();
>>    }
>>    return timeBase_ * pulseQueue_.remove();
>> }
>>
>>
>> Maybe we should change it to
>>
>> if (mode_ == PulseMode.POSITIVE || mode_ == PulseMode.NEGATIVE) {
>>
>>     throw new IllegalStateException(
>>         "Cannot wait for pulse when module was not opened in pulse mode.");
>> }
>>
>>
>> if the mode is *PulseMode.POSITIVE* or *PulseMode.NEGATIVE* then we
>> cannot wait for pulse.
>>
>> We need the PulseMode is either in *PulseMode.FREQ, **PulseMode.FREQ_SCALE_4,
>> OR **PulseMode.FREQ_SCALE_16* mode to use *getDurationBuffered()*
>>
>> Or maybe I miss something here?
>>
>> On Friday, September 1, 2017 at 7:46:31 AM UTC+7, Maximillian wrote:
>>
>>> Hi Ytai,
>>>
>>> I got this exception
>>>
>>> E/IOIOBaseApplicationHelper: Unexpected exception caught:
>>> java.lang.IllegalStateException: Cannot wait for pulse when module was
>>> not opened in pulse mode.
>>> at ioio.lib.impl.IncapImpl.getDurationBuffered(IncapImpl.java:112)
>>> at ioio.test.activities.FillActivity$1.loop(FillActivity.java:328)
>>> at ioio.lib.util.IOIOBaseApplicationHelper$IOIOThread.run(IOIOB
>>> aseApplicationHelper.java:67)
>>>
>>> I have initialized the flowmeter like this:
>>>
>>> PulseInput flowMeter;
>>>
>>> //in the setup()
>>>
>>> flowMeter = ioio_.openPulseInput(FLOW_METER_PIN, 
>>> PulseInput.PulseMode.FREQ_SCALE_16);
>>>
>>> //in the loop()
>>> float durationBuffered = flowMeter.getDurationBuffered();
>>> totalPulse += 16
>>>
>>>
>>> I don't get the exception when I use getFrequencySync(), but I'd like to
>>> you getDurationBuffered() as you suggested for more detailed count.
>>>
>>> Any suggestion?
>>>
>>> On Wednesday, August 30, 2017 at 2:02:57 PM UTC+7, Maximillian wrote:
>>>
>>>> I guess I'll just have to use getVoltage() then..
>>>>
>>>> Big thanks Ytai!
>>>>
>>>> You are a lifesaver! :)
>>>>
>>>> On Tuesday, August 29, 2017 at 11:31:16 PM UTC+7, Ytai wrote:
>>>>
>>>>> Analog samples get pushed from the IOIO to the Android at 1kHz (one
>>>>> sample every 1ms). So if you use getVoltage(), whatever sample you're
>>>>> getting is only a few milliseconds old (since there's some latency too).
>>>>> I'm guessing that for pH measurements this is completely insignificant. 
>>>>> The
>>>>> *Sync version is only interesting for example in case where you want to 
>>>>> set
>>>>> some output which affects the voltage you're measuring and then make sure
>>>>> that the reading you're getting is one that was captured after the output
>>>>> has been set. Doesn't seem relevant for your case.
>>>>>
>>>>> On Tue, Aug 29, 2017 at 12:17 AM, Maximillian <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi Ytai,
>>>>>>
>>>>>> I'd like to have the pulse counting to be as accurrate as possible.
>>>>>>
>>>>>> I'm not really sure about the difference of getVoltageSync() and
>>>>>> getVoltage().
>>>>>>
>>>>>> But when I use the *sync method, the method block until new sample
>>>>>> arrive right?
>>>>>>
>>>>>> I don't mind if i lost a few pH input.
>>>>>>
>>>>>> So in order to achieve that goal, would it be better if I use
>>>>>> getVoltage() rather than getVoltageSync()?
>>>>>> Or maybe I should try another method?
>>>>>>
>>>>>> Many thanks
>>>>>>
>>>>>>
>>>>>> On Tuesday, August 29, 2017 at 1:17:37 PM UTC+7, Ytai wrote:
>>>>>>
>>>>>>> I don't think there's a lot of value in using the *Sync version.
>>>>>>> Otherwise it's fine, as long as you don't mind that the sample rate 
>>>>>>> varies
>>>>>>> with the flow rate. Otherwise, create a separate thread for one or the
>>>>>>> other.
>>>>>>>
>>>>>>> On Aug 28, 2017 18:21, "Maximillian" <[email protected]> wrote:
>>>>>>>
>>>>>>>> Thanks a lot Ytai.
>>>>>>>>
>>>>>>>> One more thing.
>>>>>>>>
>>>>>>>> I plan to use pH sensor along with this flow sensor.
>>>>>>>>
>>>>>>>> more or less it will be like this:
>>>>>>>>
>>>>>>>> PulseInput flowMeter = ioio_.openPulseInput(FLOW_METER_PIN,
>>>>>>>> PulseInput.PulseMode.FREQ_SCALE_16); //using frequency measurement
>>>>>>>> with 16x scaling
>>>>>>>> AnalogInput phMeter = ioio_.openAnalogInput(PH_METER_PIN);
>>>>>>>>
>>>>>>>>
>>>>>>>> float phVolt;
>>>>>>>>
>>>>>>>> int totalPulse = 0; //set initial value of totalPulse
>>>>>>>>
>>>>>>>> (this is inside the loop)
>>>>>>>>
>>>>>>>> {
>>>>>>>>
>>>>>>>>     duration = flowMeter.getDurationBuffered(); //the loop will wait 
>>>>>>>> here for 16 pulse then continue to next line
>>>>>>>>
>>>>>>>>     totalPulse += 16; //add total pulse by 16 because we use 
>>>>>>>> FREQ_SCALE_16
>>>>>>>>
>>>>>>>>     ....
>>>>>>>>     phVolt = phMeter.getVoltageSync();
>>>>>>>>     phValue = calculatePhFromVolt(phVolt);
>>>>>>>>
>>>>>>>>     ....
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> I think the phMeter will always has a value to return and will not
>>>>>>>> block the UI.
>>>>>>>>
>>>>>>>> Would it be an issue if combined with the
>>>>>>>> PulseInput.getDurationBuffered()?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> On Monday, August 28, 2017 at 9:03:16 PM UTC+7, Ytai wrote:
>>>>>>>>
>>>>>>>>> Yup, that's what I meant. And you don't need the sleep.
>>>>>>>>>
>>>>>>>>> On Aug 28, 2017 1:21 AM, "Maximillian" <[email protected]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Ytai, thanks for the reply,
>>>>>>>>>>
>>>>>>>>>> Based from your suggestion,
>>>>>>>>>>
>>>>>>>>>> PulseInput flowMeter = ioio_.openPulseInput(FLOW_METER_PIN, 
>>>>>>>>>> PulseInput.PulseMode.FREQ_SCALE_16); //using frequency measurement 
>>>>>>>>>> with 16x scaling
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> int totalPulse = 0; //set initial value of totalPulse
>>>>>>>>>>
>>>>>>>>>> (this is inside the loop)
>>>>>>>>>>
>>>>>>>>>> {
>>>>>>>>>>
>>>>>>>>>>     duration = flowMeter.getDurationBuffered(); //the loop will wait 
>>>>>>>>>> here for 16 pulse then continue to next line
>>>>>>>>>>
>>>>>>>>>>     totalPulse += 16; //add total pulse by 16 because we use 
>>>>>>>>>> FREQ_SCALE_16
>>>>>>>>>>
>>>>>>>>>>     ....
>>>>>>>>>>
>>>>>>>>>>     ....
>>>>>>>>>>
>>>>>>>>>>     Thread.sleep(100);
>>>>>>>>>>
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Do you mean like this?
>>>>>>>>>>
>>>>>>>>>> And also, do I still need the Thread.sleep(100)? As the
>>>>>>>>>> getDurationBuffered() will do pause the loop while waiting for
>>>>>>>>>> 16 pulse to come.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> do I still need to use Thread.sleep(100) when using this
>>>>>>>>>> implementation? Since getDurationBuffered will do pausing the
>>>>>>>>>> loop waiting for 16 pulse to come.
>>>>>>>>>>
>>>>>>>>>> On Monday, August 28, 2017 at 11:15:05 AM UTC+7, Ytai wrote:
>>>>>>>>>>
>>>>>>>>>>> You can use getDurationBuffered() and apply scaling (to reduce
>>>>>>>>>>> the pulse rate). This will ensure you don't miss any pulses. You 
>>>>>>>>>>> can even
>>>>>>>>>>> ignore the actual value returned, since you don't seem to care 
>>>>>>>>>>> about the
>>>>>>>>>>> rate, but rather about the count. Each time getDurationBuffered() 
>>>>>>>>>>> returns,
>>>>>>>>>>> it would mean that 16 pulses (or whatever your scaling is) were 
>>>>>>>>>>> observed.
>>>>>>>>>>> So you'll end up with a somewhat cumbersome, yet accurate way to 
>>>>>>>>>>> count your
>>>>>>>>>>> pulses.
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Aug 23, 2017 at 7:39 PM, Maximillian <
>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Fyi, I use this sensor.
>>>>>>>>>>>> https://www.seeedstudio.com/Water-Flow-Sensor-YF-B1-p-2878.html
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thursday, August 24, 2017 at 9:38:08 AM UTC+7, Maximillian
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I think I could get around ~40 pulse per each call of
>>>>>>>>>>>>> flowMeter.getFrequencySync() in a Thread.sleep(100) loop.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is it still unsafe to just use the getFrequencySync() method
>>>>>>>>>>>>> for that amount of pulse?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Or maybe I can just lower the sleep time to maybe Thread.sleep
>>>>>>>>>>>>> (50) for better accuracy?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for the hint, I'll try to look into that.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thursday, August 24, 2017 at 6:18:52 AM UTC+7, Ytai wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> What's the maximum pulse rate for your application?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Aug 23, 2017 at 3:36 PM, Maximillian <
>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Can you give more hint about how to count?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm not really sure how to do it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Big thanks
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wednesday, August 23, 2017 at 11:56:20 PM UTC+7, Ytai
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sampling the frequency and integrating will give you an
>>>>>>>>>>>>>>>> estimate of the total. If it's not accurate enough, you'll 
>>>>>>>>>>>>>>>> need to count.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Aug 22, 2017 2:51 PM, "Maximillian" <
>>>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi Ytai,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This is my current code (trimmed for this post)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> int FLOW_METER_PIN = 14;
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> volatile float pulseFreq, totalPulse;
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> PulseInput flowMeter = ioio_.openPulseInput(FLOW_METER_PIN, 
>>>>>>>>>>>>>>>>> PulseInput.PulseMode.FREQ);
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> totalPulse = 0;
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> public void loop() throws ConnectionLostException, 
>>>>>>>>>>>>>>>>> InterruptedException
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     pulseFreq = flowMeter.getFrequencySync();
>>>>>>>>>>>>>>>>>     totalPulse += pulseFreq;
>>>>>>>>>>>>>>>>>     //display totalPulse value to a textView;
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>     Thread.sleep(100);
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Current behavior is already as I expected, the totalPulse
>>>>>>>>>>>>>>>>> textView will updated only when the hall sensor is
>>>>>>>>>>>>>>>>> spinning (flow detected)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If I use the getFrequencySync() method, I think the loop
>>>>>>>>>>>>>>>>> is paused, waiting the flowMeter to receive input.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If it received input, the totalPulse will increase by the
>>>>>>>>>>>>>>>>> amount of pulseFreq from getFrequencySync().
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I haven't tested with real water yet (I just blow the flow
>>>>>>>>>>>>>>>>> sensor to make the hall spin for early development test)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> My question, is it correct to use this approach with the
>>>>>>>>>>>>>>>>> getFrequencySync() method?
>>>>>>>>>>>>>>>>> Or I still need to hack the DigitalInputImpl to count the
>>>>>>>>>>>>>>>>> pulses?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Wednesday, August 23, 2017 at 4:18:28 AM UTC+7, Ytai
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It is known, but there isn't currently a plan to add it.
>>>>>>>>>>>>>>>>>> If anyone wants to contribute a patch, I will happily 
>>>>>>>>>>>>>>>>>> consider adopting it.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Aug 13, 2017 8:21 PM, "Maximillian" <
>>>>>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>>>>> <blockquote class="gmail_quote" style="margin
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
> 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.

Reply via email to