Telit LE910V1 - LTE only modem

Hi Lukasz,

I have never useg LE910-SVG but I have used LE910-EUG which is also V1 LE910 modem. It uses QMI interface and is End-of-life product according to Telit. Below is a patch I used to add support for it, maybe it will help you.

Modem is not recognized automatically, you need to point ofono to use correct driver by setting ENV{OFONO_DRIVER}="le910" in udev.

Hi Lukasz,

I have never useg LE910-SVG but I have used LE910-EUG which is also V1 LE910 modem. It uses QMI interface and is End-of-life product according to Telit. Below is a patch I used to add support for it, maybe it will help you.

Modem is not recognized automatically, you need to point ofono to use correct driver by setting ENV{OFONO_DRIVER}="le910" in udev.

Hi Piotr, Denis,

With the qmimodem patch I was able to bring the LE910-SVG modem on-line. But I had to do two things:

1. The gprs driver was never getting attached.
a) This statement in src/gprs.c, gprs_netreg_update()

	if (ofono_netreg_get_technology(gprs->netreg) ==
			ACCESS_TECHNOLOGY_EUTRAN)
		/*
		 * For LTE we set attached status only on successful
		 * context activation.
		 */
                return;

means that the gprs->driver_attached is never set to true.
If I remove this piece of code, the gprs->driver->set_attached() gets called, and that gets everything attached and working.

b) I can see, that another path to it would be:
qmimodem/gprs.c create_nas_cb() calls qmi_service_register(QMI_NAS_SS_INFO_IND, ss_info_notify) But then, ss_info_notify() is never called. I think that the modem is quick enough to register to the network before qmi_service_register(QMI_NAS_SS_INFO_IND) is called.

c) Denis, you mentioned that I need to call ofono_gprs_cid_activated() Which piece of code should do that? qmimodem/network-registration.c or plugins/gobi.c?

2. qmimodem/network-registration.c:extract_ss_info() seems to be getting a corrupted operator name:
plmn->desc_len = 3
plmn->desc[] = { 0x56, 0xfd, 0x15 }
The first byte seems correct ('V' for Verizon), but the other two are wrong (later on, dbus aborts the entire ofono process, saying this is not a valid utf-8 string). plmn->mcc and plmn->mnc are correct (311:480 - US:Verizon)

Have you ever seen anything like that?
If I replace the invalid characters, everything works ok. But I imagine this is not the right way to handle this.

Thanks for all your help with this.

Lukasz

Quoted 11 lines · Piotr Haber

Hi Lukasz,

I have never useg LE910-SVG but I have used LE910-EUG which is also V1 LE910 modem. It uses QMI interface and is End-of-life product according to Telit. Below is a patch I used to add support for it, maybe it will help you.

Modem is not recognized automatically, you need to point ofono to use correct driver by setting ENV{OFONO_DRIVER}="le910" in udev.

Hi Piotr, Denis,

With the qmimodem patch I was able to bring the LE910-SVG modem on-line. But I had to do two things:

1. The gprs driver was never getting attached.
a) This statement in src/gprs.c, gprs_netreg_update()

	if (ofono_netreg_get_technology(gprs->netreg) ==
			ACCESS_TECHNOLOGY_EUTRAN)
		/*
		 * For LTE we set attached status only on successful
		 * context activation.
		 */
                return;

means that the gprs->driver_attached is never set to true.
If I remove this piece of code, the gprs->driver->set_attached() gets called, and that gets everything attached and working.

b) I can see, that another path to it would be:
qmimodem/gprs.c create_nas_cb() calls qmi_service_register(QMI_NAS_SS_INFO_IND, ss_info_notify) But then, ss_info_notify() is never called. I think that the modem is quick enough to register to the network before qmi_service_register(QMI_NAS_SS_INFO_IND) is called.

c) Denis, you mentioned that I need to call ofono_gprs_cid_activated() Which piece of code should do that? qmimodem/network-registration.c or plugins/gobi.c?

2. qmimodem/network-registration.c:extract_ss_info() seems to be getting a corrupted operator name:
plmn->desc_len = 3
plmn->desc[] = { 0x56, 0xfd, 0x15 }
The first byte seems correct ('V' for Verizon), but the other two are wrong (later on, dbus aborts the entire ofono process, saying this is not a valid utf-8 string). plmn->mcc and plmn->mnc are correct (311:480 - US:Verizon)

Have you ever seen anything like that?
If I replace the invalid characters, everything works ok. But I imagine this is not the right way to handle this.

Hi Lukasz,

Quoted 4 lines · Lukasz Nowak

Hi Piotr, Denis,

With the qmimodem patch I was able to bring the LE910-SVG modem on-line. But I had to do two things:

So it looks like the LE910 is a Qualcomm chip / firmware, funny.

Quoted 11 lines

1. The gprs driver was never getting attached.
a) This statement in src/gprs.c, gprs_netreg_update()

    if (ofono_netreg_get_technology(gprs->netreg) ==
            ACCESS_TECHNOLOGY_EUTRAN)
        /*
         * For LTE we set attached status only on successful
         * context activation.
         */
                return;

Quoted 3 lines

means that the gprs->driver_attached is never set to true.
If I remove this piece of code, the gprs->driver->set_attached() gets called, and that gets everything attached and working.

Strictly speaking this statement is correct. In LTE there's really no concept of 'attached'. We're attached by the virtue of getting onto the LTE network (the default bearer is always available). So there should be no need to explicitly issue a set_attached method.

Quoted 10 lines

b) I can see, that another path to it would be:
qmimodem/gprs.c create_nas_cb() calls qmi_service_register(QMI_NAS_SS_INFO_IND, ss_info_notify) But then, ss_info_notify() is never called. I think that the modem is quick enough to register to the network before qmi_service_register(QMI_NAS_SS_INFO_IND) is called.

c) Denis, you mentioned that I need to call ofono_gprs_cid_activated() Which piece of code should do that? qmimodem/network-registration.c or plugins/gobi.c?

your gprs.c atom driver.

Quoted 9 lines

2. qmimodem/network-registration.c:extract_ss_info() seems to be getting a corrupted operator name:
plmn->desc_len = 3
plmn->desc[] = { 0x56, 0xfd, 0x15 }
The first byte seems correct ('V' for Verizon), but the other two are wrong (later on, dbus aborts the entire ofono process, saying this is not a valid utf-8 string). plmn->mcc and plmn->mnc are correct (311:480 - US:Verizon)

Quoted 4 lines

Have you ever seen anything like that?
If I replace the invalid characters, everything works ok. But I imagine this is not the right way to handle this.

I have not played with QMI enough to give any guidance. You might want to look at libqmi to see if they handle this differently.

Regards,
-Denis

Quoted 1 line

Strictly speaking this statement is correct. In LTE there's really no concept of 'attached'. We're attached by the virtue of getting onto the LTE network (the default bearer is always available). So there should be no need to explicitly issue a set_attached method.

The current qmimodem code, calls ofono_gprs_status_notify(NETWORK_REGISTRATION_STATUS_REGISTERED) when it receives a notification from the modem that it is fully connected. Is that the correct path to make the gprs context marked as "attached"? If that does not happen, all the dbus context APIs just return an error, and as a result, e.g. connman does not enable the cellular service.

I can add a change to qmimodem, which will explicitly ask the modem firmware if it is connected, from qmi_gprs_probe() rather than waiting on a state change notification, which never arrives. Does that make sense?

How do you usually test such changes for regressions? I do not have any other QMI modems, to verify if I have broken anything in them or not. I think the change should be safe, but I cannot be 100% certain.

Hi Lukasz,

Quoted 5 lines

Quoted 1 line

Strictly speaking this statement is correct. In LTE there's really no concept of 'attached'. We're attached by the virtue of getting onto the LTE network (the default bearer is always available). So there should be no need to explicitly issue a set_attached method.

The current qmimodem code, calls ofono_gprs_status_notify(NETWORK_REGISTRATION_STATUS_REGISTERED) when it receives a notification from the modem that it is fully connected. Is that the correct path to make the gprs context marked as "attached"? If that does not happen, all the dbus context APIs just return an error, and as a result, e.g. connman does not enable the cellular service.

So as it is today, oFono for LTE expects the following:
ofono_gprs_status_notify(with registered / roaming) and ofono_gprs_cid_activated() for the default bearer.

The gprs-context driver must then implement read_settings method. LTE is weird since the contexts can be network activated. The default bearer is 'activated' by the modem firmware itself by virtue of obtaining the LTE network registration. The logic is quite different compared to 2G/3G.

If you know your AT commands, see how the ubloxmodem driver does this. Pay attention to drivers/atmodem/gprs.c cgev_notify() and drivers/ubloxmodem/gprs-context.c.

We also now have an lte atom. See doc/lte-api.txt for details.

If the above isn't possible for QMI, then we might need to tweak the core logic (e.g. src/gprs.c) accordingly.

Please note that qmimodem driver was developed when we didn't have lte support, so the logic in there is probably incorrect / inadequate.

Quoted 5 lines

I can add a change to qmimodem, which will explicitly ask the modem firmware if it is connected, from qmi_gprs_probe() rather than waiting on a state change notification, which never arrives. Does that make sense?

How do you usually test such changes for regressions? I do not have any other QMI modems, to verify if I have broken anything in them or not. I think the change should be safe, but I cannot be 100% certain.

We try to catch most regressions during the patch review process. In the past we had some QA resources performing manual tests, but these resources are no longer available. Easiest might be to order a few qmi modems and check if your patches break them :)

Regards,
-Denis

I am still a little bit confused about ofono_gprs_cid_activated(). As far as I can see only atmodem calls it. No other driver does that.

I am not sure if a context is automatically created. I can see that the sim card has a few profiles, and the user can select which APN to use, start/stop ip network, etc.

Hi Lukasz,

Quoted 1 line

I am still a little bit confused about ofono_gprs_cid_activated(). As far as I can see only atmodem calls it. No other driver does that.

That's because only the ublox devices have been properly enabled for LTE :)

Quoted 1 line

I am not sure if a context is automatically created. I can see that the sim card has a few profiles, and the user can select which APN to use, start/stop ip network, etc.

Yes, that's how LTE works. An initial context (default bearer) is always activated on LTE. The device can provide an initial attach APN (see doc/lte-api.txt) which is used to tell the modem which APN to attach to by default. From what I recall, the device can provide an empty APN (in which case the network assigns one).

The default bearer varies by the carrier. Some use it for IMS, some use it for the internet context. So the modem/firmware behavior is often tweaked for a particular carrier. Some modems might not report the default context at all in which case the device acts more like a 3G modem than an lte one.

Regards,
-Denis