I've a weird issue. I don't know what's going on...
I try to send SMS with a T-mobile SIM card in Germany. The SIM card
doesn't require PIN code. I can get the GSM network and I don't use GPRS.
Sometimes, I can send SMS, and another time, It fails. More precisely,
when I've got an ofono which can send SMS, I can send all the SMS I
want, it works. But if I restart ofono, either it works or not.
I added OFONO_AT_DEBUG=1 in my env, and tried to find some troubles in
the logs. I've got some errors but I don't think they are criticals and
anyway, they appeared when SMS working too :
Querying remaining pin retries failed
I can see some differences in time for "AT+CRSM" commands but, they are
in the same order. And, after many tests, I don't think the problem is here.
And, when the SMS send fails, the modem tells me :
CMS ERROR: Unknown error\r\n
Not very useful....
Also, at same time, I tested in Switzerland with SwissCom and I don't
1 month ago, it worked well. I don't get it...
I've got a "SIMCOM_SIM5216E" modem. Using the driver g1 or the new
simcom driver I developped, with ofono 1.6 or 1.12, it's the same behavior.
Maybe have you already see this kind of things ? My brain is lost.
| Viallard Anthony | Syscom Instruments SA | Embedded System |
| +41 024 455 24 82 | Rue de l'industrie 21 | Software Designer |
| ~~~~~~~~~~~~~~~~~ | 1450 Sainte-Croix | ~~~~~~~~~~~~~~~~~ |
From: Timo Mueller <timo.mueller(a)bmw-carit.de>
this is the same as v3 with the changes suggested by Denis.
* Retry CLCC request on outgoing callsetup is now a N9 specific quirk
* Third patch has been split up according to HACKING rules
The idea of setting the vendor during runtime was to use the "Model"
string of the ofono_modem (analogous to what the wavecom modem
does). But as the Nokia N9 does not support the device ID profile and
the BT address has an OUI from Texas Instruments, I wasn't able to
determine that the hfpmodem is a Nokia N9. Maybe you have some
ideas on how this can be determined properly?
As currently there's no functionality to detect the vendor of a
hfpmodem on runtime the clcc quirk can be enabled for all vendors by
patching the needs_callheld_clcc_quirk method.
Timo Mueller (8):
hfpmodem: Add modem vendor stub
hfpmodem: Add vendor header to makefile
hfpmodem: Add vendor information to voicecall data
hfp_hf_bluez4: Pass vendor on voicecall creation
hfp_hf_bluez5: Pass vendor on voicecall creation
hfpmodem: Add method to query if CLCC quirks are needed
hfpmodem: Add N9 quirk for outgoing callsetup
hfpmodem: Add N9 quirk for callheld=<2 or 3>
Makefile.am | 3 +-
drivers/hfpmodem/vendor.h | 26 +++++++++++++++
drivers/hfpmodem/voicecall.c | 77 +++++++++++++++++++++++++++++++++++++++++---
plugins/hfp_hf_bluez4.c | 4 ++-
plugins/hfp_hf_bluez5.c | 5 ++-
5 files changed, 107 insertions(+), 8 deletions(-)
create mode 100644 drivers/hfpmodem/vendor.h
first of all thanks 4 your reply.
> 2013/3/26 Denis Kenzior <denkenz(a)gmail.com>
>> Hi Marco,
>> On 03/26/2013 04:07 AM, Freedreamer wrote:
>>> Hi Everybody,
>>> I'm developing a driver for an embedded system which uses a sagem HiloNC
>>> v2 and I really should need your help. It's my will to commit everything
>>> when shall be ready and working.
>>> First of all I will tell you what i did..I created a plugin sagem.c
>>> ,added a new Vendor , modified makefile & other stuff and seems to work
>>> properly. I started from calypso driver 'cause the modem is based on a
>>> Uart and I needed the MUX over that.
>>> With a very raw/dirty code I was able to use PPP/SMS/net service over
>>> virtual com.. Very good work dude! :)
>>> Now I would like to clean up my code and get a better understanding of
>>> the stack. Unfortunately I saw that functions/modules are not always
>>> commented so I have to ask u a lot of questions (maybe also trivial):
>>> 1) AT cmds sent with "g_at_chat_send" are always async , is that right ?
>>> Is there any chance to get them sync ?
>> There is not, we do not want to encourage any sort of blocking behavior
>> in the daemon. Remember there are potentially multiple modems being
>> operated on and we do not use threads.
Ok get it, i thought there were pthreads somewhere.
>> 2) in enable fnc the modem is powered but The sim is not ready so
>>> sometimes It hangs up...Do I have to to poll the sim status until is
>>> ready , or the driver will do that by itself ?
>> oFono never polls for anything. It is the driver's responsibility to do
>> that in the best possible way for the hardware. Also, powering on the
>> modem is separate from the sim being ready. The general flow is this:
>> -Enable modem
>> -Wait for the modem to power on and use ofono_modem_set_powered when that
>> happens successfully / fails.
>> - Figure out if the SIM is inserted and signal using
>> ofono_sim_inserted_notify. Do this step only once the SIM is ready to be
>> queried for its PIN status and perform any I/O on SIM files that are always
>> accessible (e.g. ICCID)
Ok. If Sim not "ready" , sending a signal prematurely could stuck anyhow
the stack ? 'cause it should explain a lot of thing..
>> 3) could u explain me what should I really do in virtual fnc set_online
>>> / post_online ? i tried to stub them but they have not never been
>> oFono has 3 basic states:
>> - Off
>> - Radio Off, Sim On
>> - Radio On, Sim On
>> set_online turns radio on / off
>> post_online populates the atoms that are available in radio 'On' state.
This is what i thought but I do not understand why I don't see the trace
log I put inside them...usually are called before pre_sim fn? are related
to any signal i have to manage/post ?
>> 4) unfortunately this modem has a SIM detection URC but it reset itself
>>> every time the status changes... so i should call the disable function
>>> and the enable again in order to have the MUX working... how can i do
>> I'm not following. Care to elaborate?
I've managing vendor URC for sim detection right now but i have
problems.For instance if I remove it when ofonod is ready the Hilonc sends
an URC to notify sim status changed but after that it reboots itself(2 sec
later)... what i did is to notify the stack that the SIM has been removed
and modem is powered off . I thought that after calling set_powered fnc the
stack should have called my driver virtual disable function in order to
properly close the MUX .. but it's not..
>> 5) I created and started the MUX as the first thing in enable fnc but is
>>> that right ? sometimes seems that the modem hangs up if just powered up.
>>> Put a delay but don't like it very much as a solution...moreover when I
>>> power up the modem all the URC have been lost 'cause the MUX has not
>>> been created yet..
>> That is what we do for most devices with a MUX, put it into MUX state
>> right away after basic initialization. The devices we have can be queried
>> for their state in addition to URCs, so it works out very well.
right now i've been using custom URC in the first power up phase to
understand modem status. I manually set them but theoretically I should
check the values saved on the modem every power cycle. What I was thinking
was to test every time the values saved and enabling them if they were not
.After that I should call an AT+cfun=1,1 in order to reset the modem and
force it to send me again the needed URCs . What do u think ?
From: Forest Bond <forest.bond(a)rapidrollout.com>
This can be set by the modem driver to indicate that the device is
always in the online state when it is enabled. This is useful for
modem drivers that handle both CDMA and GSM devices.
src/modem.c | 20 ++++++++++++++------
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/src/modem.c b/src/modem.c
index 0f12f5a..49913a9 100644
@@ -595,6 +595,17 @@ static gboolean modem_has_sim(struct ofono_modem *modem)
+static gboolean modem_is_always_online(struct ofono_modem *modem)
+ if (modem->driver->set_online == NULL)
+ return TRUE;
+ if (ofono_modem_get_boolean(modem, "AlwaysOnline") == TRUE)
+ return TRUE;
+ return FALSE;
static void common_online_cb(const struct ofono_error *error, void *data)
struct ofono_modem *modem = data;
@@ -702,11 +713,8 @@ static void sim_state_watch(enum ofono_sim_state new_state, void *user)
- * If we don't have the set_online method, also proceed
- * straight to the online state
- if (modem->driver->set_online == NULL)
+ /* Modem is always online, proceed to online state. */
+ if (modem_is_always_online(modem) == TRUE)
if (modem->online == TRUE)
@@ -745,7 +753,7 @@ static DBusMessage *set_property_online(struct ofono_modem *modem,
if (ofono_modem_get_emergency_mode(modem) == TRUE)
- if (driver->set_online == NULL)
+ if (modem_is_always_online(modem) == TRUE)
modem->pending = dbus_message_ref(msg);
This is an handsfree audio agent written in C.
I could test CVSD and MSBC (patch v6) with it.
fixes an fd leak
improves mSBC playback which could be choppy
add an option for killing an agent that connects
supports 16 bits voice settings for SCO_OPTIONS (requires kernel patch v4).
fixes a bug by which only noise was sent to remote device.
handles defered socket with following code instead of using a dummy variable:
if (recv(thread->fd, NULL, 0, 0) < 0)
Frédéric Dalleau (9):
handsfree-audio: Initial DBUS code
handsfree-audio: Build handsfree-audio command line tool
handsfree-audio: Add Alsa dependancy
handsfree-audio: Link tool with Alsa
handsfree-audio: Implement alsa playback
handsfree-audio: Add SBC dependency
handsfree-audio: Link tool with SBC library
handsfree-audio: mSBC support
handsfree-audio: Add an option to kill incoming connections
Makefile.am | 6 +-
configure.ac | 10 +
tools/handsfree-audio.c | 979 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 994 insertions(+), 1 deletion(-)
create mode 100644 tools/handsfree-audio.c