Quectel EC25AF GL-X750

[D_M]

Quectel has very poor documentation, and not one man or woman in their company comprehends english properly.

The don't document what the various AT+QCFS commands do, and due to their lack of documentation and overall poor english, one command runs into another. Plus, they have implemented very poor design standards.

There is a "usbmode" command vs a "usbnet" command. Now the "usbmode" was changed instead of "usbnet", and /dev/ttyUSBx are no longer visible.

Changing usbmode host back to auto

That is how poor Quectel understands. They never answered the question. There are a couple of threads on their forum, they never answered them. I have essentially the same question.

Seeing if GLiNet is any better at it.

[admon]

So you switched to the wrong data transmit mode and can't get back anymore? Is this the issue?

[D_M]

See what I mean? It's confusing to everyone. On purpose. Anything to make junk, needlessly complex.

The mode, means host/device, here.

The 'net' means... mode of mbim, ecm, rndis. I am not speaking about that. Although that is what I was trying to change. But they use 'mode' in both.

Quectel is apparently too proud to hire someone that knows something besides chinese.

[D_M]

USB Modes of PPP, ECM, MBIM and RNDIS are changed with the

AT+QCFG="usbnet",0

or 1 or 2 or 3, command. In that order.

USB Modes of Host or Device (control) are changed with

AT+QCFG="usbmode",0 or 1

No documentation that if you change it to host, that you are never changing it back, or how to change it back. /dev/ttyUSB2 disappears. That is an engineering 'feature' [error], so that you can no longer send AT commands to change it back.

Apparently there are physical ports on the card, with a USB-TTY 3.3v cable you can communicate. Gotta love insecure programmers/engineers who make junk to protect their job security, instead of good products.

[admon]

I will tag GL.iNets developer @ywp - maybe he knows what to do.
Since it's weekend, you might have to wait 2 days until you get a reply.

Maybe this thread can help you as well: How-To: Installing Vanilla OpenWRT on GL X3000 - even if it's for another model.

[D_M]

That thread, while interesting, is totally unrelated to the issue.

Go look at the thread I linked in the original post.

Thank you for tagging someone who might know.

[D_M]

Here are some more examples of people asking the same thing and getting no conscious replies:

AT cmd port fail after set usbnet into RNDIS mode

[ywp]

sorry，If you change the usbnet mode
in the current X750, /dev/ttyUSBx is missing
You have to disassemble the machine, remove the module, and refresh the firmware on the computer

[D_M]

Ok.

"usbmode" was used. Not "usbnet" [Update 9/7: it was the use of "usbauto" that caused the /ttyUSBx to disappear, and for the board to get stuck in a non-functional RNDIS mode, not "usbmode", apparently.]

Anyway, assuming that is what you meant, do I get a mini-pcie to usb adapter (about $12) and put the EC25-AF in it, and connect to a laptop? Is windows 10 ok?

Then how do I go about resetting the device? If there are no comm ports available? Or will one show up? What does the laptop access give that the glinet GL-X750 doesn't have, to be able to get the device working again.

Quectel makes a full-featured development board, with UART lines connected, so serial communication is possible even if the board isn't enumerating the ports through software. I found it online for $100. I'm not spending that kind of good-money-after-bad after having dealt with their hot garbage board that nukes itself. Not when decent LTE boards cost half that amount!

[ywp]

I'll talk to quectel on Monday
I need to test it myself before I can give you an answer
thank you

[D_M]

That's great. I've asked my chinese friend 'Hey, can you talk to these people? They haven't hired anyone who comprehends english properly.' Because Quectel staff, at least on their forum, do not seem to understand the premise of the question. Several people hav been asking over the years, and it seems straightforward.

GLiNet actually has staff that have a strong comprehension of english. And, people more adept than myself at working with these cards (mini pci-e 4G quectel), this specific one (EC25-) and others.

What I have gathered, from reading a Quectel 300+ page manual on the card, numerous posts, and another document that shows the pin layout, physical design:

A variety of Quectel cards, 4G, 5G, have had their operator send:
AT+QCFG="usbmode"...
instead of "usbnet"
(all are sub-options under AT+QCFG=, which I have found no full documentation on).

Or, in some other way, the card went into a condition where the /ttyUSBx disappeared.

Apparently, that is 'host' mode instead of 'device' mode. Which, mistakenly, turns off critical serial port access (AT commands).

It seems that all their cards, have a recovery mode, that requires pulling up USB_BOOT to VDD_EXT (1.8v) on power-on/boot, putting the card into Emergency Download Mode. The method to reset is then is to flash the card. There seems to a USB_BOOT pin on the EC25-AF, but in their documentation it is marked 'RESERVED', along with many other pins. This seems to put the card in a Qualcomm Gobi 'mode', which is how it is seen by the host system, ready for flashing.

If you are fortunate to have the Quectel Developers version of the Mini-PCIe to USB adapter, apparently it has hard-wired UART lines that allow communication. Those would work, regardless of whether the emulated UART lines are turned off.

The RESET_N pin, only reboots the chip. It does not reset anything. One of their staff replied in a thread about it. Incorrectly-named, should have been REBOOT_N.

This card's RNDIS function, seems to partially 'work', right now. An IPv4 address, that is clearly coming from the cell provider, appears in Openwrt. No connectivity through the router though.

The original reason, for me poking around, was the wan_watchdog.sh script was logging that it was loosing connectivity. Seeking to resolve these issues, I flashed the card, put it in NDIS or ECM mode, instead of QMI or MBIM, and it worked fine with newer official firmware. Along the way, finishing-up, somehow I was unable to get an IPv6 address into Openwrt. The AT+ commands were showing that the card was correctly getting an IPv6 from the cell provided/internet upstream.

While troubleshooting, I accidentally, due to the confusing use of terms, used usbmode instead of usbnet, the card was stuck in a non-functional RNDIS mode, with no ttyUSBx comm lines.

How to gain access to the card, to set it right?

By placing it in a USB adapter, to be accessed through a laptop [you are looking into that]?

Or how, through commands, to get the card to factory-reset itself? Those commands are, supposedly something only used by the engineers at Quectel! And require ttyUSB or hard-wired UART access.

Where is the USB_BOOT pin on this card, that will force the chip into EDM, which, after a flash, will then supposedly reset the "usbmode"? I'm sure it exists. It does on very similar products from Quectel.

Edit: Not sure how I missed this, but it happens: The hardwire UART lines are exposed on pins 11,13 on the card. Iirc, the GLiNet staff said those are not connected to anything on the main GL-X750 board. A 3.3v tty-to-USB adapter should allow communication with the board when it is powered-up. See attached.

[D_M]

A little update:

I was talking with an advanced developer, who has a developer sample of an Rxxxxx type 5G/4G Quectel board. He pointed out how the "usbmode" is not consequential to the issue the board is having, apparently. It is therefore, only some coincidence that the board was behaving strangely, at the time when that command was sent and the USB/uart comm ports disappeared. Looking at it again, it was behaving strangely before then, too:

Sequence,
Board, and GL-X750 it is in, is at first working, for over a week. This is a new component to a production environment. The 'new' (to me) GL-X750 unit, then seems to start disconnecting from the provider every few minutes. The watchdog script is catching the communications failures and 'ifup' the device.

Nothing had been changed, at that time, and other lines/devices were operational to the same tower with the same provider, and those were working normally. That means something with the Quectel board, was suspect.

Openwrt 23.05.4, (original) EC25 with stock Quectel firmware.

This is not the first GLiNet product that went bad on us. Only the second product, and it also went bad/unreliable. Albeit it could be argued only the Quectel board went bad, but you pick your suppliers. And it seems GLiNet products are designed to 'run hot', pursuing a compact design, possibly causing early failure due to thermal issues.

In the process of troubleshooting, a request had been put in for updated firmware. Since everything was being looked-at, why not?

The flash went without error. The board seemed to be performing.

Then, within 24 hrs, the board was noticed to be malfunctioning again. And the log seemed to indicate errors that had gone unnoticed. I must emphasize here, that the flash went fine - no errors. And the board was already seemingly malfunctioning prior to flashing it.

The GL-X750, to satisfy curiosity, was re-flashed just now, with the stock OEM firmware, GL-iNet 4.0-release 20317-0607-1717707440.bin. No settings were kept (erase settings). So the GL-X750 should be like 'new'. The wizard came up, I set the password, and then connected via ssh.

ls /dev

shows no ttyUSB devices There is therefore definitely something on the Quectel card which is not exposing those tty ports to the serial driver.

kmod-usb-serial, kmod-usb-serial-option, kmod-usb-serial-wwan (5.10.176-1) are all normally loaded, as they are built-into the GLiNet firmware.

Sadly, Quectel offers no true 'reset' command of their board, according to other replies on their forum. They only suggest a 'reflash', which, since there are no UART/tty ports, other than the one now hardwired to the board with an FDTI adapter, their qfirehose software has no way to initiate. And the prior flash went fine.

See update below!

[D_M]

This was exactly my problem:

EG25-G ttyUSB* not created, but detected as rndis_host

I will update my post accordingly.

The 'solution', as hard as it is for many people, is to do some fine soldering and attach TX and RX wire (I used 24g silicon wire) to the pins 11 and 13 and the ground pin, as described above in the image), and connect the other end to a 3.3v TTY to USB cable. Then there is a direct AT command terminal interface over COMx (e.g. putty).

AT+QCFG="usbauto",0
AT&W
AT+CFUN=1,1

OK

RDY

fixed the problem.

The real problem, is Quectel has an undocumented command that causes the card to go into an inaccessible mode. And then, when people ask the question, they don't know the answer. People have to figure it out for themselves. Makes you wonder if Quectel support really understands their products.

@ywp Thank you for your time. Please, also DM me on how to set my name on this forum.

[admon]

You can set your name on the preferences: https://forum.gl-inet.com/u/deno/preferences/account

[D_M]

No... I have my "Name", the only thing it allows me to change, set as D. Yet it shows up as 'deno' on here [apparently extracted from the email, which is a privacy violation]. How do I change the username? Or have it changed for me? I would like it to just be 'D'. Thanks.

[admon]

I will write you a PM

[ywp]

I should note that I can't guarantee that this method will work for you, and you can choose whether to try it or not

'mini-pcie to usb adapter' You need it

1.Install the Quectel_Windows_USB_Driver(Q)_NDIS_V2.7_EN
Download address: Quectel_Windows_USB_Driver(Q)_NDIS_V2.7_EN.zip
2.Connect to computer via usb device
1).Right click on my computer, Selective management
2). Click on Device Manager,
3). Click the port on the right page
4). You should see similar com port numbers, remember AT port numbers

3. Install the QCOM_V1.6.zip
   Download address: QCOM_V1.6.zip
   
   

[D_M]

Please note, I already solved the issue, by hard-wiring a TTY-to-USB adapter, as described above.

The problem with your proposed solution, is the same as the other advice that would not work: Once the "AT+QCFG="usbauto",1 has been sent, and the device has restarted, it shuts-down the AT communication ports, and stays in that configuration. It's non-serviceable at that point, unless someone wants to connect a TTY-to-USB cable to the device. The RESET_N pin on the chip, doesn't actually reset, only restarts the chip (like a reboot).

Some Quectel cards have a USB_BOOT pin, to put it into Emergency Download Mode, that enables a flash, which will then reset the usbauto state. The EC25-AF -unless it's undocumented - does not; I could find no such source. That process would be easier, for your end-users who don't have a problem opening their GL-X750 and shorting a pin on power-up.

@ywp Do you have any background information on whether configuring wwan0 (the Quectel in qmi/ppp, "usbnet",0 mode) receive/transmit, trigger the LED activity, causes noise, causing a failure/rejection of the device on the tower? Different, than merely having a heartbeat light, or Link Up = ON.

I don't remember how I had the GL-X750 wwan0/LED activity configured; I'd have to go look, as it's not in use presently. There was a very similar connectivity issue, it seems, with an ORBI LBR20 and Quectel EG18-NA, attempting to get that configured and operational. The Voxel 'advanced' firmware (based on the stock Netgear, which in turn seems based on DD-WRT), by default, does not light up the unit's tower activity LEDs. They are completely OFF, even when the device is connected and running. The LBR20 was cross-flashed and reset from Openwrt 23.05.4 SNAPSHOT to Voxel, and then was able to stay connected, without difficulty, for 24 hours.

Prior to that, it had repeatedly disconnected. Initially working, with the Stock Netgear firmware that came on it, the LBR20 was then flashed over to Openwrt. And one of the early preferences, was using the LED configurator, to have wwan0 receive/transmit events trigger the LEDs on the top of the unit. It had unknown connectivity issues, for days, every few minutes, and would be seemingly completely not work, like perhaps the tower was rejecting it, for long periods of time.

Flashing back to the Voxel, it stayed connected for 24 hrs. The only apparent difference, was the Voxel does not light up the tower LEDs. Flashing back to Openwrt, and loading the prior preferences, the only subsequent modification was the LED Receive/Transmit -all the LED event preferences, there were only those 2- were removed/deleted. Then, the LBR20 went on to run for hours at a time, connected without interruption.

It's the only change made: turn off the activity LED's relating to 4G communication. It's fine if they are "ON" when connected (Link up), or Heartbeat. But not on receive/transmit.

I was able to find some reference, to a developer who got a Quectel device, that had an LED trigger that could toggled with an AT command. And Quectel's direction was to turn it off, even though it was supported in their command manual. He likewise, had connection problems if he turned it on. But that may have been another design error, a power drop issue. I don't have the original post to link it or I would review it, this is from memory.

[ywp]

@D_M

LED trigger

sorry
I haven't heard that