Errors sending SMS with EG06-E with both QMI and AT commands

I’m trying to use a EG06-E (firmware EG06ELAR04A03M4G) to send SMS messages with the TELMORE operator in Denmark (23801) in its own home network. I’m using ModemManager on a Linux based system, and I’ve attempted to send SMS messages using both plain AT commands and also with QMI commands.

The SMSC is configured correctly according to CSCA?
# mmcli -m 1 --command=“AT+CSCA?”
response: ‘+CSCA: “+4540390999”,145’

Testing with AT commands (PDU edited with XXXX on purpose), I get CMS error 350 reported after several minutes:

Mon May 11 17:17:33 2020 (ttyUSB2): --> 'AT+CMGS=23<CR>'
Mon May 11 17:17:33 2020 (ttyUSB2): <-- '<CR><LF>> '
Mon May 11 17:17:33 2020 (ttyUSB2): --> '0001000A91549208XXXX00000CE8329BFD7EBFDFEFF7FB0D\26'
Mon May 11 17:19:48 2020 (ttyUSB2): <-- '<CR><LF>+CMS ERROR: 350<CR><LF>'

If I try CMGW to store first and CMSS to send from storage, the same error is reported.

When using the QMI protocol (Raw Send command, WMS 0x0020), the error received is a “MessageDeliveryFailure” of type “Temporary” (again, PDU edited with XXXX on purpose).

[11 May 2020, 17:08:07] [Debug] [/dev/cdc-wdm0] sent message...
<<<<<< RAW:
<<<<<<   length = 43
<<<<<<   data   = 01:2A:00:00:05:02:00:0D:00:20:00:1E:00:01:1B:00:06:18:00:00:01:00:0A:91:54:92:08:XX:XX:00:00:0C:E8:32:9B:FD:7E:BF:DF:EF:F7:FB:0D

[11 May 2020, 17:08:07] [Debug] [/dev/cdc-wdm0] sent generic request (translated)...
<<<<<< QMUX:
<<<<<<   length  = 42
<<<<<<   flags   = 0x00
<<<<<<   service = "wms"
<<<<<<   client  = 2
<<<<<< QMI:
<<<<<<   flags       = "none"
<<<<<<   transaction = 13
<<<<<<   tlv_length  = 30
<<<<<<   message     = "Raw Send" (0x0020)
<<<<<< TLV:
<<<<<<   type       = "Raw Message Data" (0x01)
<<<<<<   length     = 27
<<<<<<   value      = 06:18:00:00:01:00:0A:91:54:92:08:XX:XX:00:00:0C:E8:32:9B:FD:7E:BF:DF:EF:F7:FB:0D
<<<<<<   translated = [ format = 'gsm-wcdma-point-to-point' raw_data = '{ [0] = '0 ' [1] = '1 ' [2] = '0 ' [3] = '10 ' [4] = '145 ' [5] = '84 ' [6] = '146 ' [7] = '8 ' [8] = 'XX ' [9] = 'XX ' [10] = '0 ' [11] = '0 ' [12] = '12 ' [13] = '232 ' [14] = '50 ' [15] = '155 ' [16] = '253 ' [17] = '126 ' [18] = '191 ' [19] = '223 ' [20] = '239 ' [21] = '247 ' [22] = '251 ' [23] = '13 '}' ]


[11 May 2020, 17:10:22] [Debug] [/dev/cdc-wdm0] received message...
<<<<<< RAW:
<<<<<<   length = 29
<<<<<<   data   = 01:1C:00:80:05:02:02:0D:00:20:00:10:00:02:04:00:01:00:38:00:01:02:00:8D:00:13:01:00:00

[11 May 2020, 17:10:22] [Debug] [/dev/cdc-wdm0] received generic response (translated)...
<<<<<< QMUX:
<<<<<<   length  = 28
<<<<<<   flags   = 0x80
<<<<<<   service = "wms"
<<<<<<   client  = 2
<<<<<< QMI:
<<<<<<   flags       = "response"
<<<<<<   transaction = 13
<<<<<<   tlv_length  = 16
<<<<<<   message     = "Raw Send" (0x0020)
<<<<<< TLV:
<<<<<<   type       = "Result" (0x02)
<<<<<<   length     = 4
<<<<<<   value      = 01:00:38:00
<<<<<<   translated = FAILURE: Wms.MessageDeliveryFailure
<<<<<< TLV:
<<<<<<   type       = "Message ID" (0x01)
<<<<<<   length     = 2
<<<<<<   value      = 8D:00
<<<<<<   translated = 141
<<<<<< TLV:
<<<<<<   type       = "Message Delivery Failure Type" (0x13)
<<<<<<   length     = 1
<<<<<<   value      = 00
<<<<<<   translated = temporary

If instead of using “WMS Raw Send” I use “WMS Raw Write” (0x0021) first and then “WMS Send From Memory Storage” (0x0042), the result is the same.

Googling about the problem I found similar errors reported in Sierra modules as well, so I wonder if it’s something coming from the generic Qualcomm base layer software.

I’ve tried to reconfigure the SMSC address using AT+CSCA to e.g. remove the “+” or remove the full country prefix “+45”, or replace it with “0045”… but none of those attempts worked properly, they’re all timing out in the same way.

The same SIM card is able to send SMS messages correctly when tested on a phone.

Any idea what could be happening here?

Hello Aleksander,

By experience, this error is usually due to destination is unreachable, more exactly it’s unreachable for current sim card. SMSC center send response the error directly.
You can try to send SMS to another number, you can even send SMS to module itself. Therefore you can make sure whether SMS function works or not.
If you want to doube confirm this issue, you would need to capture a log to check the network trace. Have you ever used Qlog tool in linux?

Best Regards,

Hey @WillieYao-Q thanks for the reply. I’ve retested the issue with a different SIM card of a different operator (Telia) and using a different target number to send the SMS to, and I still see the same issues. I’ve run the QLog tool while reproducing the problem, here is the captured trace, could you give it a look?. This is with a Quectel EG06-E running firmware EG06ELAR03A05M4G.

The trace should contain 2 SMS send attempts using the QMI protocol (WMS Send Raw command). One of the replies from the modem is as follows:

Thu May 14 08:55:34 2020 daemon.debug [1206]: [/dev/cdc-wdm0] received generic response (translated)... <<<<<< QMUX: <<<<<< length = 28 <<<<<< flags = 0x80 <<<<<< service = "wms" <<<<<< client = 2 <<<<<< QMI: <<<<<< flags = "response" <<<<<< transaction = 13 <<<<<< tlv_length = 16 <<<<<< message = "Raw Send" (0x0020) <<<<<< TLV: <<<<<< type = "Result" (0x02) <<<<<< length = 4 <<<<<< value = 01:00:38:00 <<<<<< translated = FAILURE: Wms.MessageDeliveryFailure <<<<<< TLV: <<<<<< type = "Message ID" (0x01) <<<<<< length = 2 <<<<<< value = 03:00 <<<<<< translated = 3 <<<<<< TLV: <<<<<< type = "Message Delivery Failure Type" (0x13) <<<<<< length = 1 <<<<<< value = 00 <<<<<< translated = temporary

And the SMSC is configured as follows:
# mmcli -m 0 --command="AT+CSCA?"
response: '+CSCA: "+4528187000",145'

Thanks!

HI Aleksander,

Checked this log, I didn’t find any SMS sending command. Can you kindly re-capture it by following procedure:

  1. Start logging
  2. AT+CFUN=0
  3. wait 1s
  4. AT+CFUN=1
  5. send SMS via AT command
  6. wait “+CMS ERROR: 350”
  7. stop logging.

Best Regards,

Hey @WillieYao-Q the test was done using QMI, not AT commands. Doesn’t the trace I captured contain any QMI command? How do you configure QLog to capture the necessary info to debug this issue while using QMI instead of AT?

I’ll try to gather traces while using AT instead of QMI.

Hey @WillieYao-Q I couldn’t run the small command subset you posted as I don’t have a clean way to do so in the setup I have (e.g. there’s no minicom available). I instead configured the setup to run ModemManager with the modem controlled via AT commands, and reproduced the SMS sending issue.

Here is the QLog trace.

The QLog trace contains the full ModemManager device initialization sequence, and then the SMS send attempt once the modem got connected. I can see in the QLog trace (just running “strings” on the trace file) that there’s a SMS send failure reporting +CMS ERROR: 350 so hopefully this will be enough to understand why it failed:

Enter submit_msg_report_event_handler(1841),SMS_FAIL! cmd_name:SMS_CMGS,report_status:WMS_RPT_LL_ERROR,tp_cause:0
dsatetsismsa.c
Cleaning up ATCoP SMS state variables cmd 1 HC cmd 0 (file:dsatetsismsa.c, 1870)
dsatsms_ex.c
Enter dsatsms_signal_handler(340),SMS_NOTE: [21]->event:SMS_MSG_EVENT_SUBMIT_REPORT,result:DSAT_CMD_ERR_RSP >>>>
dsatsms_ex.c
result code:-15
dsatcmdp.c
process_at_cmd_line
dsatcmdp.c
Command output 
+CMS ERROR: 350

Hi Aleksander,

This log is usful. It indicates thst + CME ERROR:350 was due to SMS error from network: “rp_error_to_ue cause value=31” which is expected to receive “rp_ack” from network.


You could contact network provider to check whether SMS works for this sim card.

Best Regards,

Hey @WillieYao-Q but that is strange; we have already validated that the SMS sending works on that very same SIM card using a mobile phone.

Hi Aleksander,

If it’s working on a mobile phone. There should be something wrong with network configuration. Please check following commands:
AT+QCFG=“servicedomain”
AT+QCFG=“nwscanmode”

You can use mmcli to send these two commands, if “serverdomain” returns 0 or 1, “nwscanmode” returns 3, pelase configure it to correct value:
AT+QCFG=“servicedoamin”,2
AT+qCFG=“nwscanmode”,0
then reboot, your issue is mostly casued by this setting.

Best Regards,

Hey!

Nice, that worked! By default the device was in PS-2 UE mode, and after changing servicedomain with AT+QCFG to 2, it changed to CSPS-2.

# mmcli -m 1 | grep "3GPP EPS"
3GPP EPS |    ue mode of operation: ps-2
# mmcli -m 1 --command="AT+QCFG=\"servicedomain\""
response: '+QCFG: "servicedomain",1'
# mmcli -m 1 --command="AT+QCFG=\"nwscanmode\""
response: '+QCFG: "nwscanmode",0'
# mmcli -m 1 --command="AT+QCFG=\"servicedomain\",2"
response: ''
# mmcli -m 1 --command="AT+QCFG=\"nwscanmode\",0"
response: ''
# mmcli -m 1 --reset
successfully reseted the modem

// wait for modem to reset

# mmcli -m 2 --enable
successfully enabled the modem
# mmcli -m 2 | grep "3GPP EPS"
3GPP EPS |    ue mode of operation: csps-2

# mmcli -m 2 --messaging-create-sms="number=+XXXXXXXX,text='helloooooooo'"
Successfully created new SMS: /org/freedesktop/ModemManager1/SMS/0
# mmcli --sms 0 --send --timeout=300
successfully sent the SMS

// SMS received in the target number

I tried to change the UE mode of operation using AT+CEMODE=2 as well, but that failed. Does that mean that the Quectel devices do not allow AT+CEMODE setting, only querying? The quectel plugin in ModemManager would need to be updated to handle that.

(ttyUSB2): --> 'AT+CEMODE=2<CR>'
(ttyUSB2): <-- '<CR><LF>+CME ERROR: 4<CR><LF>'

I’m not sure about AT+CEMODE command. Our document never mentions this command. Please just use “servicedomain” command to configure CS/PS.
Aditional, the default value of servicedomian should be “2”. If all of you module has the setting “1” of servicedommain. That would be abnormal.

Best Regards,

Hey @WillieYao-Q,

AT+CEMODE is a generic command from 3GPP, and helps to change the EPS UE mode of operation, and allows 4 different settings: PS1 (EPS only, voice-centric), PS2 (EPS only, data-centric), CS/PS1 (EPS and non EPS, voice centric) and CS/PS2 (EPS and non EPS, data centric). The EG06 module can reply to AT+CEMODE? query of current state but looks like it cannot run the AT+CEMODE=X setting comand.

What I can see from the AT+QCFG=servicedomain documentation is that it allows changing between CS-only, PS-only and CS/PS, so if I’m not mistaken, it’s closer to the AT+CGCLASS command from 3GPP. I’m not totally sure I can include this servicedomain setting in the ModemManager Quectel plugin without adding new APIs, which would be a mess.

Thanks for the help!

1 Like