Re: Temperature rating of IoIo Board

[P.S]

Dear Ytai and All,
We were choosing http://www.mouser.com/ds/2/96/008-0256-0-786323.pdf to be 
used as an external oscillator.
Any comments or suggestions?
Best Regards

On Friday, 9 December 2016 05:00:57 UTC+5:30, Ytai wrote:
>
> No special tips. Just make sure every component you use is rated for this 
> range and that its critical parameters within the desired range across the 
> temperature range you want to support.
>
> On Dec 7, 2016 11:55 PM, "P.S" <m...@pranays.com > wrote:
>
>> Dear Ytai,
>> I will be starting to make a version of IOIO with Crystal and opensource 
>> it. Any tips with respect to hardware/software design so that the board can 
>> withstand higher ambient temperature?
>>
>> Thanks in advance
>>
>>
>> On Saturday, 9 July 2016 01:00:24 UTC+5:30, Ytai wrote:
>>>
>>> The table titled "internal RC accuracy" in the datasheet specifies a 
>>> typical 0.15% deviation, but a worst case 1% across the temperature range. 
>>> USB's nominal requirement is 0.25%. So if you want to be 100% certain you'd 
>>> need to add a crystal to the circuit (and make a configuration flag change 
>>> in the bootloader). Otherwise, you can characterize it yourself and see how 
>>> bad it actually gets.
>>>
>>> On Fri, Jul 8, 2016 at 5:18 PM, Pranay Sharma <pra...@tollmequick.com> 
>>> wrote:
>>>
>>>> HI Ytai,
>>>> I checked the data sheet of the PIC micro used in IOIO board but I am 
>>>> not able to figure out which graph to see to understand the oscillators 
>>>> behaviour to temprature changes.
>>>> Further, is there a link to exact BOM of the parts used for IOIO with 
>>>> exact part names? 
>>>> Thanks for your time
>>>>
>>>> On Friday, July 8, 2016 at 6:56:40 AM UTC+5:30, Ytai wrote:
>>>>>
>>>>> I haven't done any work to characterize the temperature range or 
>>>>> design for a specific one. You'd have to do that be checking the 
>>>>> datasheets 
>>>>> of the individual parts. I'm assuming that 85C should be safe for most if 
>>>>> not all parts. Another thing you'd need to evaluate is how stable the 
>>>>> internal oscillator of the PIC is across the temperature range. USB is 
>>>>> pretty picky about the precision of its clock.
>>>>>
>>>>> On Wed, Jul 6, 2016 at 12:59 PM, Pranay Sharma <pra...@tollmequick.com
>>>>> > wrote:
>>>>>
>>>>>> Dear ALL,
>>>>>> Could someone put some light on what are the temperature ranges for 
>>>>>> proper operation of the IOIO board.
>>>>>>
>>>>>> I was thinking to use this board for a product which would be put 
>>>>>> outdoors where maximum temperature in summers is 45Deg Celcius.
>>>>>> So the expected temperature inside the board could easily reach 55deg 
>>>>>> or 60Deg.
>>>>>>
>>>>>> BR
>>>>>> Pranay
>>>>>>
>>>>>> -- 
>>>>>> 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 ioio-users+...@googlegroups.com.
>>>>>> To post to this group, send email to ioio-...@googlegroups.com.
>>>>>> 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 ioio-users+...@googlegroups.com.
>>>> To post to this group, send email to ioio-...@googlegroups.com.
>>>> 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 ioio-users+...@googlegroups.com .
>> To post to this group, send email to ioio-...@googlegroups.com 
>> .
>> 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 ioio-users+unsubscr...@googlegroups.com.
To post to this group, send email to ioio-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ioio-users.
For more options, visit https://groups.google.com/d/optout.

Re: Temperature rating of IoIo Board

[P.S]

Dear Ytai,
I will be starting to make a version of IOIO with Crystal and opensource 
it. Any tips with respect to hardware/software design so that the board can 
withstand higher ambient temperature?

Thanks in advance


On Saturday, 9 July 2016 01:00:24 UTC+5:30, Ytai wrote:
>
> The table titled "internal RC accuracy" in the datasheet specifies a 
> typical 0.15% deviation, but a worst case 1% across the temperature range. 
> USB's nominal requirement is 0.25%. So if you want to be 100% certain you'd 
> need to add a crystal to the circuit (and make a configuration flag change 
> in the bootloader). Otherwise, you can characterize it yourself and see how 
> bad it actually gets.
>
> On Fri, Jul 8, 2016 at 5:18 PM, Pranay Sharma  > wrote:
>
>> HI Ytai,
>> I checked the data sheet of the PIC micro used in IOIO board but I am not 
>> able to figure out which graph to see to understand the oscillators 
>> behaviour to temprature changes.
>> Further, is there a link to exact BOM of the parts used for IOIO with 
>> exact part names? 
>> Thanks for your time
>>
>> On Friday, July 8, 2016 at 6:56:40 AM UTC+5:30, Ytai wrote:
>>>
>>> I haven't done any work to characterize the temperature range or design 
>>> for a specific one. You'd have to do that be checking the datasheets of the 
>>> individual parts. I'm assuming that 85C should be safe for most if not all 
>>> parts. Another thing you'd need to evaluate is how stable the internal 
>>> oscillator of the PIC is across the temperature range. USB is pretty picky 
>>> about the precision of its clock.
>>>
>>> On Wed, Jul 6, 2016 at 12:59 PM, Pranay Sharma  
>>> wrote:
>>>
 Dear ALL,
 Could someone put some light on what are the temperature ranges for 
 proper operation of the IOIO board.

 I was thinking to use this board for a product which would be put 
 outdoors where maximum temperature in summers is 45Deg Celcius.
 So the expected temperature inside the board could easily reach 55deg 
 or 60Deg.

 BR
 Pranay

 -- 
 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 ioio-users+...@googlegroups.com.
 To post to this group, send email to ioio-...@googlegroups.com.
 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 ioio-users+...@googlegroups.com .
>> To post to this group, send email to ioio-...@googlegroups.com 
>> .
>> 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 ioio-users+unsubscr...@googlegroups.com.
To post to this group, send email to ioio-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ioio-users.
For more options, visit https://groups.google.com/d/optout.

Re: Frequent disconnect()/setup() in IOIO Service

[P.S]

Hi Kevin,
I have been facing similar issues.
1. I tried the code similar to the one you posted on Github. It seems to 
lower down the disconnects if I read from UART in one thread and process 
the read data on another thread.
2. At times I saw that whenever the stream got closed IOIO was still 
connected. Its just that the stream somehow got closed. You can test it 
with a TRY/Catch. A BRUTE solution I am using is to restart the thread in 
this situation which is reading the UART. So In the Main service setup() I 
start all the threads. Then in loop() function I Check if all the threads 
reading UART and IO's are alive. If any of them is dead due to an exception 
but IOIO is still connected I re-init the thread.
THis seems to reduce the number of times the system used to die.

YTai: I have 7-8 IOIO's working with 2-3 different makes of Bluetooth 
dongles. But it seems the disconnection still happens atleast 3-4 times 
each day(my systems run 24x7). The flow for disconnections is similar to 
what Kevin shared. You talked about Calibrating the Oscillators could you 
share the link or give pointers where to search?
PS

On Monday, 5 December 2016 12:42:04 UTC+5:30, Kevin Miller wrote:
>
> On the log, the first highlighted lines, #921 - 924, say "IOIO 
> disconnected, Physical disconnect, and V/BluetoothIOIOConnection: Client 
> initiated disconnect" . That's not evidence of a disconnect? I don't know a 
> lot about the very low-level stuff, so perhaps I'd made some incorrect 
> assumptions.
>
> I will include the methods that catch (sometimes just before _flush() is 
> called and sometimes in _flush(), as this LogCat shows) the 
> "java.io.IOException: Stream has been closed", but a couple notes on the 
> Logcat:
>
>- Note: When I debug and single-step - it does not fail.
>- The IOIOService is on a separate thread from the main thread. 
>- The LogCat messages with the S2Handler.* tag are from the 
>IOIOService.
>- The device handler is on another thread, and its Logcat tags are 
>RpLidar.*
>- The IOIO Service loop calls RpLidar.connect(UART uart) via a 
>messenger and passes a reference to the Uart configured in the IOIOService 
>setup()
>- The RpLidar.connect sends a reset command to the Lidar and 
>receives some ASCII info from the Lidar such as serial number, etc.
>- So far, so good.
>- At about this point, the "IOIODisconnected" message is thrown, line 
>921 on LogCat
>- It looks like the IOIO disconnected while receiving the data because 
>there's only 20 bytes available when normally it's 57  (line 941)
>- In reset(), available() returns 20 just before _flush() is called. 
>Sometimes, a NullPointer Exception is thrown on the 
> InputStream.available() 
>here.
>- In this LogCat, the error is in _flush().
>- Inside _flush() InputStream.available() and InputStream.read()are 
> called from the same try block and IOException "Stream has been closed" 
> is 
>thrown. (line 942)
>
> Here is the flush method:
>
> private void _flushInput()
> {
> String TAG = "RpLidar._flushInput";
>
> final int arrSize = 1000;   // assume no more than this many characters 
> in response
> byte[] readBuffer = new byte[arrSize];
>
> try
> {
> while( _inputStream.available() > 0 )
> _inputStream.read( readBuffer );
> } catch (IOException e) {
> e.printStackTrace();
> Log.d(TAG,e.getLocalizedMessage()); //line 956 in LogCat
> }
> }
>
>
> Here is the reset() method that calls _flush(). It's go a lot of waits and 
> sleeps and yields because of troubleshooting in progress:
>
> /**
>  * Reset(reboot) the RPLIDAR core
>  * No response is defined in documentation, but testing shows some text 
> is returned 
>  * and is flushed - See comments for details.
>  * @return true if command was placed in queue
>  */
> public synchronized boolean reset(){
> String TAG = "RpLidar.reset";
> Log.d(TAG, "Starting...");
>
> //make sure IOIO is connected
> if(!isOpen()) return false;
>
> RplRequest req = getRplRequest(RequestTypes.RESET);
> if(req==null){
> Log.d(TAG,"FAIL: req = null");
> return false;
> }
>
> if (!doRplRequest(req)) {
> Log.d(TAG,"FAIL: doRplRequest failed");
> return false;
> }
>
> //troubleshooting
> //long timeoutMs = System.currentTimeMillis()+1000;
> //while (System.currentTimeMillis() < timeoutMs){
> //Thread.yield();
> //}
>
> try {
> Thread.sleep(1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> Log.d(TAG,"FAIL: Sleep interrupted");
> return false;
> }
>
> Log.d(TAG,"Before flush...");
> try {
> Log.d(TAG,"... inputStream.avail = "+_inputStream.available());
>