LTE modem support

[Marc_Dornan]

Yes, of course. I see your point now!

[YupsUAV]

hi @tridge!
I am back again after a holiday trip and found some time to continue my investigation.
After the FTDI232 finally helped to connect via UART, i switched to a simple flight controller with directly connected UART-Pins. The Matek H743-SLIM (V2) worked on first try.

Took me a while to get all these settings correct but it seems to work now (more or less).
I had to disable the LTE_TIMEOUT (–> 0) because the modem was reset after the "“LTE_modem: network opened” status message.
So it did’t geht a response from my UDPProxy?
Anyway, to my surprise i was able to connect via MissionPlanner from my computer.

Do you have any idea why the connection isn’t correctly recognised? I’am using the SIM7600E-L1C with the script you attached to your post on July 2.

LTE_modem.log

]
{XXX}[NOSTART:AT+CMUX=0

OK
]
>>>[ù?
ù]
>>>[ùa?
Þù]
>>>[ù?
Yù]
<<<[ùs
×ùùas
ùùs
’ù]
>>>[ùaÿAT+CPIN?
9ù]
<<<[ùÿAT+CPIN?
¼ùùÿ-
+CPIN: READY

OK
rù]
>>>[ùaÿAT+CPIN?
9ù]
<<<[ùÿAT+CPIN?
¼ùùÿ-
+CPIN: READY

OK
rù]
>>>[ùaÿAT+CREG?
9ù]
<<<[ùÿAT+CREG?
¼ùùÿ)
+CREG: 0,5

OK
uù]
>>>[ùÿAT+CIPMODE=1
°ù]
<<<[ù	ÿeAT+CIPMODE=1
5ùù	ÿ

OK
Íù]
>>>[ùÿAT+NETOPEN
·ù]
<<<[ù	ÿAT+NETOPEN
<ùù	ÿ

OK
Íùùÿ
+NETOPEN: 0
µùù	ÿ
+NETOPEN: 0
2ù]
>>>[ùÿWAT+CIPOPEN=0,"TCP","217.154.114.45",10001
-ù]
<<<[ù	ÿUAT+CIPOPEN=0,"TCP","217.154.114.45",10001
¯ùù
ïãa
yùù	ÿ%
CONNECT 115200
ûù]

I’ve also set AT+CREG=2 to enable roaming but this setting seems to get lost after reboot.

And another LTE_modem.log with LTE_TIMEOUT=20
(reboots shortly after “LTE_modem:connected” status message)

>>>[
ATI
]
>>>[ùaÿ	ATI
,ù]
<<<[
RDY

+CPIN: READY

SMS DONE

PB DONE
]
>>>[+++]
>>>[
ATI
]
<<<[ATI

Manufacturer: SIMCOM INCORPORATED
Model: SIMCOM_SIM7600E-L1C
Revision: SIM7600M11_A_V2.0.1
IMEI: 862499070419826
+GCAP: +CGSM

OK
]
>>>[ùaÿAT+CMUX=0
Úù]
<<<[AT+CMUX=0

OK
]
{XXX}[NOSTART:AT+CMUX=0

OK
]
>>>[ù?
ù]
>>>[ùa?
Þù]
>>>[ù?
Yù]
<<<[ùs
×ùùas
ùùs
’ù]
>>>[ùaÿAT+CPIN?
9ù]
<<<[ùÿAT+CPIN?
¼ùùÿ-
+CPIN: READY

OK
rù]
>>>[ùaÿAT+CPIN?
9ù]
<<<[ùÿAT+CPIN?
¼ùùÿ-
+CPIN: READY

OK
rù]
>>>[ùaÿAT+CREG?
9ù]
<<<[ùÿAT+CREG?
¼ùùÿ)
+CREG: 0,5

OK
uù]
>>>[ùÿAT+CIPMODE=1
°ù]
<<<[ù	ÿeAT+CIPMODE=1
5ùù	ÿ

OK
Íù]
>>>[ùÿAT+NETOPEN
·ù]
<<<[ù	ÿAT+NETOPEN
<ùù	ÿ

OK
Íùùÿ
+NETOPEN: 0
µùù	ÿ
+NETOPEN: 0
2ù]
>>>[ùÿWAT+CIPOPEN=0,"TCP","217.154.114.45",10001
-ù]
<<<[ù	ÿUAT+CIPOPEN=0,"TCP","217.154.114.45",10001
¯ùù
ïãa
yùù	ÿ%
CONNECT 115200
ûù]
{XXX}[no end idx]
{XXX}[no end idx]
{XXX}[no end idx]
{XXX}[no end idx]
{XXX}[no end idx]
{XXX}[no end idx]
{XXX}[no end idx]
{XXX}[no end idx]
{XXX}[no end idx]
{XXX}[no end idx]
{XXX}[no end idx]
{XXX}[no end idx]
{XXX}[no end idx]
{XXX}[no end idx]
{XXX}[no end idx]
{XXX}[no end idx]
{XXX}[no end idx]
{XXX}[no end idx]
>>>[ùaÿ	ATI
,ù]
<<<[ùÿAT+CFUN=1,1
Qùùÿ

OK
Jùùÿ	ATI
Mùùÿí
Manufacturer: SIMCOM INCORPORATED
Model: SIMCOM_SIM7600E-L1C
Revision: SIM7600M11_A_V2.0.1
IMEI: 862499070419826
âùùÿ+
+GCAP: +CGSM

OK
–ù]
<<<[ù
ïãa‡
yùù
ïãaa
yùù
ïãa

yùùÿ
CLOSED
Xùù	ÿ
CLOSED
ßùùÿU
+CIPEVENT: NETWORK CLOSED UNEXPECTEDLY
(ùù	ÿU
+CIPEVENT: NETWORK CLOSED UNEXPECTEDLY
¯ù]
>>>[ù?
ù]
>>>[ùa?
Þù]
>>>[ù?
Yù]
>>>[ùaÿAT+CPIN?
9ù]
>>>[ùaÿAT+CPIN?
9ù]
>>>[ùaÿAT+CPIN?
9ù]
>>>[ùaÿAT+CPIN?
9ù]
>>>[ùaÿAT+CPIN?
9ù]
>>>[ùaÿAT+CPIN?
9ù]
>>>[ùaÿAT+CPIN?
9ù]
>>>[ùaÿAT+CPIN?
9ù]
>>>[ùaÿAT+CPIN?
9ù]
>>>[ùaÿAT+CPIN?
9ù]
>>>[ùaÿAT+CPIN?
9ù]
>>>[ùaÿAT+CPIN?
9ù]
>>>[ùaÿAT+CPIN?
9ù]
>>>[ùaÿAT+CPIN?
9ù]
>>>[ùaÿAT+CPIN?
9ù]

And the correspending MissionPlanner Message output:

12.08.2025 16:29:11 : LTE_modem: step CPIN
12.08.2025 16:29:10 : LTE_modem: step CPIN
12.08.2025 16:29:10 : LTE_modem: step CPIN
12.08.2025 16:29:09 : LTE_modem: step CPIN
12.08.2025 16:29:09 : LTE_modem: step CPIN
12.08.2025 16:29:08 : LTE_modem: step CPIN
12.08.2025 16:29:08 : LTE_modem: step CPIN
12.08.2025 16:29:07 : LTE_modem: step CPIN
12.08.2025 16:29:07 : LTE_modem: step CPIN
12.08.2025 16:29:06 : LTE_modem: step CPIN
12.08.2025 16:29:06 : LTE_modem: step CPIN
12.08.2025 16:29:05 : LTE_modem: step CPIN
12.08.2025 16:29:05 : LTE_modem: step CPIN
12.08.2025 16:29:04 : LTE_modem: step CPIN
12.08.2025 16:29:04 : LTE_modem: step BAUD
12.08.2025 16:29:03 : LTE_modem: CMUX mode set
12.08.2025 16:29:03 : LTE_modem: step CMUX
12.08.2025 16:29:02 : LTE_modem: found modem: SimCom
12.08.2025 16:29:02 : LTE_modem: step ATI
12.08.2025 16:29:01 : LTE_modem: step ATI
12.08.2025 16:29:01 : LTE_modem: sent reset
12.08.2025 16:29:01 : LTE_modem: timeout
12.08.2025 16:28:41 : LTE_modem: connected
12.08.2025 16:28:41 : LTE_modem: step CIPOPEN
12.08.2025 16:28:41 : LTE_modem: step CIPOPEN
12.08.2025 16:28:41 : LTE_modem: network opened
12.08.2025 16:28:41 : LTE_modem: step NETOPEN
12.08.2025 16:28:41 : LTE_modem: step NETOPEN
12.08.2025 16:28:40 : LTE_modem: transparent mode set
12.08.2025 16:28:40 : LTE_modem: step CIPMODE
12.08.2025 16:28:40 : LTE_modem: step CIPMODE
12.08.2025 16:28:39 : LTE_modem: CREG OK
12.08.2025 16:28:39 : LTE_modem: step CREG
12.08.2025 16:28:38 : LTE_modem: step CREG
12.08.2025 16:28:38 : LTE_modem: step CONFIG
12.08.2025 16:28:38 : LTE_modem: step CPIN
12.08.2025 16:28:37 : LTE_modem: step CPIN
12.08.2025 16:28:37 : LTE_modem: step BAUD
12.08.2025 16:28:36 : LTE_modem: CMUX mode set
12.08.2025 16:28:36 : no start idx
12.08.2025 16:28:36 : LTE_modem: step CMUX
12.08.2025 16:28:36 : LTE_modem: step CMUX
12.08.2025 16:28:35 : LTE_modem: found modem: SimCom
12.08.2025 16:28:35 : LTE_modem: step ATI
12.08.2025 16:28:34 : LTE_modem: step ATI
12.08.2025 16:28:33 : LTE_modem: step ATI
12.08.2025 16:28:32 : LTE_modem: step ATI
12.08.2025 16:28:31 : LTE_modem: step ATI
12.08.2025 16:28:30 : LTE_modem: starting

The timeout appears exactly 20 seconds after the connection was established.

[rfriedman]

Is flow control required/recommended for the SIM7600G-H?

[karla (Karl Alberts)]

@tridge

my collection of modems is growing, not all tested yet

This is such a new interesting capability!

Any chance you may consider to add this commonly used Huawei LTE USB dongle modem to the supported collection?

Or describe how to include it…

I have used LTE for telemetry and rc control for some years, and it’s difficult to go back to limited range. I use other solutions for FPV video.
I would love to take out all my RaspberryPi units from my drones if I just could.

This LTE USB dongle from Huawei is working for me across Europe and also in China, Just swop SIMs. It’s so convenient to swop the modem and sim from model to model or my Mac.

[YupsUAV]

@tridge
Do you still work on this LTE modem topic?
I’ve just tested the Quectel BG93-M3 with the most recent script from github.
Its working as expected.

This is a offical evaluation board design from Quectel which has a better layout than the and-global board i bought with simcom modems.
You can activate an onboard 3,3V level shifter by bridging pin 1V8 and LT_EN. It works with my CAN-Adapter and also directly on my Pixhawk 4 UART.

I have two points (same behaviour with the SIMCOM 7600E-L1C and 7070G):

• The timeout function doesn’t work, have to disable it with “0” in the settings, otherwise it keeps reseting the modem after the given time.
• Speed is relatively low. I get 55-60 packets/second (mission planner link stats) and roughly 2,5kbytes/s.
  → I don’t see any impact to the speed by increasing baudrate to 460k or 921k.
  —> Downloading waypoints from FC to MissionPlanner takes very long for 250wps and regulary fails after some time because of a “timeout”.

Any toughts on this?

modem log attached with timeout = 10s.
LTE_modem.log (21.5 KB)

[sailordude (cr)]

Impressive work by all of you and with the expansion of the mobile network, its becoming more valuable by the day.
A couple of questions in regards to latency:

1. Do you have any indication if there is a reduction in latency by circumventing a companion computer? (or is this not really relevant)
2. What is the expected and accepted latency for a land or sea based vehicle, especially if you are trying to maneuver it in “manual” mode.
3. What are the most important factors to keep latency to a minimum.
   Thanks!

[YupsUAV]

Did a first flight test with my SIMCOM 7600E-L1C today. Its connected via a Vimdrones Pico CAN-Adapter because of some level shifting issues.

Overall i am not completely happy with it. MissionPlanner had some trouble to reconnect after a sudden connection loss. Took nearly 10 attempts to complete parameter download an establish a connection. RSSI was at 31, 120m altitude.

Also i found another small “bug”:
When initial_baudrate and regular baudrate don’t match, the script won’t be able to connect to the modem after a software reboot (without repowering the modem), because it tries the initial_baudrate again.
Maybe its reasonable to try regular baudrate after several failed attempts on initial_baudrate?

[Huibean (Huibean Luo)]

Hi @YupsUAV, please upgrade the pico firmware, the stock firmware won’t able to save the AP_Periph params change when reboot

ArduPilot firmware : /AP_Periph/latest/VM-L431-Periph-Pico

[YupsUAV]

I’am already using a recent firmware.
In my opinion this has nothing to do with the CAN-Adapter - the Pico works fine. It’s just about the LTE_MODEM script which doesn’t consider an already setup and connected modem and always does a cold startup.

But i’ll reach out to you, because i am struggeling to get my Vimdrones S50 ESCs working. (Will tag you in a new topic in the following days).

[tridge]

@YupsUAV

Maybe its reasonable to try regular baudrate after several failed attempts on initial_baudrate?

It tries both the initial and regular baudrate in turn when making the initial connection to the modem. It keeps trying both until it gets a response to the ATI command

[tridge]

@YupsUAV

Do you still work on this LTE modem topic?

yes

@YupsUAV

You can activate an onboard 3,3V level shifter by bridging pin 1V8 and LT_EN.

great! I’d like to see an analog trace (eg. with Salae pro) of this to see if it is really doing the level shifting correctly. I’ve ordered one which should arrive in a week or so.

@YupsUAV

MissionPlanner had some trouble to reconnect after a sudden connection loss. Took nearly 10 attempts to complete parameter download an establish a connection. RSSI was at 31, 120m altitude.

how are you powering it? The two biggest factors I’ve found for reliability are:

• level shifting issues
• power supply

for example, a lot of the modems have a “5v to 12v” input, but if you supply it with close to 5v from for example the power pin on a UART connector from a flight controller then it will tend to perform very badly, in much the way you describe. If you add a dedicated BEC at 6v or more then it becomes reliable.

I’d really love to get a LTE modem made up that can work reliably with just the JST-GH 6 pin connector, powered off the flight controller, but that isn’t possible yet that I’ve seen.

[tridge]

@sailordude

A couple of questions in regards to latency:

latency is “interesting” with LTE modems. Most messages come through quickly when you have a reasonable link to a tower, and whether you go via a companion computer or not doesn’t matter much. But if you have a bad/intermittent link then some messages can be held in the telco infrastructure for a very long time. I’ve seen packets arrive several minutes after they are sent by the flight controller!

[karla (Karl Alberts)]

@tridge

I’d really love to get a LTE modem made up that can work reliably with just the JST-GH 6 pin connector, powered off the flight controller, but that isn’t possible yet that I’ve seen.

Well, the modem I mentioned above is working very stable, no issues for 2 years many flights.
Its powered 5V from a free servo slot on the flight controller. Actually that powers a small raspberry pi zero 2, then the modem is powered from that.

[tridge]

@karla

Actually that powers a small raspberry pi zero 2, then the modem is powered from that.

the modems themselves operate at low voltages (most are 1.8v) but the power circuits that provide that voltage are much more of an issue. I can quite believe that the modem on your Pi is fine, but using the same power supply on a generic LTE won’t necessarily work well.

I have tested about a dozen LTE modems from AliExpress and other places, one of the most common issues I’ve found is power. Changing to a higher voltage BEC made a huge difference in reliability on many modems.

If the power supply of these modems was well designed then it wouldn’t be an issue, but they unfortunately are not well designed

[tridge]

@YupsUAV

This is a offical evaluation board design from Quectel which has a better layout than the and-global board i bought with simcom modems.

I’ve now received this board and have been doing some testing. I’ve been comparing it to a Simcom SIM7600E-H on the same antenna. The BG95 is doing very badly, with a very weak connection, and frequently losing the link. Changing power supply did not help.

I suspect the key difference is the BG95 is a CAT1 modem, and the SIM7600E-H is a CAT4. The local cell providers don’t seem to allow CAT1 connections from all towers, I end up connected to a tower on the far side of Canberra with the BG95, whereas the CAT4 modem connects to a tower that is quite close (you can see what tower you are connected to using the hologram.io web dashboard).

[YupsUAV]

how are you powering it? The two biggest factors I’ve found for reliability are:

• level shifting issues

• power supply

for example, a lot of the modems have a “5v to 12v” input, but if you supply it with close to 5v from for example the power pin on a UART connector from a flight controller then it will tend to perform very badly, in much the way you describe. If you add a dedicated BEC at 6v or more then it becomes reliable.

You were right! Sorry for not double checking this point as you mentioned the voltage supply in the docs.

During bench testing, the modem had issues when powered only via USB. When powered via Pixhawk 4 and its PowerModule, i didn’t see any issues. Looks like i was wrong.

On my testing plane the voltage on the Vimdrones Pico CAN-Adapter is only 4,5V! Obviously thats not enough. Did a dirty mod and hooked the modem to 6V servo supply. (everything is installed into the right wing, so i hadn’t so many options).

Did a testflight and it worked quite well No sudden connection losses, big missions where transmitted without interruptions. Parameter download worked without problems. I am very happy!

The speed increased also a little. RSSI was most time at a maximum of 31dbm. During cell handover (i guess!) it dropped to -1 for a short while. 3% packet loss rate reported in MissionPlanner during a 30 mins flight.

Thanks for testing the BG95!

I suspect the key difference is the BG95 is a CAT1 modem, and the SIM7600E-H is a CAT4.

It’s not CAT1 but CAT-M1, also known as LTE-M. It supports around 1Mbit Datarate. Furthermore it supports NB-IOT2 (CAT-NB2). Did you check which service its using? NT-IOT is rather unusable because of its high latency and very low bandwith.

I was able to rediscover the CellIDs which your script reported to the Ardupilot flight log:

Cellular Tower and Signal Map

From my point of view CAT-M1 is very well suited for telemetry as it has low latency and a very long range, but i need to do some testflights to compare. On the bench it worked similar to the SIM7600E-L1C which is CAT1 (without M).

BG95 specification for reference attached.

Quectel_BG95_Series_LPWA_Specification_V2.0.pdf (373.5 KB)

[tridge]

@YupsUAV

It’s not CAT1 but CAT-M1, also known as LTE-M

you’re right, sorry!

I suspect the local providers (Telstra, Optus and Vodaphone in Canberra) don’t have good support for CAT-M1.

Great that your modem is working well now!

[YupsUAV]

@tridge

I suspect the local providers (Telstra, Optus and Vodaphone in Canberra) don’t have good support for CAT-M1.

Did a short visit to the Telstra coverage map.

Looks like there are indeed some white spots in your area:

Optus and Vodafone AU just mention NB-IOT and don’t provide detailed coverage maps.

Edit:

[YupsUAV]

Short update:

Just got the SIM7600E-L1C working with an Matek DLVR CAN Airspeed Sensor (L431 based) as the UART host on my bench. On the DLVR i used RX3/TX3 which corresponds to CAN_D1_UC_S1_IDX = 2 (not 3!)

[YupsUAV]

@tridge

It tries both the initial and regular baudrate in turn when making the initial connection to the modem. It keeps trying both until it gets a response to the ATI command

Did a little more testing regarding this problem:

Initial and regular baudrate both set to 115k works fine after softstart (reboot commanded by MissionPlanner).

Initial baudrate 115k and regular baudrate 230k works only until Ardupilot is rebooted while the modem is still powered.

That’s repeatable. The modem is found but the script gets stuck at “CMUX” and does a reset after serveral attempts.

LTE_modem.log (4.1 KB)

@tridge

Discovered a “new” problem with the BG95-M3:

The script gets stuck at CREG step when the modem is set to roaming mode.

+CREG: 2,5,“3AAD”,“223B403”,8 isn’t correctly recognized and the CREG is repeated serveral times until reset.

Guess it’s because of the additional status output values which confues the string match command:

local reg = s:match(‘CREG: %d,(%d+)\r\n’)

Sadly i’am not able to fix this myself. Apart from that it works as expected (with roaming disabled). The baudrate behaviour (mentioned above) is the same with the BG95.

Log attached:

LTE_modem funktioniert nicht mit Roaming.log (38.5 KB)