I have programmed a D-Link GSM modem on a windows machine to send and receive SMS, for testing I used Hyperterminal.
In windows the connection manager initiates the COMx ports, modem uses one unlisted COMx port through which I can send an SMS, and through a listed NMEA port I receive incoming SMS, calls like +CMTI: "ME", 11 or RING +CLIP: XXXXXXXXXXXX
I'm successfully interpreting the message and programming it to my requirements in windows. While trying the same in linux(Fedora), I see the modem initialises /dev/ttyUSB0 and /dev/ttyUSB1 as the two newly identified devices. I use minicom to set the device ports and communicate AT commands to the same.
In both the devices (/dev/ttyUSB0 and /dev/ttyUSB1) I'm not receiving unsolicited AT result code like +CMTI indication whenever I'm expecting a new SMS. FYI I've set the CNMI setting according to the manual and several other combinations.
A strange thing is that I'm able to see RING when I'm calling but not +CLIP: <callerinfo>. Similarly I'm not getting ++PSBEARER: XX, Y or +CMTI: "ME", XX
The only alternative solution is to poll the UNREAD messages at regular intervals, which is generally a bad design. Please tell me if I'm doing anything wrong with regards to the configuration, should I change some thing else apart from these?
RING is the only UR code you can assume that will always come without any specific configuration (just because this is such an old relic that it just behaves that way...). For all other UR codes, you must explicit enable each and every one of them, e.g. AT+CLIP=1, etc, otherwise they will not be enabled. And enabling those are per serial interface, e.g. running AT+CLIP=1 on /dev/ttyUSB0 will not make +CPLIP: ... be printed on /dev/ttyUSB1.
So when you get them on windows the connection manager, it must be because it has those included in it init strings. Minicom I think defaults to no init string or possibly just a very classical one like ATS0=0 E1Q0V1.