Sierra Wireless MC7455

We do have problems with the Sierra Wireless MC7455 when it comes to a startup of our system in an area with no network reception.
The module is installed in a system which is installed in a car. On the system Ubuntu 18.04 is installed. For communcation with the Modem, we use the ModemManager. The output of mmcli -m 0 says:

       General  |                 path: /org/freedesktop/ModemManager1/Modem/0
                |            device id: ****
       Hardware |         manufacturer: Sierra Wireless, Incorporated
                |                model: MC7455
                |    firmware revision: SWI9X30C_02.33.03.00 r8209 CARMD-EV-FRMWR2 2019/08/28 20:59:30
                |            supported: gsm-umts, lte
                |              current: gsm-umts, lte
                |         equipment id: 
       System   |               device: /sys/devices/3530000.xhci/usb1/1-3/1-3.2
                |              drivers: qcserial, qmi_wwan
                |               plugin: sierra
                |         primary port: ttyUSB2
                |                ports: ttyUSB0 (qcdm), ttyUSB1 (gps), ttyUSB2 (at),
                |                       wwan0 (ignored), wwan1 (ignored)
       Status   |       unlock retries: sim-pin (3), sim-pin2 (3), sim-puk (10), sim-puk2 (10)
                |                state: connected
                |          power state: on
                |          access tech: lte
                |       signal quality: 0% (recent)
       Modes    |            supported: allowed: 2g, 3g, 4g; preferred: none
                |              current: allowed: 2g, 3g, 4g; preferred: none
       IP       |            supported: ipv4, ipv6, ipv4v6
       3GPP     |                 imei: ****
                |          operator id: ****
                |         registration: home
       3GPP EPS | ue mode of operation: ps-2
       SIM      |     primary sim path: /org/freedesktop/ModemManager1/SIM/0
     Bearer   |                paths: /org/freedesktop/ModemManager1/Bearer/0

Everything is working fine, as long as we start the system in an area with network reception.
However, when we start the system in an area with no network reception, the module seems to say good bye and never responds to AT commands.
When this happens, “journalctl -u ModemManager” says " (tty/ttyUSB2) at port timed out 10 consecutive times, marking modem ‘/org/freedesktop/ModemManager1/Modem/0’ as invalid".
As pointed out in [PATCH 2/2] base-modem: setup a maximum number of timeouts also for USB modems, this timeout happens when the Modem does not respond to AT-commands and may be marked as invalid if it timed out 10 times since ModemManager then can be sure that there is no modem behind this port. And the only relation we can see is the “no network reception at the startup”-thing, we do have absolutly 0 problems with the Modem, as long as we have network reception.

Is this a known problem? What can we do about that?

Did you try to use mincom to communicate via /dev/ttyUSB2?

The first time I used minicom to communicate with the modem via /dev/ttyUSB2 was today when I synchronized the modem with Siera Wireless to figure out, that we have the most recent version of the firmware. Before that, I always let ModemManager do all the communication stuff with the Modem.

I.e., I definitely never tryed to communicate with the modem after the communication of ModemManager with the Modem timed out. Do you think I could get new insights when trying this?

you can go with a try.

The only different thing between with network and without network is that it will consume more power for network scan, I don’t know if this will cause any hardware power problem in your platform.

Is there a way to influence the behaviour of the Modem with AT-commands in case of no network reception?

I don’t think so, I usually test with MC74 without antenna, no problem is found.

I am only able to reproduce this error in a targeted manner when I start the system in the third basement of an underground car park without antenna. In an normal environment like an office with OK network reception and no antenna, I did not get this error once so far.

are you testing the same hardware then?

Yes. We even have multiple devices in which all are identical (regarding the hardware). For all of them we observe this behaviour.

how about setting it to AT+CFUN=0 first and then go to the underground area?

I guess I can use this command to test if the Modem is able to survive the period in the underground area with and without using this command. If I find time to test, I will come back.
Thanks for the help.

i will also try and use this command to examine this out. thanks

We figured out the problem was another service which probed for a special kind of serial device. The probing sends data to any serial device it can find, and since the modem is using a serial port for communication the probing disturbed the communication between mmcli and the modem.

Nevertheless it is weird that this error only appear when we had a bad network reception.