Hi Marcel and Denis
There is an issue on downlink data transfer on ifx modem.
Please note that ifx modem will switch over to in-kernel MUX for data handling
once
the kernel MUX driver enhancements for network interface support have been
accepted
into MeeGo.
Cheers,
Waldo
plugins/ifx.c | 76
+---
1 files changed, 66 insertions(+), 10 deletions(-)
diff --git a/plugins/ifx.c b/plugins/ifx.c
index c0a69c2..e0eb982 100644
--- a/plugins/ifx.c
+++ b/plugins/ifx.c
@@ -71,6 +71,8 @@
#define
+struct gsm {
+ int lac;
+ int ci;
+ int ta;
+ int no_cells;
+ struct geran_neigh_cell{
+ int arfcn;
+ int bsic;
+ int rxlev;
+
+ } nmr[OFONO_MAX_NMR_COUNT];
+};
What about the frequency of the serving cell? I was under the
Shouldn't ofono_cell_info_results be defined here and included as an argument
for
ofono_cell_info_query_cb_t ?
Cheers,
Waldo
-Original Message-
From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On Behalf Of
Antti Paila
Sent: Tuesday, December 21, 2010 6:00 AM
To:
@@ -80,6 +82,18 @@ static const char *dlc_nodes[NUM_DLC] = {
/dev/ttyGSM1, /dev/ttyGSM2,
static const char *none_prefix[] = { NULL };
static const char *xdrv_prefix[] = { +XDRV:, NULL };
+static const char *empty_prefix[] = { , NULL };
This is still wrong. See my comment from
Hi,
I have investigated a little bit dynamic updating of emergency numbers
by network. So I suggest, I'll register new notification-handler for
'+CEN'-report in voicecall-driver. And naturally give those new
emergency-numbers for voicecall-atom to be analyzed.
The modem will typically
The conclusion was that these two test commands should be issued from the
AP to ensure that the modem is functioning properly.
I am not aware of the conclusion. My understanding is still that the
modem firmware is suppose to do its selftests all by itself.
It does not.
So what is the
Adding Infineon modem selftest to the plugin. It executes couple of AT
commands, and based on the responses, it continues with ifx modem
enabling or powers the modem down.
didn't we conclude that the modem should do all these by itself? My
understanding is that the modem executes these.
+ void (*remove)(struct ofono_ctm *tt);
+ void (*query_tty)(struct ofono_ctm *tt,
+ ofono_ctm_query_cb_t cb,
+ void *data);
+ void (*set_tty)(struct ofono_ctm *tt,
+ int enable,
I also changed this to
Conformance testing per 3GPP 34.109s5.4.1.3 requires that
RESET UE POSITIONING STORED INFO is handled.
Similar for 3GPP RESET MS POSITIONING STORED INFO per 3GPP 44.014s12.
As far as I can see there is no provision for that in commands / XML
defined by 27.007.
Would it make sense to add a
[Resend without the bottom quote - Damn you Outlook]
Conformance testing per 3GPP 34.109s5.4.1.3 requires that
RESET UE POSITIONING STORED INFO is handled.
Similar for 3GPP RESET MS POSITIONING STORED INFO per 3GPP 44.014s12.
As far as I can see there is no provision for that in commands / XML
According to the doc I have, modem implementation is quite close:
Trigger Fast Dormancy +XFDOR
This command triggers fast dormancy if all conditions are passed successful
it will be send
towards the network. There will be no confirmation if the request was
executed or not as in the
Marcel wrote:
diff --git a/TODO b/TODO
index bf2305b..9dcb43f 100644
--- a/TODO
+++ b/TODO
@@ -496,3 +496,14 @@ Miscellaneous
Priority: Low
Complexity: C4
+
+- Enable exporting contact information from vCard data to SM and ME stores.
+ Need to implement a robust
The error handling in ifx_agps_inject_time_cb needs to have a call to
CALLBACK_WITH_FAILURE.
Calling g_at_chat_register(agd-chat, %%XFTI:, ...) from
ifx_agps_inject_time_cb seems wrong:
- It gets called multiple times
- Are you sure that %XFTI can't come before the OK response?
- agd-chat
this mailing list does NOT allow top posting and you know this.
I indeed realized this about a second after I pressed send. My initial response
was to use Outlook's recall function to correct my mistake... luckily sanity
prevailed.
I am very sorry about this transgression. I will now sulk in
oFono is strict CamelCase, even for abbreviations. You do this
correctly above (AgpsManager) but not here. Please be consistent. And
it might be a good idea to not have abbreviations at all. What does LCS
stand for in this case?
It refers to terminology from 3GPP TS 04.31:
RRLP - Radio
For other modems sending the raw RRC/RRLP frames I guess the transcoding to
XML
would need to happen in the ofono driver or in ofono core if you want
to expose an
oFono XML API.
so here is my take on XML. If we have to parse it, then in general that
is a bad idea. Creating XML is
We have already had a discussion on this one when designing the current
stk modem API. The bottom line is that oFono tries to keep its core -
modem interfaces minimal and exposing the entirety of stkutil.h as
official API is definitely too much.
So right now you will need to re-encode into
Modem drivers that support Online / offline mode default to offline when oFono
loads them. Which component is responsible for calling oFono and switch the
modem to online mode? Will that component be part of MeeGo?
Cheers,
Waldo
--
Intel Corporation - Hillsboro, Oregon
Ultra Mobility Group
Modem drivers that support Online / offline mode default to offline when
oFono loads them. Which component is responsible for calling oFono and
switch the modem to online mode? Will that component be part of MeeGo?
This feature is still highly experimental and not all of the details
have been
s s wrote:
supplementaryservices-api.txt is not available in doc folder in
ofono-0.25.tar.gz ,is there any other location to find it?
http://git.kernel.org/?p=network/ofono/ofono.git;a=blob_plain;f=doc/supplementaryservices-api.txt;hb=7cd09ee21aff49afc7f5678cb56f8c5300ca42b4
Cheers,
Waldo
So my current thinking is to drop any Tech reporting in gprs atom for now.
At least until we actually find a usecase for EPSB/CPSB style reporting.
What about the CGREG style tech reporting?
Cheers,
Waldo
___
ofono mailing list
ofono@ofono.org
Please find attached a proposal for both a DBUS and Modem API for AGPS support.
This proposal introduces two AGPS features:
1) Fine time injection - the cellular modem has access to accurate timing
information that can help a GPS device to get a quicker fix. If the modem and
GPS device are
http://git.kernel.org/?p=network/ofono/ofono.git;a=tree;f=doc; has useful
documentation on the external DBUS API.
A while back the validation folks where posting test-reports [1], but I haven't
seen those in a while.
[1] http://lists.ofono.org/pipermail/ofono/2010-February/001180.html
Hi Denis,
Actually our apps listen for the IncomingMessage signal, and store the
SMS in an internal database.
At some point by design, a restart, a crash or other reasons, it may
happen that apps are down while ofono and the modem are up, in that
case we lose incoming messages.
A similar
Hi Waldo,
Hi Denis,
Actually our apps listen for the IncomingMessage signal, and store the
SMS in an internal database.
At some point by design, a restart, a crash or other reasons, it may
happen that apps are down while ofono and the modem are up, in that
case we lose
Bastian, Waldo ha scritto:
The message handling in this patch seems to be vulnerable to SQL
injection attacks. See http://en.wikipedia.org/wiki/SQL_injection
Cheers,
Waldo
Hi Waldo,
I didn't think of a message carrying an SQL injection :)
Honestly I would use prepared statement
Pekka Pessi wrote:
I've been porting the N900 modem control code to oFono. The semantics
of Powered is fine with respect of the atoms, in other words, if the
modem crashes and boots itself, all the atoms are flushed nicely.
When powering up, the Powered can be set to true when the modem is
to, 2010-02-11 kello 20:25 +0100, ext Bastian, Waldo kirjoitti:
void ofono_cell_info_query(struct ofono_cell_info *ci,
ofono_cell_info_query_cb_t cb, void *data);
What's this for?
It's basically ofono_cell_info_driver-query(...) for use by a plugin
after it has acquired the atom
struct ofono_cell_info_driver {
const char *name;
int (*probe)(struct ofono_cell_info *ci, unsigned int vendor,
void *data);
void (*remove)(struct ofono_cell_info *ci);
void (*query)(struct ofono_cell_info *ci,
Hi,
Revisited proposal for neighbouring cell info based on previous feedback:
- Low-level driver API instead of oFono.org DBUS API
- Polling based, no automatic periodic updates
- Follows definitions in OMA SUPL v2.0
I'm not particular fond of the nested list - wcdma.
This atom provides access to the modem's radio access properties. It
currently includes a single rw property, namely the radio access
selection mode setting.
It might be helpful to include the API documentation too. One thing I
don't like is the name RadioAccess. The connotation is a
People on this list keep forgetting two things:
1. We're not designing a kitchen sink API here. Most of the 'radio
related
settings' will simply never be exposed, nobody really cares what UMTS
channel
he/she is currently on.
2. We're designing the API to be easy to use for everyone, not
Hi Aki,
Honestly I don't like either approach, the Agent pattern would be a
much better fit here. This would allow us to specify
the polling/update interval and stop neighbor cell updates when no one
is interested in them.
In my experience, the positioning guys don't need
- /* Mode doesn't matter, but sounds like 2 is the sanest option */
- if (!append_cnmi_element(buf, len, cnmi_opts[0], 2310, FALSE))
+ if (data-vendor == OFONO_VENDOR_HTC_G1)
+ /* The G1 advertises support for mode 2, but returns an error
+ * if we attempt
This really belong in the kernel. Only the kernel can reliably know
when a network interface has been brought down and notify the
interested applications with the statistics.
You're missing the point.
Yes, any body can extract the statistics for a running context. But data
I am still not seeing the point in what suspended will do for us and
the UI. And that Maemo 5 exposed such a state in the UI is not an
argument to keep doing it. I asked this before, what are we suppose to
be doing when we get signaled suspended?
User, as well as intelligent
I know why you want this, but I'm still against the counter being an
oFono driver API. There needs to be a proper kernel interface that
signals the application when an interface has gone away with the rx/tx
details. This way we handle this generically for all modems without
38 matches
Mail list logo
