News:

PROTON pic BASIC Compilers for PIC, PIC24, dsPIC33

Main Menu

SIM800L strange behavior

Started by Giuseppe, Jul 02, 2025, 07:54 AM

Previous topic - Next topic

Giuseppe

I made a GSM combiner based on SIM800L module. With one module I have no problems. The combiner works correctly. However, using other GSM modules always sim800L the combiner does not work. I sent the ATI command in response I have the SIM800 version in my case R 14.18 which is the same both in the ok module and in the non-functioning one. Then with the At&V command I display all the values ��set in the 2 modules. Comparing the parameter list there are some differences. Can you help me understand which values ��I have to change to make the non-functioning module work? Below I put the value list

(Module sim800L not working)
DEFAULT PROFILE
S0: 0
S3: 13
S4: 10
S5: 8
S6: 2
S7: 60
S8: 2
S10: 15
+CRLP: 61,61,48,6
V: 1
E: 1
Q: 0
X: 4
&C: 1
&D: 1
+CLTS: 0
+CREG: 0
+CGREG: 0
+CMEE: 0
+CIURC: 1
+CFGRI: 2
+CMTE: 0
+CANT: 0,0,10
+STKPCIS: 0
+CMGF: 0
+CNMI: 2,1,0,0,0
+CSCS: "IRA"
+VTD: 1
+CALS: 1
+CHF: 0
+CAAS: 1
+CBUZZERRING: 0
+DDET: 0
+MORING: 0
+SVR: 16
+CCPD: 1
+CSNS: 0
+CSGS: 1
+CNETLIGHT: 1
+SLEDS: 64,64,64,800,3000,300
+CSDT: 0
+CSMINS: 0
+EXUNSOL: 0
+FSHEX: 0
+FSEXT: 0
+CCTURI: 0
+IPR: 0
+IFC: 0,0
+CSCLK: 0

USER PROFILE
S0: 0
S3: 13
S4: 10
S5: 8
S6: 2
S7: 60
S8: 2
S10: 15
+CRLP: 61,61,48,6
V: 1
E: 1
Q: 0
X: 4
&C: 1
&D: 1
+CLTS: 0
+CREG: 0
+CGREG: 0
+CMEE: 0
+CIURC: 1
+CFGRI: 2
+CMTE: 0
+CANT: 0,0,10
+STKPCIS: 0
+CMGF: 0
+CNMI: 2,1,0,0,0
+CSCS: "IRA"
+VTD: 1
+CALS: 1
+CHF: 0
+CAAS: 1
+CBUZZERRING: 0
+DDET: 0
+MORING: 0
+SVR: 16
+CCPD: 1
+CSNS: 0
+CSGS: 1
+CNETLIGHT: 1
+SLEDS: 64,64,64,800,3000,300
+CSDT: 0
+CSMINS: 0
+EXUNSOL: 0
+FSHEX: 0
+FSEXT:
S6: 2
S7: 60

S6: 2
S7: 60
IPR: 0
+IFC: 0,0
+CSCLK: 0

ACTIVE PROFILE
S0: 0
S3: 13
S4: 10
S5: 80,0,10
+STKPCIS0,0,10
+STKPCIS+CRLP: 61,61,48,6
V: 1
E: 1
Q: 0
X: 4
&C: 1
&D: 1
+CLTS: 0
+CREG: 0
+CGREG: 0
+CMEE: 0
+CIURC: 1
+CFGRI: 2
+CMTE: 0
+CANT: : 0
+CMGF: 0
+CNMI: 2,1,0,0,0
+CSCS: "IRA"
+VTD: 1
+CALS: 1
+CHF: 0
+CAAS: 1
+CBUZZERRING: 0
+DDET: 0
+MORING: 0
+SVR: 16
+CCPD: 1
+CSNS: 0
+CSGS: 1
+CNETLIGHT: 1
+SLEDS: 64,64,64,800,3000,300
+CSDT: 0
+CSMINS: 0
+EXUNSOL: 0
+FSHEX: 0
+FSEXT: 0
+CCTURI: 0
+IPR: 0
+IFC: 0,0
+CSCLK: 0
OK
'----------------------------------------------------------------------------------------------------------------------(Module Sim800L that works)
DEFAULT PROFILE
S0: 0
S3: 13
S4: 10
S5: 8
S6: 2
S7: 60
S8: 2
S10: 15
+CRLP: 61,61,48,6
V: 1
E: 1
Q: 0
X: 4
&C: 1
&D: 1
+CLTS: 0
+CREG: 0
+CGREG: 0
+CMEE: 0
+CIURC: 1
+CFGRI: 2
+CMTE: 0
+CANT: 0,0,10
+STKPCIS: 0
+CMGF: 0
+CNMI: 2,1,0,0,0
+CSCS: "IRA"
+VTD: 1
+CALS: 1
+CHF: 0
+CAAS: 1
+CBUZZERRING: 0
+DDET: 0
+MORING: 0
+SVR: 16
+CCPD: 1
+CSNS: 0
+CSGS: 1
+CNETLIGHT: 1
+SLEDS: 64,64,64,800,3000,300
+CSDT: 0
+CSMINS: 0
+EXUNSOL: 0
+FSHEX: 0
+FSEXT: 0
+CCTURI: 0
+IPR: 0
+IFC: 0,0
+CSCLK: 0

+CRLP: 61,61,4
+CRLP: 61,61,4S0: 0
S3: 13
S4: 10
S5: 8
S6: 2
S7: 60
S8: 2
S10: 15CMTE: 0
+CANT:CMTE: 0
+CANT:
Q: 0
X: 4
&C: 1
&D: 1
+CLTS: 0
+CREG: 0
+CGREG: 0
+CMEE: 0
+CIURC: 1
+CFGRI: 2
+ 0,0,10
+STKPCIS: 0
+CMGF: 1
+CNMI: 2,1,0,0,1
+CSCS: "IRA"
+VTD: 1
+CALS: 1
+CHF: 0
+CAAS: 1
+CBUZZERRING: 0
+DDET: 0
+MORING: 0
+SVR: 16
+CCPD: 1
+CSNS: 0
+CSGS: 1
+CNETLIGHT: 1
+SLEDS: 64,64,64,800,3000,300
+CSDT: 0
+CSMINS: 0
+EXUNSOL: 0
+FSHEX: 0
+FSEXT: 0
+CCTURI: 0
+IPR: 9600
+IFC: 0,0
+CSCLK: 0

ACTI0
X: 4
&C: 1
0
X: 4
&C: 1
0
S3: 13
S4: 10
S5: 8
S6: 2
S7: 60
S8: 2
S10: 15
+CRLP: 61,61,48,6
V: 1
E: 0
Q: &D: 1
+CLTS: 0
+CREG: 0
+CGREG: 0
+CMEE: 0
+CIURC: 1
+CFGRI: 2
+CMTE: 0
+CANT: 0,0,10
+STKPCIS: 0
+CMGF: 1
+CNMI: 2,1,0,0,1
+CSCS: "IRA"
+VTD: 1
+CALS: 1
+CHF: 0
+CAASHEX: 0
+FSEXT:SHEX: 0
+FSEXT:NG: 0
+DDET: 0
+MORING: 0
+SVR: 16
+CCPD: 1
+CSNS: 0
+CSGS: 1
+CNETLIGHT: 1
+SLEDS: 64,64,64,800,3000,300
+CSDT: 0
+CSMINS: 0
+EXUNSOL: 0
+F 0
+CCTURI: 0
+IPR: 9600
+IFC: 0,0
+CSCLK: 0
OK


kcsl

From what I can see in your profiles, the non-working module has auto-baud enabled (+IPR=0) and is in PDU mode (+CMGF=0), whereas your working module is set to fixed baud at 9600 and SMS text mode. Try sending these commands to the non-working module:

AT+IPR=9600
AT+CMGF=1
AT&W

Regards,
Joe
There's no room for optimism in software or hardware engineering.

Giuseppe

Setting these commands with a serial
AT+IPR=9600
AT+CMGF=1
AT&W
the module stores them and keeps them in memory even if I remove the power?
thanks to all

kcsl

The fact that you have two modules returning different parameters seems to imply parameters are stored within the device.
But you should test for yourself with your modules.

Change some settings, cycle the power and then read back the settings and compare.

Regards,
Joe
There's no room for optimism in software or hardware engineering.

trastikata

For similar devices you need to send "AT" after reset until you receive "OK" response, otherwise they might miss the first few commands, something like:

Repeat
        SerOut PORTC.6, 84, ["AT",13]
        GoSub CHECK_RESPONSE
        DelayMS 500
    Until RESPONSE = "OK"

Yasin

Quote from: Giuseppe on Jul 03, 2025, 03:39 PMSetting these commands with a serial
AT+IPR=9600
AT+CMGF=1
AT&W
the module stores them and keeps them in memory even if I remove the power?
thanks to all

Yes

Giuseppe

I noticed that if I send the command AT+IPR=9600 on the GSM board I also receive the echo of the command + ok as a response. While trying only the Sim800L module in serial I only receive the ok from the module. Why does this happen?

top204

#7
To stop a modem echoing back what is sent to it serially, it is usually the "ATE0" command that needs to be sent first, and it will respond with an "OK".

After that, it stay silent until it returns a command's response.

I had a modem initialisation routine that was first called when the program started, and it waited for all the pointless texts a modem usually transmits when it is first powered up, to finish, then set up the modem for its defaults. So the "ATEO" and other commands were sent before any other communications were carried out, and the modem was indicated to be functioning.