At this point I’m not even sure what problem we’re trying to solve… so I’m going to recap the situation as I understand it, for once device.
You’ve got some tags in a 61,000ms scan class. This scan class is currently set to polled-read mode. The Communication Timeout for this device is set to 60,000ms. This is probably too high, since the diagnostics screenshot showed the max request duration to be ~3300ms.
Your real problem is that the network your on is constantly killing/closing the connection from the driver’s point of view. This causes your tags to go bad quality.
At this point a few things happen. First of all, the driver attempts to reconnect. This requires that it issues a connect request to get connected to the device. What happens next depends on your scan class mode. In subscribe mode the tags will immediately be subscribed when the device is connected and read. In polled-read mode your tags won’t get read until the next time the scan class executes. This is likely why your tags stay bad quality for a long time after the device disconnects, unless you happen to reconnect at a lucky point in the cycle. In a 61,000ms scan class this is already going to be painful, in a 1,000,000ms scan class like the other you posted you’re pretty much done for.
Given the propensity for your network to kill the connection, if you’re not willing to make your scan classes significantly faster I’m going to have to recommend you switch back to subscribed mode. The downside of this is increased “burstiness” in traffic upon reconnect, because now you’re not just sending a connect request but read requests as well. The upside is your tags come back to good quality faster after a reconnect.
Am I missing anything?