That's what I mean; it should be perfectly valid to be able to scan for
> > Also, based on my experiments, the modem sometimes seems to hang when
> > running AT+COPS=?. This patch avoids AT+COPS=? from being issued when
> > the modem is in LTE mdoe.
>
> From what I can see, it also avoids the Scan when the access tech is
> unknown:
>
> + if ((access_tech == MM_MODEM_ACCESS_TECHNOLOGY_UNKNOWN) ||
> + (access_tech & MM_MODEM_ACCESS_TECHNOLOGY_LTE)) {
>
> So you're really limiting the scanning for networks only to when the
> modem is already connected to a given network which is not LTE. I don't
> think we shouldn't ban from scanning when access tech is UNKNOWN.
>
>
> I include UNKNOWN just to be safe as there may be a period of time when
> the access technology is not yet determined.
>
networks when the modem is not yet registered anywhere, i.e. when the
access tech is unknown.
> Also, the reply to AT+COPS=? may really take a loong time; you sure itSo this patch is just avoiding the need to parse an empty list as the
> gets stuck?
>
>
> From what I've seen before, the scan operation timed out and the modem
> didn't respond to AT commands anymore. However, that's not frequently
> reproducible.
>
AT+COPS=? command replies just OK by default when in LTE mode. Is it
really worth the complication of subclassing the scan method just to
avoid that? :-/
>It would be great if you could check the overall behaviour of the
> I wonder how the scan works when the Novatel LTE modem is handled by the
> QMI driver. IIRC Dan said we wouldn't need this specific plugin any more
> once the modem is handled by the QMI implementation.
>
>
> I haven't tried the QMI driver for this modem, but wonder if it behaves
> in a similar way as the limitation is most likely a firmware issue.
>
Novatel LTE modem with the QMI driver, to see if there is any reason not
to switch to it...
--
Aleksander