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
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
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
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
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
---
drivers/atmodem/network-registration.c | 1 +
drivers/atmodem/vendor.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/atmodem/network-registration.c
b/drivers/atmodem/network-registration.c
index a438726..6844860 100644
---
---
plugins/ehs6.c | 249 +
plugins/udev.c | 15
2 files changed, 264 insertions(+)
create mode 100644 plugins/ehs6.c
diff --git a/plugins/ehs6.c b/plugins/ehs6.c
new file mode 100644
index 000..8c5fe48
--- /dev/null
+++
---
Makefile.am | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Makefile.am b/Makefile.am
index 22249c4..a7da15c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -393,6 +393,9 @@ builtin_sources += plugins/caif.c
builtin_modules += tc65
builtin_sources += plugins/tc65.c
+builtin_modules
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
Implement OFONO_VENDOR_CINTERION specific support to register
textual +CIEV indications for signal strength using vendor
specific AT^SIND command
---
drivers/atmodem/network-registration.c | 64 --
drivers/atmodem/vendor.h | 1 +
2 files changed, 62
On 01/05/2015 16:05, Denis Kenzior wrote:
Hi Alex,
On 04/30/2015 02:08 PM, Alex J Lennon wrote:
On the basis that cinterion tx6x, ehsx, other devices will likely
have similar firmware requirements, implement a generic cinterion
plugin.
The udev implementation retains support for tc65
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
This enables us to take advantage of vendor specific quirks
(e.g. signal strength handling specifics for tc65)
---
plugins/cinterion.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/plugins/cinterion.c b/plugins/cinterion.c
index 7f14fa0..6d85189 100644
---
On the basis that tc6x and other Cinterion devices will likely
have similar firmware requirements, provide a generic Cinterion
plugin which is functionally identical to the replaced tc65 plugin.
The udev implementation retains support for tc65 name for
backwards compatibility, and adds support
As with tc65, ehs6 makes use of cinterion plugin
---
plugins/udev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/plugins/udev.c b/plugins/udev.c
index 6330228..3c90e40 100644
--- a/plugins/udev.c
+++ b/plugins/udev.c
@@ -245,6 +245,8 @@ static void add_modem(struct udev_device
Hi Denis,
On 01/05/2015 16:02, Denis Kenzior wrote:
Hi Alex,
This part seems to be completely unnecessary? At least by my reading
of the code flow, at_cmer_set_cb is never called in the case of
OFONO_VENDOR_CINTERION.
This is not our coding style. Please refer to doc/coding-style.txt
On error struct cb_data *cbd was used after in cinterion_set_online
after already being freed.
---
plugins/cinterion.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/plugins/cinterion.c b/plugins/cinterion.c
index 6d85189..a18b9fe 100644
--- a/plugins/cinterion.c
+++
On 13/05/2015 17:18, Philip Paeps wrote:
On 2015-05-12 18:22:59 (+0100), Alex J Lennon ajlen...@dynamicdevices.co.uk
wrote:
[...]
Just paging through this driver this afternoon. Sorry for not reviewing
the earlier patches. This caught my eye:
+static void cinterion_set_online(struct
On 04/06/2015 23:59, Alex J Lennon wrote:
On 04/06/2015 23:03, Denis Kenzior wrote:
Hi Alex,
Ordering should have nothing to do with it.
Yes, the ordering is relevant. We (like other ofono users I suspect)
have to allow multiple APNs or the automatic provisioning process fails
On 04/06/2015 23:03, Denis Kenzior wrote:
Hi Alex,
Ordering should have nothing to do with it.
Yes, the ordering is relevant. We (like other ofono users I suspect)
have to allow multiple APNs or the automatic provisioning process fails.
Then, the first context found in
On 05/06/2015 01:48, Denis Kenzior wrote:
Hi Marcel,
The actual MCC and MNC assignments are ITU T E.212 and the (U)SIM
Header of the ICCID is ITU T E.118 document.
And as a side note, the (U)SIM Header is between 6 and 7 digits. The
MNC is between 2 and 3 digits.
So in theory E212
Hi,
A request for some advice.
We're having trouble provisioning APNs for SIMs from certain Telcos, and
it seems to be because of the ordering of providers in serviceproviders.xml
Vodafone and O2 are cases in point. SIMs from either of those two
telcos, used in the UK, will fail to default to
Hi Denis,
On 04/06/2015 21:52, Denis Kenzior wrote:
Hi Alex,
On 06/03/2015 07:07 AM, Alex J Lennon wrote:
Hi,
A request for some advice.
We're having trouble provisioning APNs for SIMs from certain Telcos, and
it seems to be because of the ordering of providers in
serviceproviders.xml
On 21/06/2015 12:56, Sriram Sagar wrote:
Hi,
I am having issue in connecting 3G modem on my arm platform.
I am using connman(1.29) as my network manager and ofonod(1.14) and
modem is not been detected.
I have checked the logs
huawei_probe function is been called and hung there.
On 05/06/2015 10:29, Alex J Lennon wrote:
On 05/06/2015 01:48, Denis Kenzior wrote:
Hi Marcel,
The actual MCC and MNC assignments are ITU T E.212 and the (U)SIM
Header of the ICCID is ITU T E.118 document.
And as a side note, the (U)SIM Header is between 6 and 7 digits. The
MNC
Hi Denis,
On 26/05/2015 18:21, Denis Kenzior wrote:
Hi Mike,
On 05/26/2015 10:38 AM, Mike Williams wrote:
All,
Using connman/ofono to connect to a cellular network, the first time
activating the GPRS context works. After deactivation, the next
activation fails with an unknown error. I
On 27/05/2015 18:58, Mike Williams wrote:
Alex,
On Tue, May 26, 2015 at 12:20 PM, Alex J Lennon
ajlen...@dynamicdevices.co.uk wrote:
Would you mind sharing the auto connection patch for cellular as we have
been wondering here why configuring autoconnection didn't seem to make
any
Hi Mike,
On 26/05/2015 17:38, Mike Williams wrote:
All,
Using connman/ofono to connect to a cellular network, the first time
activating the GPRS context works. After deactivation, the next
activation fails with an unknown error. I believe this is related to
this issue:
Hi August,
On 10/07/2015 09:44, August Mayer wrote:
Hello everybody,
Which modems are supported well by ofono, in your experience?
We are currently evaluating modems, and we would like to know which
modems cooperate well with ofono. We are interested in modems which
support a GPRS/UMTS
On 27/07/2021 15:38, Denis Kenzior wrote:
Hi Alex,
On 7/20/21 11:11 AM, Alex J Lennon wrote:
Hi all,
I'm doing a bit of work with Ofono again, extending support for a
Quectel EG91 - handling additional cell strength information which
seems necessary for LTE.
I'm using Quectel's AT+QCOPS
On 03/08/2021 15:28, Denis Kenzior wrote:
Hi Alex,
I have been chasing this up with Quectel and they tell me this the
correct implementation.
"QCOPS and QENG command show the RSSI、RSRP and SINR value of the
network, this is in accordance with the 3GPP TS regulations, so it is
normal for
On 03/08/2021 15:28, Denis Kenzior wrote:
Hi Alex,
I have been chasing this up with Quectel and they tell me this the
correct implementation.
"QCOPS and QENG command show the RSSI、RSRP and SINR value of the
network, this is in accordance with the 3GPP TS regulations, so it is
normal for
On 06/08/2021 15:20, Denis Kenzior wrote:
Hi Alex,
Denis - I am being directed to the ITU 36.133 spec here
https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2420
Sure, same document/section where 27.007 refers to for . But
unfortunately
On 06/08/2021 15:44, Denis Kenzior wrote:
Hi Alex,
OK - they say it's fine and you say it's not. I don't have the time
to be the middle-man here.
I'm fairly certain your vendor's firmware is not following the
relevant standards, but it sounds like they don't want to fix it. What
can I
Hi all,
I'm doing a bit of work with Ofono again, extending support for a
Quectel EG91 - handling additional cell strength information which seems
necessary for LTE.
I'm using Quectel's AT+QCOPS which is returning some negative signal
strengths and after some investigation I've spotted that
Hi Sebastian,
Please see below:
On 27/07/2021 15:38, Denis Kenzior wrote:
Hi Alex,
On 7/20/21 11:11 AM, Alex J Lennon wrote:
Hi all,
I'm doing a bit of work with Ofono again, extending support for a
Quectel EG91 - handling additional cell strength information which
seems necessary for LTE
36 matches
Mail list logo
