Further fixes and TI Calypso Engineering Mode

andrzej zaborowski balrogg at gmail.com
Fri Nov 2 21:20:28 CET 2007


On 01/11/2007, Tick <tick at openmoko.com> wrote:
> andrzej zaborowski 提到:
> > id 969ef13d8850eae854af9ea4c9a228c226741db2 tries harder to make sure
> > that incoming calls are rejected when the dialer requests this. I
> > don't know if this change is enough. Thomas has hit this issue
> > yesterday.
> I can reject incoming call with current gsmd on SVN,
> I am wondering what problem Thomas meet yesterday?

Ok, I found out what the issue was. It only happened once and it was
because the cell changed during the ringing, so this should be fixed
by the earlier patch.

However the real issue is that a GSM modem doesn't notify us when an
incoming call is dropped, i.e. when we should stop ringing because the
caller hanged-up before we reject or accepted the call. The only way
to tell when to stop ringing is by timing out when no further +CRING
is issued for some period. I implemented a timer that will generate a
ring-timeout even to the dialer, so that the dialer knows when to stop
ringing, see commit aba18c571f07e8467dac488a3ca0697002628d9c. It
contains other fixes too.

The dialer is free to ignore this event if it doesn't need this
notification, e.g. when it only plays a single ring sound on each
incoming call notification.

> > Unrelated to this, I added some information about some additional
> > proprietary commands that TI Calypso seems to support to the
> > http://wiki.openmoko.org/wiki/GTA01_gsm_modem page. Among them there's
> > %EM (engineering mode) which lets you do some pretty cool things with
> > the modem, for example tells you what other cells are in range
> > (besides your currently serving cell), their IDs and the strength of
> > signal coming from each of them. IIRC there was some discussion about
> > this capability earlier on this list, and there was an idea to use
> > this information (if available) for making a global map of cell IDs
> > for easy geolocation.
> Ya.. Engineer mode is some what important.
> I think this support should be done in the future. (To-Do)

Well, yes, but I don't think it should be implemented in gsmd, rather
as a separate program.


More information about the gsmd-devel mailing list