Open Source Telephony
 help / color / mirror / Atom feed
From: Alex J Lennon <ajlennon@dynamicdevices.co.uk>
To: ofono@ofono.org
Subject: Re: Cinterion EHS6 support
Date: Wed, 29 Apr 2015 22:03:33 +0200	[thread overview]
Message-ID: <55413915.4000707@dynamicdevices.co.uk> (raw)
In-Reply-To: <55412E59.3090506@gmail.com>

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

  reply	other threads:[~2015-04-29 20:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-29 16:45 Cinterion EHS6 support Alex J Lennon
2015-04-29 18:17 ` Denis Kenzior
2015-04-29 18:24   ` Alex J Lennon
2015-04-29 18:50     ` Denis Kenzior
2015-04-29 19:11       ` Alex J Lennon
2015-04-29 19:17         ` Denis Kenzior
2015-04-29 20:03           ` Alex J Lennon [this message]
2015-04-29 20:11             ` Alex J Lennon
2015-04-29 22:57               ` Denis Kenzior
2015-04-30  4:42                 ` Alex J Lennon
2015-04-30  7:37                   ` Alex J Lennon
2015-04-30 17:19                     ` Denis Kenzior
2015-04-30  9:20                   ` Alex J Lennon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55413915.4000707@dynamicdevices.co.uk \
    --to=ajlennon@dynamicdevices.co.uk \
    --cc=ofono@ofono.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox