Q&a compilation of "Send and receive short message via serial port"

On the "Send and receive short message through the serial port" topic, I will communicate with netizens, discuss some of the technical issues sorted into the following text. Hopefully this article will be helpful to more friends who are interested in SMS. Because I am a hobby, time and money are limited, there is no power to many models of mobile phones and module one by one test, there may be such a mistake, I hope that the line of the expert criticism.

I wrote a message to send the program, using the PDU format to send, the program in Guangzhou to use a little problem is not, in Henan but how can not send out. Do not know why, sms "Hello" format is as follows:

Henan: 0891683108200005f011000d91683170031618f20008a9064f60597d5417

Guangzhou: 0891683108301705f011000d91683170031618f20008a9064f60597d5417

Use the SMSC number of the SIM card dependencies when sending text messages. If the card is in Guangzhou, even in the field or to use the Guangzhou smsc number. Your two SMS SMSC number is different, but use the same SIM card, I do not know if this is the reason.

Can SMS center numbers directly use the number in the SIM card instead of the user input? I used the SMS software seems to be no need to lose SMSC number.

There is a "at+csca" directive that you can use to set or query the service center number. If this number already exists in the phone, there are two solutions:

With "At+csca?" Command query, and then automatically write this number to the PDU's SCA.

The SCA field for the PDU only writes one ":"-> "00"

Use the "at+csca=xxxxxxxx" directive to set the service center number.

I am on the HyperTerminal, send the short message with AT+CMGS, the format seems to have no error, but always return "error". I typed it like this:

at+cmgs=30
> 0891683108100005F011000D91683118405057F000000006C8329BFD0E01

Excuse me, what is the reason?

The "at+cmgs" Directive is special, and you need to enter data after the carriage return. Here is "CR", not "CRLF", notice whether direct carriage return in HyperTerminal generates two characters (viewing settings). Like "AT+CMGL" instruction, even if the final input "CRLF" also does not matter.

Your problem is in the length. The length is not casually written, in your case, the length should be 21. Remove the SMSC segment (0891683108100005F0), starting with "11" (i.e. "11000d91683118405057f000000006c8329bfd0e01"), divided by 2.

The correct wording should be

at+cmgs=21
> 0891683108100005F011000D91683118405057F000000006C8329BFD0E01

(">" is a mobile prompt, not input)

I recently made a program about the short message, in your "Send and receive short message through the serial port" mentioned "text mode is a pure text, you can use different character sets, technically can also be used to send Chinese short message, but the domestic mobile phone basically do not support, mainly used in Europe and America." "is not that I use at the command" at+cmgf=1 "or" at+cmgf=0 "to my later send and receive short message has no effect AH?

Text mode is simple to write, directly to the original line, send non-ASCII content can also be sent, but the need for mobile phone support to correctly display. Many characters, such as French and German, are encoded more than 0x80, and they are all in text mode. What does Text mode do to differentiate character encoding? There are special character set instructions "At+cscs". Can be set to the extended character set "UCS2". Siemens Tc35/tc37 said that its "At+cscs" supports the "UCS2" character set, but I have no chance to test it myself. Friends who are using the Tc35/tc37 module might as well try.

As far as I know, Chinese short message, in the domestic sale of all kinds of mobile phones only support PDU mode, which became the de facto standard. In fact, the PDU mode is really good use, it is estimated that the text mode will atrophy. We write the program, I recommend only the use of PDU mode, even if the message is pure English, encoding can be flexible to take 7bit or UCS2, because 7bit can send the length is UCS2 twice times (only for pure English). If you send pure data, you do not need a mobile phone display, available 8bit.

In your smstraffic class in the send receive in the cycle, is not all the received messages into the message queue, and then execute the removal program AH? If I am a lot of concurrency, that is, the gateway has many short messages waiting to enter the phone, after reading all the short messages, in the process of deletion, because of the order of the short message, which led to the deletion of the error (for example, I now have 1-15 short messages on the phone, and then after I delete the 12th, the third automatically fill as the first one, And the new incoming message, 16 lines in the third, and was cancel it? I tried to look like the arrangement of short messages is not always the same? (at the time of reception, the same short message is sometimes 14, sometimes 15th) how does this work out?

Mobile phone message has a physical serial number, read out with the serial number, delete also to be deleted according to the serial number. The word "physics" is critical. This serial number is the same as the ID, and it will not change, no matter how many messages it has previously deleted or deleted. If there were 1-15, deleted 1 and 2, another message, the inside of the mobile phone software has two ways to deal with: Some in the 1th, and some on the 16th, I have seen. In fact, it is willing to put in any free place to do. But no matter what, will not cause confusion, because read out is what serial number, delete what serial number. Before the delete command is executed, the message is still in the same place and will not be overwritten later.

If the gateway has a lot of short messages waiting to enter the phone, the volume is very large, this approach is inefficient, because AT+CMGL occupy a long time, this time the mobile phone can not receive new messages from SMSC. I said the "real-time" reception method is better, the message came directly out, not through the process of writing to the phone.

I use the Nokia 8210 serial data cable, connected to the computer's COM1 mouth, with the smstest run hint "did not find the modem", Tracking found Gsminit () detection of the serial port at the command did not respond "OK". According to your prompts I installed the Nokia modem driver, (WIN2000 Server System) virtual out of the COM3 port of a 8210 modem equipment, call again smstest or hint "did not find the modem." But with serial line, mobile phone can through Logomanager mobile phone management software to carry out the corresponding picture logo, SMS send operation.

Nokia mobile phone itself does not have the modem function, in the jargon is not equipped with TA (Terminal Adapter) interface, need to drive the conversion, whether it is true serial, USB or infrared interface, anyway it can be virtual out of "Standard Modem" serial port. The AT command can only use standard asynchronous communication.

In my impression, Nokia 8210 requires an infrared interface to communicate with the PC. It is estimated that the driver you installed is ir->com conversion, instead of driving the serial data cable, your computer may not have an infrared interface, so the COM3 is not connected?