Reliable LTE Reconnection

[grpatt]

Does anyone have a reliable reconnection code for GPy they are willing to share? I would like a constant connection and reconnection if there is a disconnect such as a LTE.EVENT_BREAK. Any advice?

My current solution will connect to the network but def lte_cb_handler(arg) tends to cause errors only resolved with a machine.reset().

from network import LTE
from machine import UART
import time
import utime
import os
import uos
import config
import json
import pycom
import gc
import utime
import machine

def send_at_cmd_pretty(cmd):
    response = lte.send_at_cmd(cmd).split('\r\n')
    for line in response:
        print(line)

lte = LTE()
lte.reset()
lte.init()
pycom.heartbeat(False)
pycom.rgbled(0xff00)           # turn on the RGB LED in green colour

def connect_LTE():
    send_at_cmd_pretty('AT+CGDCONT=1,"IP","hologram"')

    lte.attach()        # attach the cellular modem to a base station
    i = 0
    print("Attaching..",end='')
    while not lte.isattached():
        #lte = LTE()
        i = i + 1

        print('.',end='')
        if (i % 2 == 0):
            pycom.rgbled(0xFF0000)  # Red
            #print("Attached "+str(lte.isattached())+" Attached "+str(lte.isconnected()))
        else:
            pycom.rgbled(0x000000)  # off

        time.sleep(.25)
        if (i % 120 == 0):
            print(lte.send_at_cmd('AT!="fsm"'))



    print(" ")
    print("Attached")
    print("Connecting..",end='')
    pycom.rgbled(0x7f7f00) # yellow
    lte.connect()       # start a data session and obtain an IP address
    i = 0
    while not lte.isconnected():
        i = i + 1
        print('.',end='')

        if (i % 2 == 0):
            pycom.rgbled(0x00FF00)  # Green
        else:
            pycom.rgbled(0x000000)  # off

        time.sleep(0.25)


    pycom.rgbled(0x007f00) # green
    print(" ")
    print("Connected to LTE")

connect_LTE()



       def lte_cb_handler(arg):
######################################################################################
#                    reconnect after disconnect
#   
#                    not very reliable
######################################################################################
            print(" ")
            print("starting  handler")
            ev = arg.events() # NB: reading the events also clears them
            print("", time.time(), ev, time.gmtime())
            #pycom.rgbled(0x222200)
            if ev & LTE.EVENT_BREAK:
                print("", "uart break signal")
            print("", time.time(), "test connection")

            def test_connection():
                return False
            if test_connection():
                print("", time.time(), "connection ok")
            else:
                print("", time.time(), "connection not ok")
                
                lte.deinit()
                time.sleep(5)
                lte.init()
                lte.pppresume()
                connect_LTE()
                # connect_LTE()
                # TBD: implement handling of lost connection
                # machine.deepsleep(deepsleeptime)
        lte.lte_callback(LTE.EVENT_BREAK, lte_cb_handler)

[kjm]

We run some battery powered GPYs in a wakeup-take readings-send to server-10min deepsleep cycle. We've been plagued with OSErrors ('the requested operation failed' and 'Couldnt connect to Modem!') from lte.deinit(). We've been unable to resolve the issue but have made the following observations.

1. the lte struggles with marginal signal strengths (RSRP<-115dBm). Sites with RSRPs>-100dBm have almost zero OSErrors when attempting lte.deinit()
2. failure of the modem uart connection to the gpy has some sort of weird memory that persists for several minutes, so shortening the deepsleep or even recycling the gpy power don't fix it. Mercifully a 10 min deepsleep (or removing power for 10min) seems to fix the problem.
3. lte networks are cranky beasts & their operators provide no metrics for tower or back haul loading. So you can have a connection but still be unable to run data to your server or sync the rtc for several minutes at a time.

In non battery powered applications we tend to leave the modem connected (connections can persist for days at time). If we find we don't get a server response to uploads we simply reset the modem/gpy, deepsleep for a minute & start again.

[grpatt]

(2)That is odd a deep sleep for is needed to fix the modem uart. Hopefully we can find a more clean way to reconnect the modem. In the past, I have had to reflashed the firmware on the modem to solve the problem.

I'll try to implement the deep sleep to solve my problem but it seems like there is a better solution.