WiFi.RSSI() causing lockups

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);
        }
    }
}

Can we get a bit more of your code? How is timeElapsed incremented for example?

I know the timer is firing every 5 seconds as I can see the led toggle at that frequency.

Seems to be auto-updated, see this library. The code is based on example on the library page:

http://playground.arduino.cc/Code/ElapsedMillis

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.

I meant #include <elapsedMillis.h> and “int rssi” declarations. But it seems it is just relevant part of the code.

Doh, good recommendation with switching if()s. I need my morning coffee bad :smiley:

I see :eyeglasses:, I obviously need my mornig :coffee: too, otherwise I would have read your post more thoroughly :blush:

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.

Any ideas?

As @lami pointed out, could you show us the declaration for your variable rssi?
That may give us some more clues.

double rssi = 0;

@macsboost, I’ve no idea why it wouldn’t work on your Core.

When I flash this to mine it works for more than five minutes now

#define led D7

double rssi = 0;
unsigned int interval = 50;
unsigned int rssiinterval = 5000;
unsigned long lastTime = 0;

void setup() {
    Serial.begin(115200);
    pinMode(led, OUTPUT);
    digitalWrite(led, HIGH);
    delay(1000);
}

void loop() {
    if (millis() - rssiinterval > lastTime) { //grab rssi every 5 seconds.
        if (WiFi.ready()) {
            rssi = WiFi.RSSI();
            Serial.println(rssi);
            lastTime = millis();
            digitalWrite(led, !digitalRead(led));
        }
    }
}

So I guess it’s nothing to do with WiFi.RSSI(). Try my code and if this works the culprit’s somewhere hidden in the differences :wink:

2 Likes

OK, I think my problem is passing the rssi value to the cloud.

#define led D7

double sysvolts1 = 0;
double sysvolts1raw = 0;
double sysvolts2 = 0;
double temperature = 0;
double temperatureraw = 0;
double temperaturefilt = 0;
double temp = 0;
double bilgepumpst1 = 0;
double bilgepumpst2 = 0;
double rssi = 0;


unsigned int interval = 50;
unsigned int rssiinterval = 5000;
unsigned long lastTime = 0;

void setup() {
    Serial.begin(115200);
    pinMode(led, OUTPUT);
    digitalWrite(led, HIGH);
    Spark.variable("sysvolts1", &sysvolts1, DOUBLE);
    Spark.variable("sysvolts2", &sysvolts2, DOUBLE);
    Spark.variable("temp", &temp, DOUBLE);
    Spark.variable("bilgepumpst1", &bilgepumpst1, DOUBLE);
    Spark.variable("bilgepumpst2", &bilgepumpst2, DOUBLE);
    Spark.variable("rssi", &rssi, DOUBLE);
    delay(1000);
    
}

void loop() {
    if (millis() - rssiinterval > lastTime) { //grab rssi every 5 seconds.
        if (WiFi.ready()) {
            rssi = WiFi.RSSI();
            Serial.println(rssi);
            lastTime = millis();
            digitalWrite(led, !digitalRead(led));
        }
    }
}

this locks up

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. :smile:

@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

1 Like

@ScruffR, crap! I am not keeping up :stuck_out_tongue: 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!!

1 Like

So I have this code that runs for days on my Spark core + SSD1306 OLED:

    // This #include statement was automatically added by the Spark IDE.
    #include "Adafruit_SSD1306/Adafruit_SSD1306.h"

    #define OLED_RESET D4

    Adafruit_SSD1306 display(OLED_RESET);

    int8_t dbs[128];

    void setup() {
        display.begin(SSD1306_SWITCHCAPVCC, 0x3D);
        display.clearDisplay();
    }

    void loop() {
        int i = 0;
        
      display.clearDisplay();
      display.setTextSize(2);
        display.setTextColor(WHITE);
        display.setCursor(0,0);
        display.println(WiFi.SSID());
        int8_t current = WiFi.RSSI();
        
        for(i = 0; i < 127; i++) { dbs[i] = dbs[i+1]; }
        dbs[i] = abs(current);
        
        for(i = 0; i < 128; i++) {
            int scaled = (dbs[i]/2.7);
            for(int j = 0; j < scaled; j++) {
                display.drawPixel(i,(63-j),WHITE);
            }
        }
        
        display.display();
        
        delay(1000);
    }

The only problem I notice is that the RSSI value comes back 0 (or less than 0) for periods of time.

I have 3 cores running this code and they all drop the RSSI value at the same time and pick it back up at the same time…

Reading through the RSSI code, it does do sampling, so I think it’s technically blocking, but there are some “README/BUG/TODO” type comments here:

https://github.com/spark/firmware/blob/master/src/spark_wiring_wifi.cpp#L64

So RSSI is in dB and should be negative all the time when it is working correctly. Zero and positive values indicate errors.

@developstuff can you link a spark variable to rssi and query it?

I am using atomiot… It makes it so easy to prototype and probe the unit😊

Most of my dev is wifi, I don’t have easy serial port access. It is a pain when it fails. Plus I want to log the wifi over time.