Cinterion EHS6 support

Hi,

I've created a patch which adds support for the Cinterion EHS6 to Ofono.

This is based on the TC65 source code with some changes to address an issue with +CIND handling

The patch is currently in a GitHub fork here

https://github.com/DynamicDevices/ofono/commit/06c374b94bef2b3b23c9531c22977976ab7f6e99.patch

This enables me to configure an "ehs6" rule in udev and bring up a GPRS connection successfully with Connman.

Would it be possible to contribute this to Ofono? If so could somebody let me know what, if anything, needs to be done to the patch?

Hi Alex,

Quoted 2 lines · Alex J Lennon

Hi,

Quoted 5 lines

I've created a patch which adds support for the Cinterion EHS6 to Ofono.

This is based on the TC65 source code with some changes to address an issue with +CIND handling

Most likely TC65 has this issue as well. Are there any other changes ?

Quoted 11 lines

The patch is currently in a GitHub fork here

https://github.com/DynamicDevices/ofono/commit/06c374b94bef2b3b23c9531c22977976ab7f6e99.patch

This enables me to configure an "ehs6" rule in udev and bring up a GPRS connection successfully with Connman.

Would it be possible to contribute this to Ofono? If so could somebody let me know what, if anything, needs to be done to the patch?

Generally, just send patches to the mailing list using git send-email. They will undergo the review process and will be applied to the upstream tree when/if they're ready.

The general submission guidelines are described in git. toplevel/HACKING, 'Submitting Patches' section.

Hi Denis,

Quoted 11 lines · Denis Kenzior

Hi Alex,

Quoted 7 lines · Alex J Lennon

Hi,

I've created a patch which adds support for the Cinterion EHS6 to Ofono.

This is based on the TC65 source code with some changes to address an issue with +CIND handling

Quoted 2 lines

Most likely TC65 has this issue as well. Are there any other changes ?

Yes it does. I started out with the TC65, couldn't get it going and had to apply that patch to it to get a connection up.

I didn't include the change as am focussed on EHS6 hardware here and wasn't sure what the impact would be on TC65.
I can provide the TC65 patch easily enough too if you think it useful.

Hi Alex,

Quoted 15 lines · Alex J Lennon

Hi Denis,

Quoted 12 lines · Denis Kenzior

Hi Alex,

Quoted 8 lines · Alex J Lennon

Hi,

I've created a patch which adds support for the Cinterion EHS6 to Ofono.

This is based on the TC65 source code with some changes to address an issue with +CIND handling

Quoted 5 lines

Quoted 2 lines

Most likely TC65 has this issue as well. Are there any other changes ?

Yes it does. I started out with the TC65, couldn't get it going and had to apply that patch to it to get a connection up.

It might be easier to rename tc65.c into cinterion.c and have it handle both tc65 and ehs6 if this is the only difference.

I would like to avoid duplicating modem drivers. So if plugins/tc65.c can handle the EHS6 with just minor tweaks, then this would be the preferred approach.

I understand. I am not sure what the differences are between the tc65 and the ehs6. I'll speak with Gemalto/Cinterion to get some clarification on this.

My thought process for splitting it out was along these lines:

At present I am focussed just on supporting a data-connection for one of our boards with the EHS6 on it with connman/ofono.

We'll be working with the EHS6 and probably the EHS5 extensively over the next few years on a range of board products so I will likely be testing out other functionalities for the EHS6 such as voice, sms etc. etc. I imagine.

I can prove this out on our hardware and provide any needed patches upstream if that is of use.

But we don't plan to make use of the TC65 and so I can't commit to ensuring that anything I implement for the EHS6 would work for the TC65, or indeed wouldn't break the current TC65 implementation.

I assumed that the current tc65 code worked, although it wasn't working for me on the ehs6, and as I don't know what's' going on there I was keen not to make any potentially breaking changes that might cause others problems.

Can I come back to you with the response from Cinterion/Gemalto on differences/similarities between TC65 and EHS5/6 and then you can decide whether the patch needs refactoring?

Hi Alex,

Quoted 4 lines

I understand. I am not sure what the differences are between the tc65 and the ehs6. I'll speak with Gemalto/Cinterion to get some clarification on this.

Sure. In the past we have found that the modem firmware is similar enough that no changes are needed between different modem families from the same manufacturer. There were one or two exceptions of course.

Quoted 11 lines

My thought process for splitting it out was along these lines:

At present I am focussed just on supporting a data-connection for one of our boards with the EHS6 on it with connman/ofono.

We'll be working with the EHS6 and probably the EHS5 extensively over the next few years on a range of board products so I will likely be testing out other functionalities for the EHS6 such as voice, sms etc. etc. I imagine.

Quoted 6 lines

I can prove this out on our hardware and provide any needed patches upstream if that is of use.

But we don't plan to make use of the TC65 and so I can't commit to ensuring that anything I implement for the EHS6 would work for the TC65, or indeed wouldn't break the current TC65 implementation.

Some things can be done by eye-balling the code. For example, I just ran a diff on the code you submitted. The only difference between plugins/ehs6.c and plugins/tc65.c is the vendor quirk for ofono_netreg_create. Something that tc65 also probably needs.

Quoted 1 line

Quoted 4 lines

I assumed that the current tc65 code worked, although it wasn't working for me on the ehs6, and as I don't know what's' going on there I was keen not to make any potentially breaking changes that might cause others problems.

I'm not quite sure why that would be the case. Registering for CIND indications that will never come should not cause any significant issues...

Quoted 30 lines · Denis Kenzior

Hi Alex,

Quoted 3 lines

I understand. I am not sure what the differences are between the tc65 and the ehs6. I'll speak with Gemalto/Cinterion to get some clarification on this.

Sure. In the past we have found that the modem firmware is similar enough that no changes are needed between different modem families from the same manufacturer. There were one or two exceptions of course.

Quoted 10 lines

My thought process for splitting it out was along these lines:

At present I am focussed just on supporting a data-connection for one of our boards with the EHS6 on it with connman/ofono.

We'll be working with the EHS6 and probably the EHS5 extensively over the next few years on a range of board products so I will likely be testing out other functionalities for the EHS6 such as voice, sms etc. etc. I imagine.

Quoted 6 lines

I can prove this out on our hardware and provide any needed patches upstream if that is of use.

But we don't plan to make use of the TC65 and so I can't commit to ensuring that anything I implement for the EHS6 would work for the TC65, or indeed wouldn't break the current TC65 implementation.

Some things can be done by eye-balling the code. For example, I just ran a diff on the code you submitted. The only difference between plugins/ehs6.c and plugins/tc65.c is the vendor quirk for ofono_netreg_create. Something that tc65 also probably needs.

Quoted 7 lines

Quoted 4 lines

I assumed that the current tc65 code worked, although it wasn't working for me on the ehs6, and as I don't know what's' going on there I was keen not to make any potentially breaking changes that might cause others problems.

I'm not quite sure why that would be the case. Registering for CIND indications that will never come should not cause any significant issues...

Yes I take your point Denis. Taking a step back, if I run with the unpatched tc65 plugin I see

ofonod[1886]: drivers/atmodem/sim.c:at_crsm_read_cb() crsm_read_cb: 90, 00, 28
ofonod[1886]: > AT+CIND=?\r
ofonod[1886]: < AT+CIND=?\r
ofonod[1886]: < \r\n+CIND : ("call",(0,1)), ("roam",(0,1)) \r\n
ofonod[1886]: < \r\nOK\r\n
ofonod[1886]: This driver is not setup with Signal Strength reporting via CIND indications, please write proper netreg handling for this device ofonod[1886]: src/network.c:netreg_remove() atom: 0x12eb408

This is what lead me to the patch I used here:
https://lists.ofono.org/pipermail/ofono/2012-March/012590.html

So it would appear that something is unhappy in the response parsing in network-registration.c cind_support_cb() leading us to arrive at the error label?

One option is to disable the sending of the AT+CIND=? as Reynaldo originally did, but perhaps a preferable solution is to work out what's failing here.

Does anything leap out at you as unexpected from the above response?

It looks as though the issue is that the Cinterion parts don't support signal strength via +CIND ?

Yet in at_signal_strength() it looks to me as though if this is the case the code will fall back happily to using +CSQ

That being the case I'm not sure why cind_support_cb() should be reporting an error and removing the device when it should be able to fallback and continue?

Hi Alex,

Quoted 3 lines

It looks as though the issue is that the Cinterion parts don't support signal strength via +CIND ?

Yes, we look for "signal" indicator inside cind_support_cb. If it isn't found, then we raise an error. This tells the hw integrator to address the issue. CIND logic is provided as a fallback / default since many manufacturers support this indicator for HFP.

signal_strength (and hence +CSQ) is used to bootstrap the signal strength value. This driver method is only called at very specific times. The core does not poll signal_strength. It is expected that the driver will send signal strength value to the core periodically, by whatever means is optimal for the hardware. Most modems use a custom unsolicited notification or CIND to provide information about signal strength automatically. I suspect Cinterion has a similar extension.

The consequence of the above is that it can't. If no vendor extension is available for unsolicited notifications and signal strength is not provided via CIND, then the netreg atom driver can either poll signal strength manually or simply not provide any signal strength updates. For the latter, it must enable such behavior explicitly. Hence why your patch providing OFONO_VENDOR_CINTERION logic makes this work properly.

Hope that made sense.

Quoted 26 lines · Denis Kenzior

Hi Alex,

Quoted 2 lines

It looks as though the issue is that the Cinterion parts don't support signal strength via +CIND ?

Yes, we look for "signal" indicator inside cind_support_cb. If it isn't found, then we raise an error. This tells the hw integrator to address the issue. CIND logic is provided as a fallback / default since many manufacturers support this indicator for HFP.

signal_strength (and hence +CSQ) is used to bootstrap the signal strength value. This driver method is only called at very specific times. The core does not poll signal_strength. It is expected that the driver will send signal strength value to the core periodically, by whatever means is optimal for the hardware. Most modems use a custom unsolicited notification or CIND to provide information about signal strength automatically. I suspect Cinterion has a similar extension.

The consequence of the above is that it can't. If no vendor extension is available for unsolicited notifications and signal strength is not provided via CIND, then the netreg atom driver can either poll signal strength manually or simply not provide any signal strength updates. For the latter, it must enable such behavior explicitly. Hence why your patch providing OFONO_VENDOR_CINTERION logic makes this work properly.

Quoted 1 line

Hope that made sense.

OK thanks for explaining that Denis. Yes, I was wondering if this was related to the potential asynchronous nature of +CIND reporting versus polling via at_signal_strength()

So, to make sure I understand...

The error message flags up a problem for the integrator. In the case of OFONO_VENDOR_NOKIA, OFONO_VENDOR_SAMSUNG in at_creg_set_cb() we can assume this has been investigated, and no good alternative event reporting solution is available (or a choice was made not to implement) so this is disabled.

However there remains an exercise to go through for Cinterion to check whether non-CIND reporting mechanism is available and enable it? If so I'll have a look through the documentation.

On a separate but related note, can you tell me if ofono supports monitoring of signal strength whilst a data connection is up, e.g. via use of GSM 07.10 or with modems such as Cinterion that expose multiple virtual ports over USB?

Thanks, Alex
_______________________________________________
ofono mailing list
ofono(a)ofono.org
https://lists.ofono.org/mailman/listinfo/ofono

Quoted 6 lines

The error message flags up a problem for the integrator. In the case of OFONO_VENDOR_NOKIA, OFONO_VENDOR_SAMSUNG in at_creg_set_cb() we can assume this has been investigated, and no good alternative event reporting solution is available (or a choice was made not to implement) so this is disabled.

Quoted 8 lines

However there remains an exercise to go through for Cinterion to check whether non-CIND reporting mechanism is available and enable it? If so I'll have a look through the documentation.

On a separate but related note, can you tell me if ofono supports monitoring of signal strength whilst a data connection is up, e.g. via use of GSM 07.10 or with modems such as Cinterion that expose multiple virtual ports over USB?

The EHS6 requires use of the AT^SIND command to enable signal strength reporting, which are reported with textual indication descriptors (as opposed to numerics) in the +CIEV indication, similar to the Telit.

The TC65 documentation doesn't show the "rssi" indicator as being supported by AT^SIND (pp87), although it is documented as supported by AT+CIND (pp81).

Additionally the TC65 documentation states that "All indicators provided by AT+CIND can be handled with AT^SIND as well" so there's some confusion there, and unfortunately without the TC65 hardware I can't test.

I have some code here which is correctly handling the "rssi" +CIEVs on the EHS6 as a "cinterion" plugin as far as I can see.

If you are happy with the above I could provide a patch-set to replace tc65 with a "cinterion" plugin using AT^SIND to setup signal strength reporting for the Cinterion vendor?

Quoted 26 lines · Denis Kenzior

Hi Alex,

Quoted 2 lines

It looks as though the issue is that the Cinterion parts don't support signal strength via +CIND ?

Yes, we look for "signal" indicator inside cind_support_cb. If it isn't found, then we raise an error. This tells the hw integrator to address the issue. CIND logic is provided as a fallback / default since many manufacturers support this indicator for HFP.

signal_strength (and hence +CSQ) is used to bootstrap the signal strength value. This driver method is only called at very specific times. The core does not poll signal_strength. It is expected that the driver will send signal strength value to the core periodically, by whatever means is optimal for the hardware. Most modems use a custom unsolicited notification or CIND to provide information about signal strength automatically. I suspect Cinterion has a similar extension.

The consequence of the above is that it can't. If no vendor extension is available for unsolicited notifications and signal strength is not provided via CIND, then the netreg atom driver can either poll signal strength manually or simply not provide any signal strength updates. For the latter, it must enable such behavior explicitly. Hence why your patch providing OFONO_VENDOR_CINTERION logic makes this work properly.

Quoted 1 line

Hope that made sense.

OK thanks for explaining that Denis. Yes, I was wondering if this was related to the potential asynchronous nature of +CIND reporting versus polling via at_signal_strength()

So, to make sure I understand...

The error message flags up a problem for the integrator. In the case of OFONO_VENDOR_NOKIA, OFONO_VENDOR_SAMSUNG in at_creg_set_cb() we can assume this has been investigated, and no good alternative event reporting solution is available (or a choice was made not to implement) so this is disabled.

However there remains an exercise to go through for Cinterion to check whether non-CIND reporting mechanism is available and enable it? If so I'll have a look through the documentation.

On a separate but related note, can you tell me if ofono supports monitoring of signal strength whilst a data connection is up, e.g. via use of GSM 07.10 or with modems such as Cinterion that expose multiple virtual ports over USB?