More lte woes

[kjm]

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?

[Gijs]

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!

[kjm]

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

[Gijs]

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.

[peterp]

@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".

[kjm]

@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

[peterp]

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?

[kjm]

@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

[kjm]

@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