RFCs: Infineon modem support for agps

RFCs: Infineon modem support for agps

[Robertino Benis]

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


Hi all,

Set of patches which is comming, is request for comments for
adding AGPS support to Infineon modem in oFono. It includes
basic API documentation, suggested core API  and implementation
in IFX modem driver for AGPS.

Thank you very much for your comments so far, Marcel.

Cheers,
-- r.

[RFC 1/3] doc: addidng documentation for basic assisted gps

[Robertino Benis]

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

---
 doc/assistedgps-manager-api.txt |  114 +++++++++++++++++++++++++++++++++++++++
 1 files changed, 114 insertions(+), 0 deletions(-)
 create mode 100644 doc/assistedgps-manager-api.txt

diff --git a/doc/assistedgps-manager-api.txt b/doc/assistedgps-manager-api.txt
new file mode 100644
index 0000000..b09c8b1
--- /dev/null
+++ b/doc/assistedgps-manager-api.txt
@@ -0,0 +1,114 @@
+AgpsManager hierarchy
+=====================
+
+Service		org.ofono
+Interface	org.ofono.AgpsManager
+Object path	[variable prefix]/{modem0,modem1,...}
+
+Methods		dict GetProperties()
+
+			Returns properties for the modem object. See
+			the properties section for available properties.
+
+			Possible Errors: [service].Error.InvalidArguments
+
+		void SetProperty(string name, variant value)
+
+			Changes the value of the specified property. Only
+			properties that are listed as read-write are
+			changeable. On success a PropertyChanged signal
+			will be emitted.
+
+			Possible Errors: [service].Error.InvalidArguments
+					 [service].Error.DoesNotExist
+
+		void SendLCSFrame(string frametype, string framedata)
+
+			Send a LCS position protocol frame to the Mobile
+			Network. The LCS frame typically represents a
+			Position Response.
+
+			Valid frametypes are:
+				rrlp_measure_position_response
+				rrc_measurement_report
+
+			The raw frame data is formatted as the concatenated
+			sequence of the two digit hexadecimal representation
+			of each of its octets. Example: "00FC2345"
+
+		void RequestFineTimeInjection(string rat, uint16 pulselength)
+
+			Request modem to generate a fine time injection
+			pulse. pulselength is the duration of the pulse
+			expressed in radio frames.
+
+			rat specifies the access technology used to derive
+			the pulse from and can be "gsm" or "umts".
+			If the requested access technology is not currently
+			in use an error is returned.
+
+Signals		PropertyChanged(string name, variant value)
+
+			This signal indicates a changed value of the given
+			property.
+
+		IncomingLCSFrame(string frametypes, string framedata)
+
+			LCS positioning protocol frame received from the
+			Mobile Network.
+
+			Valid frametypes for the LCS frame are:
+				rrlp_assistance_data
+				rrlp_measure_position_request
+				rrc_assistance_data_delivery
+				rrc_measurement_control
+
+			Note that position/measurement requests can include
+			assistance data as well.
+
+			The raw frame data is formatted as the concatenated
+			sequence of the two digit hexadecimal representation
+			of each of its octets. Example: "00FC2345"
+
+		FineTimeInjectionNotification(dict radioframenumber)
+
+			Notification about fine time injection pulse
+			generated by modem. The radioframenumber dict
+			is defined as follow:
+
+			string AccessTechnology
+				"gsm" or "umts"
+			
+			uint32 TdmaFrameNumber (gsm only)
+				range 0 - 2715647 (2048*26*51)
+
+			uint16 TdmaTimeslot (gsm only)
+				range 0 - 7
+
+			uint16 TimeslotBit (gsm only)
+				range 0 - 156
+
+			uint16 TimingAdvance (gsm only)
+				range 0 - 63
+
+			uint16 BcchArfcn (gsm only)
+				range 0 - 1023
+
+			uint16 Bsic (gsm only)
+				range 0 - 64
+
+			uint16 Sfn (umts only)
+				range 0 - 4095
+
+			string RrcState (umts only)
+				"cell_dch", "cell_fach", "cell_pch" or
+				"ura_pch"
+			
+			uint16 RoundTripTime (umts only)
+				range 0 - 32766
+
+
+Properties	boolean LcsEnabled [readwrite]
+
+			If LcsEnabled is False, then no LCS positioning
+			protocol frames are received.
-- 
1.7.0.4

Re: [RFC 1/3] doc: addidng documentation for basic assisted gps

[Denis Kenzior]

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

Hi Robertino,

On 11/05/2010 12:55 PM, Robertino Benis wrote:
> ---
>  doc/assistedgps-manager-api.txt |  114 +++++++++++++++++++++++++++++++++++++++
>  1 files changed, 114 insertions(+), 0 deletions(-)
>  create mode 100644 doc/assistedgps-manager-api.txt
> 
> diff --git a/doc/assistedgps-manager-api.txt b/doc/assistedgps-manager-api.txt
> new file mode 100644
> index 0000000..b09c8b1
> --- /dev/null
> +++ b/doc/assistedgps-manager-api.txt
> @@ -0,0 +1,114 @@
> +AgpsManager hierarchy
> +=====================
> +
> +Service		org.ofono
> +Interface	org.ofono.AgpsManager

So in general I'm currently against introducing this API as oFono
official API.  I suggest prefixing this with an IFX specific identifier.
 Maybe modem.ifx.AgpsManager.

> +Object path	[variable prefix]/{modem0,modem1,...}
> +
> +Methods		dict GetProperties()
> +
> +			Returns properties for the modem object. See
> +			the properties section for available properties.
> +
> +			Possible Errors: [service].Error.InvalidArguments
> +
> +		void SetProperty(string name, variant value)
> +
> +			Changes the value of the specified property. Only
> +			properties that are listed as read-write are
> +			changeable. On success a PropertyChanged signal
> +			will be emitted.
> +
> +			Possible Errors: [service].Error.InvalidArguments
> +					 [service].Error.DoesNotExist
> +
> +		void SendLCSFrame(string frametype, string framedata)

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?

> +
> +			Send a LCS position protocol frame to the Mobile
> +			Network. The LCS frame typically represents a
> +			Position Response.
> +
> +			Valid frametypes are:
> +				rrlp_measure_position_response
> +				rrc_measurement_report
> +
> +			The raw frame data is formatted as the concatenated
> +			sequence of the two digit hexadecimal representation
> +			of each of its octets. Example: "00FC2345"

Sending hex-encoded data screams as being non-portable and AT command
modem specific.  Is this really your intent here?

> +
> +		void RequestFineTimeInjection(string rat, uint16 pulselength)
> +
> +			Request modem to generate a fine time injection
> +			pulse. pulselength is the duration of the pulse
> +			expressed in radio frames.
> +
> +			rat specifies the access technology used to derive
> +			the pulse from and can be "gsm" or "umts".
> +			If the requested access technology is not currently
> +			in use an error is returned.

It seems to me that making the upper layers pass in the rat as a
parameter to this function is a pretty bad idea.  You should either have
the atom figure this out if it can (e.g. by using netreg atom) or have
the driver take care of this directly.

> +
> +Signals		PropertyChanged(string name, variant value)
> +
> +			This signal indicates a changed value of the given
> +			property.
> +
> +		IncomingLCSFrame(string frametypes, string framedata)
> +
> +			LCS positioning protocol frame received from the
> +			Mobile Network.
> +
> +			Valid frametypes for the LCS frame are:
> +				rrlp_assistance_data
> +				rrlp_measure_position_request
> +				rrc_assistance_data_delivery
> +				rrc_measurement_control
> +
> +			Note that position/measurement requests can include
> +			assistance data as well.
> +
> +			The raw frame data is formatted as the concatenated
> +			sequence of the two digit hexadecimal representation
> +			of each of its octets. Example: "00FC2345"

Same comment as above about LCS naming and hex-encoded strings.

> +
> +		FineTimeInjectionNotification(dict radioframenumber)
> +
> +			Notification about fine time injection pulse
> +			generated by modem. The radioframenumber dict
> +			is defined as follow:
> +

Why is this returned in a separate signal as opposed to a reply to the
RequestFineTimeInjection method call?

> +			string AccessTechnology
> +				"gsm" or "umts"
> +			
> +			uint32 TdmaFrameNumber (gsm only)
> +				range 0 - 2715647 (2048*26*51)
> +
> +			uint16 TdmaTimeslot (gsm only)
> +				range 0 - 7
> +
> +			uint16 TimeslotBit (gsm only)
> +				range 0 - 156
> +
> +			uint16 TimingAdvance (gsm only)
> +				range 0 - 63
> +
> +			uint16 BcchArfcn (gsm only)
> +				range 0 - 1023
> +
> +			uint16 Bsic (gsm only)
> +				range 0 - 64
> +
> +			uint16 Sfn (umts only)
> +				range 0 - 4095
> +
> +			string RrcState (umts only)
> +				"cell_dch", "cell_fach", "cell_pch" or
> +				"ura_pch"
> +			
> +			uint16 RoundTripTime (umts only)
> +				range 0 - 32766
> +
> +
> +Properties	boolean LcsEnabled [readwrite]
> +
> +			If LcsEnabled is False, then no LCS positioning
> +			protocol frames are received.

In general it is a bad idea to have properties with abbreviations in
them.  What does LCS stand for?

Regards,
-Denis

Re: [RFC 1/3] doc: addidng documentation for basic assisted gps

[Marcel Holtmann]

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

Hi Denis,

> >  doc/assistedgps-manager-api.txt |  114 +++++++++++++++++++++++++++++++++++++++
> >  1 files changed, 114 insertions(+), 0 deletions(-)
> >  create mode 100644 doc/assistedgps-manager-api.txt
> > 
> > diff --git a/doc/assistedgps-manager-api.txt b/doc/assistedgps-manager-api.txt
> > new file mode 100644
> > index 0000000..b09c8b1
> > --- /dev/null
> > +++ b/doc/assistedgps-manager-api.txt
> > @@ -0,0 +1,114 @@
> > +AgpsManager hierarchy
> > +=====================
> > +
> > +Service		org.ofono
> > +Interface	org.ofono.AgpsManager
> 
> So in general I'm currently against introducing this API as oFono
> official API.  I suggest prefixing this with an IFX specific identifier.
>  Maybe modem.ifx.AgpsManager.

I would actually go one step further and call this com.infineon.Agps or
something like that.

As I stated this many times, before we make this a generic oFono API, we
need at least three types of modems that support this kind of feature
and find the common API.

For me this is clearly IFX and ISI right now. And it looks to me that
Sjur has also shown interested, so the third one might be STE/MBM.

Regards

Marcel

Re: [RFC 1/3] doc: addidng documentation for basic assisted gps

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

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

Hi,
>> So in general I'm currently against introducing this API as oFono
>> official API.  I suggest prefixing this with an IFX specific identifier.
>>  Maybe modem.ifx.AgpsManager.
>
> I would actually go one step further and call this com.infineon.Agps or
> something like that.
>
> As I stated this many times, before we make this a generic oFono API, we
> need at least three types of modems that support this kind of feature
> and find the common API.
>
> For me this is clearly IFX and ISI right now. And it looks to me that
> Sjur has also shown interested, so the third one might be STE/MBM.

Yes, I can confirm that we are looking into this and are planning to
support AGPS for
oFono. Would you be interested if we proposed an API whith transparent transport
of the XML specified by 3GPP? Such an API should be possible to
implement with the
3GPP standardized AGPS commands, so that a generic driver could be implemented
(atmodem/agps.c).

Regards,
Sjur

Re: [RFC 1/3] doc: addidng documentation for basic assisted gps

[Denis Kenzior]

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

Hi Sjur,

On 11/05/2010 03:21 PM, Sjur Brændeland wrote:
> Hi,
>>> So in general I'm currently against introducing this API as oFono
>>> official API.  I suggest prefixing this with an IFX specific identifier.
>>>  Maybe modem.ifx.AgpsManager.
>>
>> I would actually go one step further and call this com.infineon.Agps or
>> something like that.
>>
>> As I stated this many times, before we make this a generic oFono API, we
>> need at least three types of modems that support this kind of feature
>> and find the common API.
>>
>> For me this is clearly IFX and ISI right now. And it looks to me that
>> Sjur has also shown interested, so the third one might be STE/MBM.
> 
> Yes, I can confirm that we are looking into this and are planning to
> support AGPS for
> oFono. Would you be interested if we proposed an API whith transparent transport
> of the XML specified by 3GPP? Such an API should be possible to
> implement with the
> 3GPP standardized AGPS commands, so that a generic driver could be implemented
> (atmodem/agps.c).
> 

I would definitely like to see a 27.007 based aGPS proposal.

Regards,
-Denis

Re: [RFC 1/3] doc: addidng documentation for basic assisted gps

[Marcel Holtmann]

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

Hi Denis,

> >>> So in general I'm currently against introducing this API as oFono
> >>> official API.  I suggest prefixing this with an IFX specific identifier.
> >>>  Maybe modem.ifx.AgpsManager.
> >>
> >> I would actually go one step further and call this com.infineon.Agps or
> >> something like that.
> >>
> >> As I stated this many times, before we make this a generic oFono API, we
> >> need at least three types of modems that support this kind of feature
> >> and find the common API.
> >>
> >> For me this is clearly IFX and ISI right now. And it looks to me that
> >> Sjur has also shown interested, so the third one might be STE/MBM.
> > 
> > Yes, I can confirm that we are looking into this and are planning to
> > support AGPS for
> > oFono. Would you be interested if we proposed an API whith transparent transport
> > of the XML specified by 3GPP? Such an API should be possible to
> > implement with the
> > 3GPP standardized AGPS commands, so that a generic driver could be implemented
> > (atmodem/agps.c).
> > 
> 
> I would definitely like to see a 27.007 based aGPS proposal.

I agree. If 27.007 bothered to standardize it, the seems like a good
idea to go for it.

Btw. I don't like the term aGPS. Especially GPS. That is actually more
like a product name and not really generic. Especially if you think
about the positioning systems from the European Union or Russia. So I
would like to see something like AssistedPositioning or in that spirit
of it.

Regards

Marcel

RE: [RFC 1/3] doc: addidng documentation for basic assisted gps

[Bastian, Waldo]

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

> 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 Resource LCS Protocol
LCS -> Location Services

> > +			The raw frame data is formatted as the concatenated
> > +			sequence of the two digit hexadecimal representation
> > +			of each of its octets. Example: "00FC2345"
>
> Sending hex-encoded data screams as being non-portable and AT command
> modem specific.  Is this really your intent here?

The intent is to send an array of octets. A string seemed a debug-friendly way of
mapping it onto a DBUS API, but other suggestion for a suitable DBUS type are welcome.

> > +		void RequestFineTimeInjection(string rat, uint16 pulselength)
> It seems to me that making the upper layers pass in the rat as a
> parameter to this function is a pretty bad idea.  You should either have
> the atom figure this out if it can (e.g. by using netreg atom) or have
> the driver take care of this directly.

I was asked to add it as the AGPS manager that makes the request presumes a certain RAT and there is no point in generating the pulse if the RAT has changed since.
See also http://lists.ofono.org/pipermail/ofono/2010-May/002347.html

> +
> +		FineTimeInjectionNotification(dict radioframenumber)
> +
> +			Notification about fine time injection pulse
> +			generated by modem. The radioframenumber dict
> +			is defined as follow:
> +
>
> Why is this returned in a separate signal as opposed to a reply to the
> RequestFineTimeInjection method call?

The concern was that the reply would not be immediate, but I don't think it's that much delayed that it runs in any DBUS timeouts, so I think it can be turned into a reply instead.

Cheers,
Waldo

RE: [RFC 1/3] doc: addidng documentation for basic assisted gps

[Marcel Holtmann]

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

Hi Waldo,

> > 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 Resource LCS Protocol
> LCS -> Location Services

I am with Denis here. If you mean Location Services, then call it that
way. Even within the API naming we are trying to be consistent and avoid
abbreviations whenever possible.

> > > +			The raw frame data is formatted as the concatenated
> > > +			sequence of the two digit hexadecimal representation
> > > +			of each of its octets. Example: "00FC2345"
> >
> > Sending hex-encoded data screams as being non-portable and AT command
> > modem specific.  Is this really your intent here?
> 
> The intent is to send an array of octets. A string seemed a debug-friendly way of
> mapping it onto a DBUS API, but other suggestion for a suitable DBUS type are welcome.

That is an array of bytes what you are looking for. A string of hex
encoded octets is pretty much a bad idea for an API.

It might be convenient for an AT command based modem, but a bad idea for
an D-Bus based API.

> > > +		void RequestFineTimeInjection(string rat, uint16 pulselength)
> > It seems to me that making the upper layers pass in the rat as a
> > parameter to this function is a pretty bad idea.  You should either have
> > the atom figure this out if it can (e.g. by using netreg atom) or have
> > the driver take care of this directly.
> 
> I was asked to add it as the AGPS manager that makes the request presumes a certain RAT and there is no point in generating the pulse if the RAT has changed since.
> See also http://lists.ofono.org/pipermail/ofono/2010-May/002347.html

Seems still wrong to me. Why would an application have to deal with
this. This looks like an internal implementation detail to me. Pushing
such a thing out to the application is against the philosophy of our
D-Bus APIs to simplify things.

> > +		FineTimeInjectionNotification(dict radioframenumber)
> > +
> > +			Notification about fine time injection pulse
> > +			generated by modem. The radioframenumber dict
> > +			is defined as follow:
> > +
> >
> > Why is this returned in a separate signal as opposed to a reply to the
> > RequestFineTimeInjection method call?
> 
> The concern was that the reply would not be immediate, but I don't think it's that much delayed that it runs in any DBUS timeouts, so I think it can be turned into a reply instead.

And so is the signal. Both are bound to the scheduling of the D-Bus
daemon.

Regards

Marcel

RE: [RFC 1/3] doc: addidng documentation for basic assisted gps

[Joly, Frederic]

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

Hi gentelmen,



I apologise for this very comment.



-----Original Message-----
From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)ofono.org] On Behalf Of Marcel Holtmann
Sent: Friday, November 05, 2010 9:47 PM
To: ofono(a)ofono.org
Cc: Ahmed, Suhail
Subject: RE: [RFC 1/3] doc: addidng documentation for basic assisted gps



> > > > +         void RequestFineTimeInjection(string rat, uint16 pulselength)

> > > It seems to me that making the upper layers pass in the rat as a

> > > parameter to this function is a pretty bad idea.  You should either have

> > > the atom figure this out if it can (e.g. by using netreg atom) or have

> > > the driver take care of this directly.

> >

> > I was asked to add it as the AGPS manager that makes the request presumes

> >  a certain RAT and there is no point in generating the pulse if the RAT has changed since.

> > See also http://lists.ofono.org/pipermail/ofono/2010-May/002347.html



> Seems still wrong to me. Why would an application have to deal with

> this. This looks like an internal implementation detail to me. Pushing

> such a thing out to the application is against the philosophy of our

> D-Bus APIs to simplify things.

The fine time injection consists in generating a hardware pulse for the GPS device at the beginning of a radio frame.

Thanks to assistance data received from the 3GPP network or SUPL, the Position framework (or the GPS manager) knows the link between the Universal Time and the radio frame number.

It allows the position framework to determine the Universal Time with a pretty good accuracy ( a few micro seconds). The GPS system being time based, the precise knowledge of the Time allows a faster acquisition of the position (a faster TTFF, time to first fix).

Another usage, allowing also to achieve a faster TTFF, is to provide a precise time reference to the GPS device by using the length of the pulse (usually a radio frame).



A dual mode modem is synchronized on both 3G and 2G networks so you have to specify to the modem if the pulse must be generated at the beginning of a GSM TDMA frame or at the beginning of a 3G CDMA frame. The two systems do not use similar radio frame structures.



I hope it clarifies a bit the purpose of this RAT field.



BR,



Fred


---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

[RFC 2/3] agps: adding agps related functions

[Robertino Benis]

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

---
 include/agps.h |  157 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 157 insertions(+), 0 deletions(-)
 create mode 100644 include/agps.h

diff --git a/include/agps.h b/include/agps.h
new file mode 100644
index 0000000..54f9b53
--- /dev/null
+++ b/include/agps.h
@@ -0,0 +1,157 @@
+/*
+ *
+ *  oFono - Open Source Telephony
+ *
+ *  Copyright (C) 2008-2010  Intel Corporation. All rights reserved.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ */
+
+#ifndef __OFONO_AGPS_H_
+#define __OFONO_AGPS_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <ofono/types.h>
+
+enum ofono_lcs_frame_type {
+	RRLP_ASSISTANCE_DATA = 0,		/* from modem */
+	/* Position request can include assistance data as well */
+	RRLP_MEASURE_POSITION_REQUEST = 1,	/* from modem */
+	RRLP_MEASURE_POSITION_RESPONSE = 2,	/* from GPS */
+	RRC_ASSISTANCE_DATA_DELIVERY = 3,	/* from modem */
+	/* Measurement control can include assistance data as well */
+	RRC_MEASUREMENT_CONTROL = 4,		/* from modem */
+	RRC_MEASUREMENT_REPORT = 5,		/* from GPS */
+};
+
+enum ofono_access_technology {
+	RADIO_ACCESS_TECHNOLOGY_GSM = 0,		/* GSM */
+	RADIO_ACCESS_TECHNOLOGY_UMTS = 1,		/* UMTS */
+};
+
+enum ofono_rrc_state {
+	RRC_CELL_PCH = 0,
+	RRC_CELL_FACH = 1,
+	RRC_CELL_DCH = 2,
+	RRC_URA_PCH = 3,
+};
+
+struct ofono_lcs_frame {
+	enum ofono_lcs_frame_type lcs_frame_type;
+	int frame_length;	/* size of raw_frame in bytes */
+	unsigned char  *raw_frame;
+};
+
+struct ofono_lcs_gsm_fn {
+	int TDMA_frame_number;	/* range 0 - 2715647 (2048*26*51) */
+	int TDMA_timeslot;		/* range 0 - 7 */
+	int timeslot_bit;		/* range 0 - 156 */
+	int timing_advance;		/* range 0 - 63 */
+	int bcch_arfcn;			/* range 0 - 1023 */
+	int bsic;				/* range 0 - 64 */
+};
+
+struct ofono_lcs_utran_fn {
+	int sfn;				/* range 0 - 4095 */
+	int rrc_state;			/* enum ofono_rrc_state */
+	int round_trip_time;	/* range 0 - 32766 */
+};
+
+struct ofono_lcs_radio_fn {
+	int radio_access_technology; /* enum access_technology */
+	union {
+		struct ofono_lcs_gsm_fn		gsm_frame_number;
+		struct ofono_lcs_utran_fn	utran_frame_number;
+	};
+};
+
+struct ofono_agps;
+
+typedef void (*ofono_agps_send_lcs_frame_cb_t)(const struct ofono_error *error,
+				void *data);
+typedef void (*ofono_agps_receive_lcs_frame_cb_t)(
+				const struct ofono_error *error,
+				void *data);
+typedef void (*ofono_agps_inject_time_cb_t)(const struct ofono_error *error,
+				struct ofono_lcs_radio_fn *radio_frame_number,
+				void *data);
+
+	/*
+	 * AGPS related functions, including LCS frame forwarding and
+	 * fine time injection
+	 */
+struct ofono_agps_driver {
+	const char *name;
+	int (*probe)(struct ofono_agps *agps, unsigned int vendor,
+			void *data);
+	void (*remove)(struct ofono_agps *agps);
+
+	/* The GPS manager can configure the modem to notify Assistance Data and
+	 * Position Requests from the Mobile Network by setting the LcsEnabled
+	 * status to true. If false, no notifications are sent from modem.
+	 */
+	void (*receive_lcs_frames)(struct ofono_agps *agps, int enabled,
+			ofono_agps_receive_lcs_frame_cb_t cb, void *data);
+
+	/* Assistance Data and Position Requests from the Mobile Network are
+	 * signalled via the ofono_agps_lcs_frame_notify function and the
+	 * oFono core to an external GPS manager. This GPS manager can reply
+	 * to Position Requests with one or more Position Responses which
+	 * are then send back to the modem via the send_lcs_frame function.
+	 */
+	void (*send_lcs_frame)(struct ofono_agps *agps,
+			struct ofono_lcs_frame *frame,
+			ofono_agps_send_lcs_frame_cb_t cb, void *data);
+
+	/* The GPS manager can ask the modem to generate a HW pulse (time
+	 * stamp) with a defined length and the modem replies indicates when
+	 * it generates the pulse. But as the modem has no precise idea of
+	 * Universal Time, it indicates at which radio frame number it
+	 * generated the pulse. The GPS manager which knows the link between
+	 * Universal Time and the Radio Frame number knows very precisely at
+	 * what time the pulse was generated and its duration.
+	 *
+	 * Timing accuracy is typically a few microseconds.
+	 */
+	void (*inject_time)(struct ofono_agps *agps,
+	int radio_access_technology, /* enum access_technology */
+	int pulse_length, /* duration of pulse in radio slots */
+	ofono_agps_inject_time_cb_t cb, void *data);
+};
+
+int ofono_agps_driver_register(const struct ofono_agps_driver *d);
+void ofono_agps_driver_unregister(const struct ofono_agps_driver *d);
+
+struct ofono_agps *ofono_agps_create(struct ofono_modem *modem,
+					unsigned int vendor, const char *driver,
+					void *data);
+
+void ofono_agps_register(struct ofono_agps *agps);
+void ofono_agps_remove(struct ofono_agps *agps);
+
+void ofono_agps_set_data(struct ofono_agps *agps, void *data);
+void *ofono_agps_get_data(struct ofono_agps *agps);
+
+void ofono_agps_lcs_frame_notify(struct ofono_agps *agps,
+			struct ofono_lcs_frame frame);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* __OFONO_AGPS_H */
-- 
1.7.0.4

Re: [RFC 2/3] agps: adding agps related functions

[Denis Kenzior]

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

Hi Robertino,

On 11/05/2010 12:55 PM, Robertino Benis wrote:
> ---
>  include/agps.h |  157 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 157 insertions(+), 0 deletions(-)
>  create mode 100644 include/agps.h
> 
> diff --git a/include/agps.h b/include/agps.h
> new file mode 100644
> index 0000000..54f9b53
> --- /dev/null
> +++ b/include/agps.h
> @@ -0,0 +1,157 @@
> +/*
> + *
> + *  oFono - Open Source Telephony
> + *
> + *  Copyright (C) 2008-2010  Intel Corporation. All rights reserved.
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with this program; if not, write to the Free Software
> + *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
> + *
> + */
> +

Please follow _all_ coding conventions in oFono.  They're not optional
and we actually are pretty consistent across the board.  Most of the
common 'gotcha's are documented in doc/coding-style.txt.

> +#ifndef __OFONO_AGPS_H_
> +#define __OFONO_AGPS_H_

That should be __OFONO_AGPS_H

> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include <ofono/types.h>
> +
> +enum ofono_lcs_frame_type {
> +	RRLP_ASSISTANCE_DATA = 0,		/* from modem */
> +	/* Position request can include assistance data as well */
> +	RRLP_MEASURE_POSITION_REQUEST = 1,	/* from modem */
> +	RRLP_MEASURE_POSITION_RESPONSE = 2,	/* from GPS */
> +	RRC_ASSISTANCE_DATA_DELIVERY = 3,	/* from modem */
> +	/* Measurement control can include assistance data as well */
> +	RRC_MEASUREMENT_CONTROL = 4,		/* from modem */
> +	RRC_MEASUREMENT_REPORT = 5,		/* from GPS */
> +};
> +

Please see doc/coding-style.txt Section M11

> +enum ofono_access_technology {
> +	RADIO_ACCESS_TECHNOLOGY_GSM = 0,		/* GSM */
> +	RADIO_ACCESS_TECHNOLOGY_UMTS = 1,		/* UMTS */
> +};
> +

Please see doc/coding-style.txt Section M11

> +enum ofono_rrc_state {
> +	RRC_CELL_PCH = 0,
> +	RRC_CELL_FACH = 1,
> +	RRC_CELL_DCH = 2,
> +	RRC_URA_PCH = 3,
> +};
> +

Please see doc/coding-style.txt Section M11

> +struct ofono_lcs_frame {
> +	enum ofono_lcs_frame_type lcs_frame_type;
> +	int frame_length;	/* size of raw_frame in bytes */
> +	unsigned char  *raw_frame;
> +};
> +
> +struct ofono_lcs_gsm_fn {
> +	int TDMA_frame_number;	/* range 0 - 2715647 (2048*26*51) */
> +	int TDMA_timeslot;		/* range 0 - 7 */
> +	int timeslot_bit;		/* range 0 - 156 */
> +	int timing_advance;		/* range 0 - 63 */
> +	int bcch_arfcn;			/* range 0 - 1023 */
> +	int bsic;				/* range 0 - 64 */
> +};

Try to keep the same indentation level for comments

> +
> +struct ofono_lcs_utran_fn {
> +	int sfn;				/* range 0 - 4095 */
> +	int rrc_state;			/* enum ofono_rrc_state */
> +	int round_trip_time;	/* range 0 - 32766 */
> +};
> +
> +struct ofono_lcs_radio_fn {
> +	int radio_access_technology; /* enum access_technology */

You define an enum for this, but now use an int?

> +	union {
> +		struct ofono_lcs_gsm_fn		gsm_frame_number;
> +		struct ofono_lcs_utran_fn	utran_frame_number;
> +	};
> +};
> +
> +struct ofono_agps;
> +
> +typedef void (*ofono_agps_send_lcs_frame_cb_t)(const struct ofono_error *error,
> +				void *data);
> +typedef void (*ofono_agps_receive_lcs_frame_cb_t)(
> +				const struct ofono_error *error,
> +				void *data);
> +typedef void (*ofono_agps_inject_time_cb_t)(const struct ofono_error *error,
> +				struct ofono_lcs_radio_fn *radio_frame_number,
> +				void *data);
> +
> +	/*
> +	 * AGPS related functions, including LCS frame forwarding and
> +	 * fine time injection
> +	 */
> +struct ofono_agps_driver {
> +	const char *name;
> +	int (*probe)(struct ofono_agps *agps, unsigned int vendor,
> +			void *data);
> +	void (*remove)(struct ofono_agps *agps);
> +
> +	/* The GPS manager can configure the modem to notify Assistance Data and
> +	 * Position Requests from the Mobile Network by setting the LcsEnabled
> +	 * status to true. If false, no notifications are sent from modem.
> +	 */
> +	void (*receive_lcs_frames)(struct ofono_agps *agps, int enabled,
> +			ofono_agps_receive_lcs_frame_cb_t cb, void *data);
> +
> +	/* Assistance Data and Position Requests from the Mobile Network are
> +	 * signalled via the ofono_agps_lcs_frame_notify function and the
> +	 * oFono core to an external GPS manager. This GPS manager can reply
> +	 * to Position Requests with one or more Position Responses which
> +	 * are then send back to the modem via the send_lcs_frame function.
> +	 */
> +	void (*send_lcs_frame)(struct ofono_agps *agps,
> +			struct ofono_lcs_frame *frame,
> +			ofono_agps_send_lcs_frame_cb_t cb, void *data);
> +
> +	/* The GPS manager can ask the modem to generate a HW pulse (time
> +	 * stamp) with a defined length and the modem replies indicates when
> +	 * it generates the pulse. But as the modem has no precise idea of
> +	 * Universal Time, it indicates at which radio frame number it
> +	 * generated the pulse. The GPS manager which knows the link between
> +	 * Universal Time and the Radio Frame number knows very precisely at
> +	 * what time the pulse was generated and its duration.
> +	 *
> +	 * Timing accuracy is typically a few microseconds.
> +	 */
> +	void (*inject_time)(struct ofono_agps *agps,
> +	int radio_access_technology, /* enum access_technology */
> +	int pulse_length, /* duration of pulse in radio slots */
> +	ofono_agps_inject_time_cb_t cb, void *data);
> +};
> +
> +int ofono_agps_driver_register(const struct ofono_agps_driver *d);
> +void ofono_agps_driver_unregister(const struct ofono_agps_driver *d);
> +
> +struct ofono_agps *ofono_agps_create(struct ofono_modem *modem,
> +					unsigned int vendor, const char *driver,
> +					void *data);
> +
> +void ofono_agps_register(struct ofono_agps *agps);
> +void ofono_agps_remove(struct ofono_agps *agps);
> +
> +void ofono_agps_set_data(struct ofono_agps *agps, void *data);
> +void *ofono_agps_get_data(struct ofono_agps *agps);
> +
> +void ofono_agps_lcs_frame_notify(struct ofono_agps *agps,
> +			struct ofono_lcs_frame frame);
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* __OFONO_AGPS_H */

In general the feeling I have right now is that this API is not ready
for inclusion into the core.  It seems too IFX specific and does not
follow any published standard (e.g. 27.007).

So my guidance would be to implement this API in the IFX drivers /
plugin first.  We can then see whether / what other hardware
manufacturers can support such an API.

Regards,
-Denis

[RFC 3/3] ifxmodem: adding modem API to support agps

[Robertino Benis]

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

---
 drivers/ifxmodem/agps.c |  438 +++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 438 insertions(+), 0 deletions(-)
 create mode 100644 drivers/ifxmodem/agps.c

diff --git a/drivers/ifxmodem/agps.c b/drivers/ifxmodem/agps.c
new file mode 100644
index 0000000..9b68b7e
--- /dev/null
+++ b/drivers/ifxmodem/agps.c
@@ -0,0 +1,438 @@
+/*
+ *
+ *  oFono - Open Source Telephony
+ *
+ *  Copyright (C) 2008-2010  Intel Corporation. All rights reserved.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#define _GNU_SOURCE
+#include <string.h>
+#include <stdlib.h>
+#include <stdio.h>
+#include <errno.h>
+
+#include <glib.h>
+
+#include "gatchat.h"
+#include "gatresult.h"
+
+#include <ofono/log.h>
+#include <ofono/modem.h>
+#include <ofono/agps.h>
+
+#include "util.h"
+#include "ifxmodem.h"
+
+struct agps_data {
+	GAtChat *chat;
+	unsigned int vendor;
+	enum ofono_access_technology rad_acc_tech;
+};
+
+struct ofono_agps;
+static enum ofono_access_technology rad_acc_tech;
+static const char *none_prefix[] = { NULL };
+
+#define FRAME_LEN 128
+
+static void pos_request_notify(GAtResult *result, gpointer user_data)
+{
+	struct ofono_agps *agps = user_data;
+	int framelen;
+	int frametype;
+	GAtResultIter iter;
+	struct ofono_lcs_frame lcsframe;
+	const char *messageframe;
+	unsigned char frame[FRAME_LEN];
+	long hexframelen;
+
+	/* Assuming Pos Req format: %XPOSR: <frametype>,<framelen>,<frame> */
+
+	g_at_result_iter_init(&iter, result);
+
+	if (!g_at_result_iter_next(&iter, "%%XPOSR:"))
+		return;
+
+	if (!g_at_result_iter_next_number(&iter, &frametype))
+		return;
+
+	if (!g_at_result_iter_next_number(&iter, &framelen))
+		return;
+
+	if (framelen > FRAME_LEN) {
+		ofono_error("Got POS request msg more than max buffer size!");
+		return;
+	}
+
+	messageframe = g_at_result_pdu(result);
+
+	if (strlen(messageframe) > sizeof(frame) * 2) { /*Hex, 2 chars/byte*/
+		ofono_error("Message frame too long!");
+		return;
+	}
+
+	if (decode_hex_own_buf(messageframe, -1, &hexframelen, 0,
+				frame) == NULL) {
+		ofono_error("Unable to hex-decode the AGPS frame");
+		return;
+	}
+
+	DBG("Got POS request data: %s, %ld", frame, hexframelen);
+
+	if (hexframelen != framelen) {
+		ofono_error("hexframelen not equal to reported framelen");
+		return;
+	}
+
+	lcsframe.lcs_frame_type = frametype;
+	lcsframe.frame_length = framelen;
+	lcsframe.raw_frame = (unsigned char *)frame;
+
+	ofono_agps_lcs_frame_notify(agps, lcsframe);
+}
+
+static void inj_time_notify(GAtResult *result, gpointer user_data)
+{
+
+	struct cb_data *cbd = user_data;
+	struct agps_data *agd = cbd->user;
+	ofono_agps_inject_time_cb_t cb = cbd->cb;
+	struct ofono_lcs_radio_fn rf;
+	struct ofono_error error = { .type = OFONO_ERROR_TYPE_NO_ERROR };
+	GAtResultIter iter;
+
+	g_at_result_iter_init(&iter, result);
+
+	if (!g_at_result_iter_next(&iter, "%%XFTI:"))
+		return;
+
+	if (RADIO_ACCESS_TECHNOLOGY_GSM == rad_acc_tech) {
+
+		int fn;		/* range 0 - 2715647 (2048*26*51) */
+		int ts;		/* range 0 - 7 */
+		int tsb;	/* range 0 - 156 */
+		int ta;		/* range 0 - 63 */
+		int ba;		/* range 0 - 1023 */
+		int bc;		/* range 0 - 64 */
+
+	/*	 %XFTI:<frameNum>,<TimeSlot>,<TimeSlotBit>,<TimeAdv>,
+	*	<ChannelNum>,<ChannelId>
+	*/
+		if (!g_at_result_iter_next_number(&iter, &fn))
+			goto err;
+
+		if (!g_at_result_iter_next_number(&iter, &ts))
+			goto err;
+
+		if (!g_at_result_iter_next_number(&iter, &tsb))
+			goto err;
+
+		if (!g_at_result_iter_next_number(&iter, &ta))
+			goto err;
+
+		if (!g_at_result_iter_next_number(&iter, &ba))
+			goto err;
+
+		if (!g_at_result_iter_next_number(&iter, &bc))
+			goto err;
+
+		DBG("GSM Inject Response: fn = %d ts = %d tsb = %d ta = %d"
+				"ba = %d bc = %d ", fn, ts, tsb, ta, ba, bc);
+
+		rf.gsm_frame_number.TDMA_frame_number = fn;
+		rf.gsm_frame_number.TDMA_timeslot = ts;
+		rf.gsm_frame_number.timeslot_bit = tsb;
+		rf.gsm_frame_number.timing_advance = ta;
+		rf.gsm_frame_number.bcch_arfcn = ba;
+		rf.gsm_frame_number.bsic = bc;
+		rf.radio_access_technology = RADIO_ACCESS_TECHNOLOGY_GSM;
+
+	} else if (RADIO_ACCESS_TECHNOLOGY_UMTS == rad_acc_tech) {
+
+		int sfn;	/* range 0 - 4095 */
+		int rs;		/* enum ofono_rrc_state */
+		int rt;		/* range 0 - 32766 */
+
+		/* %XFTI:<frameNum>,<RadioState>,<TripTime> */
+		if (!g_at_result_iter_next_number(&iter, &sfn))
+			goto err;
+
+		if (!g_at_result_iter_next_number(&iter, &rs))
+			goto err;
+
+		if (!g_at_result_iter_next_number(&iter, &rt))
+			goto err;
+
+		DBG("UMTS Inject Response: sfn = %d rs = %d tt = %d",
+				sfn, rs, rt);
+
+		rf.utran_frame_number.sfn = sfn;
+		rf.utran_frame_number.rrc_state = rs;
+		rf.utran_frame_number.round_trip_time = rt;
+		rf.radio_access_technology = RADIO_ACCESS_TECHNOLOGY_UMTS;
+
+	} else
+		goto err;
+
+	cb(&error, &rf, cbd->data);
+	return;
+
+err:
+	CALLBACK_WITH_FAILURE(cb, NULL, cbd->data);
+}
+
+static int ifx_agps_probe(struct ofono_agps *agps,
+					unsigned int vendor, void *data)
+{
+	GAtChat *chat = data;
+	struct agps_data *agd = ofono_agps_get_data(agps);
+
+	agd = g_try_new0(struct agps_data, 1);
+	if (!agd)
+		return -ENOMEM;
+
+	agd->chat = g_at_chat_clone(chat);
+	agd->vendor = vendor;
+
+	ofono_agps_set_data(agps, agd);
+
+	g_at_chat_register(agd->chat, "%%XPOSR:", pos_request_notify, TRUE,
+				agps, NULL);
+
+	ofono_agps_register(agps);
+
+	return 0;
+}
+
+static void ifx_agps_remove(struct ofono_agps *agps)
+{
+	struct agps_data *agd = ofono_agps_get_data(agps);
+
+	ofono_agps_remove(agps);
+	ofono_agps_set_data(agps, NULL);
+	g_at_chat_unref(agd->chat);
+	g_free(agd);
+}
+
+
+static void ifx_agps_receive_lcs_frame_cb(gboolean ok, GAtResult *result,
+				gpointer user_data)
+{
+	struct cb_data *cbd = user_data;
+	ofono_agps_receive_lcs_frame_cb_t cb = cbd->cb;
+	struct ofono_error error;
+
+	decode_at_error(&error, g_at_result_final_response(result));
+	cb(&error, cbd->data);
+}
+
+   /*
+	* The GPS manager can enable or disable AGPS manager  to receive
+	* lcs_frames from the Mobile network. If disabled, all Assistance Data
+	* and Position Requests from Mobile Network are not signalled to ofono.
+	*/
+static void ifx_agps_receive_lcs_frames(struct ofono_agps *agps,
+			int enabled, ofono_agps_receive_lcs_frame_cb_t cb,
+			void *user_data)
+{
+	struct agps_data *data = ofono_agps_get_data(agps);
+	struct cb_data *cbd = cb_data_new(cb, user_data);
+	char *commbuf;
+	unsigned int id;
+
+	if (!cbd)
+		goto error;
+
+	commbuf = g_strdup_printf("AT%%XPOS=\"%d\"", enabled);
+
+	id = g_at_chat_send(data->chat, commbuf, none_prefix,
+				ifx_agps_receive_lcs_frame_cb, cbd, g_free);
+
+	g_free(commbuf);
+
+	if (id > 0)
+		return;
+error:
+	if (cbd)
+		g_free(cbd);
+
+	CALLBACK_WITH_FAILURE(cb, user_data);
+}
+
+static void ifx_agps_send_lcs_frame_cb(gboolean ok, GAtResult *result,
+				gpointer user_data)
+{
+	struct cb_data *cbd = user_data;
+	ofono_agps_send_lcs_frame_cb_t cb = cbd->cb;
+	struct ofono_error error;
+
+	decode_at_error(&error, g_at_result_final_response(result));
+	cb(&error, cbd->data);
+}
+
+#define BUF_LEN 128
+
+	/* Assistance Data and Position Requests from the Mobile Network are
+	 * signalled via the ofono_agps_lcs_frame_notify function and the
+	 * oFono core to an external GPS manager. This GPS manager can reply
+	 * to Position Requests with one or more Position Responses which
+	 * are then send back to the modem via the send_lcs_frame function.
+	 */
+static void ifx_agps_send_lcs_frame(struct ofono_agps *agps,
+				struct ofono_lcs_frame *frame,
+				ofono_agps_send_lcs_frame_cb_t cb,
+				void *user_data)
+{
+	struct agps_data *data = ofono_agps_get_data(agps);
+	struct cb_data *cbd = cb_data_new(cb, user_data);
+	char buf[BUF_LEN * 2 + 1];
+	char *commbuf;
+	unsigned int id;
+	int buflen;
+
+	if (!cbd)
+		goto error;
+
+	if (!frame->frame_length) {
+		ofono_error("ifx_agps_send_lcs_frame: Frame length Invalid");
+		goto error;
+	}
+
+	if (frame->frame_length > BUF_LEN) {
+		ofono_error("ifx_agps_send_lcs_frame: Frame length too long!");
+		goto error;
+	}
+
+	encode_hex_own_buf(frame->raw_frame, frame->frame_length, 0, buf);
+	buflen = strlen(buf);
+	DBG("Encoded AGPS Frame = %s %d", buf, buflen);
+
+	commbuf = g_strdup_printf("AT%%XPOSR=%d,%d,\"%s\"",
+			frame->lcs_frame_type, buflen, buf);
+
+	id = g_at_chat_send(data->chat, commbuf, none_prefix,
+				ifx_agps_send_lcs_frame_cb, cbd, g_free);
+
+	g_free(commbuf);
+
+	if (id > 0)
+		return;
+error:
+	if (cbd)
+		g_free(cbd);
+
+	CALLBACK_WITH_FAILURE(cb, user_data);
+}
+
+static void ifx_agps_inject_time_cb(gboolean ok, GAtResult *result,
+				gpointer user_data)
+{
+	struct cb_data *cbd = user_data;
+	struct agps_data *data = cbd->user;
+	ofono_agps_inject_time_cb_t cb = cbd->cb;
+	struct ofono_error error;
+
+	decode_at_error(&error, g_at_result_final_response(result));
+
+	if (!ok)
+		goto err;
+
+	g_at_chat_register(agd->chat, "%%XFTI:",
+					inj_time_notify, FALSE,
+					data, g_free);
+	return;
+
+err:
+	cb(&error, NULL, cbd->data);
+	g_free(cbd);
+}
+
+	/* The GPS manager can ask the modem to generate a HW pulse (time
+	 * stamp) with a defined length and the modem replies indicates when
+	 * it generates the pulse. But as the modem has no precise idae of
+	 * Universal Time, it indicates at which radio frame number itgc
+	 * generated the pulse. The GPS manager which knows the link between
+	 * Universal Time and the Radio Frame number knows very precisely at
+	 * what time the pulse was generated and its duration.
+	 *
+	 * Timing accuracy is typically a few microseconds.
+	 */
+static void ifx_agps_inject_time(struct ofono_agps *agps,
+			int radio_access_technology,/* enum access_technology */
+			int pulse_length,/* duration of pulse in radio slots */
+			ofono_agps_inject_time_cb_t cb, void *user_data)
+{
+	struct agps_data *data = ofono_agps_get_data(agps);
+	struct cb_data *cbd = cb_data_new(cb, user_data);
+	char *buf;
+	unsigned int id;
+
+	if (!cbd)
+		goto error;
+
+	cbd->user = data;
+
+	if (radio_access_technology == RADIO_ACCESS_TECHNOLOGY_GSM) {
+		data->rad_acc_tech = radio_access_technology;
+		buf = g_strdup_printf("AT%%XFTI=\"%s%d\"", "GSM",
+						pulse_length);
+
+	} else if (radio_access_technology == RADIO_ACCESS_TECHNOLOGY_UMTS) {
+			data->rad_acc_tech = radio_access_technology;
+			buf = g_strdup_printf("AT%%XFTI=\"%s%d\"", "UMTS",
+						pulse_length);
+	} else
+		goto error;
+
+	id = g_at_chat_send(data->chat, buf, none_prefix,
+		    ifx_agps_inject_time_cb, cbd, g_free);
+
+	g_free(buf);
+
+	if (id > 0)
+		return;
+
+error:
+	if (cbd)
+		g_free(cbd);
+
+	CALLBACK_WITH_FAILURE(cb, NULL, user_data);
+}
+
+static struct ofono_agps_driver driver = {
+	.name				= "ifxmodem",
+	.probe				= ifx_agps_probe,
+	.remove				= ifx_agps_remove,
+	.receive_lcs_frames		= ifx_agps_receive_lcs_frames,
+	.send_lcs_frame			= ifx_agps_send_lcs_frame,
+	.inject_time			= ifx_agps_inject_time
+};
+
+void ifx_agps_init()
+{
+	ofono_agps_driver_register(&driver);
+}
+
+void ifx_agps_exit()
+{
+	ofono_agps_driver_unregister(&driver);
+}
+
-- 
1.7.0.4

[PATCH] todo: ifxmodem apgs support

[Robertino Benis]

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

---
 TODO |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/TODO b/TODO
index a5196f7..7ee7920 100644
--- a/TODO
+++ b/TODO
@@ -484,3 +484,8 @@ Miscellaneous
 
   Priority: Low
   Complexity: C4
+
+- Modem support:  adding support for agps in Infenion modem driver.
+
+  Priority: High
+  Complexity: C3
-- 
1.7.0.4

Re: [PATCH] todo: ifxmodem apgs support

[Denis Kenzior]

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

Hi Robertino,

On 11/05/2010 12:55 PM, Robertino Benis wrote:
> ---
>  TODO |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/TODO b/TODO
> index a5196f7..7ee7920 100644
> --- a/TODO
> +++ b/TODO
> @@ -484,3 +484,8 @@ Miscellaneous
>  
>    Priority: Low
>    Complexity: C4
> +
> +- Modem support:  adding support for agps in Infenion modem driver.
> +
> +  Priority: High
> +  Complexity: C3

Please do not invent new complexities.  The ones at listed at the top of
the TODO file are the only ones you should be using.

Regards,
-Denis

Re: [PATCH] todo: ifxmodem apgs support

[Marcel Holtmann]

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

Hi Robertino,

>  TODO |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/TODO b/TODO
> index a5196f7..7ee7920 100644
> --- a/TODO
> +++ b/TODO
> @@ -484,3 +484,8 @@ Miscellaneous
>  
>    Priority: Low
>    Complexity: C4
> +
> +- Modem support:  adding support for agps in Infenion modem driver.
> +
> +  Priority: High
> +  Complexity: C3

I was expecting to have a section for Modem support. So something like
this:

Modem support
=============

- Infineon modem: Add support ...

Please run your patches through a spellchecker. It is Infineon and
either Assisted GPS or aGPS. And sentences should start with a capital
letter. There are still a few tasks in the TODO. So you have some
examples on how we expect the format.

The key point is consistency. Be it in the documentation, the TODO file
or the source code itself.

Please be also a bit more descriptive with the TODO entry so that others
have an idea what it entails.

Also please don't invent your own complexity types. The TODO file has an
introduction section that describes it pretty clearly.

I say this complexity task is clearly only a C1.

For the priority, this is a general overall oFono priority scale. So all
modem support items should be a Low. It has nothing to do with product
schedules or anything alike.

And please also add an Owner for the entry. That would be you in this
case.

Regards

Marcel