Random NO CARRIER with SIM800/SIM900 modems (Adafruit FONA on Raspberry Pi)

We are using Konekt SIM cards in Adafruit FONA modems on a Raspberry Pi. We are using Raspbian and are using a chat script that looks like this:

ABORT		BUSY
ABORT		VOICE
ABORT		"NO CARRIER"
ABORT		"NO DIALTONE"
ABORT		"NO DIAL TONE"
ABORT		"NO ANSWER"
ABORT		"DELAYED"
ABORT		"ERROR"

# cease if the modem is not attached to the network yet
ABORT		"+CGATT: 0"

""		AT
TIMEOUT		31
OK		AT+CFUN=0
OK		AT+CFUN=1
Call\sReady	ATH
OK		ATE1

OK		AT+CGDCONT=1,"IP","\T","",0,0
OK		ATD*99#
TIMEOUT		22
CONNECT		""

This works fine on our devices, but randomly sometimes after restarting a device, we get a NO CARRIER error. Here’s a full log:

Mar 10 21:17:51 placemetersensor chat[2368]: abort on (BUSY)
Mar 10 21:17:51 placemetersensor chat[2368]: abort on (VOICE)
Mar 10 21:17:51 placemetersensor chat[2368]: abort on (NO CARRIER)
Mar 10 21:17:51 placemetersensor chat[2368]: abort on (NO DIALTONE)
Mar 10 21:17:51 placemetersensor chat[2368]: abort on (NO DIAL TONE)
Mar 10 21:17:51 placemetersensor chat[2368]: abort on (NO ANSWER)
Mar 10 21:17:51 placemetersensor chat[2368]: abort on (DELAYED)
Mar 10 21:17:51 placemetersensor chat[2368]: abort on (ERROR)
Mar 10 21:17:51 placemetersensor chat[2368]: abort on (+CGATT: 0)
Mar 10 21:17:51 placemetersensor chat[2368]: send (AT^M)
Mar 10 21:17:51 placemetersensor chat[2368]: timeout set to 31 seconds
Mar 10 21:17:51 placemetersensor chat[2368]: expect (OK)
Mar 10 21:17:51 placemetersensor chat[2368]: AT^M^M
Mar 10 21:17:51 placemetersensor chat[2368]: OK
Mar 10 21:17:51 placemetersensor chat[2368]:  -- got it
Mar 10 21:17:51 placemetersensor chat[2368]: send (AT+CFUN=0^M)
Mar 10 21:17:51 placemetersensor chat[2368]: expect (OK)
Mar 10 21:17:51 placemetersensor chat[2368]: ^M
Mar 10 21:17:51 placemetersensor chat[2368]: AT+CFUN=0^M^M
Mar 10 21:17:51 placemetersensor chat[2368]: +CPIN: NOT READY^M
Mar 10 21:17:54 placemetersensor chat[2368]: ^M
Mar 10 21:17:54 placemetersensor chat[2368]: OK
Mar 10 21:17:54 placemetersensor chat[2368]:  -- got it
Mar 10 21:17:54 placemetersensor chat[2368]: send (AT+CFUN=1^M)
Mar 10 21:17:54 placemetersensor chat[2368]: expect (Call Ready)
Mar 10 21:17:54 placemetersensor chat[2368]: ^M
Mar 10 21:17:55 placemetersensor chat[2368]: AT+CFUN=1^M^M
Mar 10 21:17:55 placemetersensor chat[2368]: +CPIN: READY^M
Mar 10 21:17:55 placemetersensor chat[2368]: ^M
Mar 10 21:17:55 placemetersensor chat[2368]: OK^M
Mar 10 21:17:56 placemetersensor chat[2368]: ^M
Mar 10 21:17:56 placemetersensor chat[2368]: SMS Ready^M
Mar 10 21:17:56 placemetersensor chat[2368]: ^M
Mar 10 21:17:56 placemetersensor chat[2368]: Call Ready
Mar 10 21:17:56 placemetersensor chat[2368]:  -- got it
Mar 10 21:17:56 placemetersensor chat[2368]: send (ATH^M)
Mar 10 21:17:56 placemetersensor chat[2368]: expect (OK)
Mar 10 21:17:56 placemetersensor chat[2368]: ATH^M^M
Mar 10 21:17:56 placemetersensor chat[2368]: OK
Mar 10 21:17:56 placemetersensor chat[2368]:  -- got it
Mar 10 21:17:56 placemetersensor chat[2368]: send (ATE1^M)
Mar 10 21:17:56 placemetersensor chat[2368]: expect (OK)
Mar 10 21:17:56 placemetersensor chat[2368]: ^M
Mar 10 21:17:56 placemetersensor chat[2368]: ATE1^M^M
Mar 10 21:17:56 placemetersensor chat[2368]: OK
Mar 10 21:17:56 placemetersensor chat[2368]:  -- got it
Mar 10 21:17:56 placemetersensor chat[2368]: send (AT+CGDCONT=1,"IP","apn.konekt.io","",0,0^M)
Mar 10 21:17:57 placemetersensor chat[2368]: expect (OK)
Mar 10 21:17:57 placemetersensor chat[2368]: ^M
Mar 10 21:17:57 placemetersensor chat[2368]: AT+CGDCONT=1,"IP","apn.konekt.io","",0,0^M^M
Mar 10 21:17:57 placemetersensor chat[2368]: OK
Mar 10 21:17:57 placemetersensor chat[2368]:  -- got it
Mar 10 21:17:57 placemetersensor chat[2368]: send (ATD*99#^M)
Mar 10 21:17:57 placemetersensor chat[2368]: timeout set to 22 seconds
Mar 10 21:17:57 placemetersensor chat[2368]: expect (CONNECT)
Mar 10 21:17:57 placemetersensor chat[2368]: ^M
Mar 10 21:17:57 placemetersensor chat[2368]: ATD*99#^M^M
Mar 10 21:17:57 placemetersensor chat[2368]: NO CARRIER
Mar 10 21:17:57 placemetersensor chat[2368]:  -- failed
Mar 10 21:17:57 placemetersensor chat[2368]: Failed (NO CARRIER)
Mar 10 21:17:57 placemetersensor pppd[2366]: Connect script failed

At the same time we can see that the modem has good signal strength and is connected to a carrier. This is from a screen session on a device that is exhibiting the above behaviour:

AT+COPS?
+COPS: 0,0,"T-Mobile USA"

OK
AT+CREG?
+CREG: 0,5

OK
AT+CGREG?
+CGREG: 0,5

OK
AT+CSQ
+CSQ: 27,0

OK

Any hints to what could cause this behaviour?

Thanks
Nik

Hey @nikhaldi,

Are you able to post a log of everything working? I want to see what feedback the module is giving you on a successful bootup.

Thanks,
PFW

Here’s the logs from a successful connection:

Mar 10 21:56:44 placemetersensor chat[5757]: abort on (BUSY)
Mar 10 21:56:44 placemetersensor chat[5757]: abort on (VOICE)
Mar 10 21:56:44 placemetersensor chat[5757]: abort on (NO CARRIER)
Mar 10 21:56:44 placemetersensor chat[5757]: abort on (NO DIALTONE)
Mar 10 21:56:44 placemetersensor chat[5757]: abort on (NO DIAL TONE)
Mar 10 21:56:44 placemetersensor chat[5757]: abort on (NO ANSWER)
Mar 10 21:56:44 placemetersensor chat[5757]: abort on (DELAYED)
Mar 10 21:56:44 placemetersensor chat[5757]: abort on (ERROR)
Mar 10 21:56:44 placemetersensor chat[5757]: abort on (+CGATT: 0)
Mar 10 21:56:44 placemetersensor chat[5757]: send (AT^M)
Mar 10 21:56:44 placemetersensor chat[5757]: timeout set to 31 seconds
Mar 10 21:56:44 placemetersensor chat[5757]: expect (OK)
Mar 10 21:56:44 placemetersensor chat[5757]: AT^M^M
Mar 10 21:56:44 placemetersensor chat[5757]: OK
Mar 10 21:56:44 placemetersensor chat[5757]:  -- got it
Mar 10 21:56:44 placemetersensor chat[5757]: send (AT+CFUN=0^M)
Mar 10 21:56:44 placemetersensor chat[5757]: expect (OK)
Mar 10 21:56:44 placemetersensor chat[5757]: ^M
Mar 10 21:56:44 placemetersensor chat[5757]: AT+CFUN=0^M^M
Mar 10 21:56:44 placemetersensor chat[5757]: +CPIN: NOT READY^M
Mar 10 21:56:46 placemetersensor chat[5757]: ^M
Mar 10 21:56:46 placemetersensor chat[5757]: OK
Mar 10 21:56:46 placemetersensor chat[5757]:  -- got it
Mar 10 21:56:46 placemetersensor chat[5757]: send (AT+CFUN=1^M)
Mar 10 21:56:47 placemetersensor chat[5757]: expect (Call Ready)
Mar 10 21:56:47 placemetersensor chat[5757]: ^M
Mar 10 21:56:50 placemetersensor chat[5757]: AT+CFUN=1^M^M
Mar 10 21:56:50 placemetersensor chat[5757]: +CPIN: READY^M
Mar 10 21:56:50 placemetersensor chat[5757]: ^M
Mar 10 21:56:50 placemetersensor chat[5757]: OK^M
Mar 10 21:56:58 placemetersensor chat[5757]: ^M
Mar 10 21:56:58 placemetersensor chat[5757]: SMS Ready^M
Mar 10 21:56:58 placemetersensor chat[5757]: ^M
Mar 10 21:56:58 placemetersensor chat[5757]: Call Ready
Mar 10 21:56:58 placemetersensor chat[5757]:  -- got it
Mar 10 21:56:58 placemetersensor chat[5757]: send (ATH^M)
Mar 10 21:56:58 placemetersensor chat[5757]: expect (OK)
Mar 10 21:56:58 placemetersensor chat[5757]: ^M
Mar 10 21:56:58 placemetersensor chat[5757]: ATH^M^M
Mar 10 21:56:58 placemetersensor chat[5757]: OK
Mar 10 21:56:58 placemetersensor chat[5757]:  -- got it
Mar 10 21:56:58 placemetersensor chat[5757]: send (ATE1^M)
Mar 10 21:56:58 placemetersensor chat[5757]: expect (OK)
Mar 10 21:56:58 placemetersensor chat[5757]: ^M
Mar 10 21:56:58 placemetersensor chat[5757]: ATE1^M^M
Mar 10 21:56:58 placemetersensor chat[5757]: OK
Mar 10 21:56:58 placemetersensor chat[5757]:  -- got it
Mar 10 21:56:58 placemetersensor chat[5757]: send (AT+CGDCONT=1,"IP","apn.konekt.io","",0,0^M)
Mar 10 21:56:58 placemetersensor chat[5757]: expect (OK)
Mar 10 21:56:58 placemetersensor chat[5757]: ^M
Mar 10 21:56:58 placemetersensor chat[5757]: AT+CGDCONT=1,"IP","apn.konekt.io","",0,0^M^M
Mar 10 21:56:58 placemetersensor chat[5757]: OK
Mar 10 21:56:58 placemetersensor chat[5757]:  -- got it
Mar 10 21:56:58 placemetersensor chat[5757]: send (ATD*99#^M)
Mar 10 21:56:58 placemetersensor chat[5757]: timeout set to 22 seconds
Mar 10 21:56:58 placemetersensor chat[5757]: expect (CONNECT)
Mar 10 21:56:58 placemetersensor chat[5757]: ^M
Mar 10 21:56:58 placemetersensor chat[5757]: ATD*99#^M^M
Mar 10 21:56:58 placemetersensor chat[5757]: CONNECT
Mar 10 21:56:58 placemetersensor chat[5757]:  -- got it
Mar 10 21:56:58 placemetersensor chat[5757]: send (^M)
Mar 10 21:56:58 placemetersensor pppd[3607]: Serial connection established.
Mar 10 21:56:58 placemetersensor pppd[3607]: Using interface ppp0
Mar 10 21:56:58 placemetersensor pppd[3607]: Connect: ppp0 <--> /dev/ttyAMA0
Mar 10 21:56:59 placemetersensor ifplugd(ppp0)[5769]: ifplugd 0.28 initializing.
Mar 10 21:56:59 placemetersensor ifplugd(ppp0)[5769]: Using interface ppp0/00:00:00:00:00:00
Mar 10 21:56:59 placemetersensor ifplugd(ppp0)[5769]: Using detection mode: IFF_RUNNING
Mar 10 21:56:59 placemetersensor ifplugd(ppp0)[5769]: Initialization complete, link beat detected.
Mar 10 21:56:59 placemetersensor ifplugd(ppp0)[5769]: Executing '/etc/ifplugd/ifplugd.action ppp0 up'.
Mar 10 21:56:59 placemetersensor ifplugd(ppp0)[5769]: client: Ignoring unknown interface ppp0=ppp0.
Mar 10 21:56:59 placemetersensor ifplugd(ppp0)[5769]: Program executed successfully.

Hey @nikhaldi,

Not trying to ask a dumb question, but, how are you powering the board? What’s the max current of the power supply you’re using?

Can you attach a voltmeter to the circuit that provides power to the SIM card and see if the board is powering down the SIM on an unsuccessful boot?

Thanks,
PFW

The max current is 2A.

We don’t do any special power management to the Adafruit FONA module (I assume you mean power to the GSM module, not power to the SIM card). We provide steady 4V to the module when the device is on.

If you can tap into the power line between the module and the SIM card, that can be really telling, for two reasons:

  • Insufficient power or a poor connection with the holder can cause SIM cards to malfunction intermittently
  • SIM900 modules and their predecessors have a history of switching off the SIM card when some problems occur, which can cause certain commands to fail and a connection to drop, and such problems can be caused simply by different network/tower timings (this is fixable though)

Ok, so just for the record, this is what we’re getting if we take out the SIM card, which I assume would be similar to when power to it is shut off:

Mar 10 21:17:51 placemetersensor chat[2364]: abort on (BUSY)
Mar 10 21:17:51 placemetersensor chat[2364]: abort on (VOICE)
Mar 10 21:17:51 placemetersensor chat[2364]: abort on (NO CARRIER)
Mar 10 21:17:51 placemetersensor chat[2364]: abort on (NO DIALTONE)
Mar 10 21:17:51 placemetersensor chat[2364]: abort on (NO DIAL TONE)
Mar 10 21:17:51 placemetersensor chat[2364]: abort on (NO ANSWER)
Mar 10 21:17:51 placemetersensor chat[2364]: abort on (DELAYED)
Mar 10 21:17:51 placemetersensor chat[2364]: abort on (ERROR)
Mar 10 21:17:51 placemetersensor chat[2364]: abort on (+CGATT: 0)
Mar 10 21:17:51 placemetersensor chat[2364]: send (AT^M)
Mar 10 21:17:51 placemetersensor chat[2364]: timeout set to 31 seconds
Mar 10 21:17:51 placemetersensor chat[2364]: expect (OK)
Mar 10 21:17:51 placemetersensor chat[2364]: AT^M^M
Mar 10 21:17:51 placemetersensor chat[2364]: OK
Mar 10 21:17:51 placemetersensor chat[2364]:  -- got it
Mar 10 21:17:51 placemetersensor chat[2364]: send (AT+CFUN=0^M)
Mar 10 21:17:51 placemetersensor chat[2364]: expect (OK)
Mar 10 21:17:51 placemetersensor chat[2364]: ^M
Mar 10 21:17:51 placemetersensor chat[2364]: AT+CFUN=0^M^M
Mar 10 21:17:51 placemetersensor chat[2364]: OK
Mar 10 21:17:51 placemetersensor chat[2364]:  -- got it
Mar 10 21:17:51 placemetersensor chat[2364]: send (AT+CFUN=1^M)
Mar 10 21:17:51 placemetersensor chat[2364]: expect (Call Ready)
Mar 10 21:17:51 placemetersensor chat[2364]: ^M
Mar 10 21:17:52 placemetersensor chat[2364]: AT+CFUN=1^M^M
Mar 10 21:17:52 placemetersensor chat[2364]: +CPIN: NOT INSERTED^M
Mar 10 21:17:56 placemetersensor chat[2364]: ^M
Mar 10 21:17:56 placemetersensor chat[2364]: OK^M

And from there it doesn’t progress.

We have a lead that the AT+CFUN in our chat scripts may be causing problems. Investigating that at the moment.

FYI: If a SIM800/SIM900 module switches the SIM card off, you won’t receive the +CPIN: NOT INSERTED URC. Same thing for power brown-outs (see http://www.8051projects.net/lofiversion/t31231/sim300-cpinready-again-after-few-minutes-ready.html — same is true for later SIMxxx moduels).

Keep us posted!

FYI, we have resolved this particular issue. The problem were the CFUN calls we included in our chat script. This was an attempt to force a reset of the module, but clearly it doesn’t work the way we expected. We had put the CFUN call in originally to try to work around other issues. We removed the CFUN calls, but this means we are looking to fix those other issues.

Created a separate thread on those issues: https://community.konekt.io/t/connectivity-issue-with-adafruit-fona-and-raspberry-pi/249

Thanks for the update, @nikhaldi! Glad to hear that!

To add some context and to help other users:

The symptoms experienced in this thread with the SIM800/SIM900 series modems are almost undoubtedly caused by a SIM-related issue. When the SIM is working (+CPIN: READY) and the network is being joined on the circuit-switched service just fine (Call Ready), and then suddenly stops working with the SIM-not-ready error (+CPIN: NOT READY), that’s an indication that the SIM is working when initially receiving power, but later is not functioning within the module properly.

In the case of the the SIM800/SIM900 modems, like used in the Adafruit FONA board, a SIM that works initially but later stops working can be caused by (in order of greatest- to least-likelihood):

  • Improper incoming power supply to the SIM800/SIM900 (insufficient current leading to a “brown-out” condition on the SIM)
  • Bad connection between SIM card and SIM card socket
  • The SIM800/SIM900 entering a state (possibly an error state) that switches off the SIM card completely until the module is power cycled
  • Improper filtering on incoming power to module, or between the module and the SIM card causing weird interference on the SIM card upon transmit (note: this does not apply to users of the Adafruit FONA board, since they have proper filtering)
  • Antenna connector or antenna placement issue causing interference to the SIM card (note: this does not seem to apply to users of the Adafruit FONA board)

To tell if this is happening, monitoring the power line between the SIM800/SIM900 modem and the SIM card using a voltmeter can be very revealing, because it at least allows a user to detect if the SIM800/SIM900 modem is switching off the SIM, which I suspect was the case for you.

It seems that issuing the AT+CFUN command you were using for resetting the module was causing power to be cut to the SIM card in an undesirable way.

Thanks,
PFW

@nikhaldi and team,

If you don’t mind pasting a copy of your working PPP CHAT script here, then that could also help other users.

TIA,
PFW

The chat script causing problems was the one included in the original question. The one that works (mostly) just has the two CFUN lines removed.

Hi @HologramPat I am facing the Same issue ( ATD* 99# or ATD* 99#; or ATD* 99***1# RESPONDING with NO CARRIER ) with SIM7600EI Module, my power supply is fine
Thanks in Advance
hat[12902]: send (ATD *99#^M)
timeout set to 22
Connect script failed

@Shaik_Moin is your device connected to a network? Try running these AT commands and post the replies.

AT+COPS?

AT+CREG?

AT+CGREG?

AT+CSQ

@benstr Thanks for the reply
Yes My device is connected with Network
Module is responding correctly with above commands, as I am able to get name of operator selection, sim is registered with network, signal strength is good and i can able to get service provider name too…

Hi there,

I use the Nova with a Hologram SIM card. The SIM is working out-of-the-box on an Android Tablet.

The Nova is now plugged on our Linux board. Since I was not able to make it work with a provider file and a chat script, I went with AT commands to debug.

So I do: minicom -D /dev/ttyACM0 -b 9600 and get:

> AT
> OK
> ATI
> SARA-U201-03B-00
> 
> OK
> AT+CGMI
> u-blox
> 
> OK
> AT+CGMM
> SARA-U201
> 
> OK
> AT+GMM
> SARA-U201
> 
> OK
> AT+CSQ
> +CSQ: 99,99
> 
> OK
> AT+CCID
> +CCID: 8***********4
> 
> AT+CPIN?
> +CPIN: READY
> 
> OK
> AT+COPS?
> +COPS: 0
> 
> OK
> AT+COPS=?
> +COPS: ,,(0-6),(0-2)
> 
> OK
> ATI
> SARA-U201-03B-00
> 
> OK
> AT+CGMI
> u-blox
> 
> OK
> AT+CGMM
> SARA-U201
> 
> OK
> AT+GMM
> SARA-U201
> 
> OK
> AT+CSQ
> +CSQ: 99,99
> 
> OK
> AT+CCID
> +CCID: 8944500301190503084
> 
> OK
> AT+CPIN?
> +CPIN: READY
> 
> OK
> AT+CFUN?
> +CFUN: 4,0
> 
> OK
> AT+CREG?
> +CREG: 0,0
> 
> OK
> AT+CGREG?
> +CGREG: 0,0
> 
> OK
> AT+CGDCONT?
> +CGDCONT: 1,"IP","hologram","0.0.0.0",0,0
> 
> OK
> AT+CGACT?
> +CGACT: 1,0
> 
> OK
> AT+COPS?
> +COPS: 0
> 
> OK
> AT+COPS=?
> +COPS: ,,(0-6),(0-2)
> 
> ATDT99**1#
> NO CARRIER
> ATDT*99***1#
> +CME ERROR: 148
> ATD*99***1#
> +CME ERROR: 148

At the end one can see the NO CARRIER response.

I’m using a SOM, an iMX6ULL from Toradex with the Viola carrier board.

Thank you for your time.

PS : Since a previous question was closed and send there I also jumped in. I can create a new question.

Hi @mthpvgm,

+CFUN: 4,0 indicates that your device is in airplane mode. You can set the device to full-functionality by running AT+CFUN=1.

Hi @sara,

Thanks for your help. I guess that airplane mode did not help :smile:.

It looks better now, I can see carrier names, CSQ is not 99 anymore but the connection is still not possible.

ATI
SARA-U201-03B-00

OK
AT+CGMI
u-blox

OK
AT+CSQ
+CSQ: 20,2

OK
AT+CPIN?
+CPIN: READY

OK
AT+COPS?
+COPS: 0,0,"Salt",2

OK
AT+COPS=?
+COPS: (2,"Salt","Salt","22803",2),(1,"Swisscom","Swisscom","22801",2),(1,"Swisscom","Swisscom","22801",0),(2,"Salt",)

OK
AT+CFUN?
+CFUN: 1,0

OK
AT+CGREG?
+CGREG: 0,0

OK
AT+CGDCONT?
+CGDCONT: 1,"IP","hologram","0.0.0.0",0,0

OK
AT+CGACT?
+CGACT: 1,0

OK
ATDT*99***1#
CONNECT
~ÿ}#À!}!}!} }4}"}&} } } } }%}&°¿}*¬}'}"}(}"}<Ê~~ÿ}#À!}!}!} }4}"}&} } } } }%}&ʰ¿}*¬}'}"}(}"}<Ê~~ÿ}#À!}!}!} }4}"}&} } }~
NO CARRIER
ATDT99**1#
NO CARRIER
ATD*99***1#
CONNECT
~ÿ}#À!}!}!} }4}"}&} } } } }%}&êz}'}"}(}"}=ß~~ÿ}#À!}!}!} }4}"}&} } } } }%}&êz}'}"}(}"}=ß~~ÿ}#À!}!}!} }4}"}&} } } } }%}~
NO CARRIER
AT+CSQ
+CSQ: 19,2

OK

I’m staying in that thread, if that’s still ok, since I still get that NO CARRIER message.

Do you see the “CONNECT” response? That means its working. The issue is that you’re trying to start a data session inside of your terminal program and it doesn’t know what to do with that. You need to use some sort of PPP daemon.

As we can see in my previous post, yes I see the CONNECT response.
Thanks @Reuben, now that this part is working, I’ll go back to ppp.

1 Like