Is there a way to permanently disable the watchdog timer so that it never re-enables itself? I’m not sure if the re-enabling is a bug or a feature. The watchdog is a major annoyance for me because it disconnects me from the tower I want. So I have to login, and manually re-lock to the tower multiple times a day.
This is on v1.0.12 and I believe it was the same on the new version.
Hey @matt
How long do you have the watchdog timer set to?
I recommend maxxing that timer out, or at least bump it up to the next longest.
@ryan can explain it best, but if you have the cell tower lock feature in use and the tower to modem connection is lost, for any reason, the modem will not reconnect at all; though it may sometimes reconnect if the band/tower comes back…. Maybe.
This is an inherent internal Qualcomm firmware thing that we had to engineer a solution around to keep the modem online. Given time, or anorher reboot, it will reconnect to the locked cell. You shouldn’t need to reapply the cell lock; I believe.
Ryan can better tell what evolved from 1.0.10 to 1.0.12, and 1.0.14 for the cell locks, I think.
BUT I’d guess your watchdog is too tightly set maybe? This can cause unnecessary watchdog reboots a lot of times. It’s why we didn’t allow a lower time like 1 minute, and I don’t like them set to even 5 miniute timers.
To be clear, I completely disable the watchdog. But it will randomly enable itself at some point. That’s the part that confuses me (why doesn’t it stay disabled?). But I will try setting it to a higher value, to see if that helps. I will report back in a few days.
Do you have cell tower locks set? You stated in the first post you relock the cell tower. If you do, the watchdog will auto enable itself; again to keep the modem from losing connection permanently.
I totally get what you’re saying, and to that effect I think you’re saying you disable it so therefore there’s no point in changing the amount of time the watchdog checks. BUT because it enables itself when you set a cell tower lock, you then should go into the watchdog menu and change the time up to like 15 or 30 minutes whatever the highest is. can’t remember right now the longest time the watchdog offers on checks.
I manually lock to a tower PCI/FREQ pair and then I disable the watchdog. At some point, 1) the watchdog re-enables itself, and 2) I lose the tower lock. I’m not sure what order those two events happen (or if they’re related).
I am aware that locking to a tower re-enables the watchdog (I believe that is mentioned in the UI). But if I disable the watchdog after locking, it seems like it should stay disabled.
My wish is to always have a lock to my chosen tower (even if it is unavailable), and never have the device “helpfully” switch to a different tower (because the tower it chooses on its own is absolute garbage and no better than not having internet at all). Hope that makes sense.
Gotcha. Understood totally. The problem is, if for any reason the tower/band you are locked to has an issue and loses connectivity (as far as the pings and pageload testing is concerned, the modem will go completely offline and not recover.
This is was an early issue we found in the core Qualcomm functions. Nothing we did would get it back online without removing the cell lock. Because of this, and not wanting people to be offline without a recovery path, we chose to force a recovery route. Part of that recovery process is removing the cell lock, but it should re-apply it later I think. It only does what you are seeing (removing the cell lock) due to it seeing a loss of connection of some kind.
I get what you are saying though, you would prefer to choose on your own if you want it to do a recovery process or not.
Again @ryan should be better able to answer than I though
Hi @matt ,
Richard is correct. WatchDog can be disabled but not when a cell is locked because the default design path is to prevent the device from completely losing connectivity.
Many customers use their IG units at remote sites and require the confidence that they will always be able to reach their devices and connected local networks even if the preferred, locked cell becomes unavailable. Without this, if the locked cell goes down or has backhaul issues which prevent connected customers from being able to reach the internet, the IG would remain in a completely disconnected state until someone could physically be on-site to login and unlock the cell which is down. In prolonged cell outage situations, the modem may not be able to reconnect to the network using the locked cell unless/until the connection is rebuilt or the modem is restarted.
We can certainly consider this as a feature request for a future update but, just to clarify and ensure my understanding is correct, when your locked cell becomes unavailable, are you saying that you would like the unit to remain disconnected from the Internet for as long as the cell remains unavailable or has no path to the Internet? Unless the outage duration is momentary you would very likely need physical access to the device in order to power cycle it and restore connectivity on the locked cell later when it became available or to unlock the unavilable cell.
Thanks for the explanation. I’m surprised that a cell going down for long periods of time (or permanently) is a common enough occurrence that you need to design around it.
I’m now wondering if the “offline detector” code is a little too sensitive, which is why I get kicked off my tower so frequently. You can technically say the modem is offline if a single connection fails to your target endpoint. But I think multiple failed connections over 5 minutes would be a more reliable way to make that determination (but maybe you’re already doing something like that).
In any case, you are exactly right. I don’t want the Invisagig software to remove my tower lock under any circumstances. If I lock to a tower, I did it for a reason. In my ideal world, if the device was disconnected from the tower (or internet), the Invisagig would repeatedly try to re-connect to that specific tower on its own.
Increasing the watchdog interval didn’t do anything for me. So I may try writing a simple script to login to the invisagig, and check the status (and re-connect if necessary). Maybe a shell interface or API is in the works? That would be better than replaying HTTP requests!
@ryan on this one 
Yes, unfortunately it can be a common occurence in some areas where the infrastructure is either not well maintained physically, is frequently impacted by weather, or simply undersized for the subscriber density leading to sustained outages.
We have multi-tiered logic that checks for lost Internet connectivity over a time period as you described. This makes it resilient to short lived disruptions in connectivity. We can certainly look at including a power-user override of the default “safe” behavior but I think it is worth re-stating that even if the modem does keep attempting a handshake it may take a manual intervention such as a a full power cycle before it can complete connection. This simply depends on the health of the cell, what took it offline to begin with, and how long it takes to recover.
Currently we do have a basic read-only API that provides JSON output for monitoring but nothing permitting config changes outside of the UI at present. Stay tuned. Thank you very much for the feature requests and feedback!