@WalkerYun It is more intersting which EUTRA band are supported, like in my result: >>> from network import LTE >>> lte=LTE() >>> print(lte.send_at_cmd('AT!="showver"')) SYSTEM VERSION ============== FIRMWARE VERSION Bootloader0 : 5.1.1.0 [39529] Bootloader1* : 6.0.0.0 [41019] Bootloader2 : 6.0.0.0 [41019] NV Info : 1.1,0,0 Software : 6.0.0.0 [41019] by robot-soft at 2018-12-13 21:41:15 UE : 6.0.0.0 COMPONENTS ZSP0 : 1.0.99-3171 ZSP1 : 1.0.98-3170 OK >>> print(lte.send_at_cmd('AT!="setDbgPerm full"')) OK >>> print(lte.send_at_cmd('AT!="showCaps"')) == CAPS config ============================= .Lock UE on SRV band : false .MFBI support : true .TM8 TDD support : false ============================================ == CAPS ==================================== . access stratum: R13 . catM : 1 . nb-IoT : 1 -- EUTRA bands -- . supported : 66/28/26/25/20/19/18/17/14/13/12/8/5/4/3/2/1 . board : 1/2/3/4/5/8/12/13/14/17/18/19/20/25/26/28/66 . admin : . pending admin : -- EUTRA carriers -- . admin : . pending admin : ============================================ OK Version 1.0r supports only a small setg of EUTRA bands, and if your provider uses these, than the device will not work.

Found the issue, appears like the pcb regulator causing the issue.

@misterlisty >>> from network import LTE >>> lte=LTE() >>> print(lte.send_at_cmd('AT!="showver"')) SYSTEM VERSION ============== FIRMWARE VERSION Bootloader0 : 5.1.1.0 [39529] Bootloader1* : 6.0.0.0 [41019] Bootloader2 : 6.0.0.0 [40343] NV Info : 1.1,0,0 Software : 6.0.0.0 [41019] by robot-soft at 2018-12-13 21:41:15 UE : 6.0.0.0 COMPONENTS ZSP0 : 1.0.99-3171 ZSP1 : 1.0.98-3170 OK >>>

Was this issue resolved? I am having the same problem with the lopy4.

It may be the case that I misunderstood the functionality of the Pygate. It looks like there's LoRa on the Pygate via the Semtech SX1257. If that's true, then my use-case would be resolved with GPy + Pygate. Can someone confirm that my original question had a flawed premise, and that GPy + Pygate would provide LoRaWAN gateway with cellular backhaul?

Gern geschehen. Grüße aus Dänemark

@jcaron Yes, you could make a simple passthrough script between UART0 and UART2 I think. That may however conflict with the normal LTA firmware, and you migth have to use WiPy firmware for the device, which ignores everything besides the ESP32. I do not know wheter is is fast enough, and you have to deal with the complete modem configuration. The physical UART pins to the modem seem accessible on FiPy only. On GPY, TX and RTS are connected internally.

@John-Baird Hi John, interesting comments. Thanks for your input. I gather you are using the deepsleep functionality of the unit. I find that the deepsleep call hangs periodically and needs to be helped along with a kick from the WDT every so often. The actual LTE communications part seems to work quite well once you work out how to drive it. I do find every so often that I get strange failures that are difficult to explain. I would be keen to understand the steps you have taken to achieve an acceptable degree of reliability, as I am sure are others. Do you use in sort of real time control within your application. I have a number of functions that need to happen on a periodic basis (from minutes to hours to days to monthly). I am just trying to get my mind around how I might be able to use the RTC for this. Working out how to initialise it/synchronise it is another challenge. I have a need to toggle an output pin every 2 seconds when my device is asleep. I sleep for 2 minutes at a time, to conserve power. I ended up having to resort to an external circuit to toggle the output as I could not see an easy way to do this with the FiPy. I could have probably used the ULP, but this is a bit beyond me at present.

I had a wild stab-in-the-dark this avo import time, network lte=network.LTE() def _getlte(): if not lte.isattached(): print('lte attaching '); lte.attach() while 1: if lte.isattached(): print(' OK'); break print('. ', end=''); time.sleep(1) _getlte() print ('try sending an SMS') lte.send_at_cmd('At+CMGF=1') # put it into text mode? lte.send_at_cmd('AT+SQNSMSSEND=61xxxxxxxxx,This is the SMS content') # where 61xxxxxxxxx' is a mobile number A doesn't work bench mark to start from?

@crumble That worked! Thank you so much! I just switched G7 to G9 and it worked like a charm!

Im not the correct person to answer your BLE queries. but if you let me know what they are Ill get them infront of someone who can and get you answers :) Otherwise. Awesome work :D

You have to go through all steps, the bootloader is not encrypted from the beginning. I am not sure about the error. Did you boot into bootloader mode, if not, that might be your problem.

@paul-thornton Thanks for your input, the probmlem was that we had connected some sensors on the pins that was shared with LTE.

@steve-williams , I did some power mesurements here on the same setup I mentioned in my previous post to give you a clear picture about the current consumption while the modem is trying to attach so as to help you identifying the problem , in first trial I intentionally powered off the CAT-M1 network in office and run a script on GPY trying to attach you can see that the modem current consumption increases after sending attach request and keep trying to attach periodically, you can see that the Avg.current consumption when trying to attach can reach 285mA (150mA more than normal). The following image is when CAT-M1 network is back online and attaching is successful :