I am using my core to measure the strength of my wifi (which is a proxy for something else I am measuring, but more on that in the “projects” section once I got it working …)
I run into the following problem: my Core connects to my wifi just fine, I get a nice stable signal for about a minute. Than I block my antenna with some metal, after which, of course, the signal drops. WiFi.RSSI() returns 2, as it should. However, upon removing the metal barrier, the signal does not get back and I keep getting “2” from WiFi.RSSI(). interestingly, my Core keep breathing cyan. . If I try to flash it using the web IDE, it can not find the core.
Does anyone know
what is going on? and
how to fix it?
and on a side note: it takes quite some time for the RSSI value to change after inserting the metal barrier: I could not find the integration time used in calculating RSSI in the docs.
does anyone know the RSSI integration time?
is there any way to get the raw rssi value, before it is converted to dB?
For completness: I am using a Core with antenna, that is attached. I have tried with different antenna’s (homemade and the small one you can buy with the core). I have reflashed factory a few times, done the deep update ande reflashed the cc3000.
any help much appreciated.
Rolf
PS my code:
#define DEBUG_SERIAL true
#define MEASUREMENT_INTERVAL 5000
int i = 0;
void setup() {
if (DEBUG_SERIAL) Serial.begin(9600);
}
void loop() {
if ((millis() % MEASUREMENT_INTERVAL) < 10){
int measurement = WiFi.RSSI();
//TODO something with uploading to internet
if (DEBUG_SERIAL) {
Serial.print(i++);
Serial.print(" ");
Serial.print(WiFi.SSID());
Serial.print(" ");
Serial.println(measurement);
}
delay(10);
}
}
Positive RSSI values indicate an error. You are probably not really connected when you see that value, but the core will continue the breath cyan until the next attempt at cloud communication which can be up to 10 seconds later. When you remove the Faraday cage the core starts renegotiating with access point to connect again, which can take quite some time (30 seconds sometimes) and your code is blocked for some of this time.
Are you waiting with the Faraday cage on for more than 10-seconds? I would think the core would stop breathing cyan then going to rapid flashing cyan and then other colors as it tries to negotiate with the AP.
The RSSI value from the TI WiFi chip is a 7-bit value already in dB; I don’t know of any other RSSI value you can get.
I know that 2 is a timeout error. my problem is that the code does not block, otherwise I would not keep getting those massages over Serial. When I install the faraday cage, the rssi output jumps imediatly to this “timeout” value of 2. When I remove the cage, I keep getting the same output and that doesn’t ever (waited > 1 hour) change again. There is no blockage going on, at least not that I notice. I had the output interval lowered to every second, and there is no delay at the moment that I remove the faraday cage.
It feels like the Spark does not try to reconnect once the wifi is in this timeout mode. Could that be true?
brainwave: does actually calling WiFi.RSSI() change anything? Does it reset triggers or counters?
I’ve done some further testing and it seems that this problem is even weirder. It is not related to my cage of Faraday at all. It seems to be related to my specific router.
If I connect my Spark to my router and monitor using the code below, I get about a minute of good readings and than WiFi.RSSI() returns 2 (timeout) while WiFI.ready() returns true and WiFi.SSID() returns my SSID. So, I am connected, but the RSSI gets a timeout. I check if I am really connected by also publishing the same info to the cloud and listening (using CLI) on my laptop. I am still connected, while I get the timeout at WiFi.RSSI(). By playing around with the time between measurements, I see that the problem is independent of the amount of WiFI.RSSI() calls that I make, it happens after about a minute.
I do not get this problem when I connect using my iPhone as a WiFi hotspot. My router is a Thompson cable-modem and router combo thing that I get from UPC with my internet subscription.
anyone any thoughts??
thanks in advance
Rolf
PS my code:
#define DEBUG_SERIAL true
#define MEASUREMENT_INTERVAL 5000
int i = 0;
void setup() {
if (DEBUG_SERIAL) Serial.begin(9600);
}
void loop() {
if ((millis() % MEASUREMENT_INTERVAL) < 10){
int measurement = WiFi.RSSI();
String SSID = WiFi.SSID();
bool connected = WiFi.ready();
//TODO something with uploading to internet
Spark.publish("isConnected",(String) connected);
Spark.publish("isConnectedTo", SSID);
Spark.publish("measurementRSSI",(String) measurement);
if (DEBUG_SERIAL) {
Serial.print(i++);
Serial.print(" ");
Serial.print(connected);
Serial.print(" ");
Serial.print(SSID);
Serial.print(" ");
Serial.println(measurement);
}
delay(10);
}
}
I’ve edited your post to properly format the code. Please check out this post, so you know how to do this yourself in the future. Thanks in advance! ~Jordy
I found a (possibly) related problem. I was running a stress test overnight to ensure that I did not have memory leaks in my code. Everything was fine the next morning, after 14 hours of running. I left my setup running and came back two hours later. At the latter time, I found out that my Core was offline, as reported by the cloud. The Core was never disconnected, was breathing cyan, and was operating just fine as far as I could determine (my loop has a non-blocking double flash of the D7 LED whenever it detects an event to log and the external event generator was generating a new event every three seconds or so). The Core was definitely offline, however – I could not communicate with it over the cloud, either by curl to functions and variables that are exposed to the cloud nor even to upload firmware from the cloud. I tried a few tests over a few minutes and finally reset to Core (via the rest button) and it came back OK.
Anyone know what’s up? I thought that breathing cyan meant that everything was OK and the Core was in communication with the cloud. It is highly unlikely that my firmware crashed, since the main loop was operating normally. Does the Core periodically try to connect? Should I periodically try a Spark.connect()? How frequently? Under what circumstances?
I have experience this same issue on my spark core. My findings are very similar to @RolfHut with RSSI returning 2 after ~60 seconds (62s, 63s, 64s, 64s, 63s, 65s) into runtime while calling the method every iteration of the loop.
Did you guys figure this out?
I know a long time as passed, but I’m having the same exact problem.
My application handles a lot of Serial1 data from/to a nRF51 BLE chip, so maybe the amount packets on the 2.4Ghz band is screwing with the wifi connection?
I really don’t want to believe this and your posts make me think that this could be an issue with the wifi chip itself.
This usually happens after 10-30min of runtime, but the more BLE devices i have connected, the faster it seems to happen.
Fyi, the application is running in AUTOMATIC mode, and the loop is not blocked by this disconnection.
I also reseted my router (Cisco Meraki MR18), but the Core kept breathing cyan as if it was still connected.
Resetting the Core brings the wifi connection back.
This isn’t a direct answer to your question but I just wanted to let you know that my focus for the near future is going to be on WiFi stability. I’m looking to get to the bottom of these types of issues.
@marfife: I have posted another troubleshooting thread indicating that the same problem has continued with the Photon and with the latest firmware version. The Core/Photon is happily breathing cyan but the Particle Cloud says that it is offline. This seems to happen after the device has been running for some time - perhaps several weeks or even months. There seems to be no event that causes it. It will not reconnect itself back online, but the software on the device is running just fine. It will only come back “online” to the Cloud after a reset.
I also have an Electron running the same code and have not seen this problem. However, I have only had the Electron for a few weeks.
I am happy to hear that Particle is looking into WiFi stability. I’m not sure if it is WiFi related, TCP related, or something within the Particle Cloud itself. Perhaps experience with the Electron (which uses UDP and 3G vs WiFi and TCP) will help to sort this out.
The Core has had some Wi-Fi stability issues due to the CC3000 module, but this code should be expected to work. I reworked your code because it was also knocking the Photon offline as well (not sure why exactly but I typically avoid % with millis() and Particle.publish() is rate limited to 1 per second. That said, this following code still knocks the Core offline, looks like the WiFi.RSSI() is doing it right away on mine.
#define DEBUG_SERIAL true
#define MEASUREMENT_INTERVAL 10000
uint32_t lastTime = 0;
int i = 0;
void setup() {
if (DEBUG_SERIAL) Serial.begin(9600);
}
void loop() {
if (millis() - lastTime > MEASUREMENT_INTERVAL) {
lastTime = millis();
int measurement = WiFi.RSSI(); // works on Photon, not Core
// int measurement = 0; // works on Core
String SSID = WiFi.SSID();
bool connected = WiFi.ready();
if (connected) {
Particle.publish("myRSSItest", String("SSID:")+SSID+String(",RSSI:")+String(measurement));
}
if (DEBUG_SERIAL) {
Serial.printlnf("%d %s %s %d", ++i, connected?"true":"false", SSID.c_str(), measurement);
}
}
}
I switched the wifi connection to a TP-LINK TL-WR702N and I’m still having the same problem.
It’s also interesting that I have the Core for almost a year and I’m only seeing this issue now.
Update: Forgot to mention that this is the error on the spark-server (i’m running the server locally)
1: Core disconnected: socket error Error: read ECONNRESET { coreID: ‘xxxxxxxxxxxxxxxxxxxxxx’,
cache_key: ‘_620’,
duration: 14122.676 }
Session ended for _620
I added a bug report here, please see my notes… seems to work ok with v0.3.4, but did not on v0.4.9. It might be simple to fix when someone can take a look, but it could also help narrow down which version of firmware this seems to have broken WiFi.RSSI() for the Core on. If you have any thoughts, please add here or in the github issue. Thanks!