On 29/04/2015 21:17, Denis Kenzior wrote:
> 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
Yes I take your point Denis. Taking a step back, if I run with the
unpatched tc65 plugin I see
ofonod: drivers/atmodem/sim.c:at_crsm_read_cb() crsm_read_cb: 90,
ofonod: > AT+CIND=?\r
ofonod: < AT+CIND=?\r
ofonod: < \r\n+CIND : ("call",(0,1)), ("roam",(0,1))
ofonod: < \r\nOK\r\n
ofonod: This driver is not setup with Signal Strength reporting
via CIND indications, please write proper netreg handling for this device
ofonod: src/network.c:netreg_remove() atom: 0x12eb408
This is what lead me to the patch I used here:
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
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
Does anything leap out at you as unexpected from the above response?