Hi everybody,

I have a problem with Q26CL702 module of a customer in France.

Every time he tries to send an sms (the application use the function adl_smssend) the reply is -8.

Module and SIM card are initializated and registered. In fact the +wind:16 unsolicited is received and using at+cmgs command the sms are sent.

SMS are received correctly, calls are made and received. Just the sms sent with the adl function don’t work…

I send another device and it doesn’t work. But the first one was returned and here works.

We have also other customer in France (and many other in different countries) which don’t complain.

He’s using FREE and ORANGE FR operator.

Has someone experienced this problem?

Here is the configuration of the module…

“DWL”,“V08b13”,"",“Sierra Wireless”,55344,“111611 18:03”,“dda36757”,“00010000”
“FW”,“FW_SRC_747_8_F4_3.Q2687G”,“R7.47.4.201208311102.Q26CL702”,“Sierra Wireless”,2221264,“083112 11:02”,“6aa633a2”,“00020000”
“OAT”,“05.01.20141211155159”,“xxxx”,“xxxx”,613624,“121114 15:52”,“080d3f55”,“00260000”
-“Developer Studio”,“”
-“Open AT Application Framework package”,“”
-“Open AT OS Package”,“”
-“Firmware Package”,“”
-“ExtendedATApplication Library Package”,“”
-“Internet Library Package”,“”


What happens if you try to send an SMS “manually”… :question:


If I send SMS using AT+CMGS everything works.

I have tried to send “manually” with application turned on (at+wopen=1) or turned off (at+wopen=0).

The +WIND:16 is received correctly, SIM card is full init (calls and incoming sms are OK)
and at+creg? is registered (+creg=0,1 for ORANGE FR; +creg: 0,5 for FREE)

Is there any short code for barring originated SMS (which however is not the case since at+cmgs works)?

I’m going to check the reply of adl_smssubscribe in case there are some issue from the beginning…



the result of adl_smsSubscribe function is 0.
From documentation this is a good value for the sms handler…

but the -8 error still comes up…

I can’t figure why that’s happen…maybe should I try to use Q2687RD and not Q26CL702 module
and maybe use firmware v7.52 and not v7.47.4?


Are you sure this happens on every attempt to send :question:

A common mistake is to try to send a message before the previous one is fully complete - in which case ADL_RET_ERR_BAD_STATE makes sense…

Internally, I think adl_smssend() still uses AT commands - so is the application doing anything else with AT commands which could “block” the sending? Particularly, commands which take a “long” time to execute - like AT+COPS=?

Hi and thanks for reply.

It happens every sms is sent using adl_smssend function and I’m pretty sure that there aren’t other sms in sending status.

However, the application polls some AT commands like


to know what is the registration and network status. The process is execute maybe once every minute…

I was not aware that some AT commands are long to execute: do you know if there is some documentation with a list of this commands?

I will try to exclude at+cops? command to check if it could be a cause…


Have you considered using unsolicited responses to advise changes in network state - rather than continually polling…?

Yes, they do - and yes, it would be useful to have it documented :exclamation:

Sending an SMS is a command that take a (relatively) “long” time - that’s why adl_smsSend() returns immediately and uses a callback to later advise the success/failure status…

Is your application careful to not do a network status poll in the period between adl_smsSend() and receiving the result… :question:

Note that at+cops? is not the same as at+cops=? :exclamation:


You are right: maybe it’s better to wait unsolicited respect to poll network status: however I inherit the project so I have to modify with care; but I think it is a good pratice.

No, the application polls independently the network status and the sms send process. However I don’t understand why over the 2000 devices we have around the world, just the devices I sent to that customer won’t send SMS (during the production test they worked)

I confirm that application uses at+cops? (ask for current carrier operator)

So far, I can’t find a solution: I will try to remove network status poll and I’ll let you know.

Thank you

Hi Contrive,

that’s an interesting problem… 3/4 of my application is working around various ADL issues, making sure the module is logged in, and restarting various services as they fail.

Your problem first.
Sometimes the documentation is fuzzy, but when there’s explanation “initialization not yet performed, or sending an SMS already in progress”, my bet is it’s one of the two.
Can you make an AT command for the customer, that will only perform adl_smsSend() and return the error code? It would be best to create a new application that does nothing else, or perhaps add a minute wait in startup of your application.

Second, I have 2 automatons, say Monitor and Sender.
Monitor has many numbered states, and fires every second.
100: ask AT+CREG? and goto 101
101: wait for +CREG response ->102 or timeout
102: ask AT+CSQ and goto 103
103: wait for +CSQ -> 104 or timeout
104: ask AT+CPAS and goto 105
105: wait for +CPAS -> must not be +CPAS: 5; back to 100 or timeout
on timeout:
201: setup a 50-second wait
203: wait, if a response comes goto 100
205: send AT+WAC
207: wait 10 seconds, on response goto 100
208: restart module :frowning:

The point is that Monitor can be interrupted at even steps. The Sender will wait for an even step, and set a busy flag.
The Monitor will wait in even step until the Sender is done.
It’s all much more involved, some hundreds of lines of code, but this is the idea. Maybe not the best way, but it works.

Thinking about it, I don’t think it should be a problem: I think adl_smsSend() does complete the SMS command(s) before it returns - so there shouldn’t (sic!) be a problem…

Does your application also receive SMS :question:

If so, do you also have problems with SMS reception…?

There is a longstanding suspicion that something can go wrong with SMS reception, resulting in the receive handler not being notified:

I’m not sure what happens to SMS sending in that case…

Is the SIM message store full :question:

I know that prevents SMS receiving (not related to Open-AT) - I guess it could also affect sending…?

The sms are correctly received and the SIM message store is empty (every time an SMS is received, it is deleted after processing). I have verified also with at+cpms? command…

I have and update:

  • I sent customer a new product mounting Q2687RD (instead of Q26CL702) and firmware R7.47.4
    adl_smsend error -8 still appear


  • I installed firmware R7.52 (which is compatible with Q2687RD) and downloaded the application (compiled for R7.52).
    No way to work…

Result: we lost the customer…

Is there a method to retrieve some traces in remote using a normal serial terminal (I can’t ask customer to install devStudio)? So I can send to Sierra and see what could be the problem.