Q & A compilation of "sending and receiving short messages via serial port"

On the topic "sending and receiving short messages via serial port", I will organize some technical questions I have discussed with netizens into the following text. I hope this article will help more friends who are interested in SMS. Because I am a hobbyist and have limited time and money, I have no power to test many models of mobile phones and modules one by one. There may be such errors, and I hope the industry experts will criticize and correct them.

QI wrote a text message sending program that uses the PDU format to send messages. The program has no problem in Guangzhou, but it cannot be sent out in Henan. I don't know why. The text message "" format is as follows:

Henan: 0891683369200005f011000d91683170010918f20008a9064f60597d5417

Guangzhou: 0891683108301705f011000d91683170010918f20008a9064f60597d5417

AThe SMSC Number of the region where the SIM card is located must be used to send text messages. If you are running a card in Guangzhou, you still need to use the SMSC number in Guangzhou even if you are in other places. The SMSC numbers in your two messages are different, but the same SIM card is used. I wonder if this is the reason.

QCan I directly use the number in the SIM card instead of the number in the text message center? I don't seem to need to enter the SMSC number for all the text messaging software I have used.

AThere is an "at + csca" command that can be used to set or query the service center number. If the phone number already exists, there are two solutions:

Use "at + csca? "Command query, and then the number is automatically written to the pdus sca.

Only one sca field of the pdu is written as "00": "08 91 68 31..."-> "00"

Set the service center number using the "at + csca = XXXXXXXX" command.

QOn the Super Terminal, I use at + cmgs to send short messages. The format seems to be correct, but "error" is always returned ". The input is like this:

at+cmgs=30> 0891683108100005F011000D91683118405057F000000006C8329BFD0E01 

What is the reason?

AThe "at + cmgs" command is special. You need to enter data after you press Enter. Here is "cr", not "CRLF". Note that two characters are generated when you press enter in the Super Terminal (view settings ). Like the "at + cmgl" command, it doesn't matter even if you finally input "CRLF.

Your problem lies in the length. The length is not random. In your example, the length should be 21. In addition to the SMSC segment (0891683000000005f0), calculate it from "11" (I .e. "11000d91683118405057f0000000000006c8329bfd0e01") and divide it by 2.

Which of the following statements is true?

at+cmgs=21> 0891683108100005F011000D91683118405057F000000006C8329BFD0E01 

(">" Is a mobile phone prompt, not input)

QI recently compiled a short message program. In your "sending and receiving short messages via serial port", I mentioned that "text mode is a plain text method and can use different character sets, technically, it can also be used to send short messages in Chinese, but Chinese mobile phones are basically not supported, mainly used in Europe and America. "Does it mean that using the AT command" at + cmgf = 1 "or" At + cmgf = 0 "has no effect on sending and receiving short messages?

AText mode is easy to write. You can send the original text directly, and send non-ASCII code content. However, you need mobile phone support to display the text correctly. For example, many characters in French and German are encoded in greater than 0x80. They all use text mode. What is the difference between character encoding in text mode? There is a special character set instruction "at + CSCs ". It can be set to the expanded character set "ucs2 ". According to Siemens TC35/tc37, its "at + CSCs" support the "ucs2" character set, but I have no chance to test it myself. If you are using the TC35/tc37 module, try it.

As far as I know, Chinese short messages only support PDU mode for various mobile phones sold in China, which has become a de facto standard. In fact, the PDU mode is very useful. It is estimated that the text mode will shrink in the future. We recommend that you use only the PDU mode for the program we write, even if the English information is sent, the encoding can be flexible to take 7 bit or ucs2, because the length of 7 bits is twice that of ucs2 ). If you want to send pure data, you can use 8 bits instead of displaying it on your phone.

QIn the big cycle of sending and receiving in your smstraffic class, do you want to put all received messages into the message queue and then execute the delete program? If I have a large number of concurrent messages, there are a lot of short messages waiting for the gateway to enter the mobile phone. After reading all the short messages, the deletion process is due to the order of short messages, this leads to accidental deletion (for example, I have 1-15 short messages on my mobile phone. After I delete the first two messages, the third one is automatically filled as the first one, and the new one is, 16 rows are ranked third, but are dropped by cancel ?) I have tried to arrange short messages, not every time? (When receiving, the same short message is sometimes 14, sometimes 15th.) How can this problem be solved?

AEach message in the mobile phone has a physical serial number. When reading the message, it carries a serial number. Delete the message based on the serial number. The word "physical" is critical. This serial number is equivalent to the ID. no matter whether the message is deleted or deleted, it will not change. If one message is deleted from 1 to 15, and another message is sent, the internal software of the mobile phone can be processed in two ways: Some put 1st messages, and some put 16th messages, I have seen it all. In fact, it is willing to put it in any idle place. However, no matter what the sequence number is, it will not cause confusion. Because the sequence number is read, it will be deleted. Before executing the DELETE command, the message is still in the original place and will not be overwritten later.

If the gateway has a lot of short messages waiting to enter the mobile phone, the processing efficiency is not high, because at + cmgl takes a long time and the mobile phone cannot receive new messages from SMSC during this time. It is better to use the "real-time" method I mentioned to send messages directly without writing them into the mobile phone.

QI connected the Nokia 8210 serial port data cable to the computer's COM1 port and run the smstest prompt "no modem found". The trace found that the serial port sending AT command in the gsminit () detection did not respond to "OK ". According to your prompts, I installed the Nokia modem Driver (Win2000 Server System) to virtualize A 8210 modem device with the com3 port, and call smstest again to prompt "no modem found ". However, with the serial line, the mobile phone can use the logomanager mobile phone management software to send corresponding image logos and text messages.

ANokia mobile phones do not provide modem functions. In professional terms, they do not have the TA (terminal adapter) interface and need driver conversion. Whether it is a real serial port, USB or infrared interface, it can virtualize the "Standard modem" serial port. The at command can only use standard asynchronous communication.

In my opinion, Nokia 8210 needs infrared interfaces to communicate with PCs. It is estimated that the driver you installed is converted to IR-> com instead of serial data cable. Maybe your computer does not have an infrared interface, so com3 cannot be connected?

It is very easy to test whether the (virtual) serial port is correctly connected. Use the "Super Terminal" that comes with windows to connect to a specific virtual port and press "at" to see if there is any response, the correct answer should be "OK ".

The Nokia data line runs the "Nokia"-Nokia proprietary protocol data, not a universal/extended at command set. Logomanager can hear and speak "Nokia", so it can work without installing a driver. Nokia has a free "Nokia PC connectivity SDK" for developing Nokia mobile phones. It is unknown whether logomanager uses this development kit.

QIn smstest, issue the AT command and then receive the response, for example

WriteComm("AT+CMGF=0/r", 10);ReadComm(ans, 128);

The writecomm function then calls readcomm. Is it too urgent? Is the readcomm function used to read the returned string or a single character or incomplete string? How many timeout control settings are most suitable?

AIn the program, timeout control is set as follows:

Commtimeouts timeouts = {// serial port timeout Control Parameter 100, // read character interval Timeout: 100 MS 1, // read operation time per character: 1 MS (n characters total n ms) 500, // basic (additional) read Timeout: 500 MS 1, // time of each character when writing: 1 MS (n characters total n ms) 100}; // basic (additional) Write Timeout: 100 MS

When Will readcomm return? Set according to this timeout. If n = 128 (the second parameter of readcomm ),

If no data exists, wait for 500 + 1*128 = 628 milliseconds to return. That is to say, if the phone is not connected, there is no response, readcomm will continue to block for 628 milliseconds, and then return.

If the data is continuously transmitted and the character interval does not exceed 100 milliseconds, but the time has reached 628 milliseconds, the read characters (strings) are returned ). The received string may be incomplete.

If the character interval exceeds 628 milliseconds within 100 milliseconds (the waiting time before the first character is not counted), The read characters (strings) are returned ). The received string must be a complete string.

When the mobile phone is correctly connected, the last line is used. A piece of data is transmitted continuously. If the baud rate is 9600bps, the character interval can be calculated to be about 0.1 milliseconds, which is much less than 100 milliseconds. If one byte or part of the data is not read, the data is returned; usually only after the data is completed can the system return 100 milliseconds. For example, if "OK/R/N" is received 128 milliseconds after readcomm (ANS, 150) is executed, an additional 100 milliseconds are required, that is to say, the function will return in 250 milliseconds. The time for transmitting 4 bytes of data is ignored. If you think that reading is too urgent, you can increase the basic (additional) read timeout value. However, there is no response within 500 milliseconds, which may be caused by a connection failure.

Note the "at + cmgl" command and its response. It may be because you need to scan all the storage areas. After sending a short message one by one, you still need to wait several seconds before sending the final "OK ". Of course, the above basic read timeout can be set to a long time (such as 20 seconds) and a long read (such as 2000. However, function blocking takes too long. If the program exits at this time, you will find that "the program has no response ". The solution in smstest is to read the serial data cyclically, splice the data read each time, and finally obtain a complete response. Gsmgetresponse () may read part of the data each time, append the new data to the read data, and check whether "OK" or "error" is seen to determine whether the complete data has been read.

[Related resources]

Kernel studio: www.kernelstudio.com

Release date: 2004-03-16