Cinterion EHS6 support

Cinterion EHS6 support

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 603 bytes --]

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?

Many thanks,

Alex

Re: Cinterion EHS6 support

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

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 ?

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

Regards,
-Denis

Re: Cinterion EHS6 support

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]

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.

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


I'll get on with it then.

Many thanks,

Alex

Re: Cinterion EHS6 support

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]

Hi Alex,

On 04/29/2015 01:24 PM, Alex J Lennon wrote:
> 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.

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

Regards,
-Denis

Re: Cinterion EHS6 support

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]



On 29/04/2015 20:50, Denis Kenzior wrote:
> Hi Alex,
>
> On 04/29/2015 01:24 PM, Alex J Lennon wrote:
>> 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.
>
> 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?

Thanks,

Alex

Re: Cinterion EHS6 support

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]

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

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

Sure

Regards,
-Denis

Re: Cinterion EHS6 support

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 2983 bytes --]



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@you as unexpected from the above response?

Regards,

Alex
 

Re: Cinterion EHS6 support

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 3482 bytes --]



On 29/04/2015 22:03, Alex J Lennon wrote:
>
> 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?
>

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?

Regards,

Alex

Re: Cinterion EHS6 support

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]

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.

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

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.

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

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.

Regards,
-Denis

Re: Cinterion EHS6 support

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 2402 bytes --]



On 30/04/2015 00:57, Denis Kenzior wrote:
> 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.

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

Re: Cinterion EHS6 support

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 3850 bytes --]



On 30/04/2015 06:42, Alex J Lennon wrote:
>
> On 30/04/2015 00:57, Denis Kenzior wrote:
>> 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.
> 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

Denis,

I've had a look through the EHS6 and the TC65 AT command sets reference
manuals

ref:
http://www.idr.com.tr/files/EHS6%20AT%20Command%20Set%20V02.000a%20%28Preliminary%20version%29.pdf

ref: http://jagfernandez.webs.uvigo.es/ET/CMOV/pr2/tc65_atc_v02000.pdf

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?

Regards,

Alex
 

Re: Cinterion EHS6 support

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]

Hi Alex,

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

Essentially.  We either don't have the vendor specific commands for 
those modems or they simply don't exist.

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

Yes, of course.  Both ways are supported.

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

That sounds like a good start.  We can always split the driver into two. 
  That is easy.  Merging two drivers into one is much harder.

Regards,
-Denis

Re: Cinterion EHS6 support

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 2899 bytes --]



On 30/04/2015 06:42, Alex J Lennon wrote:
>
> On 30/04/2015 00:57, Denis Kenzior wrote:
>> 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.
> 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?

Dennis,

I've had some feedback from the Cinterion guys now. The suggestion is
that there are around 12 years of development between the TC6x and the
EHSx, different chipsets, 2G vs 3G, and so there are substantial
differences between the products.

It seems as though it might be worth separating out? I'm agnostic about
the approach though. Can you let me know what you'd prefer?

Thanks, Alex
 

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 3815 bytes --]