Modemmanager & 4g HAT communication over UART

Hey guys,

I would like to get this HAT working on my Pi3 without the use of the external USB cable:

When I do use the external USB cable, the modem automatically shows up in the balenaOS using “mmcli -L”

When I don’t use the cable, the modem is not recognised (even though it is properly powered).

Any way to do this?

Thanks for helping!

Gr, Frans

Hi, in lack of schematics for this, I found

And in there, there are a bunch of reconnect scripts which you should check and see how to bring the modem up (for example in they state that gpio 17 is to bring the modem out of reset and gpio 24 is to power on the modem). You would need to export from userspace for example and set the gpios they use there. But you should really have a schematics for this, otherwise parse the above and see which one do the job.

Ok thanks. I will look into that!

My mail concern is that modemmanager might not pick up this modem because it will communicate over UART instead of USB. Is this a legit concern?

Hi, as long as you look into the above info, you shouldn’t have any more issues, but please come back to us if you do!

Update, because I am making progress:

The modem is now working if I follow these instructions:

Additionally, I can use minicom to connect to the modem on ttyAMA0 and send AT commands & get a response. Super!

Therefore I know that the hardware is working, and the modem is up (no additional GPIO switching is needed).

I would however like the modem to be recognised & controlled by modem manager, from the hostOS (so that connectivity is not controlled from the container, for obvious reasons).

Therefore, is there a way for me to see why modemmanager is not recognising this modem? I am sure it is supported, because if I use the USB cable it is recognised instantly.

(PS: some other forum said I needed to set the following udev rule, which I did. Too bad this didn’t help:)


Awesome news, thanks for the heads up

Any help on how to debug modemmanager in this case would be highly appreciated!

Hi Frans, based on your previous message, it sounded like the modem was working, if you used their script. What is not working, or, more precisely, what do you need to debug in modemmanager exactly? Any extra information you can provide would help us get you moving in the right direction. Thanks.

I am sorry for the confusion. Let me elaborate:


  • I would like to get a working internet connection on my Raspi3b from the 4G HAT (link in original post) i.c.w. a Quectel EC25-E modem.
  • The connection should be managed from the HostOS (not the container!), preferably by ModemManager.
  • Data connection between HAT and Raspi should be via UART (not USB).

Current Status:

  • Modem is not recognised by ModemManager (mmcli -L returns no modems).


  • To double check if all hardware is working, I tried creating PPP connection from container with the script from the HAT manufacturer (port: ttyAMA0). This was successful. Therefore I know all hardware is working, incl UART connection.
  • To double check if modem is supported by ModemManager, I connected the HAT via external USB cable to the Raspi. The modem is then immediately recognised by MM and connection is established automatically (I have created the correct connection file in system-connections).
  • Other forum posts (link1, link2, link3) suggest I have to implement certain udev rules for the modem to be recognised over ttyAMA0. I have tried various (via config.json) but nothing worked up until now.
  • When performing a ModemManager scan (mmcli -S), ModemManager (debug)logs are showing:
    ModemManager[704]: (tty/ttyAMA0): adding device at sysfs path: /sys/devices/platform/soc/3f201000.serial/tty/ttyAMA0
    ModemManager[704]: [filter] (tty/ttyAMA0): port filtered: tty platform driver

My question to you:
How can I find out WHY ModemManager is not recognising my modem on ttyAMA0? And how can I fix it…

Can any of you help?

Much appreciated!

Hi, thanks for contacting support.
The line:

ModemManager[704]: [filter] (tty/ttyAMA0): port filtered: tty platform driver

suggests that the port is being filtered by MM and it is not being probed.
The approach of flagging the platform TTY should work. I would also suggest trying a flag the serial platform device, with something like:

ACTION=="add", KERNEL=="3f201000.serial", ENV{ID_MM_PLATFORM_DRIVER_PROBE}="1"

Please check that the flag is applied with:

udevadm info /sys/devices/platform/soc/3f201000.serial

If so, then check that mmcli -L can see the modem.
As a side note, according to MM documentation at, the ID_MM_PLATFORM_DRIVER_PROBE is kept for backward compatibility. The ID_MM_DEVICE_PROCESS flag replaces it.

Did some testing, but I am getting some really inconsistent results. Its driving me crazy:

  • I have tried applying the mentioned rule. At first it was being applied (checked with udevadm), currently it is not being applied. No clue what changed. I only rebooted in between.

  • I have also tried applying the following 2 udev rules at the same time:
    ACTION=="add", KERNEL=="3f201000.serial", ENV{ID_MM_PLATFORM_DRIVER_PROBE}="1"
    This helped a little, it made MM pick up on ttyAMA0 once. I saw in the logs that MM actually scanning ttyAMA0 and was sending AT commands to the modem. Sadly it dit not recognise the modem. Have not been able to reproduce this since.

Currently the MM logs are stating the following again :anguished::
[filter] (tty/ttyAMA0): port filtered: tty platform driver

Current output from udevadm info /sys/devices/platform/soc/3f201000.serial is:

P: /devices/platform/soc/3f201000.serial
L: 0
E: DEVPATH=/devices/platform/soc/3f201000.serial
E: DRIVER=uart-pl011
E: OF_NAME=serial
E: OF_FULLNAME=/soc/serial@7e201000
E: OF_COMPATIBLE_0=brcm,bcm2835-pl011
E: OF_COMPATIBLE_1=arm,pl011
E: OF_COMPATIBLE_2=arm,primecell
E: OF_ALIAS_0=serial0
E: OF_ALIAS_1=uart0
E: AMBA_ID=00241011
E: MODALIAS=amba:d00241011

Would any of the Balena Support crew maybe be able to login to my device to help me find whats going wrong?


Hi, one of my teammates mentioned that v1.12.0 removed the ID_MM_PLATFORM_DRIVER_PROBE -

ID_MM_DEVICE_PROCESS should be used instead:

ACTION=="add", KERNEL=="3f201000.serial", ENV{ID_MM_DEVICE_PROCESS}="1"

Since this is a test device I will take the opportunity to apply the change, reboot the device and see what happens.

Will get back to you in a bit,

Hi Zahari, thanks for helping me.

Yeah Im sure I tried ID_MM_DEVICE_PROCESS as well, but since the device behaviour was (in my eyes) not consistent I was also just trying/debugging.

Feel free to do anything to the device. It is indeed a test device.

Modem is connected to the device with antenna.

That did not work either.

I think at this point it is best to contact the ModemManager developers on their modemmanager-devel mailing list. They are quite friendly and will provide useful insights. At least we will know whether this is currently possible under ModemManager - hopefully this is something that could be resolved through configuration only.

You may provide them with the ModemManager version used + full debug logs.

Before doing so however, can you please test with the latest balenaOS v2.47.0, since it includes the latest ModemManager update? There is a slight chance we can get lucky.

BTW, this is a really nice piece of hardware - quite useful for RPi users.

Please let us know if you have any questions.


Thanks @majorz, I emailed the main contributor to the github repo

Will keep you updated!


(ps: updating to 2.47 didn’t help)

1 Like

Trying to do the same on RPi 4 and the same 6fab hat. I’ll follow your path, and see if I can reproduce or find a solution. Thanks for doing some of the leg work! Will report back soon…

As @majorz said, the way to go is to tag the device with the ID_MM_DEVICE_PROCESS tag, so that the implicit whitelist rule allows the port to be probed and used. Tagging by the port name isn’t ideal though, you should better tag based on the devpath. What is the output of this command?
$ realpath /sys/class/tty/ttyAMA0

Hi @aleksander0m, thanks for helping with this!

The output of the command realpath /sys/class/tty/ttyAMA0

Would you be able to explicitly state here which udev rule(s) I need to set?


Try this:

ACTION!="add|change|move|bind", GOTO="mm_whitelist_end"
DEVPATH=="/devices/platform/soc/3f201000.serial" ENV{ID_MM_DEVICE_PROCESS}="1"

Then make sure you reboot to get the rule applied.


  1. You wrote the udev rule over 3 lines, without comma’s. Shouldn’t it all be in one line with comma’s in between?
  2. How can I double check the rule is applied after reboot?