Modem fails to respond at long intervals

The Option Icon 322 USB modem fails to respond to at commands at long intervals, and causes timeouts when waiting for a response to an at command, which are detected using the 'catch' command and causing my program to exit. When this happens, stopping and restarting the program does no good. The second restart always fails at the open() call, and by using 'fuser' ('fuser /dev/ttyHS0) it appears that the program has opened the modem, but gets stuck at a tcsetattr() call, according to the stack trace when I attach 'gdb' to the process. But, running minicom seems to restore correct operation. What does minicom do that the program does not do? If I can find out I can at least restart the program successfully. I would of course like to be able to reset the modem to restore it, but I can't figure out what does that, other than somehow (modprobe -r) deactivating the usbserial module and reactivating it.

To find out I ran both ('tclsh beaglegsm.tcl' and minicom) using 'strace' to trace system calls. Except for the open call, both do the same things regarding protocol in sending 'at' commands. The open call for minicom uses the switches:

 open("/dev/ttyHS0", O_RDWR|O_NOCTTY|O_NONBLOCK) = 3


while beaglegsm.tcl uses:

 open /dev/ttyHS0 RDWR

I programmed the open in tcl to use these same flags as minicom, and I'm now testing this arrangement:

open /dev/ttyHS0 {RDWR NOCTTY NONBLOCK}