I’ve tried several times unsuccessfully to use the RSSI function call in a loop to monitor RSSI.
I can do it once, but beyond that it causes lockups and instability.
Even using elapsed millis and waiting 5 seconds in between calls, this seems to break things.
I am copying the rssi to a spark variable so I can query it on the fly.
Other than that, the wifi link seems to be stable since the last firmware update.
Any ideas?
Thanks, Mac
unsigned int interval = 50;
unsigned int rssiinterval = 5000;
elapsedMillis timeElapsed; //declare global if you don't want it reset every time loop runs
void loop() {
if (Spark.connected() == true){
if (timeElapsed> rssiinterval){ //grab rssi every 5 seconds.
rssi = WiFi.RSSI();
timeElapsed = 0;
ledstate = !ledstate;// Turn ON the LED
digitalWrite(led, ledstate);
}
}
}
Only problem I can see is missing #include and declaration of rssi variable. But if it compiles, it is somewhere in his code I suppose.
I saw people using delays when calling some spark network related functions, so maybe Spark.connected() is called too fast? Maybe add else with delay(1000) to the if (Spark.connected()) block?
@lami, WiFi is an object that is instanciated in each “standard” Core firmware which includes application.h (I think) and hence its RSSI() methode will be present.
Although I think this should not block, I’d still go with @lami 's suggestion to slow things down a bit, but for this I’d not necessarily use a delay but turn around the if statements. And since we are only interested in the WiFi.RSSI() I’d replace Spark.connected() with WiFi.ready().
void loop() {
if (timeElapsed> rssiinterval) { //grab rssi every 5 seconds.
if (WiFi.ready()) {
rssi = WiFi.RSSI();
timeElapsed = 0;
ledstate = !ledstate;// Turn ON the LED
digitalWrite(led, ledstate);
}
}
}
@macsboost, for testing where it blocks, you could place some Serial.println() lines before and after your suspected code parts.
Thanks for the replies. The calls to WiFi.RSSI cause lockups… You can usually call it once, but more calls than that and it locks up.
calling it every loop causes failure immediately.
I tried adding the delays, but that didn’t seem to help much. The call ends up failing and returning a value of 2 and usually locks up or halts to the point that it requires a hard reset.
The one call that you do make is not reliable and returns a value of 2 a good portion of the time. I have several sparks and they all behave this way.
I’ve tried your code on my Core too and it doesn’t hang.
It carries on running, but I do experiance some issue after nine correct readings consistently.
After nine correct readings I only get return code +2 (timeout).
I’ve not yet experimented and not had a look at the implementation of WiFi.RSSI() if there might be some leak or so.
But it’s not locking.
Edit:
After some experimenting it looks that it’s not nine repetitions but the first 45 to 50 seconds it works and then fails (different rssiinterval settings).
@macsboost, unless you are compiling locally, the limit on the number Spark.variables is 4 and you have defined 6. Try reducing to 4 to see if you get better results.
@peekay123, that’s odd, because the docs don’t state anything about a different Spark.variable limit between local and cloud build.
The docs tell that there are 10 variables possible http://docs.spark.io/firmware/#cloud-functions
@ScruffR, crap! I am not keeping up You are correct and the only difference with local building is that you can go into the firmware file and change that limit whereas you can’t with the IDE. Oy!!