More lte woes



  • Got a problem with our latest shipment of GPYs

    >>> import sqnsupgrade; sqnsupgrade.info()
    <<< Welcome to the SQN3330 firmware updater [1.2.6] >>>
    >>> GPy with firmware version 1.20.0.r4
    Your modem is in application mode. Here is the current version:
    UE5.0.0.0d
    LR5.1.1.0-43818
    
    IMEI: 354347094478663
    >>> from network import LTE
    >>> lte=LTE()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    OSError: Couldn't connect to Modem!
    lte = LTE(debug=True)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: extra keyword arguments given
    

    any thoughts on what to do next?



  • @peterp The ticks_ms problem test program

    import machine, network, time, os; start=time.ticks_ms()
    def _t(): t=(time.ticks_ms()-start)/1000; return '%02d'%t
    
    print(os.uname())
    print(_t(), 'start')
    epoch=1625789769; date=time.gmtime(epoch); rtc=machine.RTC(); rtc.init(date)
    print(_t(), 'lte'); lte=network.LTE()
    print(_t(), 'attach', end=' '); lte.attach()
    while 1:
     print('.', end=' '); time .sleep(1)
     if lte.isattached(): print(); print(_t(), 'connect'); lte.connect(); break
    print(_t(), 'rtc')
    rtc.ntp_sync('time.google.com')
    while 1:
      print('.', end=' '); time .sleep(1)
      if rtc.synced(): print(); break
    #print(_t(), 'suspend'); lte.pppsuspend()
    print(_t(), 'deinit'); lte.deinit()
    print(_t(), 'deepsleep'); machine.deepsleep(9000)
    

    and the results

    (sysname='GPy', nodename='GPy', release='1.20.2.r4', version='v1.11-ffb0e1c on 2021-01-12', machine='GPy with ESP32', pybytes='1.6.1')
    00 start
    2292128 lte
    2292131 attach . . 
    2292138 connect
    2292139 rtc
    . 
    2295011 deinit
    2295018 deepsleep
    

    where the ticks_ms value is changed by rtc.init and rtc.ntp_sync



  • @peterp the ticks_ms value is altered by rtc.init & subsequently rtc.ntp_sync in 1.20.2.r4. So if we're using tick_ms to record elapsed time from program start & we subsequently use rtc.init the elapsed time continuity is lost. Curiously rtc.ntp_sync doesn't effect ticks_ms if rtc.init hasn't been used previously. Will do another post to illustrate the problem.

    Regarding the lte modem. It's only when we use suspend followed by deinit (the combo that gives the shortest time to deepsleep & therefore our preference) that the modem is disconnected on resume after deepsleep. Results below.

    The test program with modem version 48829

    import machine, network, time, os; start=time.ticks_ms()
    def _t(): t=(time.ticks_ms()-start)/1000; return '%02d'%t
    
    print(os.uname())
    print(_t(), 'lte'); lte=network.LTE()
    print(_t(), 'attach', end=' '); lte.attach()
    while 1:
     print('.', end=' '); time .sleep(1)
     if lte.isattached(): print(); print(_t(), 'connect'); lte.connect(); break
    print('rtc')
    rtc=machine.RTC()
    rtc.ntp_sync('time.google.com')
    while 1:
      print('.', end=' '); time .sleep(1)
      if rtc.synced(): print(); break
    print(_t(), 'suspend'); lte.pppsuspend()
    print(_t(), 'deinit'); lte.deinit()
    print(_t(), 'deepsleep'); machine.deepsleep(9000)
    

    With suspend removed, longest time to deepsleep, runs after deepsleep

    (sysname='GPy', nodename='GPy', release='1.20.2.r4', version='v1.11-ffb0e1c on 2021-01-12', machine='GPy with ESP32', pybytes='1.6.1')
    00 lte
    02 attach . . 
    09 connect
    rtc
    . 
    11 deinit
    19 deepsleep
    

    with deinit removed, also runs after deepsleep but the indignity of modem current during deepsleep

    (sysname='GPy', nodename='GPy', release='1.20.2.r4', version='v1.11-ffb0e1c on 2021-01-12', machine='GPy with ESP32', pybytes='1.6.1')
    00 lte
    02 attach . . 
    09 connect
    rtc
    . 
    11 suspend
    15 deepsleep
    

    our preference, shortest time to deepsleep, no modem current during deepsleep, but won't run again after deepsleep due modem disconnected

    (sysname='GPy', nodename='GPy', release='1.20.2.r4', version='v1.11-ffb0e1c on 2021-01-12', machine='GPy with ESP32', pybytes='1.6.1')
    00 lte
    02 attach . 
    03 connect
    rtc
    . 
    05 suspend
    09 deinit
    09 deepsleep
    

    If someone bothers to delve into the 1.20.2.r4/48829 entrails there are a couple of other issues:
    import sqnsupgrade; sqnsupgrade.info() always gives a core dump on the gpy
    at+cereg no longer provides TAC/eNBID info like it used to as per the sequans manual, just replies with OK now


  • Global Moderator

    ticks_ms

    why can you not use ticks_ms in 1.20.2.r4?

    modem_state=disconnected after deepsleep

    That's an interesting observation that it happens with 1.20.2.r4/48829, but not with 1.20.0.r1/48829. I would have to look into that. If I understand correctly, your reproduction is this:

    # first run
    init
    attach
    connect
    suspend
    deinit
    deepsleep
    
    # second run
    init <-- modem_state=disconnected
    attach
    connect
    suspend
    deinit
    deepsleep
    

    Yes?

    Maybe this is something we could protect against. What if you resume before deinit?

    Would you be able to test with 1.20.2.r4 and latest catm fw?



  • @peterp I have a question about 1.20.2.r4. In the old 1.20.0.r1/43818 combo we've been using time.ticks_ms() was a good way to track program flow in that it steadily increased from the first time it was called so that a diagnostic print always showed elapsed time from program start. In 1.20.2.r4 time.ticks_ms() is altered by rtc changes (eg rtc.ntp_sync). Is there any chance that time.ticks_ms() might revert to being rtc independent like it use to be?

    There also seems to be a problem with the 1.20.2.r4/48829 combo on a gpy in that the lte=LTE() after a deepsleep gives 'Couldnt connect to Modem (modem_state=disconnected)', the only way to fix this is to manually remove power for half a minute or so. This problem seems to be related to the 1.20.2.r4 rather than the 48829 since it doesn't happen with 1.20.0.r1/48829

    The culprit seems to be lte.pppsuspend()

    import machine, network, time; start=time.time()
    def _t(): t=time.time()-start; return '%02d'%t
    
    print(_t(), 'lte'); lte=network.LTE()
    print(_t(), 'attach', end=' '); lte.attach()
    while 1:
     print('.', end=' '); time .sleep(1)
     if lte.isattached(): print(); print(_t(), 'connect'); lte.connect(); break
    #print(_t(), 'suspend'); lte.pppsuspend()
    print(_t(), 'deinit'); lte.deinit()
    print(_t(), 'deepsleep'); machine.deepsleep(9000)
    

    in that the second run of the program above always gives

    OSError: Couldn't start connection to Modem (modem_state=disconnected)
    

    if we leave the suspend line in


  • Global Moderator

    @kjm said in More lte woes:

    So is there any non Pybytes firmware

    Let me chime in here on the notion of "non Pybytes" firmware. I think there are some lingering misconceptions about this.

    There really isn't such a thing as a supported "non-Pybytes firmware". Simplified(1), there is only really one firmware. "The Firmware". In the installer this is called "Pybytes" (2). This one firmware has a number of features, such as LoRa, UART, SPI, Pybytes, etc. Most people don't use all of those features and that's perfectly fine. Don't need it? Don't use it. That holds for the Pybytes feature exactly as it holds for everything else.

    I understand that in the past there was some frustration because the Pybytes feature was always on and hard to disable. Today (and for quite some time now) this isn't true anymore. pycom.pybytes_on_boot(False) is basically what constitues a "non-Pybytes firmware". The feature will not consume any ram or cpu if it is not running. Don't need it. Don't use it. Same as with Wifi, Lora, SPI, younameit.

    Now, "The Firmware", is actively developed. New features are being added. Bugs are fixed and new releases are made. For archival purposes (e.g., regression testing) we keep the old images around, but that's just what they are: Old versions, frozen in time. Whatever features or bugs they had is what is preserved. There will not be any new releases based on 1.20.0.x New releases will be a continuation of 1.20.2.x. If you have specific reasons of running old software, be aware that this is what you chose to do: Running old software. By definition it doesn't have new features or bugfixes that came with later versions.

    Hope this helps

    [1] I'm simplifying here. There ARE multiple supported firmwares: Pybytes, Pygate, Pymesh, self compiled, and then there are alpha/beta releases for new development. But these don't pertain to the conversation here. See also here: https://docs.pycom.io/updatefirmware/device/

    [2] In retrospect "Pybytes" is probably not the best name for this, but due to historical reasons, this is what it's called. It's just a name. Substitute it with "Default", or "The Firmware", or "Normal".


  • Global Moderator

    Well, the thing is that after 1.20.0.rc13, we always included the Pybytes library in the firmware. This should be no issue for you if you do not want to use Pybytes (you can disable it by using import pycom; pycom.pybytes_on_boot(False), now it will never attempt to create a Pybytes connection). If you really want to not include the Pybytes library in your firmware, you can still compile your own, and do not include the VARIANT keyword.



  • So is there any non pybytes firmware that lte=LTE(debug=1) works with? I loaded the latest I can find (1.20.0.rc13) but it doesn't like that cmd either


  • Global Moderator

    I think the LTE debug argument was introduced in one of the later versions (beyond 1.20.0.r4), it would be interesting to also see sqnsupgrade.info(debug=True) as it tests different baudrates. Though I would suspect the LTE modem to respond in any case..

    Let me know!


Log in to reply
 

Pycom on Twitter