| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
git-svn-id: http://svn.openmoko.org/trunk/src/target/gsm@3657 99fdad57-331a-0410-800a-d7fa5415bdb3
|
| |
|
|
| |
git-svn-id: http://svn.openmoko.org/trunk/src/target/gsm@3498 99fdad57-331a-0410-800a-d7fa5415bdb3
|
| |
|
|
| |
git-svn-id: http://svn.openmoko.org/trunk/src/target/gsm@3267 99fdad57-331a-0410-800a-d7fa5415bdb3
|
| |
|
|
| |
git-svn-id: http://svn.openmoko.org/trunk/src/target/gsm@3265 99fdad57-331a-0410-800a-d7fa5415bdb3
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From: Erin Yueh <erin_yueh@openmoko.com>
Subject: [PATCH] SMS status report
I made a patch for SMS status report. It can change SMS-Submit messages
and ask for a status report. When the destination address receives our
message, the service center will send a SMS-STATUS-REPORT to us. We can
tell what messages we sent by TP-MR (message reference number) value and
can know the sending result by TP-ST (Status) value from status report
messages.
git-svn-id: http://svn.openmoko.org/trunk/src/target/gsm@3200 99fdad57-331a-0410-800a-d7fa5415bdb3
|
| |
|
|
| |
git-svn-id: http://svn.openmoko.org/trunk/src/target/gsm@2733 99fdad57-331a-0410-800a-d7fa5415bdb3
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Date: Fri, 27 Jul 2007 19:39:15 +0200
Subject: [PATCH] Cell Broadcast message decoding and presentation in libgsmd-tool.
This time Cell Broadcast is tested to work, I should have made tests earlier.
Now I'm correctly getting a CB message with the human readable name of the city
and district when I'm connecting. In the previous patches the CB PDU was not
being decoded at all.
git-svn-id: http://svn.openmoko.org/trunk/src/target/gsm@2723 99fdad57-331a-0410-800a-d7fa5415bdb3
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Date: Fri, 27 Jul 2007 14:29:44 +0200
Subject: [PATCH] Multiline unsolicited responses parsing.
+CMT, +CBM and +CDS responses two lines long in PDU mode and the parser has
problem with them. As it was mentioned earlier there's no way for the parser
to know if a new line is part of the most recent command response or
unsolicited response, or a completely new unsolicited response, without looking
at the contents of the first line. My idea is that the parser for the
particular response decides if the response is too short, and returns -EAGAIN
in which case the AT parser will append the following line to the response and
resubmit it to the response parser. The disadvantage is that the generic
parser gets one more special case to remember about, but it works quite well,
hopefully there are no more cases where we will need to modify the parser. (We
may need to use a separate multiline buffer (like the current mlbuf variable)
to account for situations when a multiline unsolicited response comes in the
middle of receiving a different response, which is also possible. Also, mlbuf
should probably be moved into the parser state struct instead of being a
global).
This patch also moves initialisation of SMS options to after we are registered
to the network, so that we don't get errors from the modem. Perhaps we want to
have a dynamic list of callbacks to call on succesfull registration.
Among other changes also prevents setting dev_state.on if the radio powering-on
fails.
---
include/gsmd/event.h | 8 +++++
include/gsmd/sms.h | 1 +
src/gsmd/atcmd.c | 26 +++++++++++++++++
src/gsmd/sms_cb.c | 73 ++++++++++++++++++++++++------------------------
src/gsmd/unsolicited.c | 8 +++++
src/gsmd/usock.c | 21 ++++++++++++--
src/util/event.c | 10 +++----
7 files changed, 103 insertions(+), 44 deletions(-)
git-svn-id: http://svn.openmoko.org/trunk/src/target/gsm@2722 99fdad57-331a-0410-800a-d7fa5415bdb3
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From: Andrzej Zaborowski <balrog@zabor.org>
Date: Thu, 12 Jul 2007 14:26:46 +0200
Subject: [PATCH] Incoming SMS events
This is a proposed patch to emit a gsmd event when a new SMS arrives, also
modifies libgsmd-tool to display the notification. It makes sms_cb.c compile
but only really implements the bits necessary to make it build and for the
notifications to work. I chose AT+CNMI mode 1 (i.e. store messages in memory
and report the location through +CMTI, rather than print the message right away
through +CMT) because the parser doesn't support multiline unsolicited
responses - in fact it can't support those because in a situation when a normal
command is executing and an unsolicited response comes in (which is the case
when sending a message to yourself) it is impossible for the parser to
distinguish whether the line after the unsolicited response is part of that
response or part of the command's response.
git-svn-id: http://svn.openmoko.org/trunk/src/target/gsm@2711 99fdad57-331a-0410-800a-d7fa5415bdb3
|
| |
|
|
|
|
|
| |
- Add some 'get operator name' skeleton
git-svn-id: http://svn.openmoko.org/trunk/src/target/gsm@546 99fdad57-331a-0410-800a-d7fa5415bdb3
|
| |
|
|
|
|
|
|
|
|
|
| |
- introduce new ucmd_alloc() function
- add DTMF support to gsmd, libgsmd and gsmd-util
- fix crash of libgsmd when events don't have handlers registered
- implement call progress for TI modem
- split modem init string in separate commands to fit our parser
git-svn-id: http://svn.openmoko.org/trunk/src/target/gsm@544 99fdad57-331a-0410-800a-d7fa5415bdb3
|
| |
|
|
|
|
|
|
| |
- finish vendor plugin support
- add call progress indicator and signal quality unsolicited support to vendor_ti.c
git-svn-id: http://svn.openmoko.org/trunk/src/target/gsm@120 99fdad57-331a-0410-800a-d7fa5415bdb3
|
| |
|
|
| |
git-svn-id: http://svn.openmoko.org/trunk/src/target/gsm@115 99fdad57-331a-0410-800a-d7fa5415bdb3
|
|
|
git-svn-id: http://svn.openmoko.org/trunk/src/target/gsm@114 99fdad57-331a-0410-800a-d7fa5415bdb3
|
