On Thu, Jul 23, 2020 at 8:16 AM Aleksander Morgado
<aleksan...@aleksander.es> wrote:
>
> > > > > I will have to run the following sequence:
> > > > > - go in AT+CFUN=4 (airplane mode with SIM connected). This is
> > > > > necessary because the CID might be locked or not taken into account
> > > > > immediately (in case there is an attach attempt ongoing).
> > > > > - set AT+CGDCONT for the right CID (normally 1)
> > > > > - set AT^SGAUTH for the same CID
> > > > > - go back to AT+CFUN=1.
> > > > >
> >
> > I am implementing this sequence, and will submit soon (I hope), but I
> > am stepping into a problem with CFUN:
> >
> > ModemManager[2541]: <debug> [1595452432.501830] [modem0/ttyACM0/at]
> > --> 'AT+CFUN=1<CR>'
> > ModemManager[2541]: <debug> [1595452432.533882] [modem0/ttyACM0/at]
> > <-- '<CR><LF>OK<CR><LF><CR><LF>^SYSSTART<CR><LF>'
> > ModemManager[2541]: <debug> [1595452452.512543] [modem0] (cinterion)
> > error in step = 5
>
> Maybe you should add a regex to ignore the ^SYSSTART URC.
not sure how to do it. Any examples I can look at?
I have also noticed that it could be a known issue, because in
src/mm-broadband-modem.c: modem_power_up(), the error is not checked,
and the command
mm_base_modem_at_command (MM_BASE_MODEM (self),
"+CFUN=1",
5,
FALSE,
NULL,
NULL);
takes 5 seconds and then continues. It works faster if the modem is
already in cfun=1, because then there is no urc, only ok, but takes 5
seconds (the timeout) when changing from another mode.
> But it's a
> bit strange I must say, would need to look at the code, because the
> kind of errors we get with URCs is when the URCs get interleaved
> before the OK.
>
Yes, this is disrupting all right, but it is avoided in Cinterion
modems just because of the interpretation issues.
Giacinto
_______________________________________________
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
