FiPy LTE hangs / freezes board for seconds

[railmonitor]

Hello.

I read the following post: https://forum.pycom.io/topic/4070/lte-init-deinit-freezes-the-entire-board-for-some-seconds

And upon testing with newest firmware, i was able to confirm this behavior (both with and without using threading).

I have downloaded the firmware for the LTE here, upon advice from @robert-hh : http://stiny.webd.pl/PYCOM/

So i am running with the NB1-41019 version, which is the newest i can find.

Now since the LTE modem init / deinit hangs, i am just about to stop using the FiPy, because this makes the platform unusable for the purpose i need it for (continual sensor monitoring with data transfer to IoT Hub, need to be able to read a sensor at any time, even if connecting etc.)

But before i throw the towel in the ring, i wanted to ask, if there is any news regarding a fix to the LTE?

Also i read about a newer version (https://forum.pycom.io/topic/3985/new-lte-firmware-releases-v1-18-1-r4-stable-1-19-0-b5-development-nb-iot-firmware-40343)

But all i can find is the 41019 version. Can anyone give me a link, so i can see if a newer version is available, and if it makes changes to the LTE performance?

I really hope that there is a solution for the issue, since the FiPy in most other regards fits my project well.

[railmonitor]

@peterp Tried that, did not help. But i have now found out that the problem is caused by the timer-alarms alone, not because of actually transferring. If i put the transfer inside a while loop instead, with a 4 second sleep interval, i dont have the same delay... So if you want precise timing of events, you can only use a single timer-alarm, which is kinda bad, since Timer-alarms are otherwise a good way of ensuring precise timing..

[peterp]

@railmonitor maybe multithreaded? https://docs.pycom.io/firmwareapi/micropython/_thread

[railmonitor]

@peterp I realize that it is maybe inefficient to connect and disconnect so often, this i can tweak for sure. But the problem is also seen when i publish to the IOT hub. Every time i transfer data, there is also a delay in the readings from the accelerometer, at least when looking at the timestamps. This is the worst bit, since i want to be able to get accurate measurements with timestamps, even while transferring. I naturally try to connect / publish etc. while there is not any activity, but i must be able to detect and start measuring at any time. If i run this code (I have my LTE and IOT methods in seperate classes):

py = Pysense()
acc = LIS2HH12()
im = iothub_module()
lm = LTE_Module()
db = db_module()


lm.LTEconnect()
lm.setRTC()
im.iot_connect()

data = []
int_counter = 0

def sample():
    sample = acc.acceleration()
    time_to_convert = lm.getRTC()
    data = str(sample)+' at: '+str(time_to_convert)+', '
    print(data)

def publisher():
    timestamp = lm.getRTC()
    publishedData = "Hi at "+str(timestamp)
    im.iot_publish(publishedData)

sampling_timer = Timer.Alarm(lambda x: sample(), s = 1, periodic = True)
publish_timer = Timer.Alarm(lambda y: publisher(), s=4, periodic = False)

The output is this:

As you can see, the first four measurements happens in correct order with a second apart. The next four are delayed because of the publish to IoT Hub creates the delay.

Is there any way to work around this?

[kjm]

@peterp said in FiPy LTE hangs / freezes board for seconds:

I'm still thinking about this. I'm just curious whether there is something going on that we should be aware of.

I think a lot of us feel there is more going on with the lte modem than meets the eye Peter. Do you know why more recent firmwares (eg NBIoT 40343 & catm1 43818) are not available for download @ https://software.pycom.io/downloads/sequans2.html ? I personally feel I could make better progress if I could swap firmwares amongst modems in an effort to trace problems to hardware or firmware.

[andreas]

Dear Peter,

we tried to do it that way because the community has been unsure whether this would save additional power - which we wanted to achieve. There are different advises within the forum regarding this detail. We are invoking this directly after system start [1], not even just before going to deepsleep, in order to save maximum power - given it will actually do the right thing here. We are always happy to learn more or otherwise.

However, there are countless obstacles like this and different attempts to mitigate them. Please don't worry too much about that specific one.

With kind regards,
Andreas.

[1] https://github.com/hiveeyes/terkin-datalogger/blob/3cb8d98c/src/lib/terkin/device.py#L302-L345

[peterp]

@andreas said in FiPy LTE hangs / freezes board for seconds:

we used these parameters in order to shut down the modem even without using it, because we didn't want to invoke things like [1].

I'm still thinking about this. Are you saying you don't want to use the LTE modem at all? Why do you lte.deinit(something) anyway? Can't you just not instantiate lte = LTE() in the first place? I'm just curious whether there is something going on that we should be aware of.

[peterp]

@andreas said in FiPy LTE hangs / freezes board for seconds:

@peterp said in FiPy LTE hangs / freezes board for seconds:

for detach=False to make sense, you have to configure PSM first.

Thanks! I have to admit that we used these parameters in order to shut down the modem even without using it, because we didn't want to invoke things like [1]. As the default of detach happens to be True [2], we thought it would be a good idea to disable it in order to reduce communication delays coming from [1].

We don't know how this will actually relate to actually using the modem with or without PSM, so sorry for the noise.

[1] https://github.com/pycom/pycom-micropython-sigfox/blob/v1.20.2.rc6/esp32/mods/modlte.c#L878-L888
[2] https://github.com/pycom/pycom-micropython-sigfox/blob/v1.20.2.rc6/esp32/mods/modlte.c#L534

No problem! Maybe I need to clarify: It could be that there are use cases where detach=False is useful even without PSM, I haven't looked deeply. Thanks for the pointers.

[andreas]

@peterp said in FiPy LTE hangs / freezes board for seconds:

for detach=False to make sense, you have to configure PSM first.

Thanks! I have to admit that we used these parameters in order to shut down the modem even without using it, because we didn't want to invoke things like [1]. As the default of detach happens to be True [2], we thought it would be a good idea to disable it in order to reduce communication delays coming from [1].

We don't know how this will actually relate to actually using the modem with or without PSM, so sorry for the noise.

[1] https://github.com/pycom/pycom-micropython-sigfox/blob/v1.20.2.rc6/esp32/mods/modlte.c#L878-L888
[2] https://github.com/pycom/pycom-micropython-sigfox/blob/v1.20.2.rc6/esp32/mods/modlte.c#L534

[peterp]

Hi @railmonitor

Why do you have to initialize/deinit it often? That should be more like a one off exercise, no?

Also have a look at my post here: https://forum.pycom.io/topic/5547/power-saving-mode-psm-in-nb-iot-problems-with-reconnecting-after-deepsleep/3
this should allow you to attach faster (not needed at all actually), if that helps you...

@andreas said in FiPy LTE hangs / freezes board for seconds:

lte.deinit(detach=False, reset=True)

for detach=False to make sense, you have to configure PSM first.

[andreas]

Dear @railmonitor,

did you already try lte.deinit(detach=False, reset=True)? This might speed up the invocation, however I don't have a clue about side effects. You might want to report back about that.

With kind regards,
Andreas.