I am experiencing a truly frustrating issue with the Quectel EG21-G, firmware EG21GGBR07A11M1G. I have a Pi 5 Compute Module, running on a Waveshare CM5-IO-BASE-A board. The modem is plugged into an Exvist USB adapter: 4G LTE Global Dongle with EG25-G Mini PCIe | SIM Slot, GPS, Type-C Adapter | EXVIST. Now I have the following problem. The modem often works perfectly fine. Sometimes, however, and I’m not sure when or why, the modem goes into an error state from which I can’t get it out reliably.
Here is my test log with approaches I have already tried:
I powered the Pi via a 5V 3A power supply. Four RTL-SDRs and a USB stick were connected to the Pi. stress was executed on the Pi to max out the power supply. These tests didn’t show anything. The LTE connection was stable. The next day, the Pi was turned on again in exactly the same way, but the modem was no longer available. The phenomenon: the modem is recognized briefly, after about 5 seconds it is gone again, and the whole thing then loops. So it’s there briefly, then gone again (visible in dmesg).
Sometimes the Pi is operated with a serial-to-USB adapter, which I use to read the status of another device. I thought that this might be accidentally running on ttyUSB0, but that is not the case.
Then I debugged the USB port with usbmon. To do this, I created a pcap with tcpdump -s0 -i usbmon2 (the modem port) and viewed it with Wireshark. Here it was quite clear that the modem registers correctly, the kernel registers it as wwan, the AT communication also works, but the modem simply disappears after 4-5 seconds. The kernel also acknowledged this with “no such device”.
To really rule out power issues as the source of the error, a laboratory-grade power supply with 5.2V and 5.1A was used to operate the Pi. The modem was connected to an actively powered hub. No other consumers were connected to the pi. According to the power supply and an additional power meter, the supply was stable and sufficient. In addition, the options usb_max_current_enable and PSU_MAX_CURRENT=5000 were set to ensure that the USB ports received all the power they needed.
I then connected an external USB board to the Waveshare IO board, but this was also unsuccessful. I then connected this “broken” modem to another Pi, where it also did not work. However, a working modem on the original Pi worked perfectly fine.
I would say that I can rule out power as a problem, at least enough power does not seem to fix the error condition. Since swapping modems also works, the Pi and the Waveshare board can also be ruled out as the source of the error (or it may still have caused the original error?).
I then tried operating the modem with two antennas, but this did not change anything. Not even outside in a parking lot. It still connects to the Pi, but loses the connection again after 4-5 seconds. It doesn’t matter whether 1 or 2 antennas are connected or in which order the antennas are connected (i.e., which is main and which is div).
Finally, I operated the modem without any antennas at all, and then it worked. It remained stably connected to the kernel (but of course, due to the lack of an antenna, it was unable to establish an LTE connection and remained in searching status). As soon as an antenna was connected, the error reappeared.
Then I removed the actual modem from the carrier board (Exvist) and replaced it with another one, which worked great. Reinserting the old one led to the same error again. So I’m pretty sure that the carrier board isn’t the problem either.
I don’t know what caused the modem to end up in this state, but once it was in this state, I couldn’t get it out reliably.
I also removed the shielding. Idea: use a thermal imaging camera to see if there is a short somewhere. That didn’t reveal anything either.
That’s where I stopped. The next day, I booted up the setup again 1:1 and suddenly everything worked. The modem connected to an O2 LTE cell and I had internet.
I am kinda out of ideas. Any suggestions? How can I debug this further? I am somewhat out of ideas 