From laforge at gnumonks.org  Fri Feb 19 19:02:04 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 19 Feb 2010 20:02:04 +0100
Subject: Announcing project OsmocomBB: Open Source GSM Stack
Message-ID: <20100219190204.GD14552@prithivi.gnumonks.org>

Good news, everyone [tm]!

I am hereby publicly announcing project OsmocomBB:  A Free and Open Source
software project to create a Free Software GSM baseband firmware.

The baseband chipset is the part of a mobile phone that actuall communicates
directly with the GSM network.  It typically includes a DSP and a
microprocessor running some RTOS, drivers for the baseband chipset,
the GSM protocol stack and some kind of user interface.

GSM has been deployed first 19 years ago.  Despite billions of phones deployed
world wide, all of them run a proprietary baseband firmware, consisting of
proprietary drivers, RTOS and GSM protocol stack.

OsmocomBB has set out to change this.  We do not want our phones to be
a black box connected 24/7 to a public network.  We want to decide what
kind of data our phone reveals about us or not.

The authors behind the project have already spent the last 15 months
implementing an Open Source GSM network side protocol implementation called
OpenBSC.  In January 2010, they decided to go after the phone side protocol
stack - which turned into OsmocomBB.

=> What is the project status?

Right now we are at a state where we have full control over the baseband
hardware, including the DSP and ARM cores, the analog baseband chip,
the RF transceiver, keypad, LCD display and other components.

We can scan the GSM band for cells, perform FCCH detection, run automatic
gain control to synchronize to the cells carrier, detect the SCH to get
BSIC and GSM frame number, as well as dump the BCCH and CCCH of the cell.

=> What does Osmocom mean? 

Open Source MObile COMmunications.  It is meant as an umbrella name for
various FOSS projects related to communications, including OsmocomBB but
also including sister projects like OpenBSC.

=> Can I make phone calls yet?

No. We are currently in Rx (receive) only mode, and have no Layer2 or Layer3
implementation yet.  However, the difficult parts of driving the GMS hardware
and implementing a minimal Layer1 are behind us, so we are confident to proceed
to actual phone calls during the months to come.

=> Where can I get the source?

The git repository is at git://git.osmocom.org/osmocom-bb.git
The mailing lists are at http://lists.osmocom.org/
The project homepage including wiki is at http://bb.osmocom.org/

=> What phones are supported?

We are implementing OsmocomBB as hardware-independent as possible.  At the
moment, we only have drivers for the Ti Calypso Digital Baseband chip.
Our main target are the following Motorola-branded phones (made by Compal):
C115/116/117/118/119/120/121/122/123/139/140/155

Adding support for other Calypso-based phones should be relatively easy,
but porting it to a different baseband chip is a lot of work, especially
without access to good documentation.

=> How can you help?

We need developers who have experience in microcontroller development working
on an ARM7TDMI core.  You do not need to know anything about GSM in order to
help us with tasks such as the UI, driving the battery charging controller,
etc.  If you want to join, get yourself a phone, serial cable, join the
developer mailing list and introduce yourself!

Happy Hacking
	Harald Welte

-- 
- 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)



From chrisfriedt at gmail.com  Fri Feb 19 19:42:15 2010
From: chrisfriedt at gmail.com (Christopher Friedt)
Date: Fri, 19 Feb 2010 20:42:15 +0100
Subject: good work!
Message-ID: <3ea34a001002191142s187e958u4ed5dddfd3fa02a1@mail.gmail.com>

Congratulations to all of the developers that worked on this project -
you must be very proud at this point!

At some point, when I have some free time, I hope to contribute to the
codebase (although I don't have a motorola c123, I'm hacking on some
other handhelds currently).

C



From laforge at gnumonks.org  Fri Feb 19 22:10:05 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 19 Feb 2010 23:10:05 +0100
Subject: Layer2 Wireshark integration
Message-ID: <20100219221005.GB16218@prithivi.gnumonks.org>

Hi!

I've recycled the old GSMTAP wireshark plugin that I originally wrote
for project airprobe.

Using this patch (now in our git tree as well, applies against current
wireshark svn) and the layer2 host program as well as the l1test.bin target
program, you can watch BCCH messages in realtime.

The architecture is like this:

* DSP forwards decoded normal burst data to layer1/sync.c
* layer1/sync.c generates L1A_L23 protocol message and sends it
  via the SERCOMM HDLC layer over RS232
* "osmocon" receives the HDLC frame and relays it to the Unix domain
  socket
* "layer2" receives the L1A_L23 protocol message on the Unix domain
  socket, adds a GSMTAP header and sends it to the GSMTAP UDP port on
  localhost
* wireshark captures on the 'lo' interface and calls the GSMTAP dissector
  plugin for everything received on the GSMTAP UDP port number.

Have fun!
-- 
- 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)



From mhtajik at gmail.com  Fri Feb 19 22:49:01 2010
From: mhtajik at gmail.com (Mohammad Hosein)
Date: Sat, 20 Feb 2010 02:19:01 +0330
Subject: newer more expensive phones
Message-ID: <26f61db51002191449j5a77d70do533b43bdead81759@mail.gmail.com>

i've got a couple of newer Motorola phones like the milestone also some new
HTC phones around
any chance these can be used to start playing ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20100220/f66dfb05/attachment.htm>

From laforge at gnumonks.org  Fri Feb 19 23:32:43 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 20 Feb 2010 00:32:43 +0100
Subject: newer more expensive phones
In-Reply-To: <26f61db51002191449j5a77d70do533b43bdead81759@mail.gmail.com>
References: <26f61db51002191449j5a77d70do533b43bdead81759@mail.gmail.com>
Message-ID: <20100219233243.GO16218@prithivi.gnumonks.org>

On Sat, Feb 20, 2010 at 02:19:01AM +0330, Mohammad Hosein wrote:
> i've got a couple of newer Motorola phones like the milestone also some new
> HTC phones around any chance these can be used to start playing ?

no.

-- 
- 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)



From stefan at datenfreihafen.org  Fri Feb 19 23:33:50 2010
From: stefan at datenfreihafen.org (Stefan Schmidt)
Date: Sat, 20 Feb 2010 00:33:50 +0100
Subject: newer more expensive phones
In-Reply-To: <26f61db51002191449j5a77d70do533b43bdead81759@mail.gmail.com>
References: <26f61db51002191449j5a77d70do533b43bdead81759@mail.gmail.com>
Message-ID: <20100219233347.GA2388@excalibur.local>

Hello.

On Sat, 2010-02-20 at 02:19, Mohammad Hosein wrote:
> i've got a couple of newer Motorola phones like the milestone also some new
> HTC phones around
> any chance these can be used to start playing ?

No. For now we only there is only support for the Calypso baseband. Newer
smartphones like the one you mentioned use other chipsets. Everything that has
EDGE and above is a good indicator that no Calypso is included.

We are really looking forward to getting OsmocomBB running on other basebands,
but for now Calypso is all we support.

regards
Stefan Schmidt



From chrisfriedt at gmail.com  Sat Feb 20 12:43:02 2010
From: chrisfriedt at gmail.com (Christopher Friedt)
Date: Sat, 20 Feb 2010 13:43:02 +0100
Subject: OpenBSC questions
Message-ID: <3ea34a001002200443o55864979g5e944280cba8e441@mail.gmail.com>

So let me ask a couple of questions about OpenBSC to clarify things for myself.

What are the requirements for running OpenBSC ?
a) a USRP2
b) some kind of computer with gigabit ethernet (recommended hardware?
what kind of load would this be responsible for?)
b) a broadband internet connection
c) anything else? Some kind of VOIP account somewhere?

The reason I'm asking is that I've been doing quite a bit of work with
the USRP2 at university, and have been considering buying one for
myself for quite some time (although as a student, it's hard to
justify the price). My professional / academic / hobby interests
definitely involve hacking mobiles, investigating mobile radio,
hacking various arm devices, even hardware design, etc, and I guess
that OpenBSC would be ideal to  for testing out osmocom baseband
firmware (rather than having a commercial provider's black box for a
BS).

I guess another question I could pose to the list would be:

Is the USRP2 hardware-capable of supporting something UMTS, EDGE, etc?
I know that the spec sheets say that it's capable of 50 MHz of
instantaneous bandwidth, but I believe that the high data rate 3G (and
further) protocols are using wideband OFDM. From my understanding, I
would imagine that it would be necessary to support much more than 50
MHz of instantaneous bandwidth, or somehow be able to load the
transceiver buffers quickly and sequentially. then push a broad
spectrum in parallel. Perhaps this can be achieved with a MIMO
configuration, or with a specialized daughter card.

Any thoughts?

C



From nibbler at ccc.de  Sat Feb 20 13:07:30 2010
From: nibbler at ccc.de (Michael Horn)
Date: Sat, 20 Feb 2010 14:07:30 +0100
Subject: OpenBSC questions
In-Reply-To: <3ea34a001002200443o55864979g5e944280cba8e441@mail.gmail.com>
References: <3ea34a001002200443o55864979g5e944280cba8e441@mail.gmail.com>
Message-ID: <20100220140730.50edc0a4@minime>

On Sat, 20 Feb 2010 13:43:02 +0100
Christopher Friedt <chrisfriedt at gmail.com> wrote:

> What are the requirements for running OpenBSC ?
> a) a USRP2
no.
> b) some kind of computer with gigabit ethernet
no need for GigE.
> b) a broadband internet connection
no.
> c) anything else? Some kind of VOIP account somewhere?
no VoIP account needed.

You might want to start here:
http://openbsc.gnumonks.org/trac/wiki/OpenBSC

which should answer most of your questions.

cheers,
Michael



From alexander.chemeris at gmail.com  Sat Feb 20 13:28:17 2010
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Sat, 20 Feb 2010 16:28:17 +0300
Subject: OpenBSC questions
In-Reply-To: <3ea34a001002200443o55864979g5e944280cba8e441@mail.gmail.com>
References: <3ea34a001002200443o55864979g5e944280cba8e441@mail.gmail.com>
Message-ID: <3d032e5d1002200528ne802b42yf0a8bef4c4e4abb@mail.gmail.com>

Christopher,

You seem to ask about OpenBTS actually. If you want to know about
it, read official web-site:
http://openbts.sourceforge.net/
and wki:
http://gnuradio.org/redmine/wiki/gnuradio/OpenBTS
There are plenty information there. You can ask on its mailing list too.
And no, it doesn't work with USRP2. Currently only USRP1 is supported.
But if you want to port it to USRP2, you're welcome.

On Sat, Feb 20, 2010 at 15:43, Christopher Friedt <chrisfriedt at gmail.com> wrote:
> So let me ask a couple of questions about OpenBSC to clarify things for myself.
>
> What are the requirements for running OpenBSC ?
> a) a USRP2
> b) some kind of computer with gigabit ethernet (recommended hardware?
> what kind of load would this be responsible for?)
> b) a broadband internet connection
> c) anything else? Some kind of VOIP account somewhere?
>
> The reason I'm asking is that I've been doing quite a bit of work with
> the USRP2 at university, and have been considering buying one for
> myself for quite some time (although as a student, it's hard to
> justify the price). My professional / academic / hobby interests
> definitely involve hacking mobiles, investigating mobile radio,
> hacking various arm devices, even hardware design, etc, and I guess
> that OpenBSC would be ideal to ?for testing out osmocom baseband
> firmware (rather than having a commercial provider's black box for a
> BS).
>
> I guess another question I could pose to the list would be:
>
> Is the USRP2 hardware-capable of supporting something UMTS, EDGE, etc?
> I know that the spec sheets say that it's capable of 50 MHz of
> instantaneous bandwidth, but I believe that the high data rate 3G (and
> further) protocols are using wideband OFDM. From my understanding, I
> would imagine that it would be necessary to support much more than 50
> MHz of instantaneous bandwidth, or somehow be able to load the
> transceiver buffers quickly and sequentially. then push a broad
> spectrum in parallel. Perhaps this can be achieved with a MIMO
> configuration, or with a specialized daughter card.
>
> Any thoughts?
>
> C
>
>



-- 
Regards,
Alexander Chemeris.



From laforge at gnumonks.org  Sat Feb 20 13:37:40 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 20 Feb 2010 14:37:40 +0100
Subject: OpenBSC questions
In-Reply-To: <3ea34a001002200443o55864979g5e944280cba8e441@mail.gmail.com>
References: <3ea34a001002200443o55864979g5e944280cba8e441@mail.gmail.com>
Message-ID: <20100220133740.GA5793@prithivi.gnumonks.org>

On Sat, Feb 20, 2010 at 01:43:02PM +0100, Christopher Friedt wrote:
> So let me ask a couple of questions about OpenBSC to clarify things for myself.

Sorry, you are wrong here in multiple ways:

1) The OpenBSC mailing list is openbsc at lists.gnumonks.org
2) OpenBSC is completely unrelated to the USRP.

-- 
- 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)



From chrisfriedt at gmail.com  Sat Feb 20 15:58:12 2010
From: chrisfriedt at gmail.com (Christopher Friedt)
Date: Sat, 20 Feb 2010 16:58:12 +0100
Subject: OpenBSC questions
In-Reply-To: <20100220133740.GA5793@prithivi.gnumonks.org>
References: <3ea34a001002200443o55864979g5e944280cba8e441@mail.gmail.com> 
	<20100220133740.GA5793@prithivi.gnumonks.org>
Message-ID: <3ea34a001002200758m1b335243q1d09d495e9b463bb@mail.gmail.com>

On Sat, Feb 20, 2010 at 2:37 PM, Harald Welte <laforge at gnumonks.org> wrote:
> On Sat, Feb 20, 2010 at 01:43:02PM +0100, Christopher Friedt wrote:
>> So let me ask a couple of questions about OpenBSC to clarify things for myself.
>
> Sorry, you are wrong here in multiple ways:

Right, I had the OpenBTS and OpenBSC projects confused - the previous
replies were informative.



From thegrugq at gmail.com  Sat Feb 20 13:48:57 2010
From: thegrugq at gmail.com (the grugq)
Date: Sat, 20 Feb 2010 20:48:57 +0700
Subject: OpenBSC questions
In-Reply-To: <3ea34a001002200443o55864979g5e944280cba8e441@mail.gmail.com>
References: <3ea34a001002200443o55864979g5e944280cba8e441@mail.gmail.com>
Message-ID: <9CB7B0C7-ADEF-49CB-A431-F789CBDE2FD5@gmail.com>

Hey,

I think you're confusing the openbsc project with the openbts project.  
Openbsc uses existing BTS hardware to handle the RF and focuses on the  
backend of the BTS interface. OpenBTS uses the USRP (not the USRP2)  
for the RF and is writing a complete stack from the radio layer up.  
They are the project which connects directly with a VoIP PBX and  
handle GSM - SIP.

If you want to work on the OpenBTS project you'll need a USRP (not  
USRP2) and a couple of RF boards. The 900 band seems to best  
supported, so you'll be looking t an outlay of about 1400 USD. You'll  
also need to modify the RF boards before you can use them. It is  
documented across a number of websites. Google is your friend.

Check out the openbts website.

cheers,

--gq

On 20 Feb 2010, at 19:43, Christopher Friedt <chrisfriedt at gmail.com>  
wrote:

> So let me ask a couple of questions about OpenBSC to clarify things  
> for myself.
>
> What are the requirements for running OpenBSC ?
> a) a USRP2
> b) some kind of computer with gigabit ethernet (recommended hardware?
> what kind of load would this be responsible for?)
> b) a broadband internet connection
> c) anything else? Some kind of VOIP account somewhere?
>
> The reason I'm asking is that I've been doing quite a bit of work with
> the USRP2 at university, and have been considering buying one for
> myself for quite some time (although as a student, it's hard to
> justify the price). My professional / academic / hobby interests
> definitely involve hacking mobiles, investigating mobile radio,
> hacking various arm devices, even hardware design, etc, and I guess
> that OpenBSC would be ideal to  for testing out osmocom baseband
> firmware (rather than having a commercial provider's black box for a
> BS).
>
> I guess another question I could pose to the list would be:
>
> Is the USRP2 hardware-capable of supporting something UMTS, EDGE, etc?
> I know that the spec sheets say that it's capable of 50 MHz of
> instantaneous bandwidth, but I believe that the high data rate 3G (and
> further) protocols are using wideband OFDM. From my understanding, I
> would imagine that it would be necessary to support much more than 50
> MHz of instantaneous bandwidth, or somehow be able to load the
> transceiver buffers quickly and sequentially. then push a broad
> spectrum in parallel. Perhaps this can be achieved with a MIMO
> configuration, or with a specialized daughter card.
>
> Any thoughts?
>
> C
>



From timo.lindfors at iki.fi  Sat Feb 20 14:44:55 2010
From: timo.lindfors at iki.fi (Timo Juhani Lindfors)
Date: Sat, 20 Feb 2010 16:44:55 +0200
Subject: [PATCH] fix typo in documentation
In-Reply-To: <mailman.3.1266658061.14349.baseband-devel@lists.osmocom.org>
	(baseband-devel-request@lists.osmocom.org's message of "Sat\,
	20 Feb 2010 10\:27\:41 +0100")
References: <mailman.3.1266658061.14349.baseband-devel@lists.osmocom.org>
Message-ID: <841vggj7a0.fsf@sauna.l.org>


---
 src/README.building |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/README.building b/src/README.building
index f940d09..bfd86b6 100644
--- a/src/README.building
+++ b/src/README.building
@@ -23,5 +23,5 @@ we do not officially support this.
 
  # cd osmocom-bb/src/host/layer2
  # autoreconf -i
- # ./confiugre
+ # ./configure
  # make
-- 
1.5.6.5




From laforge at gnumonks.org  Sat Feb 20 16:41:59 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 20 Feb 2010 17:41:59 +0100
Subject: [PATCH] fix typo in documentation
In-Reply-To: <841vggj7a0.fsf@sauna.l.org>
References: <mailman.3.1266658061.14349.baseband-devel@lists.osmocom.org>
	<841vggj7a0.fsf@sauna.l.org>
Message-ID: <20100220164159.GC5793@prithivi.gnumonks.org>

> - # ./confiugre
> + # ./configure
thanks, fixed.

-- 
- 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)



From squalyl at gmail.com  Sat Feb 20 15:46:32 2010
From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=)
Date: Sat, 20 Feb 2010 16:46:32 +0100
Subject: Sim
Message-ID: <3ff29e861002200746p34e1d3baw57a696e498a5deaf@mail.gmail.com>

Hi all,

congrats for your awesome research and work, this is truly impressive.

The little ant that I am (compared to you) was interested in helping you
with the SIM aspects of the project. I think I know javacard sufficiently to
implement a basic sim card that can be totally controlled. I already started
to think on how to do that. This will include making host side tools, too.
If javacard is not open enough, we can also look at native cards using PIC,
for example. In our previous discussions, the main problem was the
availability of SIM sized cards, be them javacards or not.

pros and cons
- javacard is an industry standard, coupled with GlobalPlatform specs this
is a portable way to put an application on a card without being locked with
a card manufacturer.
- native PIC cards benefit from a lot of open tools such as the gp* PIC
tools, asm, sdcc for compiler and gpsim for simulation.
- some projects exists already, I don't know them well, maybe they can be
used, forked, improved.
- availability must be checked.

I'd like to request precisions on how the things should be done, what are
the minimal requirements (files, etc) and when the openSim project will be
needed regarding to your progress.

Regards
Sebastien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20100220/598962eb/attachment.htm>

From zero-kelvin at gmx.de  Sat Feb 20 20:48:58 2010
From: zero-kelvin at gmx.de (dexter)
Date: Sat, 20 Feb 2010 21:48:58 +0100
Subject: Sim
In-Reply-To: <3ff29e861002200746p34e1d3baw57a696e498a5deaf@mail.gmail.com>
References: <3ff29e861002200746p34e1d3baw57a696e498a5deaf@mail.gmail.com>
Message-ID: <4B804ABA.1030400@gmx.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi S?bastien.

> congrats for your awesome research and work, this is truly impressive.
> 
> The little ant that I am (compared to you) was interested in helping you
> with the SIM aspects of the project. I think I know javacard sufficiently to
> implement a basic sim card that can be totally controlled. I already started
> to think on how to do that. This will include making host side tools, too.
> If javacard is not open enough, we can also look at native cards using PIC,
> for example. In our previous discussions, the main problem was the
> availability of SIM sized cards, be them javacards or not.
> 
> pros and cons
> - javacard is an industry standard, coupled with GlobalPlatform specs this
> is a portable way to put an application on a card without being locked with
> a card manufacturer.
> - native PIC cards benefit from a lot of open tools such as the gp* PIC
> tools, asm, sdcc for compiler and gpsim for simulation.
> - some projects exists already, I don't know them well, maybe they can be
> used, forked, improved.
> - availability must be checked.
> 
> I'd like to request precisions on how the things should be done, what are
> the minimal requirements (files, etc) and when the openSim project will be
> needed regarding to your progress.

I only want to say that i am courrently drive a semilar project. I have
developed a smartcard O/S for Atmel-Cards (license is GPL, of cause....)

http://runningserver.com/software/xcos.tar

Currently i am working on a simcard implementation. Currently my simcard
can process SELECT commands (but not READ BINARY & Co so far).

The download link leads to the current release (which does not include
my simcard source). If you are intereted to see the source of my
unfinished sim project i can make it available.

I can not say when my simcard gets finished because there are a lot of
other important (and sometimes more interesting) things to do.

Best regards.
Philipp



















> 
> Regards
> Sebastien
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuASroACgkQrQQa6thSCbCxhQCfUfbA8T7xN2Tg3tfl6UpdXQxC
mnsAn0dAh/YzqrleABxTfmPNlyXmDH4u
=yhsk
-----END PGP SIGNATURE-----



From squalyl at gmail.com  Sat Feb 20 21:03:34 2010
From: squalyl at gmail.com (=?UTF-8?Q?S=C3=A9bastien_Lorquet?=)
Date: Sat, 20 Feb 2010 22:03:34 +0100
Subject: Sim
In-Reply-To: <4B804ABA.1030400@gmx.de>
References: <3ff29e861002200746p34e1d3baw57a696e498a5deaf@mail.gmail.com> 
	<4B804ABA.1030400@gmx.de>
Message-ID: <3ff29e861002201303j1876be4ap7d74737434a9d4de@mail.gmail.com>

Hi,

I'll have a look at it, thanks.
Same as you, I have lots of things to do, so my project will also take time
to complete.
It's good to know we'll have more than one implementation available.

Regards
Sebastien.

On Sat, Feb 20, 2010 at 9:48 PM, dexter <zero-kelvin at gmx.de> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi S?bastien.
>
> > congrats for your awesome research and work, this is truly impressive.
> >
> > The little ant that I am (compared to you) was interested in helping you
> > with the SIM aspects of the project. I think I know javacard sufficiently
> to
> > implement a basic sim card that can be totally controlled. I already
> started
> > to think on how to do that. This will include making host side tools,
> too.
> > If javacard is not open enough, we can also look at native cards using
> PIC,
> > for example. In our previous discussions, the main problem was the
> > availability of SIM sized cards, be them javacards or not.
> >
> > pros and cons
> > - javacard is an industry standard, coupled with GlobalPlatform specs
> this
> > is a portable way to put an application on a card without being locked
> with
> > a card manufacturer.
> > - native PIC cards benefit from a lot of open tools such as the gp* PIC
> > tools, asm, sdcc for compiler and gpsim for simulation.
> > - some projects exists already, I don't know them well, maybe they can be
> > used, forked, improved.
> > - availability must be checked.
> >
> > I'd like to request precisions on how the things should be done, what are
> > the minimal requirements (files, etc) and when the openSim project will
> be
> > needed regarding to your progress.
>
> I only want to say that i am courrently drive a semilar project. I have
> developed a smartcard O/S for Atmel-Cards (license is GPL, of cause....)
>
> http://runningserver.com/software/xcos.tar
>
> Currently i am working on a simcard implementation. Currently my simcard
> can process SELECT commands (but not READ BINARY & Co so far).
>
> The download link leads to the current release (which does not include
> my simcard source). If you are intereted to see the source of my
> unfinished sim project i can make it available.
>
> I can not say when my simcard gets finished because there are a lot of
> other important (and sometimes more interesting) things to do.
>
> Best regards.
> Philipp
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> >
> > Regards
> > Sebastien
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkuASroACgkQrQQa6thSCbCxhQCfUfbA8T7xN2Tg3tfl6UpdXQxC
> mnsAn0dAh/YzqrleABxTfmPNlyXmDH4u
> =yhsk
> -----END PGP SIGNATURE-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20100220/7dbd3438/attachment.htm>

From laforge at gnumonks.org  Sun Feb 21 11:12:56 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 21 Feb 2010 12:12:56 +0100
Subject: Sim
In-Reply-To: <3ff29e861002201303j1876be4ap7d74737434a9d4de@mail.gmail.com>
References: <3ff29e861002200746p34e1d3baw57a696e498a5deaf@mail.gmail.com>
	<4B804ABA.1030400@gmx.de>
	<3ff29e861002201303j1876be4ap7d74737434a9d4de@mail.gmail.com>
Message-ID: <20100221111256.GI6672@prithivi.gnumonks.org>

Hi Sebastien and dexter,

On Sat, Feb 20, 2010 at 10:03:34PM +0100, S?bastien Lorquet wrote:
 
> I'll have a look at it, thanks.
> Same as you, I have lots of things to do, so my project will also take time
> to complete.  It's good to know we'll have more than one implementation
> available.

I think it would be more productive if you could divide the work rather than
duplicating it.  If dexter already has the 8716 part done up to SELECT FILE,
then it might be more useful to add the SIM specific bits to it.

Also, if you want to work with SIM cards:  We still need the phone-side
implementation for OsmocomBB, i.e. a driver for the SIM reader inside the
phone, plus a software layer that provides a filesystem-level API where we can
simply call functions lieke iso7816_read_file_record() that would
 * selects a file
 * reads a caller-specified record
 * copies the result in a caller-provided buffer

To make it short: There is a lot of work to be done, and I would rather like to
see the two of you to work on separate tasks, rather than duplicating work.

After all, we want to see as much progress as possible and can need all
help we get.

Regards,
	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)



From laforge at gnumonks.org  Sat Feb 20 22:41:35 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 20 Feb 2010 23:41:35 +0100
Subject: New build process / libosmocore
Message-ID: <20100220224135.GB6672@prithivi.gnumonks.org>

Hi!

After much delibeation I have devoted today to 'fix' the way how we build
the project and how things depend on each other.

We have a couple of challenges:

1) there is (and should be!) a lot of infrastructure code sharing between
   OpenBSC and OsmocomBB Layer2/3.  I'm referring to  stuff like linuxlist.h,
   msgb.[hc], bitvec.[hc], the various GSM protocol header files, timers, etc.

2) we want to do the layer2/layer3 development on the PC, while the layer1
   resides on the target phone.  However, the code should be API compatible
   and just compile when we later decide to move (parts of) it into the
   phone.

3) there is already some code like "msgb" which is used both in layer2(PC)
   and the phone.

4) I don't want to have too many build dependencies as it makes it
   unneccesarily difficult to get started with the project.  So everything
   should build from the git tree we provide

5) we dislike the idea of code duplication or copy+paste.  This means
   that we need to build some stuff like libosmocore twice; for the
   host PC and for ARM

The solution looks like this:

* libosmocore lives in its own git://git.osmocom.org/libosmocore.git
  repository.  This is where we make changes to it.

* libosmocore is 'squashed' into the osmocom-bb.git repository by means
  of git-subtree[1] to make sure challenge '4' is fulfilled.  This is
  transparent to the user who clones our tree.  However, if you want to
  make changes, please ensure that a commit either only touches files
  within src/shared/libosmocore or outside of that directory.  Mixed
  commits will require manual action and are tiresome.

* everything is built using autotools, except for the 'firmware'
  (what used to be hello_world)

* there's now a top-level Makefile, which
  * builds libosmocore for the host
  * builds libosmocore for the target
  * builds osmocon for the host
  * builds layer2 for the host
  * builds the target firmware

I understand that this process is quite a bit more complex than what
we used to have, but it is the best option that I could come up with.

I particularly hope that I didn't do something stupid which would break
Cygwin builds... we want to keep Dieter as productive as he currently is,
after all :)

Regards,
	Harald

[1] git://github.com/apenwarr/git-subtree.git
-- 
- 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)



From 246tnt at gmail.com  Sun Feb 21 01:26:19 2010
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Sun, 21 Feb 2010 02:26:19 +0100
Subject: Links to schematics in the wiki ?
Message-ID: <866320f71002201726u7c6cb760r826f889abb44c661@mail.gmail.com>

Hi,

I'm wondering if it's ok or not to put links (and only links
obviously) to schematics of GSM in the Wiki ?
IANAL so I'm not sure exactly what the situation is ... and I'd rather
ask before I start adding too much of them :)

Cheers,

     Sylvain



From laforge at gnumonks.org  Sun Feb 21 08:06:34 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 21 Feb 2010 09:06:34 +0100
Subject: Links to schematics in the wiki ?
In-Reply-To: <866320f71002201726u7c6cb760r826f889abb44c661@mail.gmail.com>
References: <866320f71002201726u7c6cb760r826f889abb44c661@mail.gmail.com>
Message-ID: <20100221080634.GF6672@prithivi.gnumonks.org>

On Sun, Feb 21, 2010 at 02:26:19AM +0100, Sylvain Munaut wrote:
 
> I'm wondering if it's ok or not to put links (and only links
> obviously) to schematics of GSM in the Wiki ?
> IANAL so I'm not sure exactly what the situation is ... and I'd rather
> ask before I start adding too much of them :)

It's a risk I'm willing to take.  As lon as we are not hosting the
stuff ourselves we're quite fine.  The worst that can happen is somebody
claiming that I cease and desist, so worst case legal risk in the hundreds of
EUR and not more.

Regards,
	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)



From 246tnt at gmail.com  Sun Feb 21 12:26:21 2010
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Sun, 21 Feb 2010 13:26:21 +0100
Subject: Memory Leaking. _talloc_zero panics
Message-ID: <866320f71002210426nfa08619ode3f4fc3a74b7f49@mail.gmail.com>

Hi,

I've noticed that hello_world and compal_dsp_dump now crash pretty
early. I've traced it down to talloc_zero panicing by running out of
free msgb. Augmenting the number to 64 makes the software go a little
further but they still crash in the end.

I'm hoping that the person who wrote this part will see an obvious
place where the problem lies :)

    Sylvain



From laforge at gnumonks.org  Sun Feb 21 13:32:34 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 21 Feb 2010 14:32:34 +0100
Subject: Memory Leaking. _talloc_zero panics
In-Reply-To: <866320f71002210426nfa08619ode3f4fc3a74b7f49@mail.gmail.com>
References: <866320f71002210426nfa08619ode3f4fc3a74b7f49@mail.gmail.com>
Message-ID: <20100221133234.GM6672@prithivi.gnumonks.org>

On Sun, Feb 21, 2010 at 01:26:21PM +0100, Sylvain Munaut wrote:
> Hi,
> 
> I've noticed that hello_world and compal_dsp_dump now crash pretty
> early. I've traced it down to talloc_zero panicing by running out of
> free msgb. Augmenting the number to 64 makes the software go a little
> further but they still crash in the end.
> 
> I'm hoping that the person who wrote this part will see an obvious
> place where the problem lies :)

that would probably be me.  I have reproduced the problem and will look at
it later today.  Interestingly, it doesn't occur with l1test or layer1,
who send much more data over the serial port...

-- 
- 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)



From laforge at gnumonks.org  Sun Feb 21 14:04:32 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 21 Feb 2010 15:04:32 +0100
Subject: Memory Leaking. _talloc_zero panics
In-Reply-To: <20100221133234.GM6672@prithivi.gnumonks.org>
References: <866320f71002210426nfa08619ode3f4fc3a74b7f49@mail.gmail.com>
	<20100221133234.GM6672@prithivi.gnumonks.org>
Message-ID: <20100221140431.GP6672@prithivi.gnumonks.org>

On Sun, Feb 21, 2010 at 02:32:34PM +0100, Harald Welte wrote:
> > I've noticed that hello_world and compal_dsp_dump now crash pretty
> > early. I've traced it down to talloc_zero panicing by running out of
> > free msgb. Augmenting the number to 64 makes the software go a little
> > further but they still crash in the end.
> > 
> > I'm hoping that the person who wrote this part will see an obvious
> > place where the problem lies :)
> 
> that would probably be me.  I have reproduced the problem and will look at
> it later today.  Interestingly, it doesn't occur with l1test or layer1,
> who send much more data over the serial port...

it seems like it is really just the normal console printing.  Those programs
print a number of relatively short lines, and at the moment we use one msgb for
each line, even if it is not full yet.

So only dumping the PLL registers twice is already sufficient to use up
all the msgb()s.

I will think about how to solve this.  Either we introduce some busy-waiting
until more space is available, or I will try to fill existing buffers even
beyond the end-of-line.

-- 
- 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)



From laforge at gnumonks.org  Sun Feb 21 17:38:23 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 21 Feb 2010 18:38:23 +0100
Subject: Memory Leaking. _talloc_zero panics
In-Reply-To: <866320f71002210903s515b5535ibeede658f07fd67f@mail.gmail.com>
References: <866320f71002210426nfa08619ode3f4fc3a74b7f49@mail.gmail.com>
	<20100221133234.GM6672@prithivi.gnumonks.org>
	<20100221140431.GP6672@prithivi.gnumonks.org>
	<866320f71002210903s515b5535ibeede658f07fd67f@mail.gmail.com>
Message-ID: <20100221173823.GW6672@prithivi.gnumonks.org>

On Sun, Feb 21, 2010 at 06:03:08PM +0100, Sylvain Munaut wrote:
> > I will think about how to solve this. ?Either we introduce some busy-waiting
> > until more space is available, or I will try to fill existing buffers even
> > beyond the end-of-line.
> 
> I've seen the commit to fill up the msgb more. But this exposed
> another bug in msgb I think.
> The headroom allocation doesn't work AFAICT. In msgb.h there is :
> 
> static inline int msgb_tailroom(const struct msgb *msgb)
> {
>         return (msgb->data + msgb->data_len) - msgb->tail;
> }

you are right, it should be msgb->head + msgb->data_len, I've fixed
that now.

I've also changed to  busy-wait until we have msgb's available again.

dsp_dump and hello_world as well as l1test seem to work again now.

It's all still a big hack and later we need to determine if we're called
from a context that supports busy-waiting at all.

Imagine this code being executed from the FIQ context, while new memory
will always only be available from IRQ context (UART Tx FIFO interrupt):
We will deadlock.

Cheers,
	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)



From ilya.muromec at gmail.com  Sun Feb 21 13:08:07 2010
From: ilya.muromec at gmail.com (Ilya Petrov)
Date: Sun, 21 Feb 2010 15:08:07 +0200
Subject: some questions
Message-ID: <800a98741002210508n48256cf5v8a6af725a51849eb@mail.gmail.com>

Hi!

I read few pages at http://bb.osmocom.org but didnt find
answer for some little questions.

What this code is based on? Is this a port of some rtos to calypso?

-- 
 wbr, Ilya
 ICQ: none, Jabber: ilya.muromec at jabber.ru



From 246tnt at gmail.com  Sun Feb 21 14:01:04 2010
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Sun, 21 Feb 2010 15:01:04 +0100
Subject: some questions
In-Reply-To: <800a98741002210508n48256cf5v8a6af725a51849eb@mail.gmail.com>
References: <800a98741002210508n48256cf5v8a6af725a51849eb@mail.gmail.com>
Message-ID: <866320f71002210601i110cea95tc890ca11adc924ff@mail.gmail.com>

Hi,

> I read few pages at http://bb.osmocom.org but didnt find
> answer for some little questions.
>
> What this code is based on? Is this a port of some rtos to calypso?

Currently it's based on nothing. Written from scratch mostly by Harald
(with help of a few others of course, see wiki for details).
The inspiration coming from leaked documentation and the publicly
available TSM30 sources.

    Sylvain



From laforge at gnumonks.org  Sun Feb 21 14:02:36 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 21 Feb 2010 15:02:36 +0100
Subject: some questions
In-Reply-To: <800a98741002210508n48256cf5v8a6af725a51849eb@mail.gmail.com>
References: <800a98741002210508n48256cf5v8a6af725a51849eb@mail.gmail.com>
Message-ID: <20100221140235.GO6672@prithivi.gnumonks.org>

Hi Ilya,

On Sun, Feb 21, 2010 at 03:08:07PM +0200, Ilya Petrov wrote:
 
> What this code is based on? 

on nothing really.  We wrote it from scratch.  There are some smaller functions
that we imported from OpenPCD (src/target/firmware/src/lib directory), mostly
about sprintf() and related functions.

> Is this a port of some rtos to calypso?

We do not have an operating system as of now.  All we run on the phone at the
moment is the GSM Layer1, there is no need for different tasks/threads
and scheduling (which an small RTOS is mostly about).

There is no immediate need for an OS either, as we will initially work
on writing the Layer 2 / Layer3 on the PC while running Layer1 on the phone
itself.

At some later point where there are actually multiple tasks on the phone (like
a UI, the Layer1, Layer2 and Layer3, etc.) we have to decide if we want to use
any existing RTOS...

Regards,
	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)



From ilya.muromec at gmail.com  Sun Feb 21 14:14:16 2010
From: ilya.muromec at gmail.com (Ilya Petrov)
Date: Sun, 21 Feb 2010 16:14:16 +0200
Subject: some questions
In-Reply-To: <20100221140235.GO6672@prithivi.gnumonks.org>
References: <800a98741002210508n48256cf5v8a6af725a51849eb@mail.gmail.com>
	<20100221140235.GO6672@prithivi.gnumonks.org>
Message-ID: <800a98741002210614gc44bea2qa06bd64ccd7cacbd@mail.gmail.com>

2010/2/21 Harald Welte <laforge at gnumonks.org>:
> There is no immediate need for an OS either, as we will initially work
> on writing the Layer 2 / Layer3 on the PC while running Layer1 on the phone
> itself.

just like motomagix. so if i port layer1 to neptune and write usb driver
i`l be able to run layer1 on ezx bp and layers 2 and 3 on ap.

whould this be hard?

btw, can i even run it on real gsm network, not on your openbts?

-- 
 wbr, Ilya
 ICQ: none, Jabber: ilya.muromec at jabber.ru



From laforge at gnumonks.org  Sun Feb 21 16:29:39 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 21 Feb 2010 17:29:39 +0100
Subject: some questions
In-Reply-To: <800a98741002210614gc44bea2qa06bd64ccd7cacbd@mail.gmail.com>
References: <800a98741002210508n48256cf5v8a6af725a51849eb@mail.gmail.com>
	<20100221140235.GO6672@prithivi.gnumonks.org>
	<800a98741002210614gc44bea2qa06bd64ccd7cacbd@mail.gmail.com>
Message-ID: <20100221162939.GS6672@prithivi.gnumonks.org>

Hi Ilya,

On Sun, Feb 21, 2010 at 04:14:16PM +0200, Ilya Petrov wrote:
> 2010/2/21 Harald Welte <laforge at gnumonks.org>:
> > There is no immediate need for an OS either, as we will initially work
> > on writing the Layer 2 / Layer3 on the PC while running Layer1 on the phone
> > itself.
> 
> just like motomagix. so if i port layer1 to neptune and write usb driver
> i`l be able to run layer1 on ezx bp and layers 2 and 3 on ap.

theoretically, yes.  

However, the biggest part of what we currently have as a layer1 is how to talk
to the DSP ROM code.  This will likely be very different from the Ti Calypso.
So unless you have access to documentation or do a lot of tedious reverse
engineering, I think it will be quite difficult.

You also need to write drivers for all the Neptune-integrated peripherals,
and work on a way how you can actuall get your code executed on it.

> whould this be hard?

yes.

I'm not saying its impossible, but I think it is definitely more work than what
we have done so far (which is probably around two months full time work).

Nonetheless, the higher levels of layer1 and everything above could likely
be shared between various different digital basebands.

Regards,
	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)



From azrael01 at gmail.com  Sun Feb 21 16:15:52 2010
From: azrael01 at gmail.com (azrael01)
Date: Sun, 21 Feb 2010 17:15:52 +0100
Subject: SIM
Message-ID: <4B815C38.4010506@googlemail.com>

Hi,

I'm new at this project and I've no experience to program a complete SIM
card. But I've experience to implement the ISO-7816 standard on a
ARM-Cortex-M3, so that you have a SIM-interface (SIM emulation) between
the PC an the Mobile equipment.
However, if I can help I'll be pleased to hear from you.


cheers,
Carsten



From laforge at gnumonks.org  Sun Feb 21 17:17:05 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 21 Feb 2010 18:17:05 +0100
Subject: SIM
In-Reply-To: <4B815C38.4010506@googlemail.com>
References: <4B815C38.4010506@googlemail.com>
Message-ID: <20100221171705.GU6672@prithivi.gnumonks.org>

Hi Azrael,

On Sun, Feb 21, 2010 at 05:15:52PM +0100, azrael01 wrote:
 
> I'm new at this project and I've no experience to program a complete SIM
> card. But I've experience to implement the ISO-7816 standard on a
> ARM-Cortex-M3, so that you have a SIM-interface (SIM emulation) between
> the PC an the Mobile equipment.
> However, if I can help I'll be pleased to hear from you.

As you can see from previous mails, dexter will be working on a driver for the
SIM card reader shortly.  So please coordinate with him if you intend to work
in the same area.

I think if you want to play with OsmocomBB, you should get started by
first getting a compatible phone, building the existing codebase and playing
around with it.  After that you can check again with this mailing list what's
the status of of the SIM card reader driver and which parts of e.g. iso7816
still need to be implemented.

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)



From Andreas.Eversberg at versatel.de  Mon Feb 22 14:44:00 2010
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Mon, 22 Feb 2010 15:44:00 +0100
Subject: introduce myself
Message-ID: <B16317F2B1592B4492FC414114171CE60258D801@FLBVEXCH01.versatel.local>

hi there,
 
my name is andreas eversberg. i worked for the mISDN and openbsc project
before. after joining the openbsc project, i mainly worked on the call
control protocol and the application interface, as well as E1 kernel
driver improvements for openbsc. i expanded my linux-call-router
application to be able to link with openbsc, so both become a mobile
network, as used on the 26c3. 
 
i like to put my experience into the osmocomBB project. therfore i
started working on the layer 3 "call control" (network layer, mobile
side) already. (TS 04.08) the application interface is almost identical,
so osmocomBB can be used with linux-call-router also. the next goal is
to implement "radio ressource" protocol and "mobility management"
protocol (real state machine), and i hope to get help with that. all
three protocols are required to do voice calls.
 
my motivations for joining the project are at the moment:
 - having a cool (graphical) network monitor
 - backup line for PBX, PBX in a car.
 - attaching (virtual) test SIM via phone's menu
 - changing IMEI via phone's menu
 
i hope this project make as much phun as openbsc.
 

andreas




From laforge at gnumonks.org  Tue Feb 23 09:23:37 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 23 Feb 2010 10:23:37 +0100
Subject: introduce myself
In-Reply-To: <B16317F2B1592B4492FC414114171CE60258D801@FLBVEXCH01.versatel.local>
References: <B16317F2B1592B4492FC414114171CE60258D801@FLBVEXCH01.versatel.local>
Message-ID: <20100223092337.GB21886@prithivi.gnumonks.org>

Hi Andreas,

thanks for your introduction.

On Mon, Feb 22, 2010 at 03:44:00PM +0100, Andreas.Eversberg wrote:
  
> i like to put my experience into the osmocomBB project. therfore i
> started working on the layer 3 "call control" (network layer, mobile
> side) already. (TS 04.08) the application interface is almost identical,

ok, great idea.  I think as long as it makes sense, we should keep things
as similar to OpenBSC as possible...

Feel free to suggest further header files or utility functions that we should
move from OpenBSC into libosmocom.  Patches for this should go to the
OpenBSC-devel mailinglist.

> so osmocomBB can be used with linux-call-router also. 

pleae note that while the signalling plane integration might be relatively
easy, I am more worried about the actual voice side of things.

In a normal phone, the analog voice data is ADC-converted by the ABB
(TWL3025/Iota), which sends it as stream of digital samples to the VSP
(Voice Serial Port) of the DSP.  The DSP then takes care of the voice
frame processing (echo cancellation, codec, etc.) and generates the
corresponding GSM bursts which are sent over the air.

So in normal GSM phone operation, there is no way how to directly
feed raw samples or codec frames from the ARM CPU and transmit them.

Thus, it is unlikely that the existing DSP ROM code has any such
mode - or rather even more unlikely that any of the existing source
code (like TSM30 source) would use any such feature, even if it was
present in the DSP ROM code.

So to get voice data from lcr sent over GSM, there probably needs to
be some binary patching of the DSP firmware.  Sylvain and Dieter probably
know most about that so far - but even that knowledge is relatively limited, as
I understand

> the next goal is to implement "radio ressource" protocol and "mobility
> management" protocol (real state machine), and i hope to get help with that.
> all three protocols are required to do voice calls.

Please make your work available as soon as possible, even if it is still
incomplete.  If you want to push it to a branch of osmocom-bb.git, I can give
you an account.

I'm now going to be busy with real world items over the next couple of days, so
don't expect much progress here.  Next week, Zecke and myself intend to
actually get the layer2 (lapdm) implemented and have bi-directional
communication from the PC to the BTS/BSC on SDCCH's working.

> my motivations for joining the project are at the moment:
>  - having a cool (graphical) network monitor

sounds great.  I think if you want this kind of application with you
on a handheld device, the Openmoko phones are the ideal target.  There's
a Calypso based chipset that we can run our custom firmware on, and it
is connected to a [relatively] powerful application processor that
can run Linux + UI toolkit, a GPS receiver and which has access to extensive
storage (microSD).

It would be great to make the most powerful GSM protocol analyzer, e.g.  to
constantly iterate over all cells that can be found, obtain the full BCCH
information.   Geo-tag that with GPS coordinates and create a full map
of how the networks look like.  Not just Cell-ID, but things like Cell
Allocation, the HSN/MAIO you get assigned when requesting channels, etc.

I suspect at some point we could even do things like BTS/BSC vendor/model
fingerprinting based on implementation details, like OS fingerprinting
works with nmap right now :)

>  - backup line for PBX, PBX in a car.

great, but see above:  There's a DSP related challenge involved

>  - attaching (virtual) test SIM via phone's menu

yes, that's a very interesting option indeed.  Which is one more reason why
we'd like to see a fairly complete ISO 7816 filesystem implementation in Free
Software C code.  This can then be either compiled for a hardware emulator (or
even FUNcard), or we could simply compile it for our ARM target and include it
in the phone.

>  - changing IMEI via phone's menu

Sure. Or random-generate one at power-up.

> i hope this project make as much phun as openbsc.

I hope it will make even more fun :)

-- 
- 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)



From laforge at gnumonks.org  Tue Feb 23 07:59:46 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 23 Feb 2010 08:59:46 +0100
Subject: Calypso status update
Message-ID: <20100223075946.GF19561@prithivi.gnumonks.org>

Hi!

I've done a day of bugfixing today, mostly regarding the timing and
sequencing of the TPU window during receive (and transmit).

The biggest new feature is the #define TPU_DEBUG which will transfer the
content of the TPU RAM to the host PC every time tpu_enable(1) is called.

There's a TPU debugger (tpu_debug.c) as part of osmocon which receives,
decodes and prints the TPU instructions.  This way you can clearly see
the exact sequence (and timing) of the commands that are executed by
the TPU.

What turned out to be the major problem that I was hunting most of the
day:  Whe first did the downlink calibration (BLDCAL), then waited for 
a specific time, and then enabled the downlink path (BDLENA).

This worked fine so far.  I then added code to disable the TRF6151 after
the downlink path is closed (twl3025_downlink(0)).  Suddenly not a single
burst was received anymore.

Now the sequence of events seems correct, at least in the little testing
I did.

Regards,
	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)



From deacon at volny.cz  Tue Feb 23 18:59:14 2010
From: deacon at volny.cz (Tomas Kopsa)
Date: Tue, 23 Feb 2010 19:59:14 +0100
Subject: phone hardware
In-Reply-To: <20100223075946.GF19561@prithivi.gnumonks.org>
References: <20100223075946.GF19561@prithivi.gnumonks.org>
Message-ID: <4B842582.2020400@volny.cz>

Hi All !

I want to ask you if really all suggested phones have 2.5mm earphone
jack, especially MotorolaC115. I'm not sure if some special Motorola
connector would be available to buy.

Thanks,
Tomas

P.S. Can you please set to add "[baseband-devel]" (or something like
that) before subject automatically ?



From timo.lindfors at iki.fi  Tue Feb 23 19:30:35 2010
From: timo.lindfors at iki.fi (Timo Juhani Lindfors)
Date: Tue, 23 Feb 2010 21:30:35 +0200
Subject: [offtopic] mail filtering in Thunderbird
In-Reply-To: <4B842582.2020400@volny.cz> (Tomas Kopsa's message of "Tue\,
	23 Feb 2010 19\:59\:14 +0100")
References: <20100223075946.GF19561@prithivi.gnumonks.org>
	<4B842582.2020400@volny.cz>
Message-ID: <848waju4v8.fsf_-_@sauna.l.org>

Tomas Kopsa <deacon at volny.cz> writes:
> P.S. Can you please set to add "[baseband-devel]" (or something like
> that) before subject automatically ?

It seems you are using Thunderbird.

http://www.w3.org/2006/tools/EmailClientForMailingListFiltering

documents how you can configure it to keep messages of this mailing
list in a separate folder by using the standard "List-Id" header.








From laforge at gnumonks.org  Tue Feb 23 20:47:03 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 23 Feb 2010 21:47:03 +0100
Subject: phone hardware
In-Reply-To: <4B842582.2020400@volny.cz>
References: <20100223075946.GF19561@prithivi.gnumonks.org>
	<4B842582.2020400@volny.cz>
Message-ID: <20100223204703.GJ21886@prithivi.gnumonks.org>

On Tue, Feb 23, 2010 at 07:59:14PM +0100, Tomas Kopsa wrote:
> Hi All !
> 
> I want to ask you if really all suggested phones have 2.5mm earphone
> jack, especially MotorolaC115. I'm not sure if some special Motorola
> connector would be available to buy.

yes, they all have that earphone jack.

> P.S. Can you please set to add "[baseband-devel]" (or something like
> that) before subject automatically ?

simply use the "List-Id" header for filtering.  There's no need to clutter
the subject line with it.

-- 
- 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)



From benny at benny.de  Tue Feb 23 19:21:21 2010
From: benny at benny.de (Benjamin Hagemann)
Date: Tue, 23 Feb 2010 20:21:21 +0100
Subject: some links for Nokia N95
Message-ID: <20100223192121.GU17418@quelle.benny.de>

Hello together,

I have collected some informations / links for Nokia N95 and similar
topics. Maybe some of them are good enough for the wiki.

http://www.nokiaport.de/n95info/?id=processor
http://www.nokiaport.de/n95info/?id=pcb

http://www.phonewreck.com/wiki/index.php?title=Nokia_N95#Bill_of_Materials
RF Transceiver:
STMicroelectronics #4380206 Quad-band GSM/GPRS/EDGE, Dual-band UMTS/HSPDA (Unmarked)

http://www.phonewreck.com/wiki/images/thumb/8/85/Nokia_N95_pcb_back.jpg/800px-Nokia_N95_pcb_back.jpg
http://www.phonewreck.com/wiki/images/thumb/4/4b/Nokia_N95_pcb_front.jpg/800px-Nokia_N95_pcb_front.jpg

http://www2.electronicproducts.com/Nokia_N95-whatsinside_text-61.aspx

"Under the Hood: Hot 3G phone owes debt to analog"
http://www.eetimes.com/showArticle.jhtml?articleID=202800251
http://i.cmpnet.com/eet/news/07/10/DC1500_UTH_1_PG_36.gif

   Nokia disassembly (Nokia N Gage, N96, N95 8GB, N95, N85, N82, N81 8GB, N80, E90, E71,
   http://www.gsm-extreme.net/showthread.php?t=25493


OMAP2420 -> ARM11, TMS320C55x DSP, ...
http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=dsp&sectionId=2&tabId=133&familyId=325

http://focus.ti.com/docs/prod/folders/print/tms320c55.html

# Improving 32-Channel DTMF Decoders in PBX Systems Using the TMS320C5x DSP    (HTM, 8 KB) 486 views
01 Jun 1996 Read Abstract
http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=spra085

# Use of the TMS320C5x Internal Oscillator With External Crystals or Resonators  (HTM, 8 KB) 404 views
01 Jul 1995 Read Abstract
http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=spra054

http://focus.ti.com/dsp/docs/dspfindtoolswresults.tsp?sectionId=3&tabId=1620&familyId=325&toolTypeId=5&applicationId=-1

DSP/BIOS 5.x Real-Time Operating System          DSPBIOS5
LANsEND
LANsEnd uCLinux
LEOs? (Linux Embedded Operating System)
OSEck

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/index.html
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dspbios/index.html
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dspbios/5_41_03_17/exports/bios_setuplinux_5_41_03_17.bin


http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.85.1703&rep=rep1&type=pdf
Trends in Hardware Architecture for Mobile Devices

  Dr. Margarita Esponda
  Institut f?r Informatik
  Freie Universit?t Berlin
  Takustr. 9
  14195 Berlin
  November 2004

  Page 11:
  2.3 Modern DSP Architectures
  2.3.1 The TMS320C55 series

  Page 13:
  2.3.2 The TigerSHARK Architecture

  Page 14:
  3 Moving from voice to data centric systems
  3.1 Hybrid Processors


http://pdf1.alldatasheet.com/datasheet-pdf/view/29043/TI/TMS320C50.html


TCS Modem
http://www.worldlogic.com.hk/tcs_versions.html

http://en.wikipedia.org/wiki/Base_Band_5

Nokia BB5 General information ;)
http://forum.gsmhosting.com/vbb/showthread.php?s=34c3b939b47546c9d6c523bb369dd92c&t=855490

Nokia SIM Lock Server (SL-1, SL-2, SL-3)
http://www.nokiaport.de/index.php?mid=&pid=dct
http://www.nokiaport.de/forum/thread.php?threadid=4666&sid=cf6be43b2f93404b29a9c1a04e2ba19d


"Added support for RAPIDO SL_2 based models (al phones who is unlocked by credits with DK, MT, UB)"
http://www.gsm-forum.eu/latest-files-shared-nokia/28691-nokia-free-unlock-rapido-bb5-plus.html
http://www.gsm2back.com/2009/04/hot-free-unlock-rapido-bb5-plus.html

http://www.mygsmbd.com/bb5-nokia-base-band-5/914-bb5-contact-service-trun-off-problem-imei-repairing-simple-guid.html

http://www.gsmchevli.com/support/
http://www.gsmchevli.com/support/BANDLOCK/
http://www.gsmchevli.com/support/BB5PM/N95-1/

-- 
kind regards,

	Benny

gpg     0xFC505AB0
jabber  benny at benny.de
sip     benny at benny.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20100223/450cff4a/attachment.bin>

From laforge at gnumonks.org  Tue Feb 23 20:57:45 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 23 Feb 2010 21:57:45 +0100
Subject: some links for Nokia N95
In-Reply-To: <20100223192121.GU17418@quelle.benny.de>
References: <20100223192121.GU17418@quelle.benny.de>
Message-ID: <20100223205745.GK21886@prithivi.gnumonks.org>

On Tue, Feb 23, 2010 at 08:21:21PM +0100, Benjamin Hagemann wrote:
 
> I have collected some informations / links for Nokia N95 and similar
> topics. Maybe some of them are good enough for the wiki.

> http://www.nokiaport.de/n95info/?id=processor

this is the application processor, not the baseband processor.

All nokia phones that I've ever seen run a nokia-internal/custom baseband
processor (sometimes referred as CMT).  They have generations like DCT3, DCT4,
DCT4+ or today something like BB4, BB5, ...   As those processors are custom
designs that are never sold to other companies, it is unlikely that any
documentation has leaked.

Thus, I doubt you will ever find sufficient information outside Nokia to
understand them sufficiently to run custom software on them.

The wider a particular baseband processor is used (i.e. the more handset makers
use it), the higher the probability that documentation will have leaked.

> http://www.phonewreck.com/wiki/index.php?title=Nokia_N95#Bill_of_Materials
> RF Transceiver:
> STMicroelectronics #4380206 Quad-band GSM/GPRS/EDGE, Dual-band UMTS/HSPDA (Unmarked)

STMicro (and now ST-Ericsson) build a number of modem designs, including
at least one design from Nokia.

> DSP/BIOS 5.x Real-Time Operating System          DSPBIOS5

the dsp-bios once again runs on the application processor
> 
> http://en.wikipedia.org/wiki/Base_Band_5
> 
> Nokia BB5 General information ;)
> http://forum.gsmhosting.com/vbb/showthread.php?s=34c3b939b47546c9d6c523bb369dd92c&t=855490

exactly, that's what I've been talking about :)

So to be frank: If somebody wants to work on GSM baseband software:
choose baseband processors that are old, originate from smaller [ODM]
manufacturers.

Modern baseband processors have crypographically signed code (and corresponding
bootloaders), and its much more difficult to find any documentation and/or
source.

I personally believe the most attractive target after the Ti Calypso (and
related) family is the Mediatek (MTK) family, i.e. MT622x based chipsets.
There are literally hundreds of smaller chinese companies manufacturing the
phones, and you can easily find schematics of the reference designs as well as
data sheets / reference manuals of the baseband processor.

Regarding the wiki:  Please don't put information about random phones in it,
as it will just add noise and raise the impression tha tthose phones are
supported.

Cheers,
	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)



From benny at benny.de  Wed Feb 24 19:10:13 2010
From: benny at benny.de (Benjamin Hagemann)
Date: Wed, 24 Feb 2010 20:10:13 +0100
Subject: some links for Nokia N95
In-Reply-To: <20100223192121.GU17418@quelle.benny.de>
References: <20100223192121.GU17418@quelle.benny.de>
Message-ID: <20100224191013.GK17418@quelle.benny.de>

hello :)

okay, I know here is the focos for open / free baseband implementation, 
first for the Calypso chipset.

I have collected some more links  about application proessor / nokia
smartphones  today. I hope these do not disturb so much.

Hw sx1                                                                          
http://sourceforge.net/apps/mediawiki/linux-on-sx1/index.php?title=Hardware_Siemens_SX1   

Linux on N70
http://n70linux.wordpress.com/ (by sledge ?) 

  "OMAP 1710 has Locosto/Calypso secure ROM"                                                                                                                   
  "All Nokia?s registers are re-mapped from orig OMAP specs.. Nokia did it 
   on purpose as special order to Texas Instruments.                               So we will have to blind-probe the memory addresses to find out all
   those right addressings.. As well as by disassembling current ARM apps."     

  "kernel-mode source available to play with!"

Linux on Nokia6630
http://franz47root.wordpress.com/2007/07/27/linux-on-nokia-6630/ (by sythenast) 


TI Presentation: OMAP - RF                                                      
http://www.microsoft.com/india/msdn/events/Session%206%20-%20Making%20Wireless.pps_                                                                             
Page 17                                                                         
                                                                                
http://www.texas-instruments.com/corp/docs/investor/analyst2003/delfassy/wireless.pdf                                                                           
Page 11 

Nokia Schematic Section 
http://www.gsm-extreme.net/showthread.php?t=22426 
http://www.gsm-extreme.net/showthread.php?t=25480 
http://www.gsm-extreme.net/showthread.php?t=22148
http://www.nokia-tuning.net/  

http://discussion.forum.nokia.com/forum/showthread.php?t=100774   

  "You have no control over it, and the only way to determine it is by
   examining the system source code to see how the manufacturer did it
   (unless you have access to a low-level debugger that can tell you
   what's going on in the device)."                                                => open source symbian 

http://developer.symbian.org/wiki/index.php/Symbian_OS_Internals/2._Hardware_for_Symbian_OS 

"Cellular Baseband Services Guide"                                              
http://developer.symbian.org/main/documentation/reference/s%5E3/doc_source/guide/Telephony/index.html

=> Baseband Channel Adaptor (BCA) Framework, Inter System Commmunications
(ISC)

http://developer.symbian.org/main/documentation/reference/s%5E3/doc_source/guide/Telephony/telephony_utilities/etel_telephony_api_for_applications/etel_telephony_api_for_applications_index.html#etel_telephony_api_for_applications.index 

but when you search about the Inter System Communications you only found
"restricted access" pages - only for members of Symbian Foundation.

Komponente f?r die Empfangssteuerung: (nokia) (end of page)                     
http://www.nokiaport.de/index.php?mid=&pid=iccompbb5                            
http://www.nokiaport.de/index.php?mid=&pid=iccompdct4  


interesting - an other project by Harald, which I do not noticed before:
http://openezx.org/                                                             
"The OpenEZX project tries to gather information about the Linux-based 
Motorola EZX phone platform (mainly the A780, E680 and E680i phones)."

and there I found sledge with this N70 project:

"Offtopic/ask for assistance: Linux on Nokia N70 (OMAP 1710)"  
https://lists.gnumonks.org/pipermail/openezx-devel/2009-June/002998.html  


FPGA Implementation of a GSM Baseband Processor                                 
http://www.techonline.com/electronics_directory/techpaper/193103486             
                                                                                
ATMEL Embedded ASIC Macrocell: Wireless Baseband ASF08 GSM Baseband Receive Port
http://www.atmelroma.it/dyn/resources/prod_documents/doc2756.pdf                
                                                                                
Signal Processing Blockset 6.10 - GSM Digital Down Converter                    
http://www.mathworks.de/products/sigprocblockset/demos.html?file=/products/demos/shipping/dspblks/dspddc.html  

-- 
kind regards,

	Benny

gpg     0xFC505AB0
jabber  benny at benny.de
sip     benny at benny.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20100224/2499ec44/attachment.bin>

From 246tnt at gmail.com  Tue Feb 23 23:06:54 2010
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 24 Feb 2010 00:06:54 +0100
Subject: Phone acting as a BTS
Message-ID: <866320f71002231506g4c743a35l793a8f978992974e@mail.gmail.com>

Hi,

Since the beginning, I'm wondering if it would be possible to turn one
of those cheap phone into a BTS. I'm n ot talking a full featured BTS
and the mod will involve hardwares changes obviously.
The more I look at it and the more I think it might work. No, I'm not
crazy, please bear with me until the end of this post :)

So, what are the obstacles (taking the C118 as an example):

* RX filters :

Obviously you would need to remove one and replace it with one for the
good band. I would only replace one of them so that you can use the
900 band for BTS and the 1800 band for MS for example (so that you can
still listen to a official bts and calibrate the clock).

* RX/TX switch

Those have ports that have frequency bands ... but .. do they really
filter that much ?


* MS can't TX/RX simultaneously.

I think you can take advantage of the fact. Imagine that you only ever
allocate channels on TS0,1 & 2. ( BCCH+SDCCH/4 + 2*TCH/F ), you could
divide your time like this :

TS0 - Capture FCCH of a nearby station to calibrate local vcxo
TS1 - Our BTS TS0 TX
TS2 - Our BTS TS1 TX
TS3 - Our BTS TS2 TX
TS4 - Our BTS TS0 RX
TS5 - Our BTS TS1 RX
TS6 - Our BTS TS2 RX
TS7 - nothing ...


But this can still be a battery powered handheld BTS :)


     Sylvain



From laforge at gnumonks.org  Wed Feb 24 06:25:42 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 24 Feb 2010 07:25:42 +0100
Subject: Phone acting as a BTS
In-Reply-To: <866320f71002231506g4c743a35l793a8f978992974e@mail.gmail.com>
References: <866320f71002231506g4c743a35l793a8f978992974e@mail.gmail.com>
Message-ID: <20100224062542.GB1236@prithivi.gnumonks.org>

Hi Sylvain,


On Wed, Feb 24, 2010 at 12:06:54AM +0100, Sylvain Munaut wrote:
 
> * RX filters :
> 
> Obviously you would need to remove one and replace it with one for the
> good band. I would only replace one of them so that you can use the
> 900 band for BTS and the 1800 band for MS for example (so that you can
> still listen to a official bts and calibrate the clock).

One problem is physical:  All the BTS type SAW filters I've been able to
find (and there are very few on the market) are a number of times larger
than the MS type filters, i.e. you won't be able to mechanically fit them.

> * RX/TX switch
> 
> Those have ports that have frequency bands ... but .. do they really
> filter that much ?

no, they're really just switches.  The only difference is Rx/Tx outputs.

> * MS can't TX/RX simultaneously.
> 
> I think you can take advantage of the fact. Imagine that you only ever
> allocate channels on TS0,1 & 2. ( BCCH+SDCCH/4 + 2*TCH/F ), you could
> divide your time like this :
> 
> TS0 - Capture FCCH of a nearby station to calibrate local vcxo
> TS1 - Our BTS TS0 TX
> TS2 - Our BTS TS1 TX
> TS3 - Our BTS TS2 TX
> TS4 - Our BTS TS0 RX
> TS5 - Our BTS TS1 RX
> TS6 - Our BTS TS2 RX
> TS7 - nothing ...

Interesting idea, but I doubt it would work all that well.  A C0 of a BTS is
required to transmit continuously on all timeslots.  The first step when
scanning for BTS's is a power scan.  So if a MS does a power scan, it might
do that at a time when your poor-mans-BTS is not transmitting and thus not find
it.

There might be other reasons why a MS is having problems with a
'discontinuously trasmitting' C0 of a BTS, as it is required by the spec.

David Burgess might know more about it.  Also, this behavior could be
simulated with OpenBTS, just to see how phones react to it.

But I'd say definitely worth a try...

-- 
- 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)



From 246tnt at gmail.com  Wed Feb 24 10:18:24 2010
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 24 Feb 2010 11:18:24 +0100
Subject: Phone acting as a BTS
In-Reply-To: <3d032e5d1002240210l195ae724id74d16545cbadab0@mail.gmail.com>
References: <866320f71002231506g4c743a35l793a8f978992974e@mail.gmail.com>
	<20100224062542.GB1236@prithivi.gnumonks.org>
	<3d032e5d1002240210l195ae724id74d16545cbadab0@mail.gmail.com>
Message-ID: <866320f71002240218m2d9a25bbrcc85701256d8d2ef@mail.gmail.com>

> But I guess you can use two MSs, one for transmit and one for receive to
> overcome this limitation. Is there any problems with this approach other
> then good clock synchronization?

You need a very good clock sync :) But that's something that could be
tried I guess.

> PS Looking at pictures of ip.access Nanostation we didn't find any duplexers.
> How does it work then? Or have we just missed duplexers on the photos?

Nope, no duplexers.

There is a TX antenna and a RX antenna. I think they are patch antenna
that don't radiate sideways so that they don't leak into one another.
There is also a massive chunk of metal between them to isolate :)


    Sylvain



From spaar at mirider.augusta.de  Wed Feb 24 08:30:03 2010
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Wed, 24 Feb 2010 08:30:03 
Subject: Phone acting as a BTS
Message-ID: <4b84e38c.mirider@mirider.augusta.de>

Hello Sylvain,

On Wed, 24 Feb 2010 00:06:54 +0100, "Sylvain Munaut" <246tnt at gmail.com> wrote:
> 
> Since the beginning, I'm wondering if it would be possible to turn one
> of those cheap phone into a BTS. I'm n ot talking a full featured BTS
> and the mod will involve hardwares changes obviously.
> The more I look at it and the more I think it might work. No, I'm not
> crazy, please bear with me until the end of this post :)

No, you are not crazy, to be true I thought about it for a while too ;-)

It all depends on what you want to do. Just transmitting a C0 so that
other phones nearby would recognize the new BTS should be rather easy.
You can synhronize on an offical network to adjust the clock, the clock
should be stable enough for a while so that other phones can detect the
new BTS. There should also be no severe limitations from any filter
when transmitting. You are probably out of the specification for the
transceiver and maybe the power amplifier but the power should still be
good enough to cover an area large enough for experiments. Transmitting
the required SBs and FBs should not be too difficult, the DSP cannot
generate them, however its rather easy to programm the ABB with the
raw bits of a burst.

Receiving is more difficult. The filters will influence the signal
quite a lot, however it should be still possible to receive strong
signals without the requirement for a hardware modification. I
already did a few experiments to find out how far the transceiver
could be tuned out of range, for GSM-900 I was able to detect the
frequency bursts of a 840 Mhz signal with about 40 dBm less strength
than receiving a similar signal inside the GSM-900 band. 840 Mhz
would be more than enough for receiving uplink signals in GSM-900.
I did not yet tried it for the transmitter, however I expect that
it can be used to transmit downlink frequencies too.

Just as an example for the influence of the filter: The Openmoko
Freerunner uses a Calypso based Tri-Band GSM modem, its available
for GSM-900 or GSM-850, the difference is mainly a different filter
in the RX path. However you can still use the GSM-850 variant with
GSM-900 if you are close enough to the BTS.

One real problem for the "phone as a BTS" idea is the detection
of the RACH bursts. You most certainly cannot use the DSP "as is"
for this task because it does not know about the special RACH burst.
It would probably require some modification (patches) to the DSP if
you want to detect and handle them.

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de



From Andreas.Eversberg at versatel.de  Wed Feb 24 10:30:58 2010
From: Andreas.Eversberg at versatel.de (Andreas.Eversberg)
Date: Wed, 24 Feb 2010 11:30:58 +0100
Subject: AW: Phone acting as a BTS
Message-ID: <B16317F2B1592B4492FC414114171CE6025F421E@FLBVEXCH01.versatel.local>

 

>> But I guess you can use two MSs, one for transmit and one for receive
to
>> overcome this limitation. Is there any problems with this approach
other
>> then good clock synchronization?
>
>You need a very good clock sync :) But that's something that could be
>tried I guess.

maybe..

you could sync the "receiver phone" to the "transmitter phone" by using
one timeslot. (TS7)

or you could sync the receiver phone to a nearby bts and use a control
line on the serial link to sync the transmitter phone to the receiver
phone. (you need to cross-connect the serial ports on the phones for
signalling anyway.)

andreas



From tiago.maluta at gmail.com  Wed Feb 24 19:00:00 2010
From: tiago.maluta at gmail.com (Tiago Maluta)
Date: Wed, 24 Feb 2010 19:00:00 +0000
Subject: Motorola C200
Message-ID: <600adaf51002241100je2eb719oecd78598087022ab@mail.gmail.com>

Hi,

First I'd like to thank all people involved with the project. I don't
know about GSM but as Harald said [1] I can contribute with
microcontroller development.

I have an old functional Motorola C200 phone. I'd like to know if it's
possible use it? I've search for some information about C200 baseband
processor without success, so I'm asking in the list.

[1] http://lists.osmocom.org/pipermail/baseband-devel/2010-February/000000.html

--tm



From laforge at gnumonks.org  Wed Feb 24 21:23:50 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 24 Feb 2010 22:23:50 +0100
Subject: Motorola C200
In-Reply-To: <600adaf51002241100je2eb719oecd78598087022ab@mail.gmail.com>
References: <600adaf51002241100je2eb719oecd78598087022ab@mail.gmail.com>
Message-ID: <20100224212350.GC1236@prithivi.gnumonks.org>

Hi Tiago,

On Wed, Feb 24, 2010 at 07:00:00PM +0000, Tiago Maluta wrote:
 
> First I'd like to thank all people involved with the project. I don't
> know about GSM but as Harald said [1] I can contribute with
> microcontroller development.

great.  do you have any particular area of interest?

> I have an old functional Motorola C200 phone. I'd like to know if it's
> possible use it? I've search for some information about C200 baseband
> processor without success, so I'm asking in the list.

As far as I know, the C2xx series is also a Compal ODM series, but it
uses the Ti Locosto chipset and not Calypso.  There are not as many
details known about the locosto, so as of now it is not clear how
difficult a port to that chipset would be.

-- 
- 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)



From tiago.maluta at gmail.com  Thu Feb 25 18:53:24 2010
From: tiago.maluta at gmail.com (Tiago Maluta)
Date: Thu, 25 Feb 2010 15:53:24 -0300
Subject: Motorola C200
In-Reply-To: <20100224212350.GC1236@prithivi.gnumonks.org>
References: <600adaf51002241100je2eb719oecd78598087022ab@mail.gmail.com>
	<20100224212350.GC1236@prithivi.gnumonks.org>
Message-ID: <600adaf51002251053v67b73479h7ea79d835ab655f4@mail.gmail.com>

On Wed, Feb 24, 2010 at 6:23 PM, Harald Welte <laforge at gnumonks.org> wrote:
> Hi Tiago,
>
> On Wed, Feb 24, 2010 at 07:00:00PM +0000, Tiago Maluta wrote:
>
>> First I'd like to thank all people involved with the project. I don't
>> know about GSM but as Harald said [1] I can contribute with
>> microcontroller development.
>
> great.  do you have any particular area of interest?
>

Not yet.

My first step after get any supported phone hardware is make tests
until I get familiar with the project. I'll follow the maillist and
report my tests and doubts. Maybe my first test I'll be using C200 (I
din't found any C1xx yet) to raise the chipset differences.

--tm



From tiago.maluta at gmail.com  Sat Feb 27 03:05:00 2010
From: tiago.maluta at gmail.com (Tiago Maluta)
Date: Sat, 27 Feb 2010 03:05:00 +0000
Subject: Motorola C200
In-Reply-To: <600adaf51002251053v67b73479h7ea79d835ab655f4@mail.gmail.com>
References: <600adaf51002241100je2eb719oecd78598087022ab@mail.gmail.com>
	<20100224212350.GC1236@prithivi.gnumonks.org>
	<600adaf51002251053v67b73479h7ea79d835ab655f4@mail.gmail.com>
Message-ID: <600adaf51002261905m3b888227ve857c442c7ac2fa9@mail.gmail.com>

After opened the C200 I noticed that this model (marketed in Brazil)
isn't a Compal ODM series but manufactured here in Brazil, I take one
picture. http://www.flickr.com/photos/maluta/4391126380/ and added an
note for each CI.
I've searched for this part numbers but didn't get much information, I
think this model wouldn't be useful to the project, I'll take a look
to one compatible one. :p

--tm



From laforge at gnumonks.org  Sat Feb 27 05:34:54 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 27 Feb 2010 06:34:54 +0100
Subject: Motorola C200
In-Reply-To: <600adaf51002261905m3b888227ve857c442c7ac2fa9@mail.gmail.com>
References: <600adaf51002241100je2eb719oecd78598087022ab@mail.gmail.com>
	<20100224212350.GC1236@prithivi.gnumonks.org>
	<600adaf51002251053v67b73479h7ea79d835ab655f4@mail.gmail.com>
	<600adaf51002261905m3b888227ve857c442c7ac2fa9@mail.gmail.com>
Message-ID: <20100227053454.GS9820@prithivi.gnumonks.org>

Hi!

On Sat, Feb 27, 2010 at 03:05:00AM +0000, Tiago Maluta wrote:

> After opened the C200 I noticed that this model (marketed in Brazil)
> isn't a Compal ODM series but manufactured here in Brazil, I take one
> picture. http://www.flickr.com/photos/maluta/4391126380/ and added an
> note for each CI.

HERCROMC200 is a relative of the Calypso chipset (HERCROM400G2).  We don't
know many details, but I would assume they are 95-98% identical from a
software point of view.

The TWL3012 is a bit old, I have only heard of TWL3014/16/25 so far.  However,
the TSM30 source code include support for many predecessors - they are just not
called by their name, so it will likely be trial+error to find out.

The RF3140 is only a power amplifier, not much to be done from the software
to support it.

What I'm more worried about is the part you have marked as 4dtoc8, which
must be what is the Rita/TRF6151 in the c1xx design.  Can you remove the metal
part on top and take a photograph of it?

> I've searched for this part numbers but didn't get much information, I
> think this model wouldn't be useful to the project, I'll take a look
> to one compatible one. :p

Definitely, to get started with our code, you should use a phoen that
is already supported - unless you have a lot of experience with low-level
bring up of ARM microcontrollers and boot loader reverse engineering.

But in a later step, trying to reproduce the C1xx results on the C200
would of course be very interesting and exciting!

-- 
- 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)



From huseyinturan at gmail.com  Wed Feb 24 21:11:12 2010
From: huseyinturan at gmail.com (Huseyin Turan)
Date: Wed, 24 Feb 2010 23:11:12 +0200
Subject: Where to start?
Message-ID: <4b627db01002241311g17ff1142ob66324319b9d5140@mail.gmail.com>

Hi;

It is really a good work. Congratulations...
I hope to develop in this project. Although I do not have any
experience about microcontroller development and gsm,
I think I can do. I can develop with C or C++.

Does anyone suggest me any document, site to start?

Thanks...



From nohl at virginia.edu  Thu Feb 25 19:50:54 2010
From: nohl at virginia.edu (Karsten Nohl)
Date: Thu, 25 Feb 2010 20:50:54 +0100
Subject: [airprobe-main] Cell phone tracking using ss7 hlr lookups
In-Reply-To: <b9c9d67f1002221109h72ed334fpa98d054990ce2d53@mail.gmail.com>
References: <b9c9d67f1002221109h72ed334fpa98d054990ce2d53@mail.gmail.com>
Message-ID: <AB2825AC-A527-4CE6-A236-1CE431A7EE41@virginia.edu>

Hi Yanis,

I'm CCing the OsmoconBB list who could perhaps help setup a MSC-GPS  
data collector.

On Feb 22, 2010, at 8:09 PM, Yanis Pavlidis wrote:

> Hi all,
>
> not exactly related to airprobe itself, but I am sure people on this  
> list could answer my question.
> So, after reading Tobias Engels' presentation on 25c3 ( http://events.ccc.de/congress/2008/Fahrplan/attachments/1262_25c3-locating-mobile-phones.pdf 
>  ), I found out you can perform an HLR lookup and come up with the  
> current MSC number that "controls" the connection of the subscriber,  
> for any subscriber.

Yes, every telco company and VoIP provider with SS7 access in the  
world always knows where you are. Scary.

> My question is, is this MSC number, visible from the mobile phone  
> side? If yes, somebody could actually wardrive, to get the MSC  
> number-to-location mapping?
> Can airprobe, or OpenBTS help?

Creating the {MSC -> location} mapping database would be a very  
worthwhile exercise. The data collection would have to happen from  
phones. Either we create an application for one of the popular phone  
platforms (Symbian, Android, iPhone). Anybody on the list knows if  
these phones expose the MSC number to application software?

Alternative, the Osmocon project could probably expose the MSC  
information easily. The project is still in early stages and it will  
take a few months until a collector software could be running. I  
wonder if any of the supported Motorola phones have GPS?

> Forgive my ignorance on all-things-gsm, I am just beginning exploring!

Thanks for bringing up the topic!

> Thanks all,
> Yanis

Cheers,

	-Karsten



From holger at freyther.de  Thu Feb 25 21:03:26 2010
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Thu, 25 Feb 2010 22:03:26 +0100
Subject: [airprobe-main] Cell phone tracking using ss7 hlr lookups
In-Reply-To: <AB2825AC-A527-4CE6-A236-1CE431A7EE41@virginia.edu>
References: <b9c9d67f1002221109h72ed334fpa98d054990ce2d53@mail.gmail.com>
	<AB2825AC-A527-4CE6-A236-1CE431A7EE41@virginia.edu>
Message-ID: <201002252203.26633.holger@freyther.de>

On Thursday 25 February 2010 20:50:54 Karsten Nohl wrote:

> 
> Creating the {MSC -> location} mapping database would be a very
> worthwhile exercise. The data collection would have to happen from
> phones. Either we create an application for one of the popular phone
> platforms (Symbian, Android, iPhone). Anybody on the list knows if
> these phones expose the MSC number to application software?
> 
> Alternative, the Osmocon project could probably expose the MSC
> information easily. The project is still in early stages and it will
> take a few months until a collector software could be running. I
> wonder if any of the supported Motorola phones have GPS?

Hi,

I'm not aware of any GSM 04.08 message containing information
about the MSC (besides GMM Error Message MSC not reachable).

The only thing that is available is the Location Area Code and that
is broadcasted in the System Information Type. So I assume you
are meaning this one? In GSM it is possible to page you by LAC so
that is the closest you get by without more advanced messages.

Did you mean this? In that case we would be at a state where we
could easily write such a scanner application. It would scan the
ARFCNs, get the SIs write out the LAC, continue..


am I off?

z.



From nibbler at ccc.de  Thu Feb 25 22:03:54 2010
From: nibbler at ccc.de (nibbler)
Date: Thu, 25 Feb 2010 23:03:54 +0100
Subject: [airprobe-main] Cell phone tracking using ss7 hlr lookups
In-Reply-To: <AB2825AC-A527-4CE6-A236-1CE431A7EE41@virginia.edu>
References: <b9c9d67f1002221109h72ed334fpa98d054990ce2d53@mail.gmail.com>
	<AB2825AC-A527-4CE6-A236-1CE431A7EE41@virginia.edu>
Message-ID: <20100225230354.6b91dc57@minime>

Hi Karsten, all,

On Thu, 25 Feb 2010 20:50:54 +0100
Karsten Nohl <nohl at virginia.edu> wrote:

> > My question is, is this MSC number, visible from the mobile phone  
> > side? If yes, somebody could actually wardrive, to get the MSC  
> > number-to-location mapping?
> > Can airprobe, or OpenBTS help?
> 
> Creating the {MSC -> location} mapping database would be a very  
> worthwhile exercise. The data collection would have to happen from  
> phones. Either we create an application for one of the popular phone  
> platforms (Symbian, Android, iPhone). Anybody on the list knows if  
> these phones expose the MSC number to application software?

Yes, the answer is: No. The phone does not know about this.

It would have to be a service that incorporates a user or mobile
phone software based part that knows about the location and a network
based part that can perform a SMS routing request. Both of these would
have to be correlated.

The implementation of this in a way that honors privacy as well as
security is left as an exercise to the reader.

This is most certainly not a task within the scope of osmocom-bb.

cheers,
nibbler

p.s. the relevant cell specific information that is known to the phone
can be found in the first seven fields e.g. here:
http://www.nobbi.com/btsdb.php?netw=all&type=c&search=__L447L



From laforge at gnumonks.org  Fri Feb 26 07:23:32 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 26 Feb 2010 08:23:32 +0100
Subject: [airprobe-main] Cell phone tracking using ss7 hlr lookups
In-Reply-To: <AB2825AC-A527-4CE6-A236-1CE431A7EE41@virginia.edu>
References: <b9c9d67f1002221109h72ed334fpa98d054990ce2d53@mail.gmail.com>
	<AB2825AC-A527-4CE6-A236-1CE431A7EE41@virginia.edu>
Message-ID: <20100226072332.GD9820@prithivi.gnumonks.org>

On Thu, Feb 25, 2010 at 08:50:54PM +0100, Karsten Nohl wrote:

> >My question is, is this MSC number, visible from the mobile phone
> >side? If yes, somebody could actually wardrive, to get the MSC
> >number-to-location mapping?
> >Can airprobe, or OpenBTS help?
> 
> Creating the {MSC -> location} mapping database would be a very
> worthwhile exercise. The data collection would have to happen from
> phones. Either we create an application for one of the popular phone
> platforms (Symbian, Android, iPhone). Anybody on the list knows if
> these phones expose the MSC number to application software?

Sorry, the phones have no idea about this, as the current MSN number is an
attribute of the core GSM network.

You can only collect this information in the core network by means of some
form of access to the SS7 roming network (GSM MAP).

-- 
- 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)



From valerio at ftw.at  Fri Feb 26 10:54:23 2010
From: valerio at ftw.at (Valerio, Danilo)
Date: Fri, 26 Feb 2010 11:54:23 +0100
Subject: [airprobe-main] Cell phone tracking using ss7 hlr lookups
In-Reply-To: <AB2825AC-A527-4CE6-A236-1CE431A7EE41@virginia.edu>
References: <b9c9d67f1002221109h72ed334fpa98d054990ce2d53@mail.gmail.com>
	<AB2825AC-A527-4CE6-A236-1CE431A7EE41@virginia.edu>
Message-ID: <201002261154.23365.valerio@ftw.at>

On Thursday 25 February 2010 20:50:54 Karsten Nohl wrote:
> Yes, every telco company and VoIP provider with SS7 access in the  
> world always knows where you are. Scary.

A small OT with this (maybe stupid and privacy-unaware) question:

- Why would telco companies be interested in your location with an accuracy of hundreds (or even thousands) sq. Kilometers?
(note that most of the MSC datasheets declare to support millions of subscribers)

> Creating the {MSC -> location} mapping database would be a very  
> worthwhile exercise. The data collection would have to happen from  
> phones. Either we create an application for one of the popular phone  
> platforms (Symbian, Android, iPhone). Anybody on the list knows if  
> these phones expose the MSC number to application software?

Assuming you have access to the SS7,
you can get MSC areas by just picking up hundreds of telephone number from city X and see with which MSC the network responds for most of them.
There was something like this in the ppt from Tobias Engel.

Dan





From laforge at gnumonks.org  Sat Feb 27 20:19:55 2010
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 27 Feb 2010 21:19:55 +0100
Subject: C155 display driver
Message-ID: <20100227201955.GA9820@prithivi.gnumonks.org>

Hi!

Just to avoid any possible duplicate work: A member of this list already has a
working C155 color display driver.   So if you were thinking of working on
this: Please rather do another TODO item.

I'm supposed to be merging that driver during the next couple of days.

Cheers,
	Harald

p.s.: I'm back in Berlin now, will be working with zecke of getting layer2
(bi-directional) up and running.
-- 
- 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)



From prom at berlin.ccc.de  Sat Feb 27 20:21:44 2010
From: prom at berlin.ccc.de (Ingo Albrecht)
Date: Sat, 27 Feb 2010 21:21:44 +0100
Subject: Bootloader
Message-ID: <4B897ED8.3040303@berlin.ccc.de>

Hi everyone

Without further introduction and in a similar manner to laforge's last
mail I would like to note that I am working on a bootloader that will
allow for larger binaries in RAM and flexible flashing.

To avoid troublesome interaction between the Calypso bootrom (which we
use for interrupt redirection) and CFI support, I have decided to go for
an interrupt-less approach. So don't be surprised to see me committing a
polling mode to fundamental drivers (keypad, uart) sometime soon.
Luckily, the required changes are trivial.

I'll push my branch sometime soon, just dropping a line to keep everyone
informed. Feel free to drop a line in case you are interested in other
flash-based tasks like hammering out linkage details and implementing
some kind of filesystem.

Greetings
 prom



From roh at hyte.de  Sun Feb 28 02:55:12 2010
From: roh at hyte.de (Joachim Steiger)
Date: Sun, 28 Feb 2010 03:55:12 +0100
Subject: batter charging interface / iota madc block
Message-ID: <4B89DB10.5030902@hyte.de>

sorry for not writing anything earlier, but i'm currently moving so i'm
a bit short of time.

i have been working on the bci and madc block already, so if you are not
already done, i'd like to do that.

its a bit tricky since one needs to do quite a lot to charge the battery
correctly, but in the end we could even charge nimh and i guess small
lead batterys also if we want to (with different code).

i have done the irq handlers, the charger plug in detection and the
async madc stuff is already working.
it just needs some cleanup before commit.

about the bci stuff: i'm now done reading and understanding the iota
datasheets and appnotes (the latter one having invaluable information
not in the datasheets).
'just' need to get it written down in code and debug it. ;)

summary: if you can live with charging your batteries for another week
or 2, just try figuring out the ringer and or vibra for example

ps: according the the schem the vibra should be controlled by the auxdac
of iota. i poked it and some enable bit few minutes, but couldnt get it
doing anything.
so there is still a mystery or 2 left.


kind regards

--

roh



From spaar at mirider.augusta.de  Sun Feb 28 13:23:10 2010
From: spaar at mirider.augusta.de (Dieter Spaar)
Date: Sun, 28 Feb 2010 13:23:10 
Subject: batter charging interface / iota madc block
Message-ID: <4b8a6e3e.mirider@mirider.augusta.de>

Hello Joachim,

On Sun, 28 Feb 2010 03:55:12 +0100, "Joachim Steiger" <roh at hyte.de> wrote:
> 
> ps: according the the schem the vibra should be controlled by the auxdac
> of iota. i poked it and some enable bit few minutes, but couldnt get it
> doing anything.

Have you turned the Auxiliary DAC on ? It has its own power control
bit and bit 5 (ADACS) in TOGBR1 hat to be set to turn the Auxiliary DAC
on. I just did a quick test with a C123, and the following seems to
work:

  twl3025_reg_write(TOGBR1, 1 << 5); // turn ADAC on
  twl3025_reg_write(AUXDAC, 1000);
  delay_ms(1500);
  twl3025_reg_write(AUXDAC, 0);
  twl3025_reg_write(TOGBR1, 1 << 4); // turn ADAC off

Best regards,
  Dieter
-- 
Dieter Spaar, Germany                           spaar at mirider.augusta.de