sim reader code / master branch / ...

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Mon Jan 17 21:26:01 UTC 2011


Hi all!

In order to avoid the most common problems, I propose exporting something like
a feature bitmask on the L1CTL, i.e.

* L1CTL user code (layer23) can send a L1CTL_GET_FEAT_REQ request
* laye1 in the phone sends a L1CTL_GET_FEAT_RESP with all the bits
  set to 1 for the features it supports
* L1CTL user code (layer23) can then check if all the features it needs are
  supported by the L1.  IF not, it can simply abort or print a warning to the
  user.

We can simply extend the size of the bitmask over time if we need more bits.

Obvious bits I would consider are:

- is this firmware compiled with TX support?
- does this firmware contain a SIM reader driver?
- does this firmware support BURST_IND?

Maybe we could also include a static header containing a compile timestamp or
the git date/revision that the firmware was built, as well as a name of the
board.

Now I know, nice idea, who will implement it?  I currently have othe
priorities, but if somebody lurking on this list is looking for a relatively
simple way to contribute back to the project (without knowing anything about
GSM!) this might be something useful you could do.

Thanks in advance,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)




More information about the baseband-devel mailing list