It is quite likely that sending an SMS will not complete within 15s - so doing this is not a valid test.
Any application which does this is fundamentally flawed - the only certain way to ensure that an SMS send has completed (successfully or otherwise) is to use the Events returned by the SMS Service.
That sounds like perfectly valid behaviour - the SMS Service is not ready to send the next SMS until it has given all the events to confirm that the previous send has completed.
What do you mean by that?
If you keep re-sending while the Service is busy, you will keep getting the same error!
See above: there’s no “somehow” about it - it’s a matter of correctly synchronising to the Events that tell you when it’s ready again!
This is not the same as the problem described earlier in this thread - this is an application fault.
Besides all of the above, the original problem was not related to sending SMS at all.
you are right that the application in this case is at fault but the point here is that when the applications reaches such a state the reception of the SMS also stops. In the post no one has mentioned about the value of the smshandle when they received this problem.It would be interesting to look at the sms handle value in the cases when the application SMS data handler is not getting called.The SMS handle value will be able to give a proper clue as to why the application is failing to call the SMS data handler when an sms is received by the application.
The application basically does check the event received in the sms control handler which is for the first time gives the result as sms sent successfully, but then the application adds a delay due to some other process and tries to send the next sms.
I would like to know if the sms handle value returned in case where the sms data handler is not getting called is the same as I observed in the application i.e -8 which stands for sms handle in bad state.
need to check with sierra as to why the sms handle value in such cases always refers to -8 and it never recovers?
does’nt Open at implement a timeout mechanism to get the SMS handle to the OK state if it does not get back to the Good state even after advertising the event to the application in the sms control handler.
Once a faulty application has got the system into an undefined state, all bets are basically off!
I think you are confusing the handle with the return value from adl_smsSend
The handle is the value returned from the SMS Service subscription; if that indicated an error, then SMS reception would never work - which is not the case under discussion in this thread.
See above; the handle is given at subscription time - if it indicated an error, I would have detected that!
No - see above.
But that is the entire problem - the SMS does not reach the application
As per the Sierra Documentation “On success, this function(sms subscribe in this case) returns a positive or null handle, requested for further SMS sending operations.”
What I have observed is this positive value of the SMS handle getting converted into a Negative value(-8) and then stopping all the further reception of the sms by the application (which is described as the SMS not reaching the Data handler). This happens even with an application working Quiet well for a few days.
Yes the handle is given at the subscription time but as per the documentation it is requested for further sms sending operations.The ADL user guide does not mention as to what happens if this SMS handle value is found to be negative (reasons not known yet) by the OS. Also it does not mention the reasons which will get the handle into a negative value.
As per the ADL User guide if he SMS handle is requested for further SMS Operations then it implies that the value of the SMS handle should be positive or NULL to indicate the OS of a Successfull SMS subscription if at any point of an SMS operation if the OS is indicated of a negative value of the SMS handle then that will mean that the SMS service is either not subscribed correctly or has entered a BAD STATE or some other error which can be traced out through the SMS handle value (Again here I don’t know what is the Cause for the SMS Service to Enter the BAD STATE).
As far as I understand to successfully send and receive the SMS using the ADL SMS service it is required to have a positive or a NULL value of the SMS Handle,which means that the SMS Handle is a fairly good indicator of the state of the SMS Service which is managed by the OS.
I suspect some thing internal in the OS is not setting back the SMS handle to a positive value once the SMS operation is complete.
i´m not sure if this is in this thread, so i hope that this helps someone:
i just had the situation, where i got no sms event calls, while it seemed that the sim was empty. When i entered the sim into an handy (since i didnt want to look up the at commands for checking the sms on the sim) there were totally NO sms - neither sended or received.
again in the modul i asked via at-command for the sms… those who are read and those who are unread… nothing… empty… out of frustration i asked for all sms (at+cmgl=“ALL”) and there they were… enough sms to fill the sim, so that no events would find their way to the registered handler…
after deleting all sms via “at+cmgd=0,4” the registered handler got called again. 8)
If the SIM is full, the MS will not accept more messages from the network. This has nothing to do with Open-AT - it would be the same with no application.
Current workaround is to check preferred storage for new messages periodically and restart module if exist. Module usually checks and clears storage at startup.
Also possible useful addition is to resubscribe sms handler periodically.
Thats why i mention whis as possible additional solution. Together with storage checking it is my complete workaround used. Its worked, I dont know actually if problem still exist on new firmware, no time for checking.
