My Photons are experiencing inconsistent Wi-Fi connection behavior

Troubleshooting
1

Dear Particle team,

First of all, you have a pretty cool product and make a great impression as a company.
Your documentation is overall pretty good and makes it very easy for beginners to start.
To sum it up, we were very excited to start with your products and had a great user experience in the beginning.

However, the last two months were very frustrating for us since we ran into major Wi-Fi issues with the photon.
We spend an unpleasant amount of time and money dealing with a problem that shouldn’t occur and was delaying our progress significantly.

To make it short nearly all the photons we bought have some kind of major Wi-Fi problem, mostly regarding significant drops in range and the complete absence of reliability.
Some of them couldn’t connect to an iPad or notebook for setup.
Some of them had very bad Wi-Fi range out of the box (5m -7m line of sight) and the most frustrating ones showed these kind of drops only after one or two weeks operating.
These problems make it almost impossible for us to properly develop a product.
We must check every day if another photon failed or not, fix something and we have additional problems with our cloud and data handling, where everything is done via device ID and is a lot of unnecessary work, if you to have to replace failed photons over and over.
And the worst of all, we can’t test our product with users with these kinds of problems.

Regarding any details about the problem or how we tried to fix it, we already sent you several mails. For the external readers: We bought external antennas, they helped for a short amount of time, but the problem happened all over again after one week working. We investigated power supply problems. To check this, we tested the Sparkfun Power Shield and the Particle Power Shield. Didn’t change much. We checked the hardware for damages, tested it without any enclosure and with different Wi-Fi networks in different locations. To make it short we followed all the advice Rick (great support from him!!!) gave us but sadly nothing solved the problem.

Until then we were just frustrated, but confident, that we could solve the problem together with you. We understood it might take some time to find a solution and we thought this was just a minor software/firmware problem occurring with us. Again, customer support was (Rick) great.

Unfortunately, the support couldn’t help us and said problems are bigger and beyond their scope. This was also our impression, since over 10+ photons from several loads we bought meanwhile showed these problems.

This was a big bummer and destroyed a lot of confidence in your product and its reliability.

But most disappointing was the lack of response from Particle.
We are customers with an immense problem with a core function of your product where to cite your General Manger your “platform usually shines” and we should “reach out to [your] Customer Support team” if we have any problems with it. https://community.particle.io/t/the-most-frustrating-dev-board-ever/30183/3 @will
However, from the point, when it was clear that the problem was bigger, none of your engineers showed interested in this problem or contacted us or anyone else from Particle replied to us, although we offered you to send some of the problematic photons for further investigation by your engineers and told you that we need a solution urgently.

Hopefully, this public statement gets your attention, in order to help us with this problem.
We would very much appreciate an answer and support from your engineers to solve this so we can continue our product development and use your otherwise great platform.

Best regards,

Sebastian

2

Hey Sebastian,

It sounds to me like the connection issues you’ve been experiencing are a result of hardware integration into a custom circuit board, and require either firmware code reviews and/or a knowledgable electrical engineer to do a hardware review.

Our customer support team is here to help with basic issues. Some examples:

  • If your new, out of box Photon with stock firmware fails to connect to a Wi-Fi network because it’s antenna has been damaged in shipment, we can help you troubleshoot your device and process a replacement.
  • If your Photon development kit is stuck flashing green, we can point you to resources that will help you get the device connected, and can suggest some of the most successful troubleshooting steps or point you to tools that can help.

Our Customer support team is not able to help with:

  • Firmware reviews for custom user or product applications
  • Electrical design reviews to identify sources of RF interference, etc.

As was recently discussed in this thread, there are many reasons a device might struggle to connect to Wi-Fi, and it’s rare that the root cause is Particle’s infrastructure.

For just that reason, we have an internal Customer Success team who can do firmware and hardware design reviews at reasonable engineering rates. If you’d like to take advantage of those paid services, I’m happy to connect you.

If your Photon is behaving strangely when used with a Particle accessory (Power shield), our customer support team and awesome community will be able to help you debug. When it comes to a custom product, however, there are too many complicating variables for us to understand without charging for the time it would take to assist in resolving the issue.

4 Likes
3

It sounds like you’ve received responses from Particle, but that we’re unable to continue helping with our free support resources.

Given that I’m inviting you to continue troubleshooting your connection issues with your stock Photon PCBs (not integrated in a product) here in the community and with our customer support team, I’m going to change the title of your post to reflect that you’re receiving support within the scope of our free support tier that we make available to all developers.

2 Likes
4

Hi Will,

Thanks for your fast response. I appreciate that.

I am sorry if haven’t mentioned some points more clearly enough and was only referring to our e-mails conversation with the support. This might have caused some misunderstanding.

Currently, we are using normal photons, no custom PCB boards.

Also, we did really spend a lot of time not only trying to fix the problems but also to make sure, that nothing we do causes the problems.
Otherwise, I wouldn’t have written this and post this in your forum with the old topic.

We already talked to your free customer support and followed all their advice until they said that the problems are beyond what they can resolve in support.

We also posted in the community. Unfortunately, they couldn’t help us either. Sudden troubles with wifi strength and connecting to the cloud

In addition to the points I mentioned in the last post, we brought brand new photons just to check if they had the problems. We checked the antennas for damages and used external antennas which had the same problems. We used your different firmware versions and used your blink led stock app to make sure that our code wasn’t the problem. We measured the Wi-Fi strength with the WiFi.RSSI() function. There we saw big differences between individual photons in exactly the same spot but also big fluctuations over time with the same photon.
To make sure that none of the accessories is causing the problems we checked different power supplies and USB cables.
Of course, everything without any hardware connected to the photon or any enclosures might blocking the signal.
And we even bought photons from different load/charges to make sure that we were just unlucky and got a few bad devices.

And then there is this strange thing that working photons suddenly start to have connections and Wi-Fi range problems after one or two weeks (in one case even after a day, suddenly stopped working) without any environmental changes or any code/hardware changes happened at this time. Sometimes this even happens in different steps. First, the internal antenna works fine but then shows problems, so we install an external one only to have the same problems a little bit later.

Therefore, we made the request to send you these photons were the Wi-Fi range suddenly has dropped to find out why this happens without any external changes.

If we might have missed some possible causes for these problems, we are more than happy to try them out.
It would be great if you can connect us to someone who can help us with this more special troubleshooting.

1 Like
5

A post was split to a new topic: WiFi.macAddress() returns all zeros

6

Is the photon placed on a circuit board? Did you try moving it nearer to the access point? Does this behavior exhibit itself if you flash an empty user firmware?

7

Thanks for adding more details. To be clear, we will always provide free support for hardware, firmware, and platform issues that are affecting our development kits.

@domseb, thank you for the information. I read up on your thread with customer support as well as the thread you linked and would love if you'd share some of your specific results with us so we can investigate.

In addition to the points I mentioned in the last post, we brought brand new photons just to check if they had the problems. We checked the antennas for damages and used external antennas which had the same problems. We used your different firmware versions and used your blink led stock app to make sure that our code wasn’t the problem. We measured the Wi-Fi strength with the WiFi.RSSI() function. There we saw big differences between individual photons in exactly the same spot but also big fluctuations over time with the same photon.

Would you share your test code, setup, and results so that we can attempt to reproduce?

@mfallavol, that sounds like an interesting case that our firmware team would be interested in helping to debug. To make sure the thread stays coherent, I'm going to move your post into it's own thread.

2 Likes
8

The photon is not directly placed on a circuit board, but it is connected to the SparkFun Battery-Shield (https://www.sparkfun.com/products/13626). The only other electrical connections are a sensor using 3 wires and a solar panel.

Moving it nearer to the access point helped, but only when it was 2/3 or 1/2 half of the original distance. There was only one exception, once (after the photon couldn’t establish a connection) we could carry the photon where we wanted, even directly next to the access point, without the photon showing any signs of connection (slow green blinking LED).

After the drop in the WiFi-range we flashed other firmware (for example tinker) and the range didn’t improve a bit.
Only after we replaced the photon with another photon (same firmware) could we use our device again (till now it lasted 10 days, but so did the first photon).

9

@domseb; you’re not alone. I have this same issue (see post here: [SOLVED but hopefully not the last word] Photons lose connection to wifi—any ideas?) and have no answer either.

I have 1 photon running tinker and not connected to anything else just to see if it fails WiFi at some point. It does fail but much less frequently than the photons I run my app on. I cannot definitively say it is the photon, my app, router or other environmental circumstances. Just to keep my stuff going, I just implemented a watchdog that resets the device if the comms are down - yeah, I know, shotgun approach, but at least i can continue development elsewhere in the hope to return to the WiFi disconnects later on.

10

Hi Will

The setup: We placed our photon with an external antenna (http://www.delock.de/produkte/F_701_Antennen_86246/merkmale.html) on top of the SparkFun battery-shield (https://www.sparkfun.com/products/13626). To the battery-shield we connected a 1.5W solar panel with solder, a sensor to 3 pins (3V3, GND, A0) and a 800mAh LiPo battery.
The whole setup was placed into a small box out of PLA. We paid attention, that the antenna wasn’t near any wires. The box was sealed off using electrical tape. Then we put it out into our garden. There it should wake up every 3 hours and send us data (which worked fine for roughly 2 weeks).

In these two weeks, we experienced only a few minor problems, when the photon took around 1 or 2 minutes to connect instead of after a few seconds. This was acceptable for us. Once or twice at nighttime it even was more than ten minutes, but even that was still ok.
Then, one morning we waited over 2 hours and the photon still hadn’t connected. The next 3 times we had to shake our device, or move it a little bit so until there was a connection.
Eventually, even the little movement wasn’t enough and we had to carry our device up 5-7 meters next to the access point.
We use the following router: FRITZ!Box 7490 (https://en.avm.de/products/fritzbox/fritzbox-7490/). We tried restarting it and all other WiFi devices showed no difference in strength or range.

I hope this helps. If we can provide any additional information we are more than happy to do so.

This is our firmware. We have blurred some information with “…” and renamed our variables, but nothing crucial has been altered.

 //Code for the (device), with the location (…)

// This #include statement was automatically added by the Particle IDE.
#include <SparkFunMAX17043.h>

 //------------------
 //  publishsensor.ino
 //------------------

 // This code publishes a particle (…) to a webhook

 // Details for SOC measurement
 #include "SparkFunMAX17043.h"
 
 // Input details for the (…) (A0) and (…) (A1) (…)
 int variable1     = A0;

 //CONSTANT VALUES
 int InputMax        = 2200;
 int SleepDelay1     = 2 * 60000;
 int SleepDelay2     = 60000;
 int SleepHours      = 3;
 
 // Particle Variable, to check if the sleeptime is correct
 int DeepSleepTime;

 // Webhook details
 char Subj[]     = "Testreihe …";
 char Org[]      = "…";
 char Locn[]     = "…, Germany";

 // Setup the particle device
 // Code for use with external antenna
 STARTUP(WiFi.selectAntenna(ANT_EXTERNAL));

 void setup() {
     // set Pins as inputs
     pinMode(variable1, INPUT);
     Particle.variable("Schlafzeit", DeepSleepTime);
     
     Serial.begin(9600);
     lipo.begin();
     lipo.quickStart();
     
     // time to flash the device
     delay(20000);

 }

 void loop() {
     
     // First delay for connection
     delay(SleepDelay1);
     
     // Read value from analog input
     float capacity = -1);
     float moisture = analogRead(variable1);

     // Read the SOC value
     float soc = lipo.getSOC();

     // Read the Wifi strength
     float wifiStrength = WiFi.RSSI();

     // Print value to Serial port
     Serial.println();
     Serial.println("-------------");
     Serial.println();

     // Prepare payload for publish
     char payload[255];

     snprintf(payload, sizeof(payload), "{\"o\": \"%s\",\"l\": \"%s\",\"s\": \"%s\",\"m\": %f,\"c\": %f,\"k\": %f,\"w\": %f}", Org, Locn, Subj, …, capacity, soc, wifiStrength);

     // Print payload to Serial port
     Serial.println(payload);

     // Publish payload
     Particle.publish("PublishToIOTHub2", payload);

     // Put device into deep sleep mode
     if(soc < 15){
        DeepSleepTime = (3600 * 12) - ((Time.now() + 61200) % (3600 * 12)) -60;
     }
     else{
     DeepSleepTime = (3600 * SleepHours) - ((Time.now() + 7200) % (3600 * SleepHours)) - 60;
     }
     
     
     delay(SleepDelay2);

     System.sleep(SLEEP_MODE_DEEP, DeepSleepTime);
 }

Next are the times the photon published its data.
Normal: with this data, everything is all right
Emphasis: this data doesn’t fit, but there are several reasons (we reset our device ourselves, or loss of power), nothing concerning this problem
Emphasis and Strong: The photon had trouble connecting, but in the end, it managed it. Sometimes we know why (unfortunate electromagnetic shielding), other times we are clueless.
Strong: The photon could only connect with our help, as we moved it around.

When there are bigger gaps between the times, the reasons are not photon related.

2017-03-19T14:13:57.000Z -74
2017-03-19T17:02:18.000Z -77
2017-03-19T20:02:21.000Z -75
2017-03-19T23:02:22.000Z -76
2017-03-20T02:02:17.000Z -76
2017-03-20T05:02:16.000Z -75
2017-03-20T08:02:17.000Z -78
2017-03-20T11:02:17.000Z -77
2017-03-20T14:02:54.000Z -75
2017-03-20T17:02:22.000Z -78
2017-03-20T20:02:21.000Z -72
2017-03-20T23:02:21.000Z -71
2017-03-21T02:02:19.000Z -72
2017-03-21T05:02:22.000Z -72
2017-03-21T08:02:22.000Z -77
2017-03-21T11:02:27.000Z -75
2017-03-21T14:02:20.000Z -74
2017-03-21T17:02:23.000Z -75
2017-03-21T20:02:18.000Z -76
2017-03-21T23:02:31.000Z -77
2017-03-22T02:02:33.000Z -77
2017-03-22T05:02:36.000Z -77
2017-03-22T08:02:29.000Z -78
2017-03-22T11:02:20.000Z -77
2017-03-22T14:02:18.000Z -76
2017-03-22T17:02:33.000Z -77
2017-03-22T20:02:35.000Z -78
2017-03-23T01:42:51.000Z -79
2017-03-23T02:03:28.000Z -79
2017-03-23T05:02:42.000Z -80
2017-03-23T08:02:31.000Z -77
2017-03-23T11:05:08.000Z -78
2017-03-23T14:33:25.000Z -77
2017-03-23T17:02:17.000Z -77
2017-03-23T20:02:30.000Z -75
2017-03-23T23:02:20.000Z -77
2017-03-24T02:02:17.000Z -77
2017-03-24T05:02:24.000Z -77
2017-03-24T08:02:26.000Z -76
2017-03-24T11:02:17.000Z -77
2017-03-24T14:02:19.000Z -76
2017-03-24T17:02:24.000Z -80
2017-03-24T20:02:51.000Z -78
2017-03-24T23:02:26.000Z -78
2017-03-25T02:02:27.000Z -82
2017-03-25T05:02:17.000Z -82
2017-03-25T08:02:19.000Z -74
2017-03-25T11:02:17.000Z -78
2017-03-25T14:02:19.000Z -75
2017-03-25T17:02:16.000Z -74
2017-03-25T20:02:39.000Z -79
2017-03-26T06:14:43.000Z -78
2017-03-26T10:20:56.000Z -75
2017-03-26T13:06:39.000Z -81
2017-03-26T16:02:07.000Z -72
2017-03-26T17:02:17.000Z -76
2017-03-27T08:29:08.000Z -76
2017-03-27T22:02:14.000Z -76
2017-03-28T22:02:24.000Z -80
2017-03-28T23:04:47.000Z -80
2017-03-29T02:02:19.056Z -79
2017-03-29T05:02:40.700Z -78
2017-03-29T08:02:26.210Z -81
2017-03-29T13:04:35.500Z -79
2017-03-29T16:04:25.624Z -79
2017-03-29T19:02:37.074Z -77
2017-03-29T22:02:44.744Z -80
2017-03-30T01:02:43.415Z -79
2017-03-30T04:02:56.709Z -81
2017-03-30T07:26:00.222Z -82
2017-03-30T10:03:29.844Z -80
2017-03-30T13:02:45.259Z -81
2017-03-31T08:14:13.768Z -85
2017-04-01T09:20:03.262Z -75
2017-04-02T07:02:38.692Z -78
2017-04-02T10:16:45.552Z -76
2017-04-02T13:02:46.053Z -71
2017-04-02T16:02:37.004Z -73
2017-04-02T19:02:36.503Z -73
2017-04-02T22:02:43.959Z -73
2017-04-03T01:02:36.587Z -72
2017-04-03T04:02:37.112Z -73
2017-04-03T07:02:37.504Z -74
2017-04-03T10:30:22.322Z -76
2017-04-03T13:14:08.873Z -76
2017-04-03T16:07:06.727Z -75
2017-04-03T19:02:37.148Z -72
2017-04-03T22:02:36.722Z -74
2017-04-04T01:02:37.599Z -74
2017-04-04T04:03:06.203Z -73
2017-04-04T07:02:37.800Z -72
2017-04-04T10:24:27.303Z -75
2017-04-04T13:20:29.114Z -77
2017-04-04T16:02:36.999Z -74
2017-04-04T19:02:36.690Z -72
2017-04-04T22:02:39.685Z -73
2017-04-05T01:02:37.573Z -73
2017-04-05T04:02:39.798Z -72
2017-04-05T08:10:00.800Z -73
2017-04-05T10:30:06.001Z -80
2017-04-05T13:19:30.088Z -82
2017-04-05T19:35:25.284Z -84

11

Hi Joost,

would you mind to share your working watchdog code? :slight_smile:

Regards

Sebastian

12

My other note is that these tests were run in a SparkFun power shield, which we did not design, and include the device mounted in a plastic enclosure where antenna and battery placement are critical to RF performance.

You don’t have to run out and complete the testing if you don’t have it, but can you confirm you’ve noticed the same behavior with unintegrated, bare Photon PCBs using either the on-board chip or external u.FL antennas?

Even the relatively “basic” scenario you’ve described makes it very difficult to isolate the issues you’re seeing to the Photon PCB or even a specific version of firmware.

13

@domseb; I wouldn’t mind but my company would :slight_smile: The watchdog code I have is somewhat intertwined with other business logic which wouldn’t mean anything to you. The workings of a watchdog are quite simple though. First of, you can use the system watchdog (see docs here: https://docs.particle.io/reference/firmware/photon/#application-watchdog).

In my case, I have a timer that is used to update a keyboard/menu panel that I dual purpose to advance a watchdog counter and call system reset if the counter runs out. My system needs to communicate on regular intervals and I am using the communication events to reset the watchdog counter. Dual purposing the keyboard/menu panel timer means that I don’t have yet another timer in my setup eating memory.

Its not code, but hope this helps nevertheless.

14

@will
First of all, sorry for the late response, it took some time to do a little bit of testing and we had a workshop all day long.

Thanks for your response, we looked into everything you suggested. We know it is very hard to find a solution, especially from a distance and with these many variables involved. To get rid of these variables, we have done all of the descripted testing with the troublesome photons. We did this to make sure nothing we have an influence on caused the problem. We did discover some reasons, that could shorten the range of the WiFi.
But even taken all these reasons into consideration we don’t think they are the source for our problem. We didn’t change anything in our setup while testing our device. Our setup was working (at least for a while), till the problem occurred. Taken into account that nothing in the environment or our setup changed, as the problems started, we think that the photon or at least the communication between photon and access point is the most likely source for our problems. That is why we wanted to send you our hardware, so that your engineers may take a look at it.

Additionally, to hopefully clear a bit confusion again a chronological order of the events and how we perceived them.

We tested have tested our device for about one and a half weeks, than the WiFi range broke down. After that happened we took several photons with different user code and firmware versions, within our plastic enclosure or the bare photon PCB powered by a powerbank. All behaved the same, they could barely connect from 6-7m. The only exception was a photon, we hadn’t used for a long time (at least 2 weeks). This photon showed the original connection range, but only for 2-3min, after that its connection range broke down too, just like with the other photons.
When we tested the problematic photons at a friend’s house, the WiFi range was horrible too. Sadly we had no comparison prior to when the problem occurred. Furthermore, we had 2 photons is Spain, which also couldn’t connect to the WiFi properly, but we weren’t able to investigate that further.

As a workaround we installed the external WiFi antenna to continue our testing. So we continued with the antenna (in a slightly different spot with one less obstacle in the way) and collected the data, with the connection times you saw in the post above. This again worked fine for a time.
When the connection broke down the second time, we again tested the photon with different user code and firmware device. Additionally we tried to measure the difference in the WiFi strength while powering the photon with a LiPo form the SparkFun battery shield, your power shield and directly from a power bank and a laptop. There were so slight differences measured with the WiFi.RSSI() function, but only a maximum of 2 dB, which shouldn’t explain the drop in range, especially because we didn’t change anything in our setup.
We changed the photon in our device after 2 days and again it worked. Only the original photon still refused to connect. Only now, two weeks after using it the last time this photon seemed to have recovered some of the range, but still far from the range we experienced the first time we tested our device.

15

@joost
Thank you very much for your help. We will definitly look into the system watchdog in the next few days.

16

@domseb; here is a bit of code I use to check the WiFi still being in OK shape:

void checkWiFi() {
	IPAddress ip = WiFi.resolve("www.google.com");

	if (ip[0] == 0) {
		USBSerial1.printf("Resetting WiFi\n");	
		
		WiFi.off();
		delay(5000);
		WiFi.on();
		delay(1000);
		WiFi.connect();	
	}
}

Dependency on google is not great of course but this not only ensures we have an IP, but an IP that can reach the cloud. I don’t like this sort of “play code” but I’ve got nothing better.

Btw, WiFi.RSSI() returns the wackiest numbers, don’t trust it. Not more than 25ft from my router (line of sight) I see -70dB (roughly) on all photons I have (20 or so). Going another 25ft and through a bunch of walls, -75dB. Going waay out, just before it cuts out -90dB, sitting on top of the router -36dB. I understand the RSSI is perhaps only an approximation of a linear measurement but the photon doesn’t come close. So your low values may not mean much.

I have played with the ext-ant also and still cannot say it changes the range … much if at all. It feels better to have the ext-ant on (except for the cost, $10 … yikes!) but I cannot definitively claim the range improves much.

I know the photon is used in other real live applications so somehow we/I must be doing something wrong to have such wacky WiFi results. It is frustrating to be close to have a fairly good product based on this device but never get it through testing far enough. I would hate to go back to TI’s RedBear board…

17

@joost, signal quality is a rather complex topic and there isn't any linearity unless you have near to no shielding/deflecting/interfering influences between sender and receiver.
There is an interesting discussion with a video to illustrate the problem

1 Like
18

@scruffR; I am familiar with that movie, very creative guy how he mapped out his RSSI levels. (Notice how he does not reveal the absolute RSSI deltas he measured) I was a RF guy in a former life so have seen my fair share of “antenna effect” but I won’t claim to be an expert. in general signal strength decreases with d^2 - that isn’t to say there aren’t bumps along the way due to obstacles, interference, reflections etc.

But though those effects are visible and measurable, the large, overall trends of signal strength decreasing across some path is true - I don’t think you suggested that all funky signal strength behaviors we see from the Photon is due to local nodes, reflections, interference and such, no? More pointedly; if we always could gain/lose say 15-25dB signal strength by moving the photon a few inches - I’d say we have a bad transceiver design.

Ergo; WiFi.RSS() output is noisy partly due to environmental effects as discussed above, but lets leave the possibility open that its algorithm/receiver contributes also? And lets hope that this is or remains a focus of improvement for Particle. After all, an IoT device with a troublesome wireless setup is useless, it needs to be simple to setup and rock solid. At the moment, it is not - at least not for me.

More on signal strength variations here if you’re interested: http://ieeexplore.ieee.org/document/6016387/ Notice the importance of a ground plane…

19

You're right, this isn't what I suggested, but rather that other factors than mere distance can play tricks on your measurements.

One very frustrating instance that took me a while to figure was the impact of my sons mobile phone and his BT keyboard burried under some papers on my desk which kept regularly searching for eachother next to my router causing intermittent dropouts of my devices (not only Particle's).

20

Don’t forget that your WiFi router can shift to a slower baud rate and modulation scheme and/or a higher TX power if the errors become too numerous. See section 18.4.7.2 of the 802.11b spec for instance (I don’t have the 802.11g spec right at hand). There are four possible TX power levels with 100mW being the lowest. The router/base station can increase its TX power and can also ask the remote units to increase as well, although that feature is optional in the spec.

The spec also calls for a maximum error rate at a particular receiver input level (-76dBm for 802.11b). The RSSI reported by these modules is not really in dBm but can be used for comparative levels.

2 Likes