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]<javascript:>
> > 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] <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