My Photons are experiencing inconsistent Wi-Fi connection behavior

@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.

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

Hi Joost,

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

Regards

Sebastian

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.

@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.

@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.

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

@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…

@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

@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…

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).

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

@bko
Thanks for the response, this sounds like a very interesting point. Unfortunately, we are no experts in this field and therefore have some questions.

First, how can we check which baud rate/modulation scheme and which TX power level is designated to the photon?

What would be the best way to fix such a problem and therefore improve the WiFi connection from the side of the photon?

We read, that it is possible to set the power levels manually (although it is not recommended).
Is it possible to set these power levels over the photon itself or is a computer mandatory?

Finally, what is the cause for the error rate, and what would be the best way to decrease it?

Hi @domseb

I would start by looking at your environment. It makes are huge difference what other transmitters are nearby. If you ever see a WiFi device at tradeshow or maker faire, they often struggle since there are too many base stations and too many devices all in the same area competing for bandwidth. You may also be getting unintentional interference from things like bluetooth devices or motors with arcing brushes or on and on. The channel that your router uses also has an effect and choosing a channel that is not used nearby is best, but that can be impossible in an urban environment.

I have never used a Fritz!Box router but it certainly looks awesome, like something out of a 1950’s cartoon. It looks like it can do lots of things like acting as a NAS or streaming over USB 3.0 and provides DECT phone services. I would try turning all those things off, or get a simple router instead that will never be “busy” with all those other functions. You might find that there is come correlation between your Photon’s lack of range of other devices being on the same network, as well so I would pay attention to what else what happening when your Photon loses range.

WiFi is a cooperative RF environment and works well when all the devices play by the rules, but having just one misbehaving device can throw everything off. I would make sure there are no other devices in-line with your Photon under test, either between it and the router or behind it. Even a neighbor’s WiFi device directly behind your Photon can mess things up.

Some routers (Apple in particular) try to move traffic to the 5GHz band so I generally recommend that you give the 2.4GHz and 5GHz bands separate SSIDs since it cannot migrate traffic in that mode.

So in summary, I think you need to isolate the variables by finding or making a simple and quiet RF environment to test in. I run all of my IoT devices off of a separate router with its own SSID and channel to keep things isolated, for instance.

I do not think you can or should try to adjust TX power on your own. That would not be legal in the US for instance since you could easily violate the ERP standard the device was tested to. You can uses higher gain directional antennas but they can be very sensitive to changes in direction and for a product you would have to retest with the new antenna.

4 Likes

@bko
We have been busy for the last few days with testing. Sadly, we couldn’t recreate perfect testing conditions for the photon in respective to RF environment. But we had the opportunity to examine the behavior of a completely new photon fresh out the box. For the new one, as well as for the old photons we used the exact same testing conditions.

We claimed the new photon from a bit farther away (20 meters) to find out if it was possible. It turns out, this is absolutely no problem at all. Next, we went further and further away in small steps, disconnecting and reconnecting a powerbank to the photon. In the end, the maximum connection range was 35 meters for the freshly claimed photon. We were a bit surprised by this good result.

Next, we connected our external antenna to the new photon. With this setup, we got 40 meters of range. It could even be more, but because of a massive garage, we couldn’t investigate a further distance.
With an older photon (rarely used), which showed a more than promising range we got up to 25 meters.
On the other hand, an often-used photon barely had a range of more than 10 meters. Even after we unclaimed the photon and reset it’s WiFi data it didn’t get any more range.

Our findings correspond to suggestion from an experienced electrical engineer. After we told him about our problems, he said that this wasn’t an unfamiliar problem to him. He didn’t exclude any cause for the problem, but in his opinion, the most likely reason is the software. Since we tested several user codes, including Particle examples, the firmware of the photon would be the source of the problem.
After a while of operating, something in the device firmware malfunctions and reduces the power with which signals a sent.

Apparently, this is a quite common problem which is circumvented with a regular reset of the device.
In our opinion, this could explain, why @joost watchdog with resets seems to work.
But before we want to make wild accusations, @will can you definitely eliminate a firmware malfunction as a probable reason for the loss of WiFi range after a longer operating time?

Can you confirm that you’re using this code in your device testing? My guess is that the issue is linked to user firmware rather than system firmware. I am not a firmware expert, but long delays can interrupt the network keep-alive that manages the connection to the Cloud and result in inconsistent and disrupted network behavior.

My preference would be that you use the default Tinker firmware for your testing since that is a reasonable “control”. You can always get Tinker firmware back on your device by putting your device in DFU mode flashing it in the CLI with particle flash --usb tinker.


// 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);
 }
2 Likes

Thanks for your answer.

We used our firmware with a second new photon today.

First, we couldn’t recreate the exact conditions (rain and cars in the way) of 2 days ago, so the results are a little bit worse. We claimed the second new photon and went at the same spot (Tinker App). From about 30 meters the photon were able to connected to the WiFi.

Next, we flashed our code. With this came the device firmware upgrade from 0.5.3 to 0.6.1. We again went to the same spot, this time the photon connected from around 28-29 meters. To check if it was our code, we re-flashed Tinker. This time the connection was still 28-29 meters, but not the full 30 meters.

We don’t know if this was just some normal fluctuation or if it had something to do with our code, that we flashed, but we flashed the Tinker app later with the same results in range. But we know that this new photon has a very good connection, in comparison to our older ones.

May some of your system firmware developers take a look at this?

@will
Since we weren’t able to successfully isolate our problem to one source on our own, can you give us a status update about eventual firmware problems, or give any other suggestion what we might test?

I’d be rather interested in any info update on this topic also!

Hey there @domseb,

At this point, I want to align with you on the findings so far:

  • You are using the firmware that I provided above, which includes a 20s delay in the setup function as well as long delays in the user loop function. You are not running your application with multithreading enabled, which means that these long delays will interrupt the background task that maintains a connection to the Cloud, and may cause your device’s connection to reset periodically (flashing green). This has nothing to do with RF performance, and is linked to your system firmware.

  • You’ve done some testing with a new device running your firmware and have found that it is able to connect at close to 115 feet, which is within the expected and normal range for Wi-Fi.

  • Unless I’m missing something, I haven’t seen any information about range testing for the device with the default firmware application, “Tinker” running, which would be the control information that we need to determine that there’s something wrong with either (1) the hardware or (2) the system or user firmware that Particle has written.

My strong hunch is that the user firmware that you’ve written is disrupting your devices’ connections to the Internet, and that if you did the same testing with the Photon with Tinker running (as a control), you would find that its behavior is much more stable.

If you’d like us to do a firmware review, we’re happy to do so, but will need to charge for the time. In the event that we track down the source of the issue and determine it to be an issue with our own system firmware, we would refund part or all of the contractor hours spent on debugging.

1 Like