Use of mobile phone modules on CE based products

To have wireless communication on your windows-based products (dial-up, call, SMS), your choice is either to have the user add to the phone or to integrate the phone module on your product. If it is an external mobile phone, then the mobile phone only plays the role of receiving and sending data during the Internet browsing. If you must integrate the mobile phone module, then the mobile phone module to complete the full function of wireless communication, from the software development point of view, relative to a bit of trouble. This article briefly explains the issues that need to be noted in the development of software to control mobile phone modules.

First, dial-up Internet access

During Internet browsing, the phone module is responsible for connecting to the ISP, receiving data from the ISP, and sending data. If the ISP is moving in China, then there are two dial-up numbers, a number 17201, a normal dial-up Internet service that can be accessed to the cmnet at 9.6Kbps of data transmission rate, and the other number is *99#, which uses GRPs to speed up receiving and sending data. GPRS access mode provides 30kb/second to 40kb/second access speed, the use of data acceleration system can reach 60kb/seconds to 80kb/seconds. Windows CE provides support for dial-up connections, which APIs I have mentioned in the previous article (see "Windows CE dial-up Internet access"). Using the RAS function, we only need to determine the serial port connected to the mobile phone module, enter the user name, password, phone number can be connected to the ISP, and then just call IE Browser can easily browse the Web page, the entire function of the implementation we have only done a little work. However, the use of RAS functions pros and cons in the development of a relatively easy, the disadvantage in it to cover up the bottom of the implementation, from the "Windows ce dial-up Internet" figure can be seen, RAS is the implementation of the top of the dial-up connection, TAPI and Unimodem is the main implementation layer. In other words you want to set the baud rate at the RAS level such as serial port is impossible. And the CE default dial-up connection record serial port baud rate is 19200, compared to 17201 of the data transmission speed is slow, not to mention is GPRS. To set the baud rate of the serial port is maximum 115200, there are two possible ways, one is to give up RAS, call the TAPI function to achieve dial-up Internet, There are several functions in the TAPI function, such as Lineconfigdialogedit with interface and linedevspecific with no interface, can set the baud rate; Another method to be more simple, in CE first with the CE with the "dial-up Connection" program to establish a dial record, The baud rate can be set during the setup process, and the data for this dial-up record is saved to the registry. If you develop your dialer yourself, you can simply find the dialing record in the registry before dialing. This way you can set the baud rate. If your CE platform does not support the permanent maintenance of the registry, then you can save the dial-up record data directly to the PB, so that the custom kernel itself contains a dial-up record, you can read any.

Second, call, send and receive SMS

To achieve the call and send and receive text messages, using the AT command set and serial communication. Because the CE serial port does not support overlapping, so in the dial-up and web browsing period can not open the same serial port again. About serial communication I have written an article before, but the thread receiving serial data is not suitable for receiving the data returned by mobile phone module, it is necessary to structure a reasonable model for the characteristics of mobile phone module. Let me talk about the two issues I encountered in the development process, if you have different views please email me, I hope to get your valuable advice.

1, unlike mobile phones, some mobile phone modules do not have storage capabilities, so each time you start to initialize some necessary settings. For example, set SMS text mode, character format, microphone and handset volume. The actual initialization will be more. In this case, if you send a command immediately after another command, then the phone module is too much. You must first send a command, then wait for the phone module to return the result of the command, if successful and then send the next command, this will ensure that the initialization can be completed successfully, and real-time display of the current working status.

2, the mobile phone module returned information is not sure. Any command sent to the cell phone module will be returned, and the returned string may contain a response to the command, or it may not be included. This makes it necessary to retrieve the entire return information, and also to distinguish whether the returned information is a response to the command. such as "\r\nring\r\n" is not a response to a command.

There are more than two problems actually encountered, so consider the problem when the architecture receives the data section and processes the data section.