I can confirm that I experienced a very similar issue in Georgia with an ATLGM and Quectel RG520F-EU modem.
In my case, the problem turned out to be related to the mobile operator/network rather than RouterOS itself or the LTE interface.
One important detail from my troubleshooting is that the problem was very difficult to identify using the RouterOS graphical interface or the normal RouterOS CLI alone. The situation became much clearer only after accessing the modem directly through AT commands.
I used AT commands to check the actual modem state, serving cell information and carrier aggregation, including commands such as:
AT+QCAINFO
as well as other Quectel diagnostic AT commands for serving-cell and network information.
These commands did not, by themselves, prove that the operator was responsible. However, they allowed me to see the actual state of the modem and the cellular connection at a level that was not visible through the normal RouterOS GUI or CLI. By combining this information with repeated tests and changing SIM cards/operators, I was able to identify a strong correlation with the mobile network.
In Georgia, I was able to reproduce the problem with MagtiCom. The connection to the MagtiCom network/cells was problematic and the modem could enter an abnormal state. When I tested SIM cards from other Georgian operators, particularly Geocell and Silknet, I experienced significantly more stable connectivity, better speeds, and I did not encounter the same connection problems.
After changing the operator/SIM card and configuring the connection correctly for the new operator, the problem completely disappeared.
I am now running RouterOS 7.24, the same version mentioned in this discussion, together with the RG520F-EU modem, and the ATLGM has been working flawlessly. I no longer need to disable/enable the LTE interface or use an LTE restart/watchdog script.
So, at least in my case in Georgia, changing the mobile operator and applying the correct operator settings resolved the issue without any additional LTE restart or watchdog configuration.
The important point is that AT-command diagnostics were essential for understanding what was happening. Without accessing the modem directly, it was extremely difficult to determine whether the problem was caused by RouterOS, the modem firmware, the LTE interface, or the mobile network.
My experience therefore suggests that similar ATLGM/RG520F-EU problems may depend strongly on the particular mobile operator and its network/BTS configuration. In my case, the problem was associated with MagtiCom, while Geocell and Silknet provided a much more stable connection with better performance.
For anyone troubleshooting a similar issue, I would recommend checking the modem directly with AT commands and testing the same hardware with another operator before adding LTE restart scripts or watchdogs. The problem may not necessarily be caused by RouterOS or the modem firmware.
