@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?
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.
@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);
}
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?
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.