Hi again Ytai!

Still trying to reproduce it with a pwm connected to a PulseInput. Nothing 
luck so far. I find it abit annoying that frequency is an integer, so I can 
not set 1.5Hz or similar. Is it hard to change so I can send a float 
instead?

However, I tried to use the waitPulseGetDuration with the following code:

*pulseCounter = ioio_.openPulseInput(35, PulseMode.FREQ);*
*Thread.sleep(500);*
*float duration = pulseCounter.waitPulseGetDuration();*

Unfourtanly this returns an exception:

12-18 18:56:32.412  4774  4789 E IOIOBaseApplicationHelper: 
java.lang.IllegalStateException: Cannot wait for pulse when module was *not 
*opened in pulse mode.

12-18 18:56:32.412  4774  4789 E IOIOBaseApplicationHelper: at 
ioio.lib.impl.IncapImpl.waitPulseGetDuration(IncapImpl.java:58)

12-18 18:56:32.412  4774  4789 E IOIOBaseApplicationHelper: at 
com.example.ioiotest.MainActivity$Looper.getWindSpeed(MainActivity.java:191)

12-18 18:56:32.412  4774  4789 E IOIOBaseApplicationHelper: at 
com.example.ioiotest.MainActivity$Looper.loop(MainActivity.java:214)

12-18 18:56:32.412  4774  4789 E IOIOBaseApplicationHelper: at 
ioio.lib.util.IOIOBaseApplicationHelper$IOIOThread.run(IOIOBaseApplicationHelper.java:62)

Do I missunderstand something here?

Kind Regards
Thomas

Den måndagen den 2:e december 2013 kl. 17:34:32 UTC+1 skrev Ytai:
>
> On Wed, Nov 27, 2013 at 1:10 AM, Thomas Hermansson 
> <[email protected]<javascript:>
> > wrote:
>
>> Hi Ytai!
>>
>> Trying to generate the problem by looping a PWM with a PulseInput, but a 
>> great problem is that when I close the PWM in order to set another 
>> frequency it also means that the PWM goes low with generates a pulse which 
>> could be of any frequency. :) Is it possible to change the freq without 
>> closing the PWM?
>>
>
> It would be easier to just ignore that one pulse.
>  
>
>>
>> However, one thing that is easy to detect is the following sceario/bug.
>>
>> The PWM runs on 2Hz, and a dutycycle of 0.9.
>> Then I set dutycycle to 0 to simulate that no pulses are sent.
>> This causes GetFrequency to continue to report 2Hz until I reset the 
>> dutycycle to 0.9 again.
>> Then GetFreq will report the true freq of 0.1Hz one time, and then go 
>> back to report 2Hz.
>>
>
> This is the intended behavior. If you want distinct pulses, you should 
> call waitPulseGetFrequency().
>  
>
>>
>> I think it would be better if the GetFrequency would somehow also 
>> calculate that if no new pulse has arrived for 1/lastFreq s then the 
>> returned freq should be 1/(time since last pulse). That way you can see 
>> from the client that the pulses have stopped and freq gets less with every 
>> reading.
>>
>> //Thomas
>>
>>
>>
>> Den måndagen den 25:e november 2013 kl. 09:37:33 UTC+1 skrev Thomas 
>> Hermansson:
>>
>>> I will try the firmware and see what happens, and then try to reproduce 
>>> it with PwmOutput for you.
>>>
>>>
>>> Den måndagen den 25:e november 2013 kl. 02:59:16 UTC+1 skrev Ytai:
>>>>
>>>> I'm convinced there's a problem, but not sure how I can help.
>>>> A few things to try:
>>>>
>>>>    - I put a beta version of the latest firmware 
>>>> here<https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fytai%2Fioio%2Fblob%2Fmotion-control-beta%2Frelease%2Ffirmware%2Fapplication%2FMotionBeta-1.ioioapp&sa=D&sntz=1&usg=AFQjCNE9ttjpOpEUSUEa8yngwHoFvUWZBg>.
>>>>  
>>>>    Try to install it and see if it makes things better for you. As I 
>>>>    mentioned, I found and fixed a couple of thread-safety issues on the 
>>>>    firmware. 
>>>>    - If that doesn't work, it would be nice if you can reproduce it 
>>>>    for me by providing an app that requires looping back a PwmOutput to a 
>>>>    PulseInput and demonstrated the problem. You can close and re-open the 
>>>>    PwmOutput in runtime to change the frequency. This way, I can reproduce 
>>>> it 
>>>>    on my setup and possibly dig deeper. 
>>>>
>>>>
>>>>
>>>> On Sun, Nov 24, 2013 at 4:06 AM, Thomas Hermansson <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi again Ytai!
>>>>>
>>>>> I hope I haven´t got too tired of me yet. :)
>>>>>
>>>>> The last post was done over Bluetooth, so I thought I´d run it again 
>>>>> over usb. The same program is run (MainActivity.java) and the output is 
>>>>> stored to the attached log file.
>>>>>
>>>>> Search for the Key "Large Value" to find the erronous posts.
>>>>>
>>>>> Here are some highlights:
>>>>> WindSpeed: 222222.22 Hz
>>>>> WindSpeed: 200000.0 Hz
>>>>> WindSpeed: 7812.5 Hz
>>>>> Seems all to be sent when there is no wind at all, and the sensor is 
>>>>> not producing any output at all.
>>>>>
>>>>> When checking
>>>>> Line 645:
>>>>> WindSpeed: 1.3024436 Hz
>>>>> WindSpeed: 1.3024436 Hz
>>>>> WindSpeed: 1.4251511 Hz
>>>>> WindSpeed: 1.3511404 Hz
>>>>> WindSpeed: 1.3511404 Hz
>>>>> WindSpeed: 1.1975001 Hz
>>>>> WindSpeed: 1.1975001 Hz
>>>>> WindSpeed: 1.1975001 Hz
>>>>> WindSpeed: 1.1159693 Hz
>>>>> WindSpeed: 1.1159693 Hz
>>>>> WindSpeed: 4.51663 Hz  <--- Probably incorrect too
>>>>> WindSpeed: 4.51663 Hz <--- Probably incorrect too
>>>>> WindSpeed: 200000.0 Hz <--- Incorrect
>>>>> LargeValue!
>>>>> WindSpeed: 200000.0 Hz <--- Incorrect
>>>>> LargeValue!
>>>>> WindSpeed: 1.130416 Hz
>>>>> WindSpeed: 1.130416 Hz
>>>>> WindSpeed: 1.130416 Hz
>>>>> WindSpeed: 1.1174964 Hz
>>>>> WindSpeed: 1.1174964 Hz
>>>>> WindSpeed: 0.95850855 Hz
>>>>> WindSpeed: 0.95850855 Hz
>>>>>
>>>>> As the samples are taken with 100ms delay I would think it is highly 
>>>>> unlikely that two readings should suddenly have been raised to the speed 
>>>>> 4.51663 Hz.
>>>>>
>>>>> At line 2401
>>>>> WindSpeed: 1.4762577 Hz
>>>>> WindSpeed: 1.2861075 Hz
>>>>> WindSpeed: 1.2861075 Hz
>>>>> WindSpeed: 1.1391617 Hz
>>>>> WindSpeed: 36.346455 Hz <--Definitely wrong!!
>>>>> LargeValue!
>>>>> WindSpeed: 36.346455 Hz
>>>>> LargeValue!
>>>>> WindSpeed: 1.2270759 Hz
>>>>> WindSpeed: 1.2270759 Hz
>>>>> WindSpeed: 1.2270759 Hz
>>>>> WindSpeed: 0.8686633 Hz
>>>>>
>>>>> I would really apprechiate if you would look further into this issue.
>>>>>
>>>>> Kind Regards
>>>>> Thomas
>>>>>
>>>>> Den torsdagen den 21:e november 2013 kl. 22:03:53 UTC+1 skrev Thomas 
>>>>> Hermansson:
>>>>>
>>>>>> Hi again!
>>>>>>
>>>>>> Now here are the results of a minor test done today with a very 
>>>>>> simple app as I think you require. See the image of the LogCat for the 
>>>>>> incorrect readings.
>>>>>>
>>>>>> Den torsdagen den 21:e november 2013 kl. 10:26:50 UTC+1 skrev Thomas 
>>>>>> Hermansson:
>>>>>>>
>>>>>>> Hi Ytai!
>>>>>>>
>>>>>>> My program does not run anything concurrently. The main thread calls 
>>>>>>> getFrequency (which do indeed run in a separate thread), but the next 
>>>>>>> line 
>>>>>>> in the code waits for the "GetFrequency-thread" to finish. And if it 
>>>>>>> does 
>>>>>>> not finish within 4 sec, it interrupts it. before doing anything else.
>>>>>>>
>>>>>>> But yes, I can create a simple IOIOActivity and only run 
>>>>>>> GetFrequency in main looper thread and do nothing else if you would 
>>>>>>> like. 
>>>>>>> While running this test, do you want me to enable any extra prints or 
>>>>>>> anything else?
>>>>>>>
>>>>>>> Kind Regards
>>>>>>> Thomas
>>>>>>>
>>>>>>> Den torsdagen den 21:e november 2013 kl. 05:52:37 UTC+1 skrev Ytai:
>>>>>>>>
>>>>>>>> The signal looks perfect indeed.
>>>>>>>> I understand that your app does multiple things concurrently. Can 
>>>>>>>> you try to isolate the problem into a simple-as-possible app that 
>>>>>>>> exhibits 
>>>>>>>> the problem?
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Nov 20, 2013 at 12:13 PM, Thomas Hermansson <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> Ok!
>>>>>>>>>
>>>>>>>>> Then I guess simple .bmp:s are good. I attached 4 different 
>>>>>>>>> samplings. It hasn´t been very much wind here the past days. :)
>>>>>>>>>
>>>>>>>>> Kind Regards
>>>>>>>>> Thomas
>>>>>>>>>
>>>>>>>>> Den tisdagen den 19:e november 2013 kl. 05:37:19 UTC+1 skrev Ytai:
>>>>>>>>>>
>>>>>>>>>> What I wanted was to verify that the input to the pin is indeed 
>>>>>>>>>> what you expect it to be, i.e. not noisy or glitchy.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Nov 18, 2013 at 2:23 AM, Thomas Hermansson <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>> I will capture it and post it here.
>>>>>>>>>>>
>>>>>>>>>>> What exactly do you want? My oscilloscope can capture up to 1000 
>>>>>>>>>>> frames and save it. Will you use it and somehow replay it, or do 
>>>>>>>>>>> you just 
>>>>>>>>>>> want to check how noisy the output of my signal is?
>>>>>>>>>>>
>>>>>>>>>>> I'll create a 1000 frames captured with 1 second delay in 
>>>>>>>>>>> between when I get home today unless I hear some other request.
>>>>>>>>>>>
>>>>>>>>>>> //Thomas
>>>>>>>>>>>
>>>>>>>>>>> Den söndagen den 17:e november 2013 kl. 18:44:33 UTC+1 skrev 
>>>>>>>>>>> Ytai:
>>>>>>>>>>>>
>>>>>>>>>>>> Do you have a scope capture of the input?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Nov 17, 2013 at 7:31 AM, Thomas Hermansson <
>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Yes I´m an idiot :-) I got carried away as it fitted my bug 
>>>>>>>>>>>>> description.
>>>>>>>>>>>>>
>>>>>>>>>>>>> How ever as the quest continues and I evaluate an try to use 
>>>>>>>>>>>>> PulseMode.FREQ_SCALE_16 and PulseMode.FREQ_SCALE_4 I find that I 
>>>>>>>>>>>>> get values 
>>>>>>>>>>>>> that are to high, at least 4-5 times. According to the 
>>>>>>>>>>>>> documentation it 
>>>>>>>>>>>>> clearly states that GetFrequency should return the actual 
>>>>>>>>>>>>> frequency so that 
>>>>>>>>>>>>> the enduser should not have to divide by 4 or 16. However I get 
>>>>>>>>>>>>> significant 
>>>>>>>>>>>>> differences.
>>>>>>>>>>>>> And if running FREQ_SCALE_16 and dividing the result with 16 
>>>>>>>>>>>>> it is far too low. (I verify this by instantly running the same 
>>>>>>>>>>>>> code with 
>>>>>>>>>>>>> PulseMode.FREQ set and also verifying it with the oscilloscope 
>>>>>>>>>>>>> running). As 
>>>>>>>>>>>>> you have written in the documentation that it should return the 
>>>>>>>>>>>>> correct 
>>>>>>>>>>>>> result, I get more and more confused. :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> I wanted to use the FREQ_SCALE_16 to average out that IOIO 
>>>>>>>>>>>>> getFrequency sometimes return values that are 5-10 times as high 
>>>>>>>>>>>>> as it is. 
>>>>>>>>>>>>> If you check 
>>>>>>>>>>>>> www.surfvind.se<http://www.google.com/url?q=http%3A%2F%2Fwww.surfvind.se&sa=D&sntz=1&usg=AFQjCNHHR9yiT1zM66kDd5qHyE5Zv3RxFw>and
>>>>>>>>>>>>>  select the XDevelopementSamsung sensor which runs on IOIO, then 
>>>>>>>>>>>>> watch 
>>>>>>>>>>>>> the chart you will see that the max-wind shows a signigicantly 
>>>>>>>>>>>>> larger value 
>>>>>>>>>>>>> - and today there is very little wind outside - 2-3m/s, so 
>>>>>>>>>>>>> windgusts at 
>>>>>>>>>>>>> 15-20 is not likely to happen. 
>>>>>>>>>>>>>
>>>>>>>>>>>>> Have you run IOIO and getFrequency for a longer time and 
>>>>>>>>>>>>> verify the output? Or are there any other users here that have 
>>>>>>>>>>>>> used IOIO 
>>>>>>>>>>>>> and getFrequency that may have seen this problem too?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Spec spec = new Spec(ANEMOMETER_SPEED);
>>>>>>>>>>>>> spec.mode = Mode.PULL_UP;
>>>>>>>>>>>>> pulseCounter = ioio.openPulseInput(spec, ClockRate.RATE_16MHz,
>>>>>>>>>>>>> PulseMode.FREQ_SCALE_16, true);
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Kind Regards
>>>>>>>>>>>>> Thomas
>>>>>>>>>>>>>
>>>>>>>>>>>>> Den fredagen den 15:e november 2013 kl. 03:12:51 UTC+1 skrev 
>>>>>>>>>>>>> Ytai:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think you misunderstand how Java monitors work. A call to 
>>>>>>>>>>>>>> wait() removed the lock. I don't think there's a deadlock here.
>>>>>>>>>>>>>> Disconnect or hardReset() may save you here, depending on 
>>>>>>>>>>>>>> what the problem is.
>>>>>>>>>>>>>> Basically, I wouldn't use Bluetooth for something that needs 
>>>>>>>>>>>>>> to be super reliable for a long time. You can also try a 
>>>>>>>>>>>>>> different dongle 
>>>>>>>>>>>>>> and see if it changes anything.
>>>>>>>>>>>>>> I think you're barking at the wrong tree - this is either a 
>>>>>>>>>>>>>> firmware failure (which might have been fixed already, but not 
>>>>>>>>>>>>>> yet 
>>>>>>>>>>>>>> released), or a Bluetooth related issue, which will be much 
>>>>>>>>>>>>>> trickier to 
>>>>>>>>>>>>>> diagnose.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Nov 14, 2013 at 1:47 PM, Thomas Hermansson <
>>>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sorry for the spamming, but I see the same problem in 
>>>>>>>>>>>>>>> AnalogInput, and I guess it will be found in all other API:s 
>>>>>>>>>>>>>>> too.
>>>>>>>>>>>>>>> I´m not convinced that the occurance of this in AnalogInput 
>>>>>>>>>>>>>>> would cause my AnalogReadings to sometimes display the same old 
>>>>>>>>>>>>>>> value all 
>>>>>>>>>>>>>>> the  time, but I´ll continue debug for a while. :-)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> //T
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Den torsdagen den 14:e november 2013 kl. 22:38:46 UTC+1 
>>>>>>>>>>>>>>> skrev Thomas Hermansson:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I´m of course talking about IncapImpl.java.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Den torsdagen den 14:e november 2013 kl. 22:37:56 UTC+1 
>>>>>>>>>>>>>>>> skrev Thomas Hermansson:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi again!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Now I´m quite sure that I have found why GetFrequency or 
>>>>>>>>>>>>>>>>> GetDuration blocks forever when pulses come very slow. It is 
>>>>>>>>>>>>>>>>> due to that 
>>>>>>>>>>>>>>>>> both getDuration and dataReceived are synchronized. When 
>>>>>>>>>>>>>>>>> using my old 
>>>>>>>>>>>>>>>>> approach where I open and close the pin for every reading, 
>>>>>>>>>>>>>>>>> and instantly 
>>>>>>>>>>>>>>>>> later calling getFrequency, then valid_ will be false and we 
>>>>>>>>>>>>>>>>> are waiting 
>>>>>>>>>>>>>>>>> until it gets set. However, as getDuration has a lock, no 
>>>>>>>>>>>>>>>>> other 
>>>>>>>>>>>>>>>>> synchronized function will be possible to be called in this 
>>>>>>>>>>>>>>>>> class, before 
>>>>>>>>>>>>>>>>> this one ends....so dataReceived will never be allowed to run.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think the simplest solution is just to remove 
>>>>>>>>>>>>>>>>> synchronized from getDuration due to that:
>>>>>>>>>>>>>>>>> checkstate is synchronized and if last duration is updated 
>>>>>>>>>>>>>>>>> it is really doesn´t matter.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What do you think about this?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> @Override
>>>>>>>>>>>>>>>>> public float getDuration() throws InterruptedException,
>>>>>>>>>>>>>>>>> ConnectionLostException {
>>>>>>>>>>>>>>>>>  checkState();
>>>>>>>>>>>>>>>>> while (!valid_) {
>>>>>>>>>>>>>>>>> wait();
>>>>>>>>>>>>>>>>> checkState();
>>>>>>>>>>>>>>>>>  }
>>>>>>>>>>>>>>>>> return timeBase_ * lastDuration_;
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  Kind Regards
>>>>>>>>>>>>>>>>> Thomas
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>  -- 
>>>>>>>>>>>>>>> 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/grou
>>>>>>>>>>>>>>> ps/opt_out.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  -- 
>>>>>>>>>>>>> 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/grou
>>>>>>>>>>>>> ps/opt_out.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  -- 
>>>>>>>>>>> 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/groups/opt_out
>>>>>>>>>>> .
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  -- 
>>>>>>>>> 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/groups/opt_out.
>>>>>>>>>
>>>>>>>>
>>>>>>>>  -- 
>>>>> 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/groups/opt_out.
>>>>>
>>>>
>>>>  -- 
>> 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/groups/opt_out.
>>
>
>

-- 
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/groups/opt_out.

Reply via email to