I bought a SixFab carrier board with the LE910C4-NF card on it about 2 years ago, and I’m finally getting around to installing it and putting it into production. I’ve used both a Google Fi data-only SIM, and the SixFab SIM (the Fi SIM barely worked, the SixFab SIM sort of works). The carrier is connected to a RPi 0W using only a USB cable (not stacked on top like a hat); OS is Raspbian/Debian 11.7. SixFab-CORE is not installed; I’m bringing up the cellular IP link manually when needed. I’m facing a series of issues, so let’s start with the first one:
All the documentation indicates that one should use /dev/ttyUSB2 for issuing AT commands. The funny thing is: it works exceedingly badly. Characters coming back from the Telit modem often don’t get echoed, characters going to the Telit modem occasionally get dropped on the floor making issuing longer commands hard. Once in a while, the screen program hangs when trying to connect, while the pyserial-miniterm program occasionally errors out getting a timeout on one of the hardware modem control lines.
Most of the time, using /dev/ttyUSB3 instead for AT commands works fine (that’s not a typo, three instead of two). Occasionally, both ttyUSB2 and ttyUSB3 get “jammed”. This happens more often when IP is enabled (AT#ECM? reports 0,1). When this happens, the fix is either to reboot the Raspberry Pi, or cutting power to the Telit modem by unplugging the USB cable between Pi and SixFab carrier.
Absolutely nothing in dmesg, neither about USB connecting/reconnecting (only see the connection messages at boot time), nor about under voltage.
I assume the Telit module is getting enough power, because sometimes it functions great, connecting on the cell network, providing 200 kBytes/s of IP throughput. I guess I could run a pair of extra wires from the 5V and ground connection on the RPi to the SixFab carrier.
Installed minicom today. I’ve used pyserial-miniterm, cu, and screen, and now minicom. No change in symptoms.
BUT: Your second question just gave me a clue. Could there be some rogue process that is connecting to /dev/ttyUSB2 and eating characters? Turns out there is: fuser shows that a process running /usr/sbin/ModemManager has that device open. I’ll need to do some research what that thing is, what it does, and whether I need or want it.
Also, today I added two short wires (20 gauge, 4 inches) to pins 4 and 6 on the 40-pin connector (from RPi to SixFab board) to feed +5V and Gnd between them. The RPi does not show low voltage alarms, the power supply is capable of making 5V 3A, and measuring the voltage with my Fluke shows very accurately 5V (the supply is a TI buck converter coming from 12V, which is a car battery). While in the neighborhood, I connected a wire from the RPi to SixFab’s GPIO 26 (= physical pin 37), so now I can remotely power cycle the cell modem.
Anyway, adding the new wires didn’t change things either. But the power issue can’t have been serious: even before adding the extra power wires the cell modem was able to connect, and deliver 150 KByte/s … sometimes. I think in the long run I’ll pull the fuse from the SixFab board (since USB cables and connectors are so unreliable in delivering power), and rely on my new wires instead.
Disabled ModemManager with “systemctl ModemManager disable”. Now /dev/ttyUSB2 works perfectly! And everything else (like “ifconfig wwan0 up/down” or changing routes) continues to work too. It’s not clear to me whether ModemManager has any useful function for me, as I intend to bring the cell modem up and down myself when needed; either with AT commands issued to a virtual USB serial port, or with ifconfig or ip commmands.
Your hint saved the day. Onto the next problem: Why do my packets not get routed today, but were routed yesterday? I’ll diagnose that tomorrow morning.