I've been running the pre-release v6.3.0 Dev OS since I came across this now closed thread which described connectivity issues in v5.8.2:
It had been running flawlessly until yesterday here on my bench when I discovered my device was stuck in the "Could not reach Internet" state:
All my other mobile devices and laptops here on this same LAN were connected and operational, yet the Photon2 was unable to "phone home" and was offline. I'm running in Automatic Mode with a dedicated System Thread, and I validated all my application threads were operational and running.
I'm wondering if I should be procedurally invoking Particle.connnected() to perform some type of intervention for this issue, or if there was another course of preemptive action to mitigate this condition. We're getting ready to deploy Photon2's into the wild and having this potential connectivity failure is not an option.
Are you logging data over serial semi-frequently? I've noticed that even on 6.3.0, if I'm logging something with any frequency (a 50 character log every second) it sometimes will disconnect and have trouble reconnecting until I restart the device. When I remove the repeating logs, the issue goes away. I didn't make a thread about it since I'm told logging will be improved in the next OS release.
Thanks @jettonj, and yes I'm indeed running extremely active serial IO on all 3 ports:
Serial 1 = 9600 bps ISM Radio logging to another on-prem NuC device
Serial 2 = 115.2k bps Class 1 BT Radio for long range Bluetooth connection to mobile devices
Serial 3 = 57.6k bps continuous RS-485 polling to a network of UHF readers
All (3) of these ports are running the SerialBufferRK library to mange the asynchronous data flow that we're dealing with. We're also running TCP Socket communications to a CAN Controller that's interconnected to a network of flow and conductivity sensors.
Not running our data streams isn't feasible, so I'm looking for intervening methods and/or preemptive suggestions until there's an official release.
The SerialBufferRK library is not recommended as you can just increase the size of the buffer for Serial1.
NOTE: You should not use this library! In Device OS 3.3.1 you can use acquireSerial1Buffer to just change the size of the hardware buffer. This is more efficient and eliminates issues where the worker thread cannot empty the serial buffer fast enough, which can occur at high baud rates.
Can you share the log output for when it fails to connect?
Well OK then, good to know... We've been leveraging that library with success so far and haven't experienced a case that we've experienced any noticeable failure (we're fully asynch and able to stitch together serial packet data across multiple reads). More efficiency is a good thing, so I'll go ahead and deprecate that library usage.
When it comes to log data, however, we're not pumping out any system content as we've commandeered that ISM serial link for optimizing read algorithm results to refine our reading strategies.
This hang-up has only occurred once over the course of months that I've ever noticed, and if there's procedural work arounds to circumvent this I'm ready to drop in code.