How to get consistent signal strength values from card.wireless

Notecard API
1

While using a Notecard Cell+WiFi in WiFi mode, we’re using the following MCU code to retrieve ‘bars’ and ‘rssi’ values from card.wireless, then upload those values as part of our ‘note.add’ payload. We are operating in ‘continuous’ mode, and for the purpose of testing we are sending a new request to Notehub every 20-30 seconds.

  J *rsp = notecard.requestAndResponse(notecard.newRequest("card.wireless"));
  if (rsp != NULL)
  {
    signal_rssi = JGetNumber(JGetObject(rsp, "net"), "rssi");
    signal_bars = JGetNumber(JGetObject(rsp, "net"), "bars");
    notecard.deleteResponse(rsp);
  }

  J *req = notecard.newRequest("note.add");
  if (req != NULL)
  {
      JAddBoolToObject(req, "sync", true);
      J *body = JAddObjectToObject(req, "body");
      if (body != NULL)
      {
          JAddNumberToObject(body, "motor_temp", round(kls.status.motor_temp));       
          JAddNumberToObject(body, "bms_voltage", bms.get.packVoltage);
          JAddNumberToObject(body, "bms_current", bms.get.packCurrent);
          JAddNumberToObject(body, "bms_SOC", int(bms.get.packSOC));
          JAddNumberToObject(body, "charger_connected", bms.get.chargeState);
          JAddNumberToObject(body, "load_connected", bms.get.loadState);
          JAddNumberToObject(body, "cell_temp_max", bms.get.tempMax);
          JAddNumberToObject(body, "signal_rssi", signal_rssi);
          JAddNumberToObject(body, "signal_bars", signal_bars);
      }
      notecard.sendRequest(req);
  }

The issue is that ~75% of the time we see values like 4 bars and -34 dBm, which are sane values given that the hardware is only about 15 feet away from our WiFi access point with nothing blocking/shielding it. However, the other ~25% of the time, bars and rssi are reported as either 0 or 1 bar, and between -80 and -90 dBm. Since the physical orientation of the hardware and access point aren’t changing, I suspect these are errant values due to poor timing. Is the Notecard reporting these rogue values because the readings are ill-timed in relation the radio’s connection cycle? If so, how do we mitigate that so we get consistent/accurate values?

TIA!

2

Hi @josh77,

The values returned from a card.wireless request are only updated on new sessions with Notehub. So if you’re in continuous mode, I don’t think you would see updated numbers until the connection resets. You can try using periodic mode (or minimum mode and performing manual hub.sync calls) or use the duration argument while in continuous mode to create a new session every x minutes.

Let me know if that works!

Thanks,
Rob

3

Hey Rob, thanks for the reply, but not sure I understand what’s going on then. If we’re in continuous mode, and those values are not supposed to refresh until a new session is started, then why are we seeing such wild fluctuations every 4th or 5th reading (every 2-3 minutes)? It doesn’t make sense that the signal would truly intermittently drop to 1 bar and -90 dBm when the wireless AP is 15 feet away with clear line of sight and no enclosure around the Notecard. That’s why I was thinking it had something to do with the connection cycling. But it sounds like you’re saying the values shouldn’t be updating/cycling that often if we’re in continuous mode, so now I’m not sure what would be causing that.

And I don’t think we want to force more frequent re-connections or new sessions, as we’re not trying to get more frequent readings from card.wireless, we’re just trying to eliminate the erroneous ones.

4

Hi @josh77,

Yeah, that’s a good point. Can you check the events in Notehub to see if new _session.qo events are appearing in correlation with the updated card.wireless response values? The reason I ask is any network interruption/reconnection can be enough to reset your connection (e.g. if your Wi-Fi router is resetting the connection for some reason). Otherwise, a card.wireless request is always going to look back at the last known network data (it’s not going to initiate a new request to check on the literal current status of the network).

Thanks,
Rob