If I send the below AT Commands after the TRB142 is turned on (power on) and sends RDY (Ready) and before the 4G status LED is turned on (flashing) then I cannot detect an incoming SMS with “+CMTI: “ME”,0”, even if “AT+CEREG” returns “+CEREG: 0,1” (Registered, home network). But if I wait to send the below AT Commands until the 4G status LED is turned on (flashing) it works fine.
Although AT+CEREG may return +CEREG: 0,1 (registered to the home network), the SMS subsystem (URC reporting like +CMTI) depends not only on registration but also on completion of network attach and initialization of URC delivery. AT+CNMI enables SMS URC indications, but if the TE does not respond or acknowledge correctly, the module can disable URC routing automatically. Unsolicited messages like +CMTI are tied to URC configuration (AT+CNMI, AT+QCFG="urc/ri/smsincoming", AT+QINDCFG). If these are sent too early (before URCs are fully enabled after attach), the device may not deliver SMS notifications to the TE.
To conclude, the TRB142 may report +CEREG: 0,1 before the 4G LED starts blinking, but SMS URC reporting (+CMTI) is not reliable until the device has fully initialized its SMS/URC stack, which aligns with when the 4G LED indicates active connection (blinking).
Thanks for your fast reply. Is it possible with AT Commands detect that TRB142 “has fully initialized its SMS/URC stack, which aligns with when the 4G LED indicates active connection (blinking)”?
The time from TRB142 send RDY (ready) and the 4G LED indicate active connection is approximately 17 seconds (just now).
To just rely on a time don’t feels right.
Would appreciate if you have a more reliable solution.
I believe the command you would be looking for is gsmctl -A AT+QINISTAT - when the SIM is fully done initializing, it should return the number 7 when the initialization is done.
Hello,
Thanks once again for your fast reply. I have now tested “AT+QINISTAT” and the modem return seven (7) as you wrote. But seven was returned direct after the modem send RDY (ready), approximately 17 seconds before the 4G status LED start to blink.
I have also read the QUECTEL EC21 Hardware document and cannot find any outputs for the network type LEDs and the mobile signal strength LEDs.
I assume it is the host MCU inside the TRB142 that control all the status LEDs.
My question is then, what are the conditions in the host MCU software that control the network status LEDs?
Is the information taken from the EC21 module?
If yes, can I if you inform me use the same information (with AT commands) do the same?
The status LEDs (network type LED, signal strength LEDs, etc) are driven by the firmware, not by the mobile module itself. Meaning of what each “status” of the LED is can be found here: TRB142 LEDs - Teltonika Networks Wiki
I don’t think I understood the question properly, could you clarify more on this?
First, the correct word is firmware not software as i wrote.
I wrote before that I read the QUECTEL EC21 Hardware document and cannot find any outputs for the network type LEDs and the mobile signal strength LEDs.
Because of this I thought there was a separate MCU that controll the EC21 module as well as all the status LEDs.
But now when you wrote “The status LEDs (network type LED, signal strength LEDs, etc) are driven by the firmware, not by the mobile module itself.” then I made a deeper investigation of the TRB 142 hardware (Japanese basic research ) and found that the status LEDs are controlled by the EC21 modules firmware.
Now when I know this then I mean you have bug in the TRB142 firmware.
The TRB142 sends RDY (ME initialization is successful) after power on and accept AT commands but is not fully initiated before one of the mobile network type LEDs is turned on.
An incomming SMS (“+CMTI: “ME”,0”) will be ignored until, in my case the 4G LED is turned on.
I ask you kindly to find a solution of this problem. Make an improvement in your firmware or give me information about an AT command I can use to poll the status mobile network type LEDs.
Simply relying on a time delay at startup doesn’t feel reliable.
Why thank you for your extensive research on this case & for sharing the findings/results of it. I can most definitely try & inquire more about this with our R&D, whether it is something that is expected to be happening on our devices, or whether it really is a bug after all.
I’ll get back to you as soon as I get an answer from them, which might take a while.
Could you please retest the AT commands with the mobifd service disabled? You can disable it by entering the command /etc/init.d/mobifd stop in the SSH and then manually connect to the mobile operator. This service automatically controls the mobile services, connectivity, interfaces & the modem, which could be causing the issues.
Additionally, you can try setting your Preferred network type to something other than 4G (try 3G only, 2G only) and then try the commands again:
LEDs are controlled by RUTOS and not the module itself.
Since RUTOS runs directly on the module on TRB1 and TRB5 families, this probably caused confusion. If you check the schematic of any other device, you’ll see that the LEDs are connected to the SoC.
We have an application called ledman that monitors the network mode and signal strength, and then controls the LEDs accordingly. ledman gets required info from gsmd.
So some delay is normal, as all internal services need time to start, establish a connection, gather the required information, and only then LEDs are lit.
An incomming SMS (“+CMTI: “ME”,0”) will be ignored until, in my case the 4G LED is turned on.
If gsmd isn’t running yet and hasn’t initialized the modem, some URCs might be missed, and no notifications will be displayed in the WebUI about new messages.
Hello,
I don’t have the schematic for the TRB1 family and therefore can’t verify that the LEDs are connected to the SoC. Would appreciate it if you could send me the schematics.
You write that “some delay” is normal. But a delay of about 17 seconds from TRB142 sending RDY (ready) and the 4G status LED turning on and accepts an incoming SMS is not what I call “some delay”.
A real handshake that the 4G LED is on is preferable.
I did some tests with “ledman” and “gsmd” in RutOS and got the following commands.
For example, I tried ledman -C (Turn off all leds and exit) and then ledman -a (Return to autonomous) which worked well.
Is there no command to read all status LEDs?
Would appreciate it if you could send the source code to “ledman” to perhaps understand the conditions required for the 4G LED to light up.
I am disappointed that you cannot help solve my problem which I think is easy for you, but I am not surprised.
Why spend time and effort on a customer who has only bought three products from Teltonika.
) and found that the status LEDs are controlled by the EC21 modules firmware.
