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.
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?
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.
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.
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).
Hey Rob, yes it appears new sessions are being created and then closed every time we do a notecard.sendRequest(req), see attached event log. We are set to wifi transport and continuous mode, using the settings below.
I assume from your previous comments this is not normal behavior?
(FYI, we just updated to the new 9.1.1 firmware, but behavior was the same on previous version.)
Regarding the fluctuation in the “rssi” and “bars” values from card.wireless, the card definitely reports a significant cyclical dip in signal strength, which seems to occur toward the beginning of a new session. If I connect to a terminal session and I run constant card.wireless commands every 1-2 seconds, I will see the card at a stable -30 rssi and 4 bars the majority of the time. But seemingly as a new session begins, it will suddenly drop to -80 rssi and 1 bars…and after a few seconds will normalize back to -30 rssi and 4 bars.
This might be normal expected behavior for the hardware, but from an end-user perspective it’s confusing/concerning to see a signal strength wildly fluctuate that frequently. If we cannot dictate the timing of the card.wireless reading in a manner that avoids reading the values while they are bottomed out, then we’ll need to employ some other method of filtering out these rogue values. Any thoughts on that? Thanks!
It turns out there are some differences between how the card.wireless API works between cellular and Wi-Fi Notecards, so I’m glad you had me look into this!
Even during a continuous session, when connected over Wi-Fi the Notecard will periodically scan for new access points, at which point it will take signal measurements. (So that answers my first question!).
The issue you’re seeing with signal values dropping at the start of a new session like possibly because:
When a new session starts the ESP32 may temporarily reduce power or recalibrate.
Network resources are being actively negotiated (like DHCP address acquisition).
There is no signal averaging for these values, meaning momentary fluctuations are reported directly.
So I would recommend implementing a basic moving average filter on your side that takes multiple readings and averages them before reporting the signal strength. This would smooth out the temporary dips that occur when new sessions begin.
Thanks Rob, that makes sense. Appreciate the detailed explanation.
So just to confirm, even in continuous mode it is expected behavior for our WiFi connection to close sessions immediately after data upload, resulting in a new session for each new request? And that’s different from a cellular continuous mode connection, which tries to maintain sessions indefinitely, or according to the duration setting you’ve specified with hub.set?
No, that’s not by design. I’m trying to replicate your issue locally but am unable to unfortunately. This makes me wonder if the Wi-Fi router (or DHCP server) you are using is being a little aggressive in how it de-provisions IP addresses if something goes idle?
Also, you might want to check on the status of the Notehub connection with:
{"req":"hub.status"}
And verify connected:true prior to taking any readings from card.wireless? Just a thought in case there are some delays in getting an IP from the router hence causing fluctuations in the signal strength readings?
Rob, I don’t think this is a router issue, based on the Notehub event log showing these session disconnects happening instantly after each data upload, and the notation that “notecard ended the session” (see attached). The log shows the new session connected, the data uploaded, and the session closed, all within a one second timestamp. Seems very unlikely the router would sense the device going idle and de-provision its connection that quickly.
Are there any settings we could have unknowingly tweaked to create this behavior? Here is what we get from hub.get…
Yeah, those settings should be fine. You’re definitely getting disconnected from Notehub somehow, we just have to figure out why. You’re on the latest firmware (9.1.1) correct?
It’s definitely worth capturing a trace log so we can see what’s happening before/during/after a successful sync with Notehub.
Looks like I might have at least partially solved the mystery. This connect/disconnect behavior is apparently a result of having card.location set to periodic mode, even with a period of 60 minutes.
Once we set card.location to “off”, the behavior totally changes. You can see from the new log that the session is now staying connected after data upload.
We tested it again using the cellular connection, and the behavior is the same. If card.location is set to anything other than “off”, a continuous connection is not possible. The card immediately terminates the sessions after data upload. Here is the event log from the cellular tests. The 3:26pm test is with card.location set to periodic/3600, and you can see the card immediately ends the session after upload. The 3:28pm connection is with card.location set to “off”, and you can see the session stays open.
So is the take away here that continuous data connections are not possible with GPS enabled, even with a relatively long card.location periodic value? That’s not how I thought I understood things from the documentation. I know that both data and gps can’t be set to ‘continuous’ at the same time, but the fact that the system allows you to set data to ‘continuous’ while setting GPS to ‘periodic’ suggests that a continuous data connection is possible with GPS enabled.
Thanks Rob. Not sure if it’s helpful but I went ahead and captured trace logs for all four scenarios, power cycling the card in between each, and took screenshots of the event logs that correspond.
One thing that jumps out when you compare session “opened” events in the log is that when card.location is off, the session open explicitly states “continuous connection mode”. But when location is in periodic mode, the session open events do not have this tag, reinforcing the notion that continuous connections are not possible when GPS is in periodic mode.
We assumed that a continuous data connection would have to be occasionally interrupted when the GPS cycled on periodically, but this is suggesting you have to completely disable GPS to achieve a continuous data connection.
I was able to talk this over with someone internally. After sending the card.location.mode request, the Notecard is going to immediately switch off of cellular/wifi and try to get a GPS fix. It will remain in this mode until there is a successful satellite fix to ascertain its initial location. In the meantime, you can sync new Notes, but that will simply disable GPS temporarily, send the Note over cell/wifi, then re-enable GPS (again, this is only until it makes a fix).
Now repeat this process every hour and I think we see the problem. I would recommend either getting the device into a spot where it can get a satellite fix more quickly, or switch to using an external GPS module.
