[RFC] HFP support into oFono and BlueZ
by Gustavo F. Padovan
Hi,
These patches implement the new API for the Audio Gateway in BlueZ. It
follows the last version of the HandsfreeGateway and HandsfreeAgent
Intefaces API.
The first two patches is for BlueZ and the other for oFono. You can
test it with using enable-modem and test-voicecall scripts into the
test dir of oFono.
Feel free to test it and send me your comments. We have some bugs yet.
The audio part is not working yet. We are going to work on pulseaudio
this week to get this done soon.
Regards,
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
9 years, 11 months
CDMA SMS Handling
by Rajesh.Nagaiah＠elektrobit.com
Hi,
There was a discussion about the CDMA SMS handling and CDMA PDUs in the
IRC channel couple of days before. I would like to highlight the
differences between CDMA and GSM PDU and how we should proceed with this
from my understanding. Let me know your opinion.
Even though oFono supports +CMT and +CMTI, if we feed the incoming CDMA
PDUs to the SMS core it wont get decoded correctly, as there is
substantial differences between the GSM and CDMA SMS PDUs as described
in 3GPP2 specification C.S0015-B Short Message Service (SMS) for
Wideband Spread Spectrum Systems
For eg, the incoming PDU example that was mentioned in the IRC
discussion
+CMT: , 40,
00000210020207028CE95DCC65800601FC08150003168D30010610241830608003061010
04044847
40 - Length of the PDU in bytes
00 - Message Type ( 00 - SMS Point-to-Point)
00 - TeleService Identifier Tag (SMS Parameter Indentifier)
02 - TeleService Identifier Length (SMS Parameter Length)
10 - TeleService Identifier Value - First 8 bits
02 - TeleService Identifier Value - Second 8 bits
TeleService Identifier - 0x1002 - CDMA Messaging Teleservice
(CMT-95)
02 - Originating Address Tag
07 - Originating Address Length
02 - Originating Address 1st 8 Bits
8C - Originating Address 2nd 8 Bits
E9 - Originating Address 3rd 8 Bits
5D - Originating Address 4th 8 Bits
CC - Originating Address 5th 8 Bits
65 - Originating Address 6th 8 Bits
80 - Originating Address 7th 8 Bits
Digit Mode - 1 Bit
Number Mode - 1 Bit
Number Type - 0 or 3 bits
Number Plan - 0 or 4 bits
Number Fields - 8 Bits
Number Field occurrence of CHARi
CHARi - 4 or 8 bits ( 4 - in case of DTMF encoding, 8 - incase
of ASCII encoding)
Reserved - 0-7 bits
Lets take the 1st and 2nd 8 bits
02 - 0000 0010 ( Digit Mode bit - 0, Number Mode bit - 0)
8C - 1000 1100
As Digit mode bit is set to 0, Number Plan and Number Type is void
(0 bits) in this case.
So the remaining 6 bits of 1st 8bits and the first 2 bits of 2nd
8bit is Number fields
Number fields - 00 0010 10 - 0000 1010 - 0x0A (10 digits)
As Digit mode bit is set to 0, each address digit here is
represented as 4bit DTMF digit
0x8C 0xE9 0x5D 0xCC 0x65 0X80
1000 1100 1110 1001 0101 1101 1100 1100 0110 0101 1000 0000
10 0011 0011 1010 0101 0111 0111 0011 0001 1001 0110 0000 00
3 3 0 5 7 7 3 1 9 6 Last 6 bits
are reserved bits
Originating Address - 3305773196
06 - Bearer Reply Option Tag
01 - Bearer Reply Option Length
FC - First 6 bits Reply Sequence number and last 2 bits reserved set to
0
1111 1100 - 111111 REPLY_SEQ
00 Reserved
08 - Bearer Data Tag
15 - Bearer Data Length
00 - Message Indentifier Tag ( Bearer Data Sub parameter )
03 - Message Indentifier Length
16 - Message Type 4 bits Message Id 4 Bits
8D - Message Id 8 Bits
30 - Message Id 4 Bits, UDH Header indicator 1 Bit, Reserved 3 Bits
How Message Identifier value 16 8D 30 was formed ?
Message type ( 4 bits ) - 1( 0001 - Deliver)
Message Identifier ( 16 bits ) - 26835( 0x68D3)
Header Indicator (1 bit) - 0 (UDH not present in User Data
Subparameter)
Reserved ( 3bits) - 0 (000)
01 - User Data Tag ( Bearer Data Sub parameter )
06 - User Data Length
10 - Message Encoding 5 bits ( 0001 0000 ( 00010 = 2 -> 7-bit ASCII )) &
Number Fields 3 bits ( 000)
24 - Number Fields 5 Bits + User char field 1's 3 bits ( 0010 0100 )
18 - User char field 1's remaining 5 bits + User char field 2's 3 bits
(0001 1000)
30 - User char field 2's remaining 5 bits + User char field 3's 3 bits
(0011 0000)
60 - User char field 3's remaining 5 bits + User char field 4's 3 bits
(0110 0000)
80 - User char field 4's remaining 5 bits + Reserved 3 Bits (1000 0000)
Number Fields: 000 00100 - 04 (4 Character fields)
User Char [1] - 100 00011 - 0x83
User Char [2] - 000 00110 - 0x06
User Char [3] - 000 01100 - 0x0C
User Char [4] - 000 10000 - 0x10
Hex 0x83 0x06 0x0C 0x10
Octets 1000 0011 0000 0110 0000 1100 0001 0000
Septets 1000 001 10000 01 100000 1 1000001
Character A(0x41) A(0x41) A(0x41) A(0x41)
Message content: AAAA
Message Encoding - 2 (00010 - 5 bits)
Number Fields - 4 (0000 0100 - 8 bits)
User characters - 0x83 0x06 0x0C 0x10 ( 8 bits each)
00010 0000 0100 1000 0011 0000 0110 0000 1100 0001 0000
0001 0000 - 0x10
0010 0100 - 0x24
0001 1000 - 0x18
0011 0000 - 0x30
0110 0000 - 0x60
1000 0000 - 0x80 (Last 3 bits set to 0's(reserved bit) to complete
the octets)
03 - Message Center Time Stamp Tag ( Bearer Data Sub parameter )
06 - Message Center Time Stamp Length
all date and time fields contain two 4-bit BCD numbers giving the
decimal value of the field.
10 - Year (2010)
10 - Month (10 - October)
04 - Day
04 - Hour
48 - Minutes
47 - Seconds
Time Stamp 04:48:47 04/10/2010
Decoded Information:
Message Type: Deliver (Incoming Message)
Teleservice: CMT-95
Message Identifier: 26835
Originating Address: 3305773196
Message content: AAAA
Message Center Time Stamp: 04:48:47 04/10/2010
As from the above decoding example we can see there is substantial
differences between the GSM and CDMA SMS specifications and so the SMS
atom needs many additions and needs to be heavily modified to support
also CDMA SMS handling. Currently the oFono sms file unit handles the
common and the GSM technology aspects of the SMS stack along with the
smsutils. The SMS atom has the GSM specific members, segmentation and
queuing logic. The smsutils mainly takes care of encoding/decoding of
the PDUs, which is GSM specific. As the segmentation and queuing logic
and the interface is common for both GSM and CDMA, we could reuse this
common code and add the CDMA handling into it and create a new
cdmasmsutils unit to support the CDMA SMS specifics, much like the
smsutils does already for GSM.
BR,
Rajesh
10 years, 1 month
Enabling/disabling the GPS part of a Huawei EM770W
by Florian Mayer (Mayer Electronics)
Hello folks,
is it possible to enable / disable the GPS part of a Huawei EM770W 3G
modem through a DBUS command? It is done with the command AT^WPDGP and
AT^WPEND on the modem (tested it on PCUI port). Or is it possible to
send generic AT commands through DBUS?
Regards
Florian Mayer
11 years, 4 months
Add Barred Dialing Support
by Jeevaka Badrappan
Hi,
This patch adds the barred dialing support. If Barred Dialing service is
enabled, then oFono will go into emergency mode. Patch has been tested with the phonesim.
Regards,
jeevaka
11 years, 8 months
RE: [RFC] AGPS Support
by Sjur BRENDELAND
Hi Bastian,
> Bastian, Waldo wrote:
>
> Please find attached a proposal for both a DBUS and Modem API for AGPS
> support. There are some minor changes compared to the proposal from
> May 14, 2010.
>
...
> 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"
....
> 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;
> };
The 27.007 Spec specifies positioning request/responses for AT where
Positioning data are coded in XML data structures.
I think the oFono interface should not use binary data, but rather be aligned with 27.007
and present decoded data as DBUS typed signals and methods with the same information
content as specified in the XML data for AT+CPOS, AT+CPOSR.
In this way the vanilla AT driver could handle the CPOS, CPOR AT-commands
and code/decode between XML and explicit data structures, which in turn
oFono Core could code/decode as DBUS data types.
Regards,
Sjur Brændeland
11 years, 8 months
Need clarification in querying the pin status
by mamata l
Hi,
I need clarification for querying the pin status when enabling/disabling pin
fails and the maximum number of attempts of wrong password are reached in
the modem.
I am trying to enable pin with the wrong password, and trying to get the pin
status. I observe that the maximum number of attempts for wrong password
have reached and the modem has reached to puk state and also the modem
de-registers from network.
In this case when i tried to get the properties using "GetProperties", the
properties from the ofono core are received without querying the information
from the modem. The "PinRequired" received is "none" .
Could you please provide some info how to get the sim pin state when sim is
blocked on puk at run-time and is there any way for app to know the number
of attempts remaining.
Thanks,
Mamata
11 years, 8 months
[PATCH 0/4] Icon patches (rebased)
by Kristen Carlson Accardi
Rebased old patch. Found some errors that had been introduced into the
simfs code. Added file type to simutil, although I couldn't test it
on any real hardware.
Kristen Carlson Accardi (4):
simfs: cache images
sim: implement GetIcon
simfs: fix incorrect math when calculating length to copy
simutil: add file type for EFimg
src/sim.c | 187 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
src/simfs.c | 83 ++++++++++++++++++++++---
src/simfs.h | 4 +
src/simutil.c | 1 +
4 files changed, 266 insertions(+), 9 deletions(-)
--
1.7.2.1
11 years, 8 months
[PATCH 1/4] stemodem: Add rtnl header file.
by Sjur Brændeland
From: Sjur Brændeland <sjur.brandeland(a)stericsson.com>
Add new asynchronous rtnl interface for creating and deleting
CAIF Network interfaces.
Creation takes struct rtnl_req_param as input containing
ip type (v4/v6), channel id etc. The result is returned in
struct rtnl_rsp_param containing the interface name and
interface index.
---
drivers/stemodem/rtnl.h | 41 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 41 insertions(+), 0 deletions(-)
create mode 100644 drivers/stemodem/rtnl.h
diff --git a/drivers/stemodem/rtnl.h b/drivers/stemodem/rtnl.h
new file mode 100644
index 0000000..566452b
--- /dev/null
+++ b/drivers/stemodem/rtnl.h
@@ -0,0 +1,41 @@
+/*
+ *
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) 2010 ST-Ericsson AB.
+ *
+ * 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
+ *
+ */
+struct rtnl_rsp_param {
+ int result;
+ gpointer user_data;
+ char ifname[IF_NAMESIZE];
+ int ifindex;
+};
+
+struct rtnl_req_param {
+ void (*callback)(struct rtnl_rsp_param *param);
+ gpointer user_data;
+ int type;
+ int conn_id;
+ gboolean loop_enabled;
+};
+
+extern int rtnl_create_caif_interface(struct rtnl_req_param *req);
+extern int rtnl_delete_caif_interface(int ifid);
+
+extern int rtnl_init(void);
+extern void rtnl_exit(void);
+
--
1.6.3.3
11 years, 9 months
Re: [PATCH] hso: Set modem name based on udev network interface name
by "Benoît Monin"
Hi Marcel,
> De : Marcel Holtmann
>
> Hi Benoit,
>
> the friendly modem name is for devices that do have a friendly name,
> like Bluetooth headsets. Why do you wanna misuse the interface name
> here. I am a bit against this, because it leads to speculation and
> assumptions in userspace programs.
>
Maybe I should give some details of what I'm trying to achieve. The
device we're building has 2 identical modems with fixed position on
USB. We also have the possibility to drive their power supply
independently and to swap the sim cards.
I need a way to know which one is modem A and which one is modem B
and I have no easy way of knowing the modem serial number or the
sim subscriber id beforehand. With an udev rule, I can easily set
a fixed name for the network interface of each modem. But under
ofono, I can't tell which modem is which. That's why I added this
"not-so-friendly" name.
Is there a way of knowing which physical modem ofono is refering to ?
I recognize that our case may not be the most common and I understand
that you don't want to abuse the Name property. Maybe exposing the
NetworkInterface as a modem property would be ok ? or exposing
a PhysicalName ?
--
Benoît.
11 years, 9 months
