Correct use of sms.send()


#1

What is the correct way of using sms.send()? If I do the following:

$ =at'at'
= { "\r\nOK" }
$ =at'at+cpin=1234'
= { "\r\nOK" }
$ sms.send('+123456789', 'Hello world')

it never returns.
I had a look at the code and there is a “wait(‘sms’, ‘*’)” command just
after calling internal.sms_send(). To get an idea why wait() never returns I changed sms.send() to:

function sms.send( ...)
	return internal.sms_send(...);
end

If I now call sms.send() I always get a return code of -8 which, according to adl_error.h, is ADL_RET_ERR_BAD_STATE. Note that I’ve waited a good 10 seconds before entering any commands so the initialization should be completed. I have no problems sending SMSs using at+cmgs in hyperterminal.

Related to this, how do I use at+cmgs in interactive lua? The following
doesn’t work:

=at('at+cmgs="+123456789"\rHello world')
=at('at+cmgs="+123456789"', 'Hello world')

Thanks
chris


#2

AT+CMGS is quite horrible to use, due to its “\r\n>” prompt. You’d have to build a whole program, featuring a state machine, which waits for the prompt between each newline you send.

A quick look at the ADL SMS sending feature reads “Returned values: […] ADL_RET_ERR_BAD_STATE if the product is not ready to send an SMS (initialization not yet performed, or sending an SMS already in progress)”. My guesses:

  • wrong pin code
  • no network
  • your SIM card doesn’t support SMS services

Have you tried to put your SIM card in your personnal phone and send an SMS that way. Alternatively, have you tried to put your personnal SIM card in the devkit and send an SMS that way.

However, sms.send() should report the error to you, not simply hang there when the internal call to adl_smsSend() yields an error. This will be fixed ASAP.


#3

Thanks for the reply.
After my initial post I actually checked with at+creg? that I’m registered on the network before trying to send an SMS and, as the post indicated, the PIN is also correct. I use exactly the same setup (SIM, Tastrack Supreme, PC, cables, etc.) with hyperterminal to send SMSs without any problems.

I’ve also written a small program in C to enter the PIN and wait for at+creg? to report that I’m registered on the network and it, too, works. But when I try sms.send() in interactive Lua I keep getting -8. As I mentioned in the previous paragraph, at+creg? says I’m registered on the network (I also checked this using hyperterminal).

I ran some tests using hyperterminal and then lua interactive. Before each run I turned power to the Fastrack off and on to make sure I start from a clean state.
Here are the results when using hyperterminal (I’ve sent the SMS to myself so you can see that it is also received at the end)

+WIND: 13         

+WIND: 1        

+WIND: 7        
at  
OK  
at+cpin=1234            
OK  

+WIND: 16         

+WIND: 4        

+WIND: 10,"SM",0,"FD",0,"ON",0,"SN",1,"EN",0

+WIND: 11,,, -- checksums deleted

at+creg=2
OK

+CREG: 1,"0067","55E1"
at+creg?
+CREG: 2,1,"0067","55E1"

OK
at+cmgs="0123456789"
> hello from hyperterminal
+CMGS: 9

OK

+CMTI: "SM",19
at+cmgr=19
+CMGR: "REC UNREAD","0123456789",,"09/06/30,22:01:53+08"
hello from hyperterminal

OK

Here are the results when using lua interactive.
Note that I have redefined sms.send() so that I can get the result code.

Lua interactive shell
$ =at('at+cpin=1234');
= { "\r\nOK" }
$ =at('at+creg=2')
= { "\r\nOK" }
$ =at('at+creg?')
= {
  "\r\n+CREG: 2,1,\"0067\",\"55E1\"",
  "\r\nOK" }
$
$ -- redefine sms.send() so that we get return codes
$ function sms.send(phone_nr, msg)
   local rc_sms = internal.sms_send(phone_nr, msg);
   if (rc_sms < 0) then
      return rc_sms;
   else
      local _, ev = wait('sms', '*');
      return ev;
   end
end
$
$ global 'rs'
$ rs = sms.send('0123456789', 'hello from lua interactive');  p(rs)
-8
$

Here is another session where I first call sms.init() and then internal.sms_send()

Lua interactive shell
$ =at('at+cpin=1234');
= { "\r\nOK" }
$ =at('at+creg=2')
= { "\r\nOK" }
$ =at('at+creg?')
= {
  "\r\n+CREG: 2,1,\"0067\",\"55E1\"",
  "\r\nOK" }
$ h = sms.init(); p(h)
true
$ rc_sms = internal.sms_send('0123456789', 'Hello from Lua'); p(rc_sms)
-8
$

Is there a way to determine which version of oatlua I’m actually using? Something weird is going on here :confused:

chris


#4

It definitely works for me:

$ =sms.send('0668922888', 'SMS test')
= "MR"
$ =sms.list()
= { {
    state = "REC READ",
    phone = "+33668922888",
    text = "SMS test",
    date = "09/07/01,10:17:53+08",
    n = "1" } }
$

There’s a basic question: are you using the plug-in provided by Wavecom with Open AT? If so, I’m afraid you’ll have to update your version: I believe that Wavecom will have troubles for a while packaging updated versions of the plug-in in their deliveries.

The simplest way is to:

You can also build it properly as an Eclipse library project, but it requires quite some proficiency with Eclipse and CDT.


#5

I checked out the latest version of oatlua from the subversion repo (rev 36) and rebuilt the oatlua library. I then recompiled lua_interactive and linked it with the new library and it still doesn’t work. Here is the output when trying to send an SMS. Note that I’ve added a ‘(r36)’ in oatlua_r36/src_lua/shell.lua to the greeting and regenerated the corresponding bytecode file to make sure I’m using the new library.

Lua interactive shell (r36)
$ =at('at+cpin=1234');
= { "\r\nOK" }
$ =at('at+creg?')
= {
  "\r\n+CREG: 2,2",
  "\r\nOK" }
$ =at('at+creg?')
= {
  "\r\n+CREG: 2,1,\"0067\",\"55E1\"",
  "\r\nOK" }
$ rs = sms.send('0123456789', 'hello from lua');
run(): error: src_lua\\sms_lua.lua:5: -8
stack traceback:
        [C]: in function 'error'
        src_lua\\sms_lua.lua:5: in function 'send'
        shell:1: in function 'code'
        src_lua/shell.lua:79: in function <src_lua/shell.lua:77>
$

I’ve deleted the application (+wopen=4), re-downloaded the firmware (7.3) and lua_interactive and I still get the problem. And I can still send an SMS using hyperterminal using the exact same setup :frowning:

I’ve noticed that, when sending an SMS using hyperterminal, +creg reports “+creg: 0,1” while in lua_interactive it gets reported as “+creg: 2,1” even though I did not set the creg mode to 2. Is there perhaps something set in the background during lua start-up that changes the way the modem registers on the network? I grepped for creg in all the oatlua and lua_interactive source directories but did not find anything.

Perhaps this is not a lua problem. Where else can I look for the problem?
chris


#6

uh. The change in +CREG mode is puzzling indeed, and doesn’t look like a Lua issue. Lua doesn’t mess with CREG (you can even check with a “grep -ri creg ~/src/oatlua”).

One possibility to explore is that sometimes, ADL’s AT command handler does mess with AT commands, and a command sent through ADL doesn’t behave the same as when sent on a real UART. It might be that AT+CREG and/or AT+CPIN are masqueraded in strange ways by ADL; of course, oatlua relies on ADL’s adl_atCmdCreate() and its funky command interpretations to run AT commands. And unfortunately, I’m not aware that a list of such tricky commands exists :frowning:

The only difference between my working experiment and your non-working one is that my SIM card has no PIN code. Could you try to:

  • repeat the experiment with another SIM card?
  • suppress the PIN code from the current card?
  • replace the card with a PIN-free one?

This won’t solve your issue, but might narrow it to some PIN code issues.


#7

The problem is definately related to the SIM card initialization. When I enter the PIN using the Lua function internal.sim_init() I can send an SMS. When I enter the PIN using at(‘at+cpin=…’), sending an SMS fails even though SIM initialization succeeds, as we have seen in previous posts.

Here is an example of a session that worked. I first installed an event handler to notify me when an SMS is received (this comes straight from the manual). I then do everything one step at a time; sms_send() is suppose to automatically do the handle initialization (sim.init) but I did not have time to test it.

Lua interactive shell (r36)
$ function on_sms_rcv(emitr, evnt, msg)
   assert (emitr == 'sms' and evnt == 'read');
   printf('SMS:\nFrom %s, received at %s:\n   %s',
      msg.phonenum, msg.timestamp, msg.text)
   return 'again' -- don't detach the hook.
end
$ sighook ({'sms'}, {'read'}, on_sms_rcv)

$ internal.sim_init('1234');
$ p(internal.sim_get_state())
"FULL_INIT"

$ p(sms.init())
true

$ p(internal.sms_send('0123456789', 'Can somebody please explain this to me!'))
0
$ SMS:
From 0123456789, received at 09/07/03,17:38:09+08:
   Can somebody please explain this to me!
SMS:
From 0123456789, received at 09/07/03,17:38:09+08:
   Can somebody please explain this to me!

Why is the event handler called twice?

Thanks for all the help in finding a solution.
chris


#8

About “AT+CPIN”: I’ve heard that this command had some strange features, that couldn’t be fixed by Wavecom without breaking the compatibility with existing customers’ apps. I’m sorry I don’t remember what was/were the exact issue(s).

I don’t know why you have 2 reactions: either you somehow registered it twice, or the signal is wrongly emitted twice. If you have the WIP traces on a UART, you can have a look at them to see if there are 1 or 2 “[LUAW] SIGNAL sms.read” logs: if so, then there’s a bug in oatlua. If not, you’ve probably somehow registered your callback twice.


#9

Thanks for the reply. proc.tasks.waiting shows only a single hook registered, so there must be duplicate events. I never use the IDE, is there a way to display the traces while working in lua-interactive?

As an aside, has internal.at() been replaced by internal.at_cmd()? According to the manual it should be used for ATD as it behaves differently from other AT commands.

Thanks
chris


#10

Displaying the traces: they can sent to a UART port, as unsollicited; in your call to wip_netInitOpts(), you should find an option line:

WIP_NET_OPT_DEBUG_PORT, WIP_NET_DEBUG_PORT_UART1, /* WIP traces on UART1 */

You can set this port to whatever you want, including WIP_NET_DEBUG_PORT_USB. I plan to allow to serve the traces over telnet (and/or maybe rather UDP, to be sure that they don’t mess with the scheduling), but it isn’t done yet.


#11

There are two sms.read events when receiving a single SMS, here is a trace; the “ignoring duplicate event” string is written by my app when it detects a duplicate sms.read event.

[LUAW] SIGNAL at.CMTI
[LUAW] SIGNAL sms.read            <---------- first sms.read
[LUAW] {
  
[LUAW] phonenum = 
[LUAW] "0123456789"
[LUAW] ,
  
[LUAW] text = 
[LUAW] "X"
[LUAW] ,
  
[LUAW] timestamp = 
[LUAW] "09/07/06,21:40:08+08"
[LUAW]  }
[LUAW] 

[LUAW] SIGNAL sms.read            <---------- second sms.read
[LUAW] "ignoring duplicate event"

I do not have a spare port to display the traces on :frowning: (UART1 is already used by telnet) so I’ll have to wait for the update that serve the traces over telnet.

Is there a chance of adding a revision number to oatlua that can be read by an application?

Thanks
chris


#12

I hadn’t time to investigate the double message issue yet. But SMSes are stored in folders, and sometimes move from folder to folder subrepticiously, e.g. from “REC UNREAD” to “REC READ” as you open them. It’s not impossible that this move from folder to folder is linked to the multipile msg.

Version numbering: good point. I’ll see if I can incorporate the SVN release number automatically, there must be something similar to CVS’s $version$ in SVN.