gsmd and ezx integration.

Antonio Ospite ospite at
Sat Sep 29 11:21:53 CEST 2007


we in OpenEZX are planning an ezx plugin for gsmd
but there are some points we would like to enlighten.

We need to interact with our Baseband Processor for some extra
functionality not related to GSM:
  * acquire BDADDR (printed on a banner at the first interaction)
  * enable/disable Bluetooth
  * set system time at startup (or from GSM network time)
  * get battery level
  * get powerkey event
  * shut down BP when system halts
  * set/get wake up timers
  * handle battery charging status

We need to acquire some of these infos on the first interaction with
the modem, and store them for later use.

Moreover the design of our mux_cli driver (Motorola GSM TS 07.10
Multiplex driver) uses different devices for different sets of AT
commands (the restriction stands only for unsolicited messages from the
BP and not for request and response messages); while, as far as we
know, the _current_ gsmd infrastructure expects the modem as a single

Presently there are mainly two ways we see a possible integration:

a. have our ezxd talk with mux devices and act like a proxy between
   gsmd and the modem. This way we handle all the non-GSM stuff in ezxd.
   This should be feasible right now, but it sounds clumsy and may
   introduce some latencies, I do not know if this can be a problem.

b. have gsmd talk with mux devices, and use ezxd to query non-GSM stuff
   via the libgsmd passthrough mode or rather handle everything inside
   the ezx plugin, given a practical "API". Since there are some
   infos that can't be obtained on request, we should find a way to ask
   to to gsmd some data stored by the plugin on startup. We propose to
   let a plugin define custom AT commands, so to have a very high level
   API. For instance we think to define the command AT+EBDADDR=? to
   query the bdaddr (stored by plugin on startup) as if we were
   requesting it to the modem.

Use AT commands implemented at gsmd level seems to us the most clean,
high level, and _neutral_ interface.

The point is: to do b. we would need some modifications in gsmd, maybe
some of them are already planned, like the support of different devices
for different services. Harald does know the EZX infrastructure and can
comment on that.

So, please reply to this mail to comment, complete or correct what I
wrote :)


  Web site:
Public key:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :

More information about the gsmd-devel mailing list