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/06c374b94bef2b3b23c9531c22... 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 Denis, On 29/04/2015 20:17, Denis Kenzior wrote: > Hi Alex, > > On 04/29/2015 11:45 AM, Alex J Lennon wrote: >> 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 >> > > 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.

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?

On 29/04/2015 21:17, Denis Kenzior wrote: > Hi Alex, > >> 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. > >> 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. > 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. > >> 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?

Hi Alex, > > 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.

> 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?

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?