FiPy LTE-M: sometimes infinite RTC synch, unreachable port
I use a simple code where the FiPy connects to LTE-M eNB, synch to RTC, sends a MQTT packet and then go deepsleep. I'm using an emulated core network and EPC.
Sometimes, 1 out of 5 or 6 wakes-up, the FiPy is stuck in the RTC synch process. It seems that the UL request is ok, but I think the FiPy doesn't correctly get the answer. It shouldn't be a problem since radio problems can always occur, but here, since the socket is created, it sends requests with the wrong port. I can clearly see the wrong request with wireshark.
Even if I bypass the RTC connection, I get similar issues with the MQTT client.connect() stucks forever in the socket creation, blocking other thread (I create an alarm with machine.reset() as callback, but it is never called).
I don't know where is the problem, if it comes from pycom firmware or Sequans. For Sequans I'm on 35529. For the FiPy, I was on v1.20.0.rc4 but I switched to v1.18.1.rc2. I still have the problem, but less frequently.
@invalidname Hi. Look I can;t be certain. There are a bunch of reasons intial connects seems to fail, so I am aggressive with watchdog, so I wouldn't see anything hang for more than 15seconds ;-) But I do see WDT triggered whilst performing an RTC sync occasionally.
@timh I’m not sure it is the same problem. On my side the process seems block forever, as if there wasn’t any timeout set (I’m talking of tens of hours in RTC synch or MQTT connect). Is it the same thing on your side?
@invalidname I see this too at times with the initial MQTT connect taking a very long time. I am using the WDT so that recovers in this situation. (though to be honest I see this on Wifi as well LTE Cat M1 connections). I am using TLS so this handshake may well be taking too long.