@Eugenio-Bubba Do you mean core dump? And also show software version: print(os.uname()) add also print('deepsleep') statement before machine.deepsleep() to see if core dump is after going to sleep

Does it always stop working at that line? Did you try without WLAN, or changing the order to see if it works? Could you try lte = LTE(debug=True) to see additional debug information? And lastly, you could check the free memory using this function: def memory(): machine.info() print("GC free=", gc.mem_free(), "alloc=", gc.mem_alloc(), "total=", gc.mem_alloc() + gc.mem_free()) # micropython.mem_info() print("mp stack", micropython.stack_use()) print("heap internal", pycom.get_free_heap()[0]) print("heap external", pycom.get_free_heap()[1]) With the appropriate imports Let me know!

@livius Haha :) The noise is only present when the GPy is in the testing room. We tested just the GPy attached to the expansion board in the room to make sure it could have only been the GPy.

Result: The testing facility had equipment to simulate a base station inside the testing room and provided us with a special SIM which connected to it (on LTE band 20 - 800MHz). We could then use our normal MicroPython code to send a ping lte.send_at_cmd('AT!="IP::ping 8.8.8.8"') or send data over a socket connection. [image: 1620129486650-lte-cat-m1-b20-847mhz-30-1000mhz-tx-on-vp-full-eut-5.3.2021-1.59.55-pm.png]

(2)That is odd a deep sleep for is needed to fix the modem uart. Hopefully we can find a more clean way to reconnect the modem. In the past, I have had to reflashed the firmware on the modem to solve the problem. I'll try to implement the deep sleep to solve my problem but it seems like there is a better solution.

The MQTT library should work fine over LTE (we use it in Pybytes as well), though it seems the address resolver cannot find your mqtt server. the EAI_FAIL (Error Address Information) is caused by the DNS lookup failing, unrelated to the MQTT protocol.

@techykermit how you wire looks like? If you simply use this pin not connected then you got this behavior If you connect it to GND by wire you will see pin in wake_reason(). If you have e.g. button wired to this pin you must look at debounce. Add e.g. 100nF ceramic capacitor should fix problem.

@carl-declercq Best of luck, let me know if you need any further help!

@hammerfet have you had success at this lately? Just getting started with lte and will try telenor and telia.

@kjm Just ran into the SQNINS=0 issue myself; I get the same output whether 0 or 1 is specified for full or fast scanning. Can anyone provide insight into this?

@kjm Thanks a lot. print(lte.send_at_cmd('AT+CGCONTRDP')) works! It gives +CGCONTRDP: 1,5,"telstra.internet.xxx.yyy.gprs","10.247.zz.gg.255.255.255.255","","10.4.hh.ii","10.5.jjj.kk","","" 10.247.zz.gg is the local ip address. Sad it is not public ip. Cheers, Paul

@Gijs said in WiFi AP: I looked at this for a long time, but then figured it out Hi @Gijs I really appreciate the support you’ve given me. I have testes, everything all right. Regards, Vojtech

What happens after you call py.go_to_sleep(), is the Pytrack coprocessor cuts off the supply power to the microcontroller. This is the lowest power sleep state available. On the accelerometer wake, the coprocossor switches the power back on, meaning the Gpy will boot up as if it was just plugged in (starting with boot.py and continuing in main.py). If you have a pytrack 1, you do not have to use the workaround provided in the link I posted. The suggestion to wait 10 minutes is because sometimes you have to wait for traffic lights and such, where you do not want to turn off the tracker. I would take the inactivity interrupt (which follows the activity interrupt, when the movement is on the falling edge) from the accelerometer, and note down the time. Then, in the main loop check that time against the current time and see if the 10 minutes have passed. If so, go to sleep and make it wake on accelerometer. You'll have to set the sensitivity just correct that it does not wake up on small movements of entering and exiting the caravan, but that it does trigger on driving it on the road I presume.

Hi, did you find a solution to this?

Hi, Over the last year we have changed a big part of our LTE stack, including changing the CEREG setting (in version 1.20.2.r2). Check whether the CEREG setting is set to 1, or change it to 1 using the following: from network import LTE lte = LTE() print(lte.send_at_cmd('AT+CEREG=1'))

@Gijs THX :) i also found a script of an member using lte on MQTT - the only problem I have that after some minutes I get back OSError: [Errno 104] ECONNRESET is this problem on my side ( LTE connection down )? I also try to figure out why on one loop the print("") comes random and on a other loop it stay on one spot..

https://forum.pycom.io/topic/6835/camera-uart-reading-pycom?_=1613190557153 I did get a better camera working.

I'm using 100 ms for that genuine HIGH state on the GPy after a successfull Data transmission at the moment and after 1.5 days I can say it works so far. :) Thanks for the help again!