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
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;
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
so I can see what the default modem should be?
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 UE220.127.116.11d 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 UE18.104.22.168d whereas the dead ones reply PYCOM FiPy UE22.214.171.124d God knows how a cereg cmd makes the lte modem think its FiPy?!