GPY loss of attachment ability



  • I've managed to get 2 GPY lte modems into a state where they can no longer attach, presumably because of an AT cmd sequence

    lte.send_at_cmd('AT+CEREG=2;+CEREG?;+CEREG=0') 
    

    I was evaluating. Since I'm now down to only one working GPY I've been trying to get them working again. So far I've tried;
    ATZ
    AT^RESET
    AT+SQNSFACTORYRESET followed by AT^RESET
    and reflashing the modems firmware
    to no avail. Can anybody suggest something I haven't thought of? I guess I'm after something to erase the modem flash where it keeps the persistent results of changes wrought by AT cmds
    Is there anybody with a surplus of GPYs willing to risk

    lte.send_at_cmd('AT+CEREG?') 
    

    so I can see what the default modem should be?



  • Hi,
    Over the last year we have changed a big part of our LTE stack, including changing the CEREG setting (in version 1.20.2.r2). Check whether the CEREG setting is set to 1, or change it to 1 using the following:

    from network import LTE
    lte = LTE()
    print(lte.send_at_cmd('AT+CEREG=1'))
    


  • I know this is a year later, but I'm in a similar boat .. my Pycom is now reporting same thing. I'm running FiPy though, 1.20.2.r4 ... everything was running just fine and I brought it in to flash from r1 to r4 then this happened. Its actually happened to 3x of mine now. So something isn't happy.

    
    PYCOM
    FiPy
    UE5.0.0.0d
    
    OK


  • I maybe got a clue to what's going on https://forum.pycom.io/topic/4915/gpy-pytrack-modem-won-t-attach-after-firmware-upgrade/7 with responses to print(lte.send_at_cmd("ATI"))
    My one working GPY responds SEQUANS Communications VZM20Q UE5.0.0.0d whereas the dead ones reply PYCOM FiPy UE5.0.0.0d God knows how a cereg cmd makes the lte modem think its FiPy?!


Log in to reply
 

Pycom on Twitter