 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion Groups General General TopicsGSMBluetoothProviders AlltelATT WirelessCingularFidoNextelSprint PCST-MobileVerizonManufacturers EricssonNokiaMotorolaCountry Specific Australian GroupUK GroupRelated Topics PocketPCPalmMore Topics ... |
Cellular Phone Forum / General / GSM / January 2006CMGS sends message then stops communicating after Ctrl-Z
Hi there, I've been working with the C programming language on a GSM PDU SMS send message program. This is the first time I've ever done any kind of serial communications (though I've written and fixed lots of business programs in my time). I can successfully send my SMS message to my mobile (Sony Ericsson v600i - routing via the supplied Sony Ericsson connection software), but after sending the Ctrl-Z, my program ceases communication with the mobile. I cannot even get a response from a subsequent humble ATZ command! The commands all work OK on Hyperterminal, though. I understand that sending the Ctrl-Z is the equivalent of telling the serial 'file' that this is the end, and obviously my program has it's communication terminated by the mobile or one of the data lines, but which? How can I send subsequent commands to the mobile (and pick up the feedback from my SMS send) - I've opened communication using that suggested by the web page at http://www.easysw.com/~mike/serial/serial.html under "communicating with a MODEM". Is there another setting I can configure so that my program is not dropped? -- Also, is there an AT command to find out how many SMS messages are waiting on the phone or on the GSM mobile, prior to picking them up? Thanks in anticipation Andy Burgess > I've been working with the C programming language on a GSM PDU > SMS send message program. This is the first time I've ever [quoted text clipped - 7 lines] > response from a subsequent humble ATZ command! The commands > all work OK on Hyperterminal, though. I'm not familiar with the SE v6001. Are you using this to send the SMSs, receive them, or both? What role does "the supplied [SE] connection software" play in all of this? The web page you refer to below shows the type of POSIX commands I use in Linux versions of my programs. My DOS/Windows versions address the serial port much more directly. I use C, but I'm no C expert. What OS are you running under? > I understand that sending the Ctrl-Z is the equivalent of > telling the serial 'file' that this is the end, and obviously [quoted text clipped - 7 lines] > "communicating with a MODEM". Is there another setting I can > configure so that my program is not dropped? Let's start with the simple things first. You should be sending AT+CMGS=<length><CR> where "<CR>" is the single <carriage return> character _without_ a <linefeed> (most important). And how are you calculating <length>? Then you should be waiting for the ">" prompt (it will be proceeded by <CR><LF>) from the modem. Only then should you send your PDU, and it should be terminated by a single <ctrl-Z> character _without_ any end-of-line character such as <CR> or <LF>. And you might then have to flush the buffer at this point to get it out of your UART and onto the cable. Otherwise it might sit there until the next <CR> sent triggers a buffer flush, but the result of that scenario on the modem will be undefined. At this point, the modem should respond with +CMGS: <mr> where <mr> is the actual message reference number which the modem used (range 0 to 255 from memory, so unlikely the same as the dummy one you were forced to include within the PDU). > Also, is there an AT command to find out how many SMS messages > are waiting on the phone or on the GSM mobile, prior to > picking them up? Yes and no. You'd normally use "AT+CMGL" to do this (list unread messages). But all message reading commands (including AT+CMGL) change the message status from unread to read. So you need to be aware of this and program your way around this behaviour. Alternatively, your modem might have a proprietary command which allows looking at unread messages without changing their status. Some Siemens devices have proprietary AT^CMGL and AT^CMGR commands, for example, to do this - but such commands are outside the scope of the GSM standards. John > > I've been working with the C programming language on a GSM PDU > > SMS send message program. This is the first time I've ever [quoted text clipped - 10 lines] > I'm not familiar with the SE v6001. Are you using this to send > the SMSs, receive them, or both? The model is actually is v 600 i. In answer to your question, yes, at the mo, I'm only using it to send SMSs - I have not got around to decoding incoming PDUs yet. > What role does "the supplied [SE] connection software" play in > all of this? Right, sorry I didn't explain very well. I'm using the phone on a USB port and in order to access the AT commands through Windows, I need to have the Sony Ericsson comms software running and having seen the phone (putting the phone icon on the task bar) - otherwise Windows won't find the port! When I talk about the SE software, I mean "Sony Ericsson File Manager" (which allows you to pick up pictures/upload pictures video etc to the phone - I hope you see what I mean. > The web page you refer to below shows the type of > POSIX commands I use in Linux versions of my programs. My > DOS/Windows versions address the serial port much more > directly. I use C, but I'm no C expert. What OS are you > running under? Well I'm running GNU C under a piece of software called Cygwin - which is, in principle Linux under Windows - hence the "POSIX" stuff. > Let's start with the simple things first. Excellent, sounds good to me! > You should be sending > AT+CMGS=<length><CR> Yes I am - followed by a C '\r' - or <CR> only - not '\n' which is both (or perhaps just <LF>). > And how are you calculating <length>? Simply (perhaps too simply) by taking the length of my encoded hexadecimal string and dividing it by two (for each octet pair). I think I'm right in saying that if I hadn't got this right, that the mobile wouldn't send an SMS? > Then you should be waiting for the ">" prompt (it will be > proceeded by <CR><LF>) from the modem. Absolutely! > Only then should you send your PDU, and it should be terminated by a single <ctrl-Z> > character _without_ any end-of-line character such as <CR> or > <LF>. Yes, I'm doing that. I display what I'm about to write to the modem (and to a log file), an example of a previous successful message is: AT+CMGS=53 to which I replied with: 079144775810065011000B927077808048F30000AA2C74741914AFA7C76B9058FEBEBB41E6371A4AEB7E16532E86D2FCB41747419C40EEBF320F2FB0C^Z and (I've just noticed in my log, but not on screen) it gave me: +CMGS: 0 > And you might then have to flush the buffer at this > point to get it out of your UART and onto the cable. Otherwise > it might sit there until the next <CR> sent triggers a buffer > flush, but the result of that scenario on the modem will be > undefined. I believe I'm doing this - as the message is sent, but if not - how do I do that - something like sending an additional <CR>? What's UART again - some other name for serial? > At this point, the modem should respond with > > +CMGS: <mr> As you can see above it did, but I want to be able to trap this message programmatically! Thinking about my log file - is my problem perhaps something to do with the monitor responding to my display of the command and "suspending" on the Ctrl-Z, rather than the modem? ---- > > Also, is there an AT command to find out how many SMS messages > > are waiting on the phone or on the GSM mobile, prior to [quoted text clipped - 9 lines] > AT^CMGL and AT^CMGR commands, for example, to do this - but > such commands are outside the scope of the GSM standards. Right, cheers. That's the next step when I get the creation of SMSs working! Thanks for your feedback. Andy PS I've just got hold of a TEXT mode GSM modem so things may become even easier now too - no PDU encoding! There's a lot of detail in your reply Andy, and I've addressed only parts of it here. >> And how are you calculating <length>? > Simply (perhaps too simply) by taking the length of my encoded > hexadecimal string and dividing it by two (for each octet > pair). I think I'm right in saying that if I hadn't got this > right, that the mobile wouldn't send an SMS? Not necessarily. As with most of this technical detail, the result of getting it wrong is undefined. So it might always work as intended, only sometimes work as intended (perhaps only in a specific context), of fail every time. And when it does fail, the mode of the failure is of course undefined. With PDU length, I've found some devices to be very forgiving (as long as the <length> parameter is greater-than or equal-to the correct length). Other devices are absolutely pedantic, and won't tolerate any inaccuracy, anywhere. > an example of a previous successful message is: > > AT+CMGS=53 I calculate your complete PDU to be 121 hex characters, or 60½ octets. Take away 8 octets for the SCA gives us a "correct" 52½ octets (53 rounded up, but see later about half-octets). I've broken up your PDU as follows (a task I really enjoy, why ever do you want to use text-mode?) 0791447758100650 SCA 11 PDU-type 00 MR 0B927077808048F3 DA 00 PID 00 DCS AA VP (4 days) 2C UDL (44 characters) 74741914AFA7C76B9058FEBEBB41E6371A4AEB7E16532E86D2FCB41747419C40EEBF320F2FB0C (user data) Your UD field contains 38½ octets. There must be a whole number of octets. See GSM 03.38, clause 6.1.2.1. So I think your character-packing algorithm needs some attention. 44 7-bit characters gets packed into 39 octets. I passed your UD field through a little PDU decoding utility I once wrote, and it decoded as "the quick brown fohP4 S M m G$q d / @ " which probably isn't quite what you intended (my program does take the liberty of converting "rubbish" to spaces). The other problem of note is your DA field. In particular, the "type of number" indicator of 92 hex seems wrong. While the "9" indicates an international number, the "2" is undefined as a numbering plan identifier in GSM 03.40, clause 9.1.2.5. > What's UART again - some other name for serial? It's the chip which does the conversion between serial data and "parallel" (bus-oriented) internal data, in each direction. > Thanks for your feedback. You're most welcome. Sometimes I need an excuse to exercise the grey matter. I meant to ask earlier, does your program sail through other commands without hanging up until the first AT+CMGS command? I have a feeling we'll end up looking more closely at buffer flushing. My programs pass the <ctrl-Z> character out immediately, but I borrowed a swag of serial configuration ideas from long-forgotten sites. John > Not necessarily...... And when it does > fail, the mode of the failure is of course undefined. Right, point taken ! > I've broken up your PDU as follows (a task I really enjoy, why > ever do you want to use text-mode?) It's simpler to code in the short term - I've got to get this running quite quick now! Are there any advantages in using PDU over text? > 0791447758100650 SCA > 11 PDU-type [quoted text clipped - 6 lines] > 74741914AFA7C76B9058FEBEBB41E6371A4AEB7E16532E86D2FCB41747419C40EEBF320F2FB0C > (user data) > I passed your UD field through a little PDU decoding utility I > once wrote, and it decoded as > "the quick brown fohP4 S M m G$q d / @ " Yes I got the same runnning that through the webpage at http://home.student.utwente.nl/s.p.ekkebus/portfolio/resource/sms_pdu.html ! I think my log file must have stored it incorrectly - I did receive the message correctly! > The other problem of note is your DA field. In particular, the > "type of number" indicator of 92 hex seems wrong. While the > "9" indicates an international number, the "2" is undefined as > a numbering plan identifier in GSM 03.40, clause 9.1.2.5. I think I meant 91 - like I had before for SCA? > > What's UART again - some other name for serial? > It's the chip which does the conversion between serial data and > "parallel" (bus-oriented) internal data, in each direction. Ah right, I knew it was a chip, but had forgotten! I didn't know till now what it did! > > Thanks for your feedback. > You're most welcome. Sometimes I need an excuse to exercise the > grey matter. Mine's been well and truely stretched on this project - re-learning C (and trying some other things in Perl too). learning serial comms learning SMS AT commands (I'd used basic modem AT commands before) > I meant to ask earlier, does your program sail through other > commands without hanging up until the first AT+CMGS command? I > have a feeling we'll end up looking more closely at buffer > flushing. I took on what you said here about buffer "flushing". I sent an additional "\r" - CR and it did the trick -- I now get my feedback! Thanks! Incidentally, I've just fixed my first "siphon" on the (UK) toilet too - a bit of a learning curve there too! Still that works now too! > My programs pass the <ctrl-Z> character out > immediately, but I borrowed a swag of serial configuration > ideas from long-forgotten sites. If you'd like to elucidate these sites - please do! Thanks v much John. I'll probably be back in touch re picking up SMSs. Is there a good way of tying together a reply to an SMS, other than "Oh it's about the right time, it must be this one!" >> I've broken up your PDU as follows (a task I really enjoy, >> why ever do you want to use text-mode?) > > It's simpler to code in the short term - I've got to get this > running quite quick now! Are there any advantages in using PDU > over text? Probably not for ordinary text messages. PDU-mode bypasses the phone's own PDU <=> text converter, moving the scope for conversion errors and bugs from phone manufacturer's firmware to yourself as programmer. Many devices driven in text-mode don't convert successfully from ASCII to the GSM 7-bit alphabet for those 7-bit characters from the extension table in GSM 03.38, clause 6.2.1.1. That's basically characters from the list "^~{}[]\". And you'd certainly need PDU-mode to send or read the Euro currency symbol over a serial connection. Also, anything requiring the UDHI bit to be turned on within the PDU-type octet will likely need PDU-mode (although you can set that bit itself in text-mode using AT+CSMP - it's the UDH itself within the UD that's the problem). This means that any EMS functionality (embedded pictures, sounds, emoticons, simple drawings, video attributes, etc) is beyond your reach. > I took on what you said here about buffer "flushing". I sent > an additional "\r" - CR and it did the trick -- I now get my > feedback! Thanks! Bear in mind that a <CR> following the <ctrl-Z> is non-standard, and some device somewhere may not like it. It's a work-around. > Thanks v much John. I'll probably be back in touch re picking > up SMSs. Is there a good way of tying together a reply to an > SMS, other than "Oh it's about the right time, it must be this > one!" Not that I'm aware of. You obviously get the originator's number, SMSC number, and SMSC timestamp with the reply. But that's about all that may be useful. One very neat SMS trick that deserves a mention in case it's of use to you is the ability to overwrite an earlier message you sent. It has to come from the same number, so you can't overwrite an SMS sent by someone else. There are 7 "virtual memory locations" that you can use to do this. Just set up your PID within the range 41 through 47 (you can do this in text-mode too). So, within the receiving phone, a message with a PID of 42 will overwrite any earlier message from you that also had a PID of 42. John > If you'd like to elucidate these sites - please do! I think http://tinyurl.com/blukb has most, if not all, of the serial port specific code I found useful for the Linux/POSIX programs I wrote (non-canonical according to one of my comments, but it was a while ago). I see that I've got the following lines as part of initialisation: newtio.c_cflag = SPEED | CS8 | CLOCAL | CREAD; newtio.c_iflag = IGNPAR; newtio.c_oflag = 0; newtio.c_lflag = 0; newtio.c_cc[VTIME] = 10; newtio.c_cc[VMIN] = 0; if that helps. Merry Xmas to all. John Thanks for that gen, John. Sorry for the delay in posting back. I've basically got all my program sorted, bar one problem, similar to a message you've replied to regarding only sending 159 characters. I can send SMSs of 148 characters or less, but as soon as I get nearer to the 160 limit, the program refuses to send the PDU message. I've checked my code and noted that magically the 12 characters it won't print correspond exactly with my initial send string of something like "AT+CMGS=154<cr>". It would appear that my Siemens TC35 i TGSM Modem is holding on to the initial command string of 12 characters in its buffer, and I'm at a loss as to how to let it send me a 160 char SMS. I'm sure some clever person on this forum knows how to get past this. In the meanwhile I'll prevent my program from sending a message longer than 148 characters! I've tried changing to the settings you had in your program, John, but I get an error on the "SPEED" item. Thanks in anticipation > I can send SMSs of 148 characters or less, but as soon as I > get nearer to the 160 limit, the program refuses to send the > PDU message. I've checked my code and noted that magically the > 12 characters it won't print correspond exactly with my > initial send string of something like "AT+CMGS=154<cr>". Hi Andy, Have you tried AT+CMGS=140 Siemens devices are usually happy with using 140 as the PDU length parameter in all siuations, regardless of the actual PDU length. In fact, 140 is the maximum, and the correct figure for a 160-character message, because it's a count of UD packed octets, not unpacked septets. > I've tried changing to the settings you had in your program, > John, but I get an error on the "SPEED" item. Just leave out SPEED if your baud rate is working OK - it's probably a different variable name. John I wrote: > Just leave out SPEED if your baud rate is working OK - it's > probably a different variable name. Oops, not a variable at all, but an equate: #define SPEED B19200 John > I wrote: > [quoted text clipped - 6 lines] > > John That now works for me with your serial settings, and I feel happier about your code rather than the other, as it's simpler and the other uses "bitwise operators" and the "~" - complement one, which I believe in the context of the code I picked up is equivalent to "NOT". The other code's to initialise the modem is too complicated anyway! I've still got the issue with the AT+CMGS=xxx statement. I've tried with your suggested AT+CMGS=140, but it still seems the data's stuck in the buffer. Looking at the GNU notes for "special characters" I discovered if one sent a ^Z (VEOF) at the beginning of a line, you would read back 0 characters. Could this potentially solve my issue or would it cause me more trouble? --- Also my program doesn't seem to be able to talk to the GSM modem after initial PC start up. Loading up Hyperterminal and firing a command at it seems to wake it up, and my program can subsequently use it - any idea why? Cheers Andy > That now works for me with your serial settings, and I feel > happier about your code rather than the other, as it's simpler [quoted text clipped - 10 lines] > Could this potentially solve my issue or would it cause me > more trouble? --- I don't know, the use of GNU special characters not an area I recall reading about. > Also my program doesn't seem to be able to talk to the GSM > modem after initial PC start up. Loading up Hyperterminal and > firing a command at it seems to wake it up, and my program can > subsequently use it - any idea why? I'm not sure what you mean here. Is it only after the problem with AT+CMGS that things lock up? Or are you seeing other issues before that? Perhaps different manifestations of the same underlying problem? I think we can discount the Siemens modem itself for the time being. These are commonly used in this sort of application without problems. At this stage, we need to eliminate serial communications problems - character framing or flow control. Obviously, the serial parameters need to be set up the same on PC and modem. 8 data bits, no parity, 1 stop bit is the usual character framing, and the default setting for Siemens modems according to my TC35 manual. In an earlier post, I said I used newtio.c_cflag = SPEED | CS8 | CLOCAL | CREAD; but I think newtio.c_cflag = SPEED | CRTSCTS | CS8 | CLOCAL | CREAD; would be better (explicitly turning hardware flow control on). This is what I do (by a totally different mechanism) in my DOS programs. On the modem side, this would mean including AT\Q3 as part of modem initialization, so that the modem matches the PC. Have you tried programmatically aborting an "AT+CMGS=140" command? Feed the modem with a 160-character message in a PDU as usual, and terminate the PDU string with <ESC> instead of <ctrl-Z>. You should be returned to command mode, and be able to execute further commands, such as "AT" itself (the null command that should simply return "OK"). We may also need to look at how you're reading the characters/strings from the modem. At this stage, I thing we're leaving the world of GSM behind and talking serial communications. So feel free to do the obvious adjustment to my e-mail address amd contact me directly if you'd prefer. John > Also, is there an AT command to find out how many SMS messages > are waiting on the phone or on the GSM mobile, prior to > picking them up? I suppose you might be able to use AT+CPMS? if you work around it's limitations. It will tell you how many messages are stored at any particular time. If the number were to increase unexpectedly on a later invocation, that would indicate new received messages. A quite different approach would be to use AT+CNMI so as to generate unsolicited +CMTI: <mem>,<index> responses immediately to the serial port on receipt on new messages. But unsolicited responses could potentially interfere with commands you might be giving at the time. I think GSM devices are meant to raise the "ring indicator" serial pin for one second prior to dumping an unsolicited response so that you can accommodate it, but I'd have to research that aspect. John |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.