On Wed, Dec 18, 2013 at 10:05 AM, Thomas Hermansson < [email protected]> wrote:
> 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? > Not hard at all, change it if you want. > > 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? > Just use getDuration() > > 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] >> > 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/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]. > 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.
