Long Term Photon Connection Stability

I was wondering if anybody else has been experiencing stability problems with the connectivity of their Photons. I have noticed that my Photons cannot connect to the cloud after some time (> 6-12 hours).

The Wifi signal in my office is not very strong and thus I notice the Photon blinking green and then cyan occassionally throughout the day. However, I have left my Photons running overnight for the past two days and have noticed some issues. My Photons are programmed to update my server with data every 10 seconds. Thus, I can remotely see if the Photons are online and posting data to my server. For the past two nights the data stream has stopped sometime overnight. Also, when I return to the office in the morning the Photons are in an endless loop trying to connect to the cloud (lots of blinking green and cyan but no “breathing cyan”). As soon as I press the reset button once the Photon can connect to wifi and the cloud.

I am running the release/photon_043 firmware on my Photons. I am running in SEMI_AUTOMATIC mode with some reconnection code running in my main loop. Additionally I am seeing some strange behavior when the Photon loses connection during the day when I am in the office. Sometimes I see the LED flashing green and the cyan without interruption to my connected peripherals. However, sometimes I see flashing red and I see that my code is restarting from the Setup function when the connection to the cloud is lost. I am confused by this behavior as the Photon is behaving as though it has been reset.

I would ideally like for my code to never reset to the setup() function while running. Also, I need the system to handle periodic wifi/cloud disconnections gracefully. I have tried to follow the prior postings regarding SEMI_AUTOMATIC mode but am still experiencing these issues.

5 Likes

I too have noticed photons (running 0.4.3) reverting to flashing cyan and no longer communicating with the cloud.

I plan to break out wireshark to get a handle on the behaviour. I will update when I have more info, but it might be a few days.

6 Likes

@AndyW Oh, good idea on the wireshark. I will try to find a time when the Photon is having communication problems and catch some packets. I use wireshark a lot to check our BLE packets but haven’t tried this on Wifi.

Good ideas! I wonder if an antenna upgrade might help as well, you mentioned the signal strength wasn’t awesome, I ordered a pack of these recently and they seem to be doing okay (probably overkill though):

-> giant 9 dBi antennas with u.fl adapters

http://www.amazon.com/Super-Power-Supply%C2%AE-WHR-300HP2D-WZR-1750DHPD/dp/B00QU4M3WS

Thanks,
David

Yes, I’ve been tempted to buy some of these with u.fl adapters:
https://item.taobao.com/item.htm?spm=a230r.1.14.8.E5BwJf&id=35325172019&ns=1&abbucket=13#detail

However, this has been a good experiment to see the Photon in a less-than-ideal Wifi environment. Undoubtedly some of my customers will have similar setups where they will be using the product. I have not experienced so many problems when testing the boards at home where I have good Wifi coverage. My biggest concern is why the Photon seems to get into a state where it can no longer reconnect to the network (even though I can press reset and regain connectivity right away).

1 Like

Hi,

I have also experienced these stability issues. What I am doing right now is pinging a certain address regularly. If the ping fails for 30 times, I issue a reset. With that I have been able to run it for days. In the mode I use it right now, this is fine. However having the long term stability would of course be much better.

Note that my Wifi connection is really strong, so I do not believe that this is an issue of a failing Wifi connection.

3 Likes

That’s good to know. Please do let us know if you do get wireshark captures, or have more context about any connection instability on the photon vs. the core. There’s no reason why they shouldn’t both be very robust.

Thanks!
David

My issue is not going to be wifi signal strength. I had 2 photons running different sketches and off different power supplies that were both stuck in this mode earlier this week, I suspect it may be an ISP induced condition.

2 Likes

I thought I’d just chip in here too and say that neither of my photons (0.4.3 firmware) will last the night connected to WiFi. (In the same room as the router).
They are pretty much straight out of the box, just running the tinker app too. In the morning they are always just flashing cyan, and won’t connect until reset. (Admittedly they do re-connect promptly when reset).
I am on satellite internet with ping sometimes exceeding 1 second, however if this is contributing to the effect then I think the firmware needs to be more robust as I can see many applications for these devices where connection speed/ping may not be optimal (rural weather stations etc.)
(As I’m sure many people are) I’m developing hardware based on this platform to be rolled out to customers, I’m hoping that an update in the near future will prevent the need for constant resetting.@Stevie seems to have found a temporary fix perhaps but I don’t think this is acceptable in the long term.

2 Likes

I had the same problem, exacerbated whenever I used my microwave. Once I changed some router settings as below, I haven’t lost connection for days now. Obviously, it’s not a real fix for the long run but may help pinpoint what about the firmware is flawed:

1 Like

Hi bpr, at risk of offending some of the software purists, I’ve adapted a version of your code that attempts reconnection ten times, then sends a pin HIGH that switches on a transistor (FET) which shorts the Photon reset pin to GND, effectively pushing the button to reset the unit. I have had about eight resets in the last 24 hours, but a 100% recovery rate. I’ll give it another day or so and post the code and a diagram of the cct. I’m sure that the Particle guys and community will sort this flashing blue lockup out but I need to deploy next Tuesday in a pilot site - desperate times…

1 Like

@DRCO , Yea, I’m hoping for a firmware fix soon, but can’t you just use System.reset(); instead of the FET? Again, only as a temporary fix?

Yes, that was the first option - software is way easier. But there was some debate about how System reset(); works - and how long before we could get a rapid blue flashing event to occur. I made an executive decision, spent the 40 cents, soldered the thing up and had it under test in an hour. As mentioned, I’m on deadline. Interesting point, this afternoon I has some sort of problem, possibly with my ISP - the Photon went into a cycle of logging on and off for about 40 minutes before finally finding the network again (breathing cyan). During this time I could not open pages from particle.io, community or dashboard. Now I cant imagine the device op’s network is on the same servers but spooky…

I will definitely try System reset(); on another device and prototype rig.

1 Like

We seem to have a lot of “quick fixes” here with System resets but I am wondering if anybody has any insight into the root cause of this issue. Yes, we can recover the system by hard resetting the Photon, but this is hardly ideal for a production product. I am at the point of having to pull all system functions off of the Photon and having to put them on a separate microcontroller. We run normal microcontrollers for months and months without resets. I cannot imagine our product having unresponsive periods when either the cloud is unreachable or the main loop is blocked by a connect function. Additionally I don’t know why the Photon is resetting from the setup() function multiple times throughout the day.

Some updates regarding my testing:
I tested the Photon on another network today that has previously caused some problems. Despite all phones and laptops being able to easily connect to the Wifi network and send and receive data, the Photon gets stuck at flashing green or cyan repeatedly. After some time of trying to connect it will eventually start flashing red before resetting. Also, I cannot see the Photon calling any of the webhooks. At this point I firmly think that the Photon has some problems connecting to certain networks with particular settings. Some Wifi networks I use work flawlessly and others have nothing but trouble. I do not think this is an issue of signal strength. Also, on the “problem” networks I have observed the Photon switching to flashing mode or red LED mode when it tries to send a publish command to a web hook or I try to send a curl.

I am really hoping that somebody has some idea about what is causing this issue and how we can work towards a resolution.

5 Likes

I agree that the short term reset fix is not a solution - and that for any commercial application we need one. It has got to be a firmware issue - maybe @Dave or @mdma could let us know if this instability problem with Photon is on the agenda at Particle?

1 Like

I have hacked together two small scripts to test my Photons long term connectivity.
For the first try I went with really basic networking not actively using cloud functions (though my Photon
is connected to the cloud).
I’m running this code on the photon (change the IP to the system running the python code):
http://pastebin.com/eqh7YK84
and this Python 3 script on my Raspberry Pi but any other computer running Python would do:
http://pastebin.com/pcm0q4De

All the Photon does is send a counter to the Raspberry Pi via UDP every 20 seconds, from that the Pi calculates
the uptime of the Photon and counts missed packets. My Photon has been running fine for almost 10 hours at the moment but I just added the missed packets functionality so I don’t have a count on that yet.
Maybe some of the people having problems with resets could try this as well and maybe we can then also add cloud function calls or publish if this bare version runs fine.

Just an update on my hardware reset solution - sorry to say it’s a failure. It ran for about a day and a half then died and reverted to the dreaded flashing cyan, I am now out of ideas and resources - so I,ll be using a spark core for my pilot and pursuing other platforms for the production version. Thanks to @bpr, @kennethlimcp.

Hi

I am running trials on my systems remote in a hotel. I get zero disconnects in the day running 7am to 10 pm. The system shuts down overnight and restarts the next morning. This has been running almost two weeks without failure since I got my Photons.
The only thing I was careful to do was make sure my code is non blocking. I don’t use any higher level libraries. I use simulated EEPROM code spark publish, function and variable. I publish at a variable rate but usually around once per 110 seconds.
I just wanted to offer that the systems can be successful for long term connections and tell you the steps I took. I will work on 24 hour trials soon.

Best regards
Clive

2 Likes

Add one more user with the Photon losing wifi connection, after switching power supplies to rule that out I still drop connection. Photon located across the room from router, so I don’t think its a lack of signal problem.
I have taken note of the antenna posts as I to need to boot my signal, my first intended use was for a snail-mail mailbox monitor. Distance is about 100 ft, but no-go on the chip antenna.

Curiously enough, after not changing any settings on my router, (although I did power cycle it). Both of my photons have been connected for about 2 days now, I haven’t even seen them temporarily disconnect from the cloud (although I obviously haven’t been watching them the whole time).
This is after they previously had been disconnecting temporarily (flashing magneta and then reconnecting about once every 10 or 15 minutes, and permanently disconnecting when left any longer than 4-5 hours.

One of them is running tinker and the other one just the flashing LED example.

Although this is good in a way, still not conclusive why they are working reliably now but weren’t before. Would be great if someone from the dev team could let us know that this issue is under consideration.

No amount of additional features can offset the inconvenience of asking customers to reset their devices, so I think we need to get the basics right first…