after having connected about every 5 minutes for the entire day the notecard suddenly can no longer perform any syncs, it looks like it is on GSM and gets as far as:
before it eventually fails on timeout or similar. It looks like resolving a.notehub.io works. Any idea what could be going on? It has been in the exact same position with service the entire day.
When you see this happen, I would start with issuing a card.wireless request to get a few more details: {"req":"card.wireless"}. If you want to send me a PM with the results of that, I can look into it more closely and likely have further debugging steps we can take.
@rsmith and @gauteh - I’ve been looking into this locally and we found an issue on our end that was preventing some Notehub connections. It looks to be back up now, can you take another look?
the last couple of days I have had several modems having trouble connecting. It takes a long time to do “wireless registration”, and then eventually fails on:
M10:35.52 14 < GetCXRegAgain
M10:35.52 14 > GetCXReg at+cgreg?
M10:35.57 14 < GetCXReg +CGREG: 2,2
M10:35.57 modem: wireless: waiting for wireless service 15 sec [++++] {cell-registration-wait}
M10:35.57 14 < GetCXReg OK
M10:37.84 17 < Heartbeat
M10:37.84 modem-state: proceeding even though PS service not attached
M10:37.94 17 > GetNetInfo at+qnwinfo
M10:37.99 17 < GetNetInfo +QNWINFO: "GSM","24202","GSM 900",38
M10:37.99 modem: wireless: cellular radio gsm band GSM 900
M10:37.99 17 < GetNetInfo OK
M10:37.99 17 > EnableDTR at&d1
M10:38.04 17 < EnableDTR OK
M10:38.04 17 > SleepMode AT+QSCLK=0
M10:38.08 17 < SleepMode OK
M10:38.18 17 > GetCSQ at+csq
M10:38.23 17 < GetCSQ +csq: 25,99
M10:38.23 17 < GetCSQ OK
M10:38.23 17 > QueryQCSQ at+qcsq
M10:38.28 17 < QueryQCSQ +QCSQ: "GSM",-63
M10:38.28 17 < QueryQCSQ OK
M10:38.28 modem: wireless: waiting for wireless service 18 sec [++++] {cell-registration-wait}
M10:38.28 17 < GotTime
M10:38.28 17 < PPP
M10:38.28 modem: wireless: waiting for data service {wait-data} {connecting}
M10:38.79 lwip: tcp task activated
M10:38.79 18 > EnterPPP ATD*99*PPP*1#
M10:38.83 18 < EnterPPP CONNECT 150000000
M10:38.83 modem: wireless: network registration took 26 sec
M10:38.83 modem: wireless: connected {connected-closed}
M10:38.83 sync: wakeup: modem connected
M10:38.83 modem: watchdog poll interval changed from 750ms to 900000ms
S10:38.86 sync: project: using product UID product:no.met.gauteh:sfy
S10:38.86 sync: notehub: asking discovery service to assign a notehub session handler
S10:38.86 sync: network: opening unidirectionally-authenticated secure session to a.notefile.net:8086 {socket-open-session}
S10:38.86 lwip: USING NARROWBAND TIMEOUTS
S10:39.78 sync: network: IP connect: waiting for connection for 0 sec (sent:0 rcvd:-3)
S10:40.79 sync: network: IP connect: waiting for connection for 1 sec (sent:0 rcvd:0)
S10:41.80 sync: network: IP connect: waiting for connection for 2 sec (sent:0 rcvd:0)
S10:42.81 sync: network: IP connect: waiting for connection for 3 sec (sent:0 rcvd:0)
S10:43.82 sync: network: IP connect: waiting for connection for 4 sec (sent:0 rcvd:0)
S10:44.83 sync: network: IP connect: waiting for connection for 5 sec (sent:0 rcvd:0)
S10:45.86 sync: network: IP connect: waiting for connection for 6 sec (sent:0 rcvd:0)
S10:46.87 sync: network: IP connect: waiting for connection for 7 sec (sent:0 rcvd:0)
S10:47.88 sync: network: IP connect: waiting for connection for 9 sec (sent:0 rcvd:0)
S10:48.89 sync: network: IP connect: waiting for connection for 10 sec (sent:0 rcvd:0)
the modems were working fine for several hours before. It seems that if it manages to connect, then it is more likely to work fine. Notecard is on Notecarrier-B powered by USB cable to computer.
Any idea of what could be going on? A nearby modem that works shows 4 bars of signal strength.
Also, which Notecard model and which antenna are you using? This seems like it could be a signal/connectivity issue that can manifest during TLS authentication since you’re sending a relatively large amount of data (~4KB) at the time.
Note that for the latest post I don’t get to the TLS step (maybe I should have opened a new thread), and it hasn’t had the chance to try and sync anything to notehub yet. Here’s the output from card.wireless at a later time:
Can you please try power-cycling the Notecard? This will force it to attempt a fresh connection to Notehub, just in case there was some issue with the handler you were connected to originally. Also, if you see that {extended-service-failure} again, please try issuing a manual hub.sync command to see if that helps.
I’ve tried to power-cycle (pulling EN low). I am seeing the same issue today with several different notecards. I do a manual hub.sync on startup, with allow = true so that it should be removed from any penalties. I’m inside a huge building, but I don’t see how this could break things. I’ve tried multiple antennas.
It takes a long time in “waiting for wireless service”, then fails somewhere during “IP connect”.