Re: GlobeTrotter HSDPA Modem -> Failed to find a usable modem character set

[Dan Williams <dcbw redhat com>]

On Thu, 2011-09-15 at 13:22 +0200, Aleksander Morgado wrote:
> > (ttyHS0): --> 'AT_OPSYS?<CR>'
> > Sep 15 10:43:34 ThinClient modem-manager[2081]: <debug>
> > [mm-at-serial-port.c:298] debug_log(): (ttyHS0): <--
> > '<CR><LF>ERROR<CR><LF>'
> > Sep 15 10:43:34 ThinClient modem-manager[2081]: <debug>
> > [mm-serial-parsers.c:412] mm_serial_parser_v1_parse(): Got failure
> > code 100: Unknown error
> > Sep 15 10:43:34 ThinClient modem-manager[2081]: <debug>
> > [mm-at-serial-port.c:298] debug_log(): (ttyHS0): --> 'AT+CSCS=?<CR>'
> > Sep 15 10:43:34 ThinClient modem-manager[2081]: <debug>
> > [mm-at-serial-port.c:298] debug_log(): (ttyHS0): <-- '<CR><LF>_OPSYS:
> > 3,2<CR><LF><CR><LF>OK<CR><LF>'
> > Sep 15 10:43:34 ThinClient modem-manager[2081]: <debug>
> > [mm-at-serial-port.c:298] debug_log(): (ttyHS0): --> 'AT
> > +CMER=3,0,0,1<CR>' 
> 
> To me the real issue here seems to be that the reply to "AT_OPSYS?" is
> split in a first "ERROR" string and then "_OPSYS: 3,2 OK". The serial
> parsers will consider the ERROR part as being a full response, and
> therefore ModemManager issues the "AT+CSCS?" command next, and then we
> get the second chunk of the OPSYS reply as if it were the reply to the
> AT+CSCS... The fix could be to let "ERROR" be considered as a partial
> reply by providing a custom regex in the response parsers, similar to
> what it was done here:
> 
> http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=262edb96d50138a724173840fc63ca93ede322c2

That's a really weird response though.  I can't recall having seen a
modem return ERROR *and* a valid response.  Perhaps the response there
is actually an unsolicited response that's been enabled by the
AT_OSSYS=1.  It may be that the modem simply isn't quite ready yet when
we start poking it?  That could also be the reason why AT_OSQI=1 is
failing.

What Option modem is this again?

Dan