Fipy CANNOT connect to Pybytes using Verizon LTE



  • Hi,

    I have tried to activate my Fipy1.0 with ExpansionBoard 3.1 over Verizon LTE using an activation string auto-generated from the Pybytes platform. I got the errors below.

    >>> pybytes_config = PybytesConfig().read_config()
    >>> from _pybytes import Pybytes
    >>> pybytes = Pybytes(pybytes_config)
     ssl_params={'ca_certs': '/flash/cert/pycom-ca.pem'}
     ssl_params={'ca_certs': '/flash/cert/pycom-ca.pem'}
    WMAC: 840D8E120404
    Firmware: 1.20.2.r1
    Pybytes: 1.6.0
    >>> pybytes.activate("eyJjYXJyaWVyIjoidmVyaXpvbiIsImJhbmQiOjEzLCJjaWQiOjMsImFwbiI6ImludGVybmV0IiwidHlwZSI6IklQIiwicmVzZXQiOmZhbHNlLCJhIjoiYmViMWU1NGUtZTQ0My00Y2Y2LWJmY2EtZjljZjc0MDA5OTgxIn0=")
    Disconnecting current connection!
    self.__connection_status=0 | self.__network_type=None
    Already disconnected
    {'reset': False, 'carrier': 'verizon', 'apn': 'internet', 'cid': 3, 'band': 13, 'type': 'IP', 'a': 'beb1e54e-e443-4cf6-bfca-f9cf74009981'}
    performing LTE activation
    LTE init(carrier=verizon, cid=3)
    LTE attach(band=13, apn=internet, type=IP)
    LTE connect()
    LTE is_connected()
    LTE connection established
    Failed to send activation request!
    [Errno 113] ECONNABORTED
    Exception during WiFi cli activation!
    'NoneType' object has no attribute 'status_code'
    Activation failed!
    >>>
    

    I have also tried in REPL. Seems like I can resolve IP of Google, but unable to establish a connection. Please see the errors below.

    >>> import socket
    >>> import ssl
    >>> import time
    >>> from network import LTE
    >>> import pycom
    >>> lte = LTE(carrier="verizon")
    >>> lte.attach()
    >>> lte.connect(cid=3)
    >>> sockaddr = socket.getaddrinfo('www.google.com', 443)
    >>> print("socket address: {}".format(sockaddr))
    socket address: [(2, 1, 0, '', ('142.250.64.132', 443))]
    >>> s = socket.socket()
    >>> s.connect(sockaddr[0][-1])
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    OSError: [Errno 113] ECONNABORTED
    >>>
    

    Anyone could help or give some hints? I got stuck on this for days and tried almost everything I could find on this forum. The modem firmware is the last version.



  • @Gijs
    I have not tried to update the firmware, but it seems like my problem has been fixed.

    I have successfully established LTE connection and publish the data to a server over MQTT. For the very first time that the chip trying to connect to the internet, it takes a long time (5 min) from scanning to connected. I guess a better antenna can make this process faster.

    Now I have to face a new problem - unstable MQTT connection.
    My code publishes data every two seconds. 402 runs are the most runs that I can get. Most of the time my code was errored out by the error "OSError: [Errno 104] ECONNRESET" after 20 to 100 runs.

    It is also turned out that publishing a long string (e.g. "3.13, 5.75, 8.56, 98987.65464, 465.56412") usually could get more runs than publishing a short string (e.g. "3.13"), which confused me a lot.

    Run 399: publish data over the LTE...
    Run 400: publish data over the LTE...
    Run 401: publish data over the LTE...
    Run 402: publish data over the LTE...
    Traceback (most recent call last):
      File "main.py", line 81, in <module>
      File "/flash/lib/mqtt.py", line 120, in publish
    OSError: [Errno 104] ECONNRESET
    Pycom MicroPython 1.20.2.r1 [v1.11-a5aa0b8] on 2020-09-09; GPy with ESP32
    Type "help()" for more information.
    >>>
    

    Line 81 of my code.

    client.publish(topic = MQTTtopic , msg = "3.13, 5.75, 8.56, 98987.65464, 465.56412")
    

    Line 120 of MQTT library.

    self.sock.write(pkt, i + 1)
    

    I think I have faced the exactly the same problem when I played with my Wipy board (WiFi connection) and try to publish data through MQTT.

    How could I get a more rugged and stable data-publishing process?


  • Global Moderator

    Hi,
    Could you try to reinstall the LTE modem firmware using this: https://docs.pycom.io/updatefirmware/ltemodem/?
    Let me know!
    Gijs



  • I finally get it to work by changing to one of my AT&T Sim cards. And I realized that the Verizon Sim I tested before is assigned to a static IP bundled with another IMEI so that it won't work on other devices.

    It worked properly yesterday so that I can publish data using MQTT to one the server.

    However, problems arise again when I tried to work on this device today. I can not attach LTE anymore using the same code that worked yesterday. REPL continuously returns me SYSTEM FSM (I don't have print(lte.send_at_cmd('AT!="fsm"')) in my test code why it keep returning me system FSM??).

    SYSTEM FSM
    ==========
        +--------------------------+--------------------+
        |            FSM           |        STATE       |
        +--------------------------+--------------------+
        | RRC TOP FSM              |CAMPED              |
        | RRC SEARCH FSM           |CAMPED              |
        | RRC ACTIVE FSM           |IDLE                |
        | PMM PLMN FSM             |NORM_CAMPED         |
        | EMM MAIN FSM             |NULL                |
        | EMM AUTH FSM             |NULL                |
        | EMM CONN FSM             |NULL                |
        | EMM TAU FSM              |NULL                |
        | EMM TEST FSM             |NULL                |
        | ESM BEARER FSM           |BEARER_NULL         |
        | SMS MT FSM               |IDLE                |
        | SMS MO FSM               |IDLE                |
        | HP MAIN FSM              |IDLE                |
        | HP USIM FSM              |READY               |
        | HP SMS MO FSM            |IDLE                |
        | HP SMS MT FSM            |IDLE                |
        | HP CAT FSM               |IDLE                |
        +--------------------------+--------------------+
    
    OK
    
    .
    SYSTEM FSM
    ==========
        +--------------------------+--------------------+
        |            FSM           |        STATE       |
        +--------------------------+--------------------+
        | RRC TOP FSM              |CAMPED              |
        | RRC SEARCH FSM           |CAMPED              |
        | RRC ACTIVE FSM           |IDLE                |
        | PMM PLMN FSM             |NORM_CAMPED         |
        | EMM MAIN FSM             |NULL                |
        | EMM AUTH FSM             |NULL                |
        | EMM CONN FSM             |NULL                |
        | EMM TAU FSM              |NULL                |
        | EMM TEST FSM             |NULL                |
        | ESM BEARER FSM           |BEARER_NULL         |
        | SMS MT FSM               |IDLE                |
        | SMS MO FSM               |IDLE                |
        | HP MAIN FSM              |IDLE                |
        | HP USIM FSM              |READY               |
        | HP SMS MO FSM            |IDLE                |
        | HP SMS MT FSM            |IDLE                |
        | HP CAT FSM               |IDLE                |
        +--------------------------+--------------------+
    
    OK
    

    I also tried to reset the modem several times and set back to factory default, but none of the means fix this problem.

    >>> import sqnsupgrade
    >>> sqnsupgrade.info(debug=True)
    <<< Welcome to the SQN3330 firmware updater [1.2.6] >>>
    >>> GPy with firmware version 1.20.2.r1
    The current delay is 1000
    Response (+++ #1): None
    Response (AT #1) b'\r\nERROR\r\n'
    Response (AT #2) b'\r\nOK\r\n'
    Response (AT+SMOD?) b'\r\n2\r\nOK\r\n'
    Converting response: 2 to int...
    Modem state: 2
    Your modem is in application mode. Here is the current version:
    mirror? False  recover? False  resume? True  direct? True  atneg_only? False bootrom? False load_fff? False
    baudrate: 921600 target_baudrate: 921600
    SYSTEM VERSION
    ==============
      FIRMWARE VERSION
        Bootloader0* : 5.1.1.0 [43818]
        Bootloader1  : NA
        Bootloader2  : NA
        NV Info      : 1.1,0,0
        Software     : 5.1.1.0 [43818] by robot-soft at 2019-05-29 15:58:56
        UE           : 5.1.0.0f
      COMPONENTS
        ZSP0         : 1.0.99-13616
        ZSP1         : 1.0.99-12376
    
    IMEI: 354347092584462
    

    Anyone can give any hint? I appreciate it in advance.



  • @Mao
    Update.

    I found the reason why my Fipy kept disconnect and reconnect to REPL.

    I have used improper LTE antenna (Molex 824-2170MHz). After changing to an ultra-wideband antenna (TAOGLAS FXUB63), my device never disconnected from REPL anymore.

    I still cannot create a socket to connect to google.

    >>> import socket
    >>> from network import LTE
    >>> lte = LTE(carrier="verizon")
    >>> lte.isattached()
    False
    >>> lte.attach()
    >>> lte.isattached()
    True
    >>> lte.connect(cid=3)
    >>> lte.isconnected()
    True
    >>> sockaddr = socket.getaddrinfo('www.google.com', 80)
    >>> s = socket.socket()
    >>> s.connect(sockaddr[0][-1])
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    OSError: [Errno 113] ECONNABORTED
    >>>
    


  • Thank you, Gijs.

    I had tried both port 80 without SSL and port 443 using SSL. both returned me the same error. lte.isattached() returns me True.

    Now I'm facing a new problem:
    Every time after I tried to attach or connect the LTE, Fipy disconnected from the REPL and then reconnected and kept doing this for every half minute. I tried to reset the modem but didn't help. I felt I have destroyed something hardwarely... I will try to re-flash the firmware.

    >>> import socket
    >>> from network import LTE
    >>> lte = LTE(carrier="verizon")
    >>> lte.isattached()
    True
    >>> lte.attach()
    >>> lte.isattached()
    True
    >>> lte.connect(cid=3)
    >>> > Failed to connect (Error: Port is not open). Click here to try again.
    Connecting to COM13...
    

  • Global Moderator

    Hi,
    I do not see you checking lte.isattached() in the second flow.. It might take a while before the LTE connection attaches and connects. Other than that, the LTE version you are using (I believe its CAT M1) might not support the SSL (https socket 443), causing the ECONNABORTED

    Best,
    Gijs


Log in to reply
 

Pycom on Twitter