If you report an error, you may be asked to provide a debug log.
SMSLib works with Apache log4j. Log4j is usually control by a file named
log4j.properties. SMSLib uses the
There is a convinient
log4j.properties file set to DEBUG output in the
/misc folder of the distribution directory. Copy this file in your classpath or current execution directory in order to quickly enable the full SMSLib logging.
If you are using SMSLib for Java on Linux with the RxTx communication library, you may encounter a situation where you get a no response exception, as if no modem is actually connected to your computer. This error situation will hit you if you are working with virtual serial ports, like USB or IrDA bridges / virtual devices.
This is attributed to RxTx: SMSLib v3 uses comm port signals (data ready,etc) to wake-up and read port data. Under some circumstances, RxTx does not forward these port signal to the application, so SMSLib thinks that it never gets any data back from the modem.
SMSLib has implemented a work-around for this situation: If you face the above problem, run your applications with the
-Dsmslib.serial.polling parameter. This will instruct SMSLib to work in poll mode: It will not wait for comm port's data signals but it will poll the port every 300 milliseconds to see if there is any data available for reading.
Please note that if you are using SUN Java Comm v3 (instead of RxTx) you generally not need to use this switch, unless you find that your modem does not work otherwise.
In any case, the polling switch is a workaround and should be avoided if things work well without it.
If everything else seems to have been setup properly, keep in mind that most GSM modems have a default baud speed at which they operate. Most of the times, the autobaud sensing feature does not exist or does not work like GSM phones. So, be sure that you are using the baud rate speed that you modem requires.
If you using USB/Bluetooth/IrDA connections on Linux, RxTx may not recognize your serial device / port. You may get a NoSuchPortException.
Assuming that your port is named
/dev/xyz-port , you can:
gnu.io.rxtx.SerialPortssystem property with your device name.
/dev/xyz-portto something resembling a standard serial port, like
/dev/ttyS20, and use this one instead.
When running under Linux and RxTx, you may encounter some unresolved errors during execution. These errors mean that your Java runtime cannot locate the necessary RxTx library (.so).
To resolve this, run your application with the
-Djava.library.path=/dir-path/to/.so/file in order to instruct java to search to the specific directory where you have placed the RxTx so files.
There are times when you run the CommTest utility but your modem is not detected.
Several GSM modems require a standard baud rate in order to identify the connection. This baud rate can be changed with some special AT commands.
The issue here is that the CommTest utility does not check all valid baud rates. If you check the source code, there is an array (
bauds) which hold all the rates that will be test. What you can do is to add to this array all baud rates that you suspect are missing. Recompile and run the CommTest again and check if your modem is now detected.
If you are getting one or two framing errors during the initial connection (and this happens on a random basis) its probably nothing.
If you are consistently getting framing errors, probably you are trying to connect with a baud rate that is unsupported by your modem. Some modems require a fixed baud rate to operate. Either consult your manual or try with different baud speeds.