MicroPython Forum (Archive)

I'm using an rpi pico with an NB-IoT cell modem https://www.waveshare.com/w/upload/c/c2 ... NB-IoT.pdf  The pico-modem interface is simple, just a uart connection for AT cmds & a single gpio line to turn the modem power supply on/off

My initial program worked   
Then I tried to get clever by replacing the sleep with dormant https://github.com/ghubcoder/PicoSleepD ... -945177298 for lower power consumption.  Now the connect to cell AT cmd fails after the first cycle. This was a big surprise since the pico-to-modem uart comms & gpio pwr on/off line post dormancy behave exactly the same as post sleep.
I finally got it going with a kludgy work around. I've got my 1mA dormancy Vs 18mA sleep but there are 2 things I don't understand, why the AT connect cmd fails after a dormancy & why resetting the pico post dormancy fixes it.

From your description it would seem that after the dormant period the Pico can communicate with the modem. The fact that failure occurs on the connect to cell command suggests it may be a power problem on the modem board which will suddenly require a lot more power. The schematic is pretty illegible so it's hard to be sure, but maybe the modem power supply isn't re-initialising properly.

FWIW my experience with Waveshare hardware is dire. Two display units bought from different suppliers each with different hardware faults.

A Sim7020E can pull over 130 mA when connecting to a weak LTE signal. I'm wondering if dormant is doing any power supply tricks, such as toggling the on-board SMPS Power Save pin.

Thnx for the input fellas. I ditched the waveshare, got a new pico & wired it's uart to a sim7020e breakout board which I powered separately to the pico (which is still powered from the USB). So now when the pico goes dormant the modem stays powered. On the second run of the program the modem connect cmd again fails so I figure the problem has to be something to do with the uart even though I can't see any difference on the pico uart Tx line with a DSO.

I really expected the modem to remain connected after the first dormancy so how the uart activity during or after the first dormancy is disconnecting it (& why the machine.reset() prevents it happening) has got me beat. I guess put the machine.reset() back in after the dormancy & learn to live with it.

That sounds very odd indeed. You've got me stumped

Doesn't make any sense eh Peter. Guess I should be grateful the bug remains stable with a change of hardware.

I finally got to the bottom of this. The dormancy leaves the pico with a uart unable to send or receive more than 32 chrs. So when the modem returns
b'at+cgcontrdp\r\r\n+CGCONTRDP: 1,5,"telstra.internet","10.108.59.111.255.255.255.0",,"101.168.244.106","10.4.130.164",,,,,1500 for the connect cmd the pico sees only
b'at+cgcontrdp\r\r\n+CGCONTRDP: 1,5,

Good bit of detective work. I suggest producing a simple test case and raising an issue.