Librem 5 BroadMobi modem reports wrong (?) manufacturer/model info -- bug in firmware? Where to find documentation for the modem?

The baseband modem in my Librem 5 Birch is a BroadMobi BM818-E1 modem. However, the following modemmanager command says “QUALCOMM INCORPORATED” which I think is wrong:

purism@pureos:~$ mmcli -L
    /org/freedesktop/ModemManager1/Modem/0 [QUALCOMM INCORPORATED] 0

It can also be seen in this way:

purism@pureos:~$ mmcli -m 0
  General  |            dbus path: /org/freedesktop/ModemManager1/Modem/0
           |            device id: [...]
  Hardware |         manufacturer: QUALCOMM INCORPORATED
           |                model: 0
           |    firmware revision: MPSS.JO.2.0.2.c1.1-00032-9607_GENNS_PACK-1  1  [Feb 25 2019 01:00:00]
           |       carrier config: default
           |         h/w revision: 10000
           |            supported: gsm-umts, lte
           |              current: gsm-umts, lte
           |         equipment id: [...]

There, it says “manufacturer: QUALCOMM INCORPORATED” and “model: 0”.

It is possible to see correct manufacturer and model info by using the following “AT” command instead:

purism@pureos:~$ sudo mmcli -m 0 --command=ATI
response: 'Manufacturer: BroadMobi
Model: BM818-E1
Revision: M1.0.0_E1.0.0.0_A1.0.0
IMEI: [...]

So it seems like the “AT” command gives correct manufacturer and model information, while the “mmcli -L” and “mmcli -m 0” commands give wrong results.

Having experimented with some ModemManager code changes, I think this has to do with the different ways that ModemManager can talk to the modem. The information shown when doing “mmcli -L” or “mmcli -m 0” has been fetched by ModemManager using QMI ( This can be seen in ModemManager debug output (enabled by adding --debug in /lib/systemd/system/ModemManager.service), it looks like this:

Feb 04 09:51:11 pureos ModemManager[506]: <debug> [1612428671.653558] [modem0] loading manufacturer...
Feb 04 09:51:11 pureos ModemManager[506]: <debug> [1612428671.653595] [modem0] loading manufacturer by calling qmi_client_dms_get_manufacturer()...
Feb 04 09:51:11 pureos ModemManager[506]: [/dev/cdc-wdm0] sent message...
                                          <<<<<< RAW:
                                          <<<<<<   length = 13
                                          <<<<<<   data   = 01:0C:00:00:02:01:00:02:00:21:00:00:00
Feb 04 09:51:11 pureos ModemManager[506]: [/dev/cdc-wdm0] sent generic request (translated)...
                                          <<<<<< QMUX:
                                          <<<<<<   length  = 12
                                          <<<<<<   flags   = 0x00
                                          <<<<<<   service = "dms"
                                          <<<<<<   client  = 1
                                          <<<<<< QMI:
                                          <<<<<<   flags       = "none"
                                          <<<<<<   transaction = 2
                                          <<<<<<   tlv_length  = 0
                                          <<<<<<   message     = "Get Manufacturer" (0x0021)
Feb 04 09:51:11 pureos ModemManager[506]: <debug> [1612428671.654027] [modem0/ttyUSB1/at] <-- '<CR><LF>OK<CR><LF>'
Feb 04 09:51:11 pureos ModemManager[506]: <debug> [1612428671.654381] [modem0/ttyUSB1/at] --> 'AT+CMEE=1<CR>'
Feb 04 09:51:11 pureos ModemManager[506]: [/dev/cdc-wdm0] received message...
                                          <<<<<< RAW:
                                          <<<<<<   length = 44
                                          <<<<<<   data   = 01:2B:00:80:02:01:02:02:00:21:00:1F:00:02:04:00:00:00:00:00:01:15:00:51:55:41:4C:43:4F:4D:4D:20:49:4E:43:4F:52:50:4F:52:41:54:45:44
Feb 04 09:51:11 pureos ModemManager[506]: [/dev/cdc-wdm0] received generic response (translated)...
                                          <<<<<< QMUX:
                                          <<<<<<   length  = 43
                                          <<<<<<   flags   = 0x80
                                          <<<<<<   service = "dms"
                                          <<<<<<   client  = 1
                                          <<<<<< QMI:
                                          <<<<<<   flags       = "response"
                                          <<<<<<   transaction = 2
                                          <<<<<<   tlv_length  = 31
                                          <<<<<<   message     = "Get Manufacturer" (0x0021)
                                          <<<<<< TLV:
                                          <<<<<<   type       = "Result" (0x02)
                                          <<<<<<   length     = 4
                                          <<<<<<   value      = 00:00:00:00
                                          <<<<<<   translated = SUCCESS
                                          <<<<<< TLV:
                                          <<<<<<   type       = "Manufacturer" (0x01)
                                          <<<<<<   length     = 21
                                          <<<<<<   value      = 51:55:41:4C:43:4F:4D:4D:20:49:4E:43:4F:52:50:4F:52:41:54:45:44
                                          <<<<<<   translated = QUALCOMM INCORPORATED

If I understand this correctly, the above shows how ModemManager is sending a “Get Manufacturer” request to the modem, and the modem is responding with “SUCCESS” and claiming that the manufacturer is “QUALCOMM INCORPORATED”. It looks similar for the “model” info, there is again a request and a response, the response saying that the model is “0” which is what mmcli shows.

In contrast, when using the “sudo mmcli -m 0 --command=ATI” command, ModemManager is not using QMI but it is issuing the given commad “ATI” in another way, such “AT” commands is the old way of talking to modems (a.k.a. Hayes command set,

So is seems we can get the correct manufacturer and model info when using “AT” commands, but not when using QMI. I think it seems like a problem not with ModemManager but inside the modem itself, since ModemManager is just using the information it is given by the modem, the modem is saying that the manufacturer is “QUALCOMM INCORPORATED” which is wrong. So I think there is a bug, but maybe not in any software I have direct access to, but in the (proprietary?) firmware of the modem.

What do you think, do you agree that this seems like a bug inside the modem?

If this modem does not work well with QMI, would it be possible to tell ModemManager to skip QMI altogether and just use AT commands instead when talking to the modem?

Can we find documentation for the modem somewhere, to see if it is supposed to handle QMI?
The most official page I could find was this one but not much details there.
I found this which says “Control Via AT Commands” but does not seem to mention QMI.
Also this “Operation Manual” but it’s in a strange format, hopefully there is something better?

Other ideas or thoughts on this? Is it the FSFs fault that we are stuck with such a shitty modem? Or, perhaps a rant about how all such problems are really just caused by proprietary code and how great it would be to have FOSS firmware for everything? :slight_smile:

I don’t actually know anything about modems to help here, but

It’s Qualcomm’s fault for being the monopolist in the modem market.


There are very few M.2 modems that support voice. Most of them could but it’s due to closed firmware that the support can’t be added easily.


The BroadMobi BM818 is based on the Qualcomm MDM9607 modem, so it is correctly reporting the maker of the cellular baseband. For more info on the modem, see:

Unfortunately, BroadMobi doesn’t provide any public documentation for its products. The AT commands listed in the manual for the Quectel EG25-G should work on the BM818, since the EG25-G and BM818 use the same Qualcomm modem.


Interesting. So, it’s essentially the same modem (or rather: chip) as in the pinephone. That might result in some synergies in the future.


I assume that BroadMobi and Quectel license the cellular baseband core from Qualcomm, which they incorporate into their custom ASICs, so technically they are using different chips with the same baseband cores. What would be interesting to know is whether Qualcomm licenses its basebands in a way that allows licensees to modify them or do they have to treat them like unmodifiable black boxes.


Being about 1% of all AT commands, unfortunately.

I tried AT+QFLDS (seemed as if it should be harmless) and the response I received was: ERROR

Same result for AT+QFLST

What does this mean about the truth of your suggestion? I don’t know.

Did you try it this way?

Each modem manufacturer can decide to implement the Qualcomm modem in their own way, so there are no guarantees. Did you get any of the AT commands to work?


Yes e.g. ATI works fine
e.g. AT+CSQ works fine

@irvinewade’s tests with the AT commands suggests that the two modems are implemented very differently, so we might not get much synergy between the two modems. :frowning:

1 Like

If I understand that properly, then it’s the same IP core in different chips, with different firmware. Now, if someone were to try to reverse engineer both firmwares, maybe that knowledge could be helpful. You know, different implementations that in the end do similar things.
Just trying to see something positive in it :grimacing:

1 Like

It’s not all bad, there are some things that do work on both. I tried a bunch of AT commands found here and found that the following seem to work in the same way on Librem 5 and PinePhone:

purism@librem5:~$ sudo mmcli -m any --command="AT+GMI"
response: 'BroadMobi'
purism@librem5:~$ sudo mmcli -m any --command="AT+GMM"
response: 'BM818-E1'
purism@librem5:~$ sudo mmcli -m any --command="AT+GMR"
response: 'M1.0.0_E1.0.0.0_A1.0.0'

mobian@pinephone:~$ sudo mmcli -m any --command="AT+GMI"
response: 'Quectel'
mobian@pinephone:~$ sudo mmcli -m any --command="AT+GMM"
response: 'EG25'
mobian@pinephone:~$ sudo mmcli -m any --command="AT+GMR"
response: 'EG25GGBR07A08M2G'

AT+CPAS – Mobile Equipment Activity Status: gives 0 when idle and 4 when a call is ongoing

AT+GSN – Request International Mobile Equipment Identity (IMEI)

AT+CIMI – Request International Mobile Subscriber Identity (IMSI)

AT+CPIN? – check if PIN code has been entered OK, says “READY” if so

AT+COPS? – check current mode and currently selected operator:

purism@librem5:~$ sudo mmcli -m any --command="AT+COPS?"
response: '+COPS: 0,0,"Tele2",7'

mobian@pinephone:~$ sudo mmcli -m any --command="AT+COPS?"
response: '+COPS: 0,0,"Tele2 Comviq",7'

AT+CSQ – Signal Quality Report

AT+CLCC – List Current Calls of ME

AT+CMGF – check or set SMS Message Format, text mode or PDU mode

AT+CSCA? – Service Center Address

AT+CMGL=4 – list all SMS messages (to see them this way, chatty needs to be stopped because otherwise chatty will take care of the SMS messages and delete them from the modem)

AT+CGATT – Attachment or Detachment of PS

AT+CGDCONT? – Define PDP Context

purism@librem5:~$ sudo mmcli -m any --command="AT+CGDCONT?"
response: '+CGDCONT: 1,"IPV4V6","","",0,0,0,0
+CGDCONT: 2,"IPV4V6","","",0,0,0,0
+CGDCONT: 3,"IPV4V6","","",0,0,0,0'

mobian@pinephone:~$ sudo mmcli -m any --command="AT+CGDCONT?"
response: '+CGDCONT: 1,"IP","wholesale","",0,0,0,0
+CGDCONT: 2,"IPV4V6","ims","",0,0,0,0
+CGDCONT: 3,"IPV4V6","","",0,0,0,1'

AT+CGPADDR – Show PDP Address

AT+CCLK? – queries the real time clock (RTC) of the module

purism@librem5:~$ sudo mmcli -m any --command="AT+CCLK?"
response: '+CCLK: "21/02/07,00:57:47+04"'

mobian@pinephone:~$ sudo mmcli -m any --command="AT+CCLK?"
response: '+CCLK: "21/02/07,00:57:48+04"'

No idea why the timezone is “+04” but that’s what it says, on both of them.

Anyway my point was to show that there are quite a lot of commands that actually do work on both. (But far from all of them, my impression is that if you take some random AT command that works on the PinePhone then there is less than a 50/50 chance that it will work on the Librem 5.)


AT command set is relatively standardized and works across several vendors - but each vendor tends to also add their own custom commands that obviously won’t work on modules from other vendors. And in the case of those two modems, the vendors who implemented those additional commands are BroadMobi and Quectel, not Qualcomm (although some of the custom commands do seem to come from some Qualcomm’s reference implementation, I guess).


Because the timezone is in “quarters of an hour” i.e. 15 minute intervals. So “+04” means GMT+1 i.e. 1 hour ahead of GMT, which would be about right for a number of countries in western Europe.

I would suppose that this design allows the response to represent timezones that are e.g. 9.5 hours ahead of GMT using only two digits (e.g. +38), rather than the usual four digits (e.g. 0930).

On the other hand, which lamer decided to build a Y2K problem in by saving two more digits? :wink:

What does AT+CBC give on the PP? (get battery charge status)

On the L5:

+CBC: 2,0

which means “charging has been finished” (not correct on my L5 right now) and “battery level is 0%” (empty? or full? wrong anyway).

I would suppose that the modem has no idea what the battery level is. Do some modems have their own battery?

That’s correct. Modem modules like that can be used almost autonomously, serving as a communication brain for some data collecting microcontroller etc. They sometimes even include things like HTTP clients that can be used via AT commands, and some also allow to attach additional modules to them, for instance to get WiFi networking.

Of course the modem as used on the Librem 5 has no idea about the state of the battery or other peripherals.


I get this on the PinePhone:

mobian@pinephone:~$ sudo mmcli -m any --command="AT+CBC=?"
response: '+CBC: (0-2),(0-100),(voltage)'
mobian@pinephone:~$ sudo mmcli -m any --command="AT+CBC"
response: '+CBC: 0,94,4115'

Same commands on the Librem 5:

purism@librem5:~$ sudo mmcli -m any --command="AT+CBC=?"
response: '+CBC: (0-3),(0-100)'
purism@librem5:~$ sudo mmcli -m any --command="AT+CBC"
response: '+CBC: 2,0'

So on the PinePhone there is a third piece of info there, apparently voltage in millivolts. And the charge level was 94%. So the PinePhone modem seems to have its own battery. I wonder, does this mean the modem is still active, using its internal battery, even after I turn off the PinePhone?

Is (was) this equal to the actual charge level of the phone’s battery?

I wouldn’t accept that conclusion necessarily but if that is correct then that would be a major concern!

Is it possible that mmcli is intercepting the specific command?

I’m using minicom to talk directly to the modem (on an L5).

Not exactly, but both are nearly full. Looking at the phone battery in Settings–>power that shows 99%.

Starting a small experiment now, disconnecting the charging cable and turning the PinePhone off, the plan is to leave it off for a few hours and then turning it on and directly checking both battery charge levels. If the “modem battery” charge level is significantly lower then, that would indicate the existence of such a battery.


I always thought that there exist only 24 Time zones +12 to the East and -12 West of Greenwich (ore A…M -ex.J and N…Y). A precise description can be find in ISO 8601.
So a timezone defined in 15 min. is new to me.