Sorry, I sometimes tend to lose context in these discussions and/or forget some little details of the API :) Looking at the code again, I see that I haven't added support for blocking in frequency mode. I don't remember what was the reasoning behind this, but this should be very easy to fix (basically just removing the Exception throwing should suffice I guess).
On Thu, Dec 19, 2013 at 5:46 AM, Thomas Hermansson < [email protected]> wrote: > Hi ytai! > > In your last post you told me > > "This is the intended behavior. If you want distinct pulses, you should > call waitPulseGetFrequency()." > > //Thomas > > > Den torsdagen den 19:e december 2013 kl. 04:32:23 UTC+1 skrev Ytai: > >> 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/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.
