From laforge at gnumonks.org  Mon May  7 08:45:06 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 7 May 2012 10:45:06 +0200
Subject: key generation on SIM failed (cause 2)
In-Reply-To: <726B505068782D49BB803FB7949E62370173A8726F@MARY.main.mobik.si>
References: <726B505068782D49BB803FB7949E62370173A7A94B@MARY.main.mobik.si>
	<CAHL+j0_rQrV5qdkadbwes=iv18w8z9N5ma313L_Xd7oxO4Qv2A@mail.gmail.com>
	<726B505068782D49BB803FB7949E62370173A7A97D@MARY.main.mobik.si>
	<CAHL+j086US9FNB6d-85dZ0bAdYkJQnurds1gyB7QOtoZQL2yZg@mail.gmail.com>
	<CAHL+j08iGFrgMNBv-5d62SDNVJOvkGLfyekWuZWeo9SkPaJRyA@mail.gmail.com>
	<726B505068782D49BB803FB7949E62370173A8726F@MARY.main.mobik.si>
Message-ID: <20120507084506.GG32115@prithivi.gnumonks.org>

Hi Alozij,

sorry for the late response.

On Thu, Apr 26, 2012 at 06:51:58AM +0000, Alojzij Sinur wrote:
> We tried to open it but there was no success with wireshark. Even with your plugin.

Thanks.  It seems like there is mostly a problem in splitting the APDUs.
So the trace seems to make sense if I look at the hexdump, but the
simtrace program seems to be unable to separate the APDUs from each
other.

> In both cases the phone was just turned on. PIN was disabled.
> 
> Please check if you see anything unusual in it.

I don't really see anything unusual.  But I think without being able to
reproduce your setup (using the same model sim card + phone), it will be
difficult to further analyze this problem.

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 Alojzij.Sinur at mobik.si  Mon May  7 07:56:06 2012
From: Alojzij.Sinur at mobik.si (Alojzij Sinur)
Date: Mon, 7 May 2012 07:56:06 +0000
Subject: key generation on SIM failed (cause 2)
References: <726B505068782D49BB803FB7949E62370173A7A94B@MARY.main.mobik.si>
	<CAHL+j0_rQrV5qdkadbwes=iv18w8z9N5ma313L_Xd7oxO4Qv2A@mail.gmail.com>
	<726B505068782D49BB803FB7949E62370173A7A97D@MARY.main.mobik.si>
	<CAHL+j086US9FNB6d-85dZ0bAdYkJQnurds1gyB7QOtoZQL2yZg@mail.gmail.com>
	<CAHL+j08iGFrgMNBv-5d62SDNVJOvkGLfyekWuZWeo9SkPaJRyA@mail.gmail.com> 
Message-ID: <726B505068782D49BB803FB7949E62370173A94294@MARY.main.mobik.si>

Hi.

DO you have any idea why this SIM does not work with osmocon software?

We still had no success. 

Thanks.

 

-----Original Message-----
From: Alojzij Sinur 
Sent: Thursday, April 26, 2012 8:52 AM
To: 'Sylvain Munaut'
Cc: baseband-devel at lists.osmocom.org; Jaka Nemanic
Subject: RE: key generation on SIM failed (cause 2)

Hi.

We received SIMTRACE and made some traces.
I attached them. 

We tried to open it but there was no success with wireshark. Even with your plugin.

In both cases the phone was just turned on. PIN was disabled.

Please check if you see anything unusual in it.

Thank You.

Regards,

Alojzij.

-----Original Message-----
From: Sylvain Munaut [mailto:246tnt at gmail.com] 
Sent: Thursday, April 05, 2012 2:42 PM
To: Alojzij Sinur
Cc: baseband-devel at lists.osmocom.org; Jaka Nemanic
Subject: Re: key generation on SIM failed (cause 2)

BTW, in the logs, do any of the other SIM access work ? Because what fails in those log is the "go back to MF" part which should happen a lot of time before as well.

Cheers,

    Sylvain

From GNUtoo at no-log.org  Sun May  6 22:04:33 2012
From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli)
Date: Mon, 07 May 2012 00:04:33 +0200
Subject: Sagem OT-290 trace phone / GSMTAP integration
In-Reply-To: <20120409131637.GE7895@prithivi.gnumonks.org>
References: <20120409131637.GE7895@prithivi.gnumonks.org>
Message-ID: <1810513.UXOrZHqVla@gnutoo-desktop>

On Monday, April 09, 2012 03:16:37 PM Harald Welte wrote:
> Hi all!
Hi,
> I would be willing to give away one of the two remaining OT-290 (for
> free) to anyone who would in return commit to developing a GSMTAP
> interface for it.
Since no one responded to that message, I guess no one is interested.
How important is that work?

> The message format on the serial UART between phone and PC is documented
> (PDF documentation by Sagem included with the phones).  So based on this
> documentation and an OT-290 phone, it should be possible to write a
> small command-line program that receives the GSM/GPRS messages from the
> OT-290 and sends them via GSMTAP into wireshark.
> 
> The result would then be similar to what
> http://cgit.osmocom.org/cgit/dct3-gsmtap/ is for DCT-3 phones.
How hard is it and how much time is needed is to implement that? is it 
possible to have a look to the specifications before deciding?

Denis.



From laforge at gnumonks.org  Mon May  7 07:26:13 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 7 May 2012 09:26:13 +0200
Subject: Sagem OT-290 trace phone / GSMTAP integration
In-Reply-To: <1810513.UXOrZHqVla@gnutoo-desktop>
References: <20120409131637.GE7895@prithivi.gnumonks.org>
	<1810513.UXOrZHqVla@gnutoo-desktop>
Message-ID: <20120507072613.GD32115@prithivi.gnumonks.org>

Hi Denis!

On Mon, May 07, 2012 at 12:04:33AM +0200, Denis 'GNUtoo' Carikli wrote:

> > I would be willing to give away one of the two remaining OT-290 (for
> > free) to anyone who would in return commit to developing a GSMTAP
> > interface for it.
>
> Since no one responded to that message, I guess no one is interested.

Unfortunately we haven't seen any volunteers, yes.

> How important is that work?

I think it will be very useful once the work GPRS RLC/MAC/PCU for
OpenBTS and/or osmo-bts is proceeding.

> How hard is it and how much time is needed is to implement that? is it
> possible to have a look to the specifications before deciding?

I will contact you in private mail about it.

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 tyson.key at gmail.com  Mon May  7 12:20:31 2012
From: tyson.key at gmail.com (Tyson Key)
Date: Mon, 7 May 2012 13:20:31 +0100
Subject: Sagem OT-290 trace phone / GSMTAP integration
Message-ID: <CAOrJ_03R+5R+HvgWuv91Bh68qf4xuAb7PRHiuHE+vd7u=L3a4A@mail.gmail.com>

Hi list,

It's my first time posting here, and I've just subscribed - so apologies
for totally wrecking archive threading.

I've just received a copy of the e-mail regarding the OT-290, thanks to
Andrew Back; and I'm wondering it's possible to discuss the feasibility of
implementing this functionality with Harald - since it doesn't seem to have
generated much interest from others, and I'm "fortunate" enough to live in
a small British town without EDGE coverage (which should make it easier to
test GPRS-related tracing functionality).

Although I'm unfamiliar with how things work in Osmocom, I've previously
worked on Wireshark dissectors for USB-encapsulated AT commands, and
various NFC/smartcard-related protocols (PN532, FeliCa and MiFare); and am
also familiar with Nokia's proprietary ISI baseband protocol, and parts of
ETSI's GSM/UMTS specifications - so this sort of stuff isn't totally alien
to me.

I'm also currently studying Computer Science as an undergraduate (at the
University of Bradford) - but I should be able to make time to work on this.

Thanks,

Tyson.

-- 
                                          Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20120507/46dc4dfa/attachment.htm>

From laforge at gnumonks.org  Mon May  7 17:55:59 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 7 May 2012 19:55:59 +0200
Subject: Sagem OT-290 trace phone / GSMTAP integration
In-Reply-To: <CAOrJ_03R+5R+HvgWuv91Bh68qf4xuAb7PRHiuHE+vd7u=L3a4A@mail.gmail.com>
References: <CAOrJ_03R+5R+HvgWuv91Bh68qf4xuAb7PRHiuHE+vd7u=L3a4A@mail.gmail.com>
Message-ID: <20120507175559.GK31273@prithivi.gnumonks.org>

Hi Tyson,

thanks for your introduction and for your interest in this project.

On Mon, May 07, 2012 at 01:20:31PM +0100, Tyson Key wrote:

> I've just received a copy of the e-mail regarding the OT-290, thanks to
> Andrew Back; and I'm wondering it's possible to discuss the feasibility of
> implementing this functionality with Harald - since it doesn't seem to have
> generated much interest from others, 

> and I'm "fortunate" enough to live in a small British town without
> EDGE coverage (which should make it easier to test GPRS-related
> tracing functionality).

Even in areas with EDGE coverage, the network will always fall back to
GPRS if you use a GPRS-only phone (like the OT-290).  So the fact that
your town only has GPRS doesn't make a difference here.

> Although I'm unfamiliar with how things work in Osmocom, I've previously
> worked on Wireshark dissectors for USB-encapsulated AT commands, and
> various NFC/smartcard-related protocols (PN532, FeliCa and MiFare); and am
> also familiar with Nokia's proprietary ISI baseband protocol, and parts of
> ETSI's GSM/UMTS specifications - so this sort of stuff isn't totally alien
> to me.

Cool, this sounds like a good set of skills to address this problem.

> I'm also currently studying Computer Science as an undergraduate (at the
> University of Bradford) - but I should be able to make time to work on this.

I guess time is the key aspect here.  I would definitely want to make
sure that whoever gets a OT-290 for implementing the GSMTAP interfacing
code is likely to be able to complete the task before GPRS is phased out ;)

So I guess I will leave it up to Denis and you to figure out who might
have more of an interest and/or time in this.

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 GNUtoo at no-log.org  Tue May  8 16:27:02 2012
From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli)
Date: Tue, 08 May 2012 18:27:02 +0200
Subject: Sagem OT-290 trace phone / GSMTAP integration
In-Reply-To: <CAOrJ_03R+5R+HvgWuv91Bh68qf4xuAb7PRHiuHE+vd7u=L3a4A@mail.gmail.com>
References: <CAOrJ_03R+5R+HvgWuv91Bh68qf4xuAb7PRHiuHE+vd7u=L3a4A@mail.gmail.com>
Message-ID: <12264363.QrRvXQokBc@gnutoo-desktop>

On Monday, May 07, 2012 01:20:31 PM Tyson Key wrote:
> Hi list,
Hi, and sorry for the delay of responding. 
> Although I'm unfamiliar with how things work in Osmocom,
That doesn't seem a problem at all.
The goal is only to interface the trace phone with wireshark trough gsmtap.
> I've previously
> worked on Wireshark dissectors for USB-encapsulated AT commands, and
> various NFC/smartcard-related protocols (PN532, FeliCa and MiFare);
I never worked on wireshark but that seem a usefull skill.
> and am also familiar with Nokia's proprietary ISI baseband protocol,
good, I know a bit ISI too but not too much in detail(I was involved in the 
port of SHR and freesmartphone to the nokia n900).
That skill can help a lot too.
> and parts of
> ETSI's GSM/UMTS specifications - so this sort of stuff isn't totally alien
> to me.
good.

I don't know which one of us has the higher chances to succeed, but since you 
are willing to do it, and that you seem to have the required skills, and that 
I can work on other things as well(for instance finish the port nuttx to the 
calypso phones), I would say that you can take the phone assuming you really 
work on it and I hope you'll succeed.
I wish you good luck.

Also Harald Welte said:
>The majority of what those phones can do is now also possible with
>OsmocomBB.
And I've already two osmocomBB compatibles phone(the freerunner and the c155).
Altough I did not yet analyze the GSM protocol yet apart looking briefly at my 
own gsm packets without understanding the details, I'm still learning how the 
GSM protocol(Um and Abis) work(I only know the big picture so far) with the 
online slides of Joachim G?ller.

I'll also try to find out about all the other features of osmocombb, to look if 
they are really usefull for development in the GSM protocol,and how to use 
them legally in Europe.

So far I was concentrated on nuttx and only tried some of the osmocombb 
features recently(like the gsmtap/wireshark integration on the master branch).

Denis.



From azet at azet.org  Wed May  9 15:21:38 2012
From: azet at azet.org (Aaron Zauner)
Date: Wed, 9 May 2012 17:21:38 +0200
Subject: Encrypted GSM phone
In-Reply-To: <4F846B95.3000902@infosecurity.ch>
References: <CABdhxhQ9PC6XV5QYMv+H6N9wt5gZ4dfrwy+YO1ONM6cJqfYdgA@mail.gmail.com>
	<CAHL+j0-LQjdsOdo3dWLeVLt=NOogS7oVkj-CNDzfsdLvZs1tDw@mail.gmail.com>
	<4F83DB64.2080304@gmx.de>
	<53ED53E7-A644-4403-81D3-1778FDFF4341@jcis.net>
	<4F846B95.3000902@infosecurity.ch>
Message-ID: <CAN8NK9GS6ykpRNi09Go262ZTMEsiFGct1sD+SQuYns_+HRMfWg@mail.gmail.com>

i'm also still following this, but it seems to be a dead end.

off-topic:
current smartphones already have the capability to run sms[1]/voice
encryption software or voip with encryption [2].

[1] https://github.com/whispersystems/textsecure
[2] https://play.google.com/store/apps/details?id=com.privategsm.beta



From nathan at freitas.net  Wed May  9 15:54:27 2012
From: nathan at freitas.net (Nathan Freitas)
Date: Wed, 09 May 2012 11:54:27 -0400
Subject: Encrypted GSM phone
In-Reply-To: <CAN8NK9GS6ykpRNi09Go262ZTMEsiFGct1sD+SQuYns_+HRMfWg@mail.gmail.com>
References: <CABdhxhQ9PC6XV5QYMv+H6N9wt5gZ4dfrwy+YO1ONM6cJqfYdgA@mail.gmail.com>
	<CAHL+j0-LQjdsOdo3dWLeVLt=NOogS7oVkj-CNDzfsdLvZs1tDw@mail.gmail.com>
	<4F83DB64.2080304@gmx.de>
	<53ED53E7-A644-4403-81D3-1778FDFF4341@jcis.net>
	<4F846B95.3000902@infosecurity.ch>
	<CAN8NK9GS6ykpRNi09Go262ZTMEsiFGct1sD+SQuYns_+HRMfWg@mail.gmail.com>
Message-ID: <4FAA9333.5060405@freitas.net>

On 05/09/2012 11:21 AM, Aaron Zauner wrote:
> i'm also still following this, but it seems to be a dead end.
>
> off-topic:
> current smartphones already have the capability to run sms[1]/voice
> encryption software or voip with encryption [2].
>
> [1] https://github.com/whispersystems/textsecure
> [2] https://play.google.com/store/apps/details?id=com.privategsm.beta
>
The Guardian Project is working on an open, interoperable secure VoIP
stack and best practices as well:

Open Secure Telephony Network
- public testbed: https://ostel.me/
- research wiki: https://guardianproject.info/wiki/OSTN

Encrypting GSM without IP is possible, but in my experience of real
world use, it is incredibly difficult to make work between carriers,
countries, and generally the CDPD or second digital channel for
something like Cryptophone to work on, is near impossible to active on
most operators today.

+n




From francisg at fnop.net  Wed May  9 16:24:42 2012
From: francisg at fnop.net (Francisco Guerreiro)
Date: Wed, 9 May 2012 17:24:42 +0100
Subject: Encrypted GSM phone
In-Reply-To: <CAN8NK9GS6ykpRNi09Go262ZTMEsiFGct1sD+SQuYns_+HRMfWg@mail.gmail.com>
References: <CABdhxhQ9PC6XV5QYMv+H6N9wt5gZ4dfrwy+YO1ONM6cJqfYdgA@mail.gmail.com>
	<CAHL+j0-LQjdsOdo3dWLeVLt=NOogS7oVkj-CNDzfsdLvZs1tDw@mail.gmail.com>
	<4F83DB64.2080304@gmx.de>
	<53ED53E7-A644-4403-81D3-1778FDFF4341@jcis.net>
	<4F846B95.3000902@infosecurity.ch>
	<CAN8NK9GS6ykpRNi09Go262ZTMEsiFGct1sD+SQuYns_+HRMfWg@mail.gmail.com>
Message-ID: <CADKjWypTLMvaTezmr4FVS8Wr0LYZ+w70-Qb6mWWSQBirRnxVmQ@mail.gmail.com>

csipsimple supports zrtp

On Wed, May 9, 2012 at 4:21 PM, Aaron Zauner <azet at azet.org> wrote:

> i'm also still following this, but it seems to be a dead end.
>
> off-topic:
> current smartphones already have the capability to run sms[1]/voice
> encryption software or voip with encryption [2].
>
> [1] https://github.com/whispersystems/textsecure
> [2] https://play.google.com/store/apps/details?id=com.privategsm.beta
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20120509/efe4760e/attachment.htm>

From nibbler at ccc.de  Wed May  9 17:52:29 2012
From: nibbler at ccc.de (Michael Horn)
Date: Wed, 9 May 2012 19:52:29 +0200
Subject: Encrypted GSM phone
In-Reply-To: <CADKjWypTLMvaTezmr4FVS8Wr0LYZ+w70-Qb6mWWSQBirRnxVmQ@mail.gmail.com>
References: <CABdhxhQ9PC6XV5QYMv+H6N9wt5gZ4dfrwy+YO1ONM6cJqfYdgA@mail.gmail.com>
	<CAHL+j0-LQjdsOdo3dWLeVLt=NOogS7oVkj-CNDzfsdLvZs1tDw@mail.gmail.com>
	<4F83DB64.2080304@gmx.de>
	<53ED53E7-A644-4403-81D3-1778FDFF4341@jcis.net>
	<4F846B95.3000902@infosecurity.ch>
	<CAN8NK9GS6ykpRNi09Go262ZTMEsiFGct1sD+SQuYns_+HRMfWg@mail.gmail.com>
	<CADKjWypTLMvaTezmr4FVS8Wr0LYZ+w70-Qb6mWWSQBirRnxVmQ@mail.gmail.com>
Message-ID: <20120509195229.65de5907@x200s.home.nibbler.de>

On Wed, 9 May 2012 17:24:42 +0100
Francisco Guerreiro <francisg at fnop.net> wrote:

> csipsimple

on top of android. which is kinda moot.



From azet at azet.org  Wed May  9 18:22:34 2012
From: azet at azet.org (Aaron Zauner)
Date: Wed, 9 May 2012 20:22:34 +0200
Subject: Encrypted GSM phone
In-Reply-To: <20120509195229.65de5907@x200s.home.nibbler.de>
References: <CABdhxhQ9PC6XV5QYMv+H6N9wt5gZ4dfrwy+YO1ONM6cJqfYdgA@mail.gmail.com>
	<CAHL+j0-LQjdsOdo3dWLeVLt=NOogS7oVkj-CNDzfsdLvZs1tDw@mail.gmail.com>
	<4F83DB64.2080304@gmx.de>
	<53ED53E7-A644-4403-81D3-1778FDFF4341@jcis.net>
	<4F846B95.3000902@infosecurity.ch>
	<CAN8NK9GS6ykpRNi09Go262ZTMEsiFGct1sD+SQuYns_+HRMfWg@mail.gmail.com>
	<CADKjWypTLMvaTezmr4FVS8Wr0LYZ+w70-Qb6mWWSQBirRnxVmQ@mail.gmail.com>
	<20120509195229.65de5907@x200s.home.nibbler.de>
Message-ID: <CAN8NK9Gtm3ikKTT77YuYTnLErJTkr35_ZjA+ENCvTYR1PLQRsA@mail.gmail.com>

off-topic:
i had various problems with csipsimple while using 2g or 3g. the
built-in android 2.3+ voip implementation does not support voip via
telco network, only wifi.

On Wed, May 9, 2012 at 7:52 PM, Michael Horn <nibbler at ccc.de> wrote:
> On Wed, 9 May 2012 17:24:42 +0100
> Francisco Guerreiro <francisg at fnop.net> wrote:
>
>> csipsimple
>
> on top of android. which is kinda moot.
>



From pere5027 at vandals.uidaho.edu  Wed May 16 00:45:39 2012
From: pere5027 at vandals.uidaho.edu (Joshua Pereyda)
Date: Tue, 15 May 2012 17:45:39 -0700
Subject: What does FBSB RESP: result=255 mean?
In-Reply-To: <CAHL+j08dHmbuRtcwPFeyVVQnpROLCu6n7kZi==at=HrbeWtW2A@mail.gmail.com>
References: <CAGPHiNmRtN-4GQKtMxySuZO3ecppmzcxK=L3yiDNOMAm1N9Aqw@mail.gmail.com>
	<CAHL+j08dHmbuRtcwPFeyVVQnpROLCu6n7kZi==at=HrbeWtW2A@mail.gmail.com>
Message-ID: <CAGPHiNkO43GQfCTpi0yKUzEC4JC9-nLMmYNGkBYQMEUKc_mXVQ@mail.gmail.com>

Sylvain,

Thanks for the prompt and helpful reply (much more prompt than this
one).  That clarified quite a bit.

>> <000c> l1ctl.c:114 FBSB RESP: result=255
>>
>> I tried checking the code, but I can't quite figure out what's going on. ?It
>> looks like 255 is an error code, but I don't know where to go from there.
>
> It just means failure to sync ...
>
> Most likely the ARFCN you gave doesn't carry a valid C0.
>
> Note that it's only tested on 900/1800. US band support is not tested
> and probably not functional especially in burst_ind. Fixing it is left
> as an exercise to the reader ...

Haha, thanks.  I tested it in 850 and scanned through channels 128 to
251 and was able to identify a Paging Channel (PCH) at 180, and some
other stuff on some other channels.  So ccch_scan appears to work in
the 850 band; not sure about anything else or about 1900.

Thanks again, just replying to document the findings.


Josh




From laforge at gnumonks.org  Tue May  1 07:19:19 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 1 May 2012 09:19:19 +0200
Subject: should we continue to focus on nuttx?
In-Reply-To: <1335806068.61062.YahooMailNeo@web31816.mail.mud.yahoo.com>
References: <12150909.QP7hAsS4GH@gnutoo-desktop>
	<20120430160216.GG15890@prithivi.gnumonks.org>
	<1335806068.61062.YahooMailNeo@web31816.mail.mud.yahoo.com>
Message-ID: <20120501071919.GR15890@prithivi.gnumonks.org>

Hi Gregory,

thanks for your feedback, it is much appreciated.

On Mon, Apr 30, 2012 at 10:14:28AM -0700, Gregory Nutt wrote:
> So I have trouble understanding that the issue there.? And secondly,
> NuttX does have a rather complete graphics capability.? Probably the
> best in class:

The question is not whether it has the best graphics capabilities or
not.  The question is rather: Is it suitable for a 98x67 / 96x64
resolution display like in our target platforms?

To me, the NuttX graphics framework seemed to be aimed at much larger
resolution displays, more like a "real" computer with actual windows on
a desktop - not like a small cellphone where every pixel counts.
Please correct me if that impression was wrong.

So the question was not whether NuttX is good or bad - simply if it is
the best possible fit for our specific application :)

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 meeeecius at yahoo.com  Tue May  1 09:33:22 2012
From: meeeecius at yahoo.com (Micka A.)
Date: Tue, 1 May 2012 09:33:22 +0000 (UTC)
Subject: BER 
Message-ID: <loom.20120501T104418-694@post.gmane.org>

Hello,

there is one question, how in layer23 calculates BER?? 
for example it shows 143.. 120 .. and so on, there for sure not percent.




From laforge at gnumonks.org  Wed May  2 10:06:04 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 2 May 2012 12:06:04 +0200
Subject: May 09, 7pm / Osmocom meeting in Berlin
Message-ID: <20120502100604.GY32252@prithivi.gnumonks.org>

Hi all!

This is the announcement for the 3rd incarnation of our bi-weekly
Osmocom Berlin meeting.

	May 09, 7pm @ CCC Berlin, Marienstr. 11, 10113 Berlin

The schedule is as follows:

19:00	Introduction / Workshop on Osmocom SIMtrace (Kevin Redon)

	Kevin will introduce SIM/USIM/UICC cards, present what SIMtrace
	is and how it works, as well as how to use it to trace
	communication between SIM card and phone.

20:00	Informal discussions


If you are interested to show up, feel free to do so.  There is no
registration required.  If the initial part is not interesting to you,
feel free to join us later at 20:00.  The meeting is free as in "free
beer", despite no actual free beer being around ;)

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 GNUtoo at no-log.org  Wed May  2 16:33:12 2012
From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli)
Date: Wed, 02 May 2012 18:33:12 +0200
Subject: uwire.c relicensing
Message-ID: <1540323.mzfU4Ly1il@gnutoo-desktop>

Hi,

We(Alan Carvalho de Assis and me) also need the permission of Sylvain Munaut 
and Steve Markgraf for the relicensing of src/target/firmware/ of osmocombb for 
inclusion in nuttx(BSD licensed).

What we need right now is to get the permission on that file:
src/target/firmware/calypso/uwire.c

Basically we want to add LCD support as quickly as possible to the compal 
e99(And in parallel to fix the configs and the linker scripts to get more 
space).

Denis.



From 246tnt at gmail.com  Wed May  2 16:52:34 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 2 May 2012 18:52:34 +0200
Subject: uwire.c relicensing
In-Reply-To: <1540323.mzfU4Ly1il@gnutoo-desktop>
References: <1540323.mzfU4Ly1il@gnutoo-desktop>
Message-ID: <CAHL+j0-pJfkABTbA_=9H8rP8MS8WcwTQHQXUjgsq9ok53aOyBg@mail.gmail.com>

Hi,

> We(Alan Carvalho de Assis and me) also need the permission of Sylvain Munaut
> and Steve Markgraf for the relicensing of src/target/firmware/ of osmocombb for
> inclusion in nuttx(BSD licensed).

Well I can tell you that I will _not_ consent for anything related to
anything close to the GSM function (dsp / tsp / l1 / ....).


> What we need right now is to get the permission on that file:
> src/target/firmware/calypso/uwire.c

For that file I see no objections to dual licensing.

It's pretty trivial anyway ... I didn't even remember I wrote it ...

Cheers,

    Sylvain



From henk.vergonet at gmail.com  Sun May  6 14:09:52 2012
From: henk.vergonet at gmail.com (Henk)
Date: Sun, 6 May 2012 16:09:52 +0200
Subject: Ramblings of a Osmocom supporter
Message-ID: <CAMFK4TMkYewZw=HjN0U1UL_q-TcjTDqi_Fcnr-B2bPrdchfL_Q@mail.gmail.com>

Hi all,

First of all, what an exciting piece of hacking, well done guys!

So after one year I revisited the osmocom and flashed the bootloader
and the RSSI on my C116 device.

I was wondering is there something of a TODO of sorts in order to get
users of different skill levels involved?

One thing I can think of is extending the loader with functions to
access the DSP:
  read (p)rom, read write regs & memory, potentially adding DSP
patching support.

Regards,
Henk



From henk.vergonet at gmail.com  Sun May  6 14:16:54 2012
From: henk.vergonet at gmail.com (Henk)
Date: Sun, 6 May 2012 16:16:54 +0200
Subject: [ticket] RSSI fails to sync on 1800Mhz bands
Message-ID: <CAMFK4TOO8667+HiZxNiThhw5QqpuknP07Pk4HBOxZAphnNyRxw@mail.gmail.com>

Version: OSMOCOM Monitor Tool (revision osmocon_v0.0.0-1346-g186fefc-modified)

RSSI is running from flash

There seems to be a problem when trying to sync to the DCS bands also
the spectum window is not that what you expect. There seem to be a few
very strong peaks but the rest is flat.



From henk.vergonet at gmail.com  Sun May  6 14:26:10 2012
From: henk.vergonet at gmail.com (Henk)
Date: Sun, 6 May 2012 16:26:10 +0200
Subject: [ticket] RSSI fails to sync on 1800Mhz bands
In-Reply-To: <CAMFK4TOO8667+HiZxNiThhw5QqpuknP07Pk4HBOxZAphnNyRxw@mail.gmail.com>
References: <CAMFK4TOO8667+HiZxNiThhw5QqpuknP07Pk4HBOxZAphnNyRxw@mail.gmail.com>
Message-ID: <CAMFK4TMPRo+QgofA1++KtLF3KreMNMFS2B71HWQRzgPNQk52xQ@mail.gmail.com>

Addition:

Monitoring the 900 MHZ band works very well.
regards

On 5/6/12, Henk <henk.vergonet at gmail.com> wrote:
> Version: OSMOCOM Monitor Tool (revision
> osmocon_v0.0.0-1346-g186fefc-modified)
>
> RSSI is running from flash
>
> There seems to be a problem when trying to sync to the DCS bands also
> the spectum window is not that what you expect. There seem to be a few
> very strong peaks but the rest is flat.
>



From chris.pcguy.inci at gmail.com  Sun May  6 16:16:03 2012
From: chris.pcguy.inci at gmail.com (Christian Inci)
Date: Sun, 06 May 2012 18:16:03 +0200
Subject: [PATCH] Adding the manufacturer id of STMicroelectronics (resend)
Message-ID: <4FA6A3C3.4010806@gmail.com>

For supporting the flash on a Motorola C118.

Signed-off-by: Christian Inci <chris.pcguy.inci at gmail.com>



From chris.pcguy.inci at gmail.com  Fri May  4 05:42:06 2012
From: chris.pcguy.inci at gmail.com (Christian Inci)
Date: Fri, 4 May 2012 07:42:06 +0200
Subject: Adding the manufacturer id of STMicroelectronics
Message-ID: <mailman.49.1641743555.42824.baseband-devel@lists.osmocom.org>

For supporting the flash on a Motorola C118.

Signed-off-by: Christian Inci <chris.pcguy.inci at gmail.com>
---
 src/target/firmware/flash/cfi_flash.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/src/target/firmware/flash/cfi_flash.c b/src/target/firmware/flash/cfi_flash.c
index 69369d5..474dcbb 100644
--- a/src/target/firmware/flash/cfi_flash.c
+++ b/src/target/firmware/flash/cfi_flash.c
@@ -71,6 +71,7 @@ struct cfi_query {
 
 /* manufacturer ids */
 enum cfi_manuf {
+	CFI_MANUF_ST    = 0x0020,
 	CFI_MANUF_INTEL = 0x0089,
 };
 
@@ -532,7 +533,7 @@ int flash_init(flash_t * flash, void *base_addr)
 	if (res) {
 		return res;
 	}
-	if (m_id != CFI_MANUF_INTEL) {
+	if (m_id != CFI_MANUF_INTEL && m_id != CFI_MANUF_ST) {
 		/* we only support intel devices */
 		return -ENOTSUP;
 	}
-- 
1.7.8.6



--------------020907080906030400030607--



From holger at freyther.de  Sun May  6 17:37:49 2012
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sun, 06 May 2012 19:37:49 +0200
Subject: [PATCH] Adding the manufacturer id of STMicroelectronics (resend)
In-Reply-To: <4FA6A3C3.4010806@gmail.com>
References: <4FA6A3C3.4010806@gmail.com>
Message-ID: <4FA6B6ED.1000906@freyther.de>

On 05/06/2012 06:16 PM, Christian Inci wrote:
> -	if (m_id != CFI_MANUF_INTEL) {
> +	if (m_id != CFI_MANUF_INTEL && m_id != CFI_MANUF_ST) {
>  		/* we only support intel devices */
>  		return -ENOTSUP;

update the comment. :)



From chris.pcguy.inci at gmail.com  Sun May  6 20:42:33 2012
From: chris.pcguy.inci at gmail.com (Christian Inci)
Date: Sun, 06 May 2012 22:42:33 +0200
Subject: [PATCH] Adding the manufacturer id of STMicroelectronics (try 2)
Message-ID: <4FA6E239.5040804@gmail.com>

For supporting the flash on a Motorola C118.

Note:
Flashing rssi on it worked fine.

Signed-off-by: Christian Inci <chris.pcguy.inci at gmail.com>


From chris.pcguy.inci at gmail.com  Sun May  6 20:39:26 2012
From: chris.pcguy.inci at gmail.com (Christian Inci)
Date: Sun, 6 May 2012 22:39:26 +0200
Subject: Adding the manufacturer id of STMicroelectronics
Message-ID: <mailman.50.1641743555.42824.baseband-devel@lists.osmocom.org>

For supporting the flash on a Motorola C118.

Note:
Flashing rssi on it worked fine.

Signed-off-by: Christian Inci <chris.pcguy.inci at gmail.com>
---
 src/target/firmware/flash/cfi_flash.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/target/firmware/flash/cfi_flash.c b/src/target/firmware/flash/cfi_flash.c
index 69369d5..8ecd206 100644
--- a/src/target/firmware/flash/cfi_flash.c
+++ b/src/target/firmware/flash/cfi_flash.c
@@ -71,6 +71,7 @@ struct cfi_query {
 
 /* manufacturer ids */
 enum cfi_manuf {
+	CFI_MANUF_ST    = 0x0020,
 	CFI_MANUF_INTEL = 0x0089,
 };
 
@@ -532,8 +533,7 @@ int flash_init(flash_t * flash, void *base_addr)
 	if (res) {
 		return res;
 	}
-	if (m_id != CFI_MANUF_INTEL) {
-		/* we only support intel devices */
+	if (m_id != CFI_MANUF_INTEL && m_id != CFI_MANUF_ST) {
 		return -ENOTSUP;
 	}
 
-- 
1.7.8.6


--------------090106030808000805030408--



From laforge at gnumonks.org  Mon May  7 08:47:03 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 7 May 2012 10:47:03 +0200
Subject: [PATCH] Adding the manufacturer id of STMicroelectronics (try 2)
In-Reply-To: <4FA6E239.5040804@gmail.com>
References: <4FA6E239.5040804@gmail.com>
Message-ID: <20120507084703.GH32115@prithivi.gnumonks.org>

Hi Christian,

On Sun, May 06, 2012 at 10:42:33PM +0200, Christian Inci wrote:
> For supporting the flash on a Motorola C118.

thanks, I've merged your patch.
-- 
- 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 kesmtp at freenet.de  Mon May  7 18:37:30 2012
From: kesmtp at freenet.de (Mathias K.)
Date: Mon, 07 May 2012 20:37:30 +0200
Subject: jtag trouble j100i
Message-ID: <4FA8166A.9060508@freenet.de>

Hello,


i try to connect the j100i with the latest openocd (git) but there is always something wrong with
the embedded ice module. My configuration script is based on openocd_calypso.cfg and the
calypso_magic.svf. The main difference i can see is the idcode and the irlen. My changes in the
script looks like this:

set _CPUTAPID 0xf9001807

jtag newtap $_CHIPNAME dsp -expected-id 0x00000000 -irlen 5
jtag newtap $_CHIPNAME arm -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID

This changes are based on some appended svf scripts that simple scan the jtag chain to get more
informations.
The jtag_idcodes.svf returns the shifted idcodes like this:

SDR 32 TDI(ffffffff);
length = 32
TDI = 0xFFFFFFFF
TDO read = 0xF200300E
SDR 32 TDI(ffffffff);
length = 32
TDI = 0xFFFFFFFF
TDO read = 0xFFFFFFFF

The jtag_devices.svf told me the device count and the possible ir register count/length:

SIR 32 TDI(ffffffff);
length = 32
TDI = 0xFFFFFFFF
TDO read = 0xFFFFFE25

TDO: 11...11000100101 Looks like 3 ir registers with 4,3 and 2 bit length

SDR 32 TDI(ffffffff);
length = 32
TDI = 0xFFFFFFFF
TDO read = 0xFFFFFFFC

TDO: 11...1100 Looks like 2 devices


But every access to the embedded ice registers (they are located in the internal scan chain 2)
result in random (most time zero) values for the comms ctrl register and a cpu halt state. Is there
anything wrong? Is there a different "magic" 0x0b jtag command or argument for this kind of cpu?


Thanks & Regards,

Mathias
-------------- next part --------------
! based on http://www.fpga4fun.com/JTAG3.html

STATE RESET;
! LOAD IDCODE istruction
RUNTEST IDLE 5 TCK;
ENDDR DRPAUSE;

SDR 32 TDI(ffffffff);
SDR 32 TDI(ffffffff);
SDR 32 TDI(ffffffff);
SDR 32 TDI(ffffffff);
SDR 32 TDI(ffffffff);
SDR 32 TDI(ffffffff);
SDR 32 TDI(ffffffff);
SDR 32 TDI(ffffffff);
-------------- next part --------------
! http://www.fpga4fun.com/JTAG3.html

STATE RESET;
! LOAD IDCODE istruction
RUNTEST IDLE 5 TCK;
ENDIR IRPAUSE;
ENDDR DRPAUSE;

! fill ir reg with ones
! set devices in bypass mode
SIR 32 TDI(ffffffff);
SIR 32 TDI(ffffffff);
SIR 32 TDI(ffffffff);
SIR 32 TDI(ffffffff);
SIR 32 TDI(ffffffff);
SIR 32 TDI(ffffffff);
SIR 32 TDI(ffffffff);
SIR 32 TDI(ffffffff);

! flush dr register
SDR 32 TDI(00000000);
SDR 32 TDI(00000000);
SDR 32 TDI(00000000);
SDR 32 TDI(00000000);
SDR 32 TDI(00000000);
SDR 32 TDI(00000000);

! send ones to dr
! at the first one received
! there are no more devices
SDR 32 TDI(ffffffff);
SDR 32 TDI(ffffffff);
SDR 32 TDI(ffffffff);
SDR 32 TDI(ffffffff);
SDR 32 TDI(ffffffff);
SDR 32 TDI(ffffffff);

From steve at steve-m.de  Mon May  7 19:12:54 2012
From: steve at steve-m.de (Steve Markgraf)
Date: Mon, 07 May 2012 21:12:54 +0200
Subject: jtag trouble j100i
In-Reply-To: <4FA8166A.9060508@freenet.de>
References: <4FA8166A.9060508@freenet.de>
Message-ID: <4FA81EB6.4090705@steve-m.de>

Hi,

On 07.05.2012 20:37, Mathias K. wrote:
> set _CPUTAPID 0xf9001807
> jtag newtap $_CHIPNAME dsp -expected-id 0x00000000 -irlen 5

That doesn't look right, the idcode is 0x3100e02f and the DSP irlen is
8.

Have you actually tried openocd_calyso.cfg as-is? It works fine here,
even with a J100i.

Regards,
Steve



From kesmtp at freenet.de  Mon May  7 19:39:59 2012
From: kesmtp at freenet.de (Mathias K.)
Date: Mon, 07 May 2012 21:39:59 +0200
Subject: jtag trouble j100i
In-Reply-To: <4FA81EB6.4090705@steve-m.de>
References: <4FA8166A.9060508@freenet.de> <4FA81EB6.4090705@steve-m.de>
Message-ID: <4FA8250F.5080707@freenet.de>

Hello,

On 07.05.2012 21:12, Steve Markgraf wrote:
> Have you actually tried openocd_calyso.cfg as-is? It works fine here,
> even with a J100i.

yes, i have tried it before but i got the same results:

Info : 208 46 core.c:1069 jtag_examine_chain(): TAP calypso.dsp does not have IDCODE
Info : 209 46 core.c:951 jtag_examine_chain_display(): JTAG tap: calypso.arm tap/device found:
0xf9001807 (mfg: 0x403, part: 0x9001, ver: 0xf)
Warn : 210 46 core.c:951 jtag_examine_chain_display(): JTAG tap: calypso.arm       UNEXPECTED:
0xf9001807 (mfg: 0x403, part: 0x9001, ver: 0xf)
Error: 211 47 core.c:951 jtag_examine_chain_display(): JTAG tap: calypso.arm  expected 1 of 1:
0x3100e02f (mfg: 0x017, part: 0x100e, ver: 0x3)

...

Info : 219 55 embeddedice.c:232 embeddedice_build_reg_cache(): Embedded ICE version 0
Error: 220 55 embeddedice.c:297 embeddedice_build_reg_cache(): unknown EmbeddedICE version (comms
ctrl: 0x00000000)


Did you solder anything else than the jtag signals + gnd/vcc? Is there anything else to take care
(running firmware/custom firmware, batterie, external charger cable)? I use the arm usb tiny jtag
adapter and the signals looking good so far. I also reduced the jtag speed but there is no difference.


Regards,

Mathias



From steve at steve-m.de  Mon May  7 20:47:29 2012
From: steve at steve-m.de (Steve Markgraf)
Date: Mon, 07 May 2012 22:47:29 +0200
Subject: jtag trouble j100i
In-Reply-To: <4FA8250F.5080707@freenet.de>
References: <4FA8166A.9060508@freenet.de> <4FA81EB6.4090705@steve-m.de>
	<4FA8250F.5080707@freenet.de>
Message-ID: <4FA834E1.6060905@steve-m.de>

Which Testpoint did you use for TDO? TP4 or TP16?
TP16 would be correct.

Regards,
Steve



From kesmtp at freenet.de  Wed May  9 12:46:28 2012
From: kesmtp at freenet.de (Mathias K.)
Date: Wed, 09 May 2012 14:46:28 +0200
Subject: jtag trouble j100i
In-Reply-To: <4FA834E1.6060905@steve-m.de>
References: <4FA8166A.9060508@freenet.de> <4FA81EB6.4090705@steve-m.de>
	<4FA8250F.5080707@freenet.de> <4FA834E1.6060905@steve-m.de>
Message-ID: <4FAA6724.5070606@freenet.de>

Hello,

i use TP16 as TDO. I have tried it with pullups on all jtag lines but no success. There is a problem
with the arm usb tiny adapter and this kind of cpu.

I tried it with a self made adapter and i can see the correct idcode.


Thanks,

Mathias


On 07.05.2012 22:47, Steve Markgraf wrote:
> Which Testpoint did you use for TDO? TP4 or TP16?
> TP16 would be correct.
> 
> Regards,
> Steve
> 




From gouchengcheng at gmail.com  Wed May  9 03:40:46 2012
From: gouchengcheng at gmail.com (Chengcheng Gou)
Date: Wed, 9 May 2012 11:40:46 +0800
Subject: How to send a sms using BB
Message-ID: <CANV9D0kj0CP0qAL4jOziyJT=qr0FqdqNYNwwZWWpfLcg4BxsaQ@mail.gmail.com>

Hi,
anyone did try it?



From henk.vergonet at gmail.com  Wed May  9 05:52:49 2012
From: henk.vergonet at gmail.com (Henk)
Date: Wed, 09 May 2012 07:52:49 +0200
Subject: How to send a sms using BB
Message-ID: <shvdb5y4ctru8c3kbtyjjjrf.1336542769353@email.android.com>

It works

Chengcheng Gou <gouchengcheng at gmail.com>schreef:

>Hi,
>anyone did try it?
>

From GNUtoo at no-log.org  Sun May 13 14:34:04 2012
From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli)
Date: Sun, 13 May 2012 16:34:04 +0200
Subject: [nuttx] data abort issues(maybe linker script issues)
Message-ID: <3783738.1Kgid4MjaL@gnutoo-desktop>

Hi,

Since there is only 256k of internal memory(starting from 0x00800000 and 
finishing at 0x00840000 ) on the compal_e99, And that in nuttx we went over 
0x00840000(which is bad and may be cause a similar data abort than the 
follownig one), I wonder if we could use the external RAM like in the attached 
patch(we're a bit short on memory).

However the patch may still be wrong because it still produces a data abort:
nsh> nxtext
nxtext [2:100]
nsh> nxtext_initialize: Initializing external graphics device
nxtext_initialize: Open NX
[...]
nxtext_main: NX handle=1006ea0
nxtext_main: Set background color=32
[...]
row: 60 col: 0 npixels: 98
row: 61 col: 0 npixels: 98
row: 62 col: 0 npixels: 98
row: 63 col: 0 npixels: 98
row: 64 col: 0 npixels: 98
row: 65 col: 0 npixels: 98
row: 66 col: 0 npixels: 98
[...]
row: 50 col: 0 npixels: 98
rowData abort. PC: 00826090
Assertion failed at file:arm/up_dataabort.c line: 198 error code: 32773
sp:     01006d78
IRQ stack:
  base: 010003fc
  size: 000003fc
User stack:
  base: 01006e88
  size: 000007fc
01006d60: 00008005 000000b0 008212d4 008318f0 01006d80 000000c6 00008005 
000000b0
01006d80: 00000055 0100104c 008210ec a0000053 00821128 00826090 0082012c 
01001444
01006da0: 00000000 e1d2c0b0 e20c10ff 00000020 000000b0 00000055 0100104c 
00832df8
01006dc0: 01006ea4 00000000 00000000 0100104c 01006de0 00826014 00826090 
a0000053
01006de0: 00000011 01001058 01000d24 0082ac98 00832c48 01000d24 01000d24 
00832c48
01006e00: 01006ea4 01000d52 01006ea4 0082aef0 01006ea4 01000d24 00832c48 
00000018
01006e20: 008327d0 00000006 008327cd 0082a744 01006ea4 008327cd 00000008 
008327d6
01006e40: 00000001 00000001 00000000 008327cd 01006ea4 00000000 00000000 
0082a3c4
01006e60: 00000001 00000020 00000000 00000000 00000000 00000000 00000000 
00823c54
01006e80: 00000000 00000000 00000000 00000000 00000000 00000000 00000060 
80000810
R0: 01001444 00000000 e1d2c0b0 e20c10ff 00000020 000000b0 00000055 0100104c
R8: 00832df8 01006ea4 00000000 00000000 0100104c 01006de0 00826014 00826090
CPSR: a0000053

The PC is in the following malloc, but sometimes it was previously in 
semaphores...

00825fec <malloc>:
  825fec:       e92d4038        push    {r3, r4, r5, lr}
  825ff0:       e2504000        subs    r4, r0, #0
  825ff4:       0a000020        beq     82607c <malloc+0x90>
  825ff8:       e2844017        add     r4, r4, #23
  825ffc:       e3c4500f        bic     r5, r4, #15
  826000:       ebffffa2        bl      825e90 <mm_takesemaphore>
  826004:       e3550501        cmp     r5, #4194304    ; 0x400000
  826008:       23a00012        movcs   r0, #18
  82600c:       31a00005        movcc   r0, r5
  826010:       3bffffe9        blcc    825fbc <mm_size2ndx>
  826014:       e59f309c        ldr     r3, [pc, #156]  ; 8260b8 <malloc+0xcc>
  826018:       e0830200        add     r0, r3, r0, lsl #4
  82601c:       e5904008        ldr     r4, [r0, #8]
  826020:       ea000000        b       826028 <malloc+0x3c>
  826024:       e5944008        ldr     r4, [r4, #8]
  826028:       e3540000        cmp     r4, #0
  82602c:       0a000011        beq     826078 <malloc+0x8c>
  826030:       e5943000        ldr     r3, [r4]
  826034:       e1530005        cmp     r3, r5
  826038:       3afffff9        bcc     826024 <malloc+0x38>
  82603c:       ea000011        b       826088 <malloc+0x9c>
  826040:       e0840005        add     r0, r4, r5
  826044:       e7843005        str     r3, [r4, r5]
  826048:       e5805004        str     r5, [r0, #4]
  82604c:       e5845000        str     r5, [r4]
  826050:       e0842002        add     r2, r4, r2
  826054:       e5921004        ldr     r1, [r2, #4]
  826058:       e2011102        and     r1, r1, #-2147483648    ; 0x80000000
  82605c:       e1833001        orr     r3, r3, r1
  826060:       e5823004        str     r3, [r2, #4]
  826064:       ebffffba        bl      825f54 <mm_addfreechunk>
  826068:       e5943004        ldr     r3, [r4, #4]
  82606c:       e3833102        orr     r3, r3, #-2147483648    ; 0x80000000
  826070:       e5843004        str     r3, [r4, #4]
  826074:       e2844008        add     r4, r4, #8
  826078:       ebffffa1        bl      825f04 <mm_givesemaphore>
  82607c:       e1a00004        mov     r0, r4
  826080:       e8bd4038        pop     {r3, r4, r5, lr}
  826084:       e12fff1e        bx      lr
  826088:       e2842008        add     r2, r4, #8
  82608c:       e892000c        ldm     r2, {r2, r3}
  826090:       e5832008        str     r2, [r3, #8]
  826094:       e5943008        ldr     r3, [r4, #8]
  826098:       e3530000        cmp     r3, #0
  82609c:       1594200c        ldrne   r2, [r4, #12]
  8260a0:       1583200c        strne   r2, [r3, #12]
  8260a4:       e5942000        ldr     r2, [r4]
  8260a8:       e0653002        rsb     r3, r5, r2
  8260ac:       e353000f        cmp     r3, #15
  8260b0:       9affffec        bls     826068 <malloc+0x7c>
  8260b4:       eaffffe1        b       826040 <malloc+0x54>
  8260b8:       01001414        tsteq   r0, r4, lsl r4

The data abort prevents us from testing the lcd with the nuttx examples 
applications that makes use of the LCD....
(for now it only draws a background and then crash like mentioned above).

I've also attached the appconfig and the defconfig.

What other informations should I give?

The branch I'm using is here:
https://gitorious.org/gnutoo-s-for-upstream-osmocom-bb-and-nuttx-bb/nuttx-bb-
gta02/commits/lcd-cleanup (which will be rebased for cleanup purposes).

Denis.

From GNUtoo at no-log.org  Sun May 13 13:07:56 2012
From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli)
Date: Sun, 13 May 2012 15:07:56 +0200
Subject: [PATCH] [for upstream ???]: fix linker script for compal_e99 highram
Message-ID: <mailman.51.1641743555.42824.baseband-devel@lists.osmocom.org>

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo at no-log.org>
---
 nuttx/configs/compal_e99/nsh_highram/ld.script |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/nuttx/configs/compal_e99/nsh_highram/ld.script b/nuttx/configs/compal_e99/nsh_highram/ld.script
index 7096a61..34ce015 100644
--- a/nuttx/configs/compal_e99/nsh_highram/ld.script
+++ b/nuttx/configs/compal_e99/nsh_highram/ld.script
@@ -16,7 +16,7 @@ MEMORY
     LRAM (rw) : ORIGIN = 0x00800000, LENGTH = 0x00020000
     TRAM (rw) : ORIGIN = 0x00820000, LENGTH = 0x00020000
     /* compal-loaded binary: our unitialized data, stacks, heap */
-    IRAM (rw) : ORIGIN = 0x00840000, LENGTH = 0x00010000
+    IRAM (rw) : ORIGIN = 0x01000000, LENGTH = 0x011fffff
 }
 SECTIONS
 {
-- 
1.7.5.4


--nextPart2762333.I70qBvf3Po
Content-Disposition: attachment; filename="appconfig"
Content-Transfer-Encoding: 7Bit
Content-Type: text/x-matlab; charset="UTF-8"; name="appconfig"

############################################################################
# configs/compal_e99/nsh_highram/appconfig
#
#   Copyright (C) 2011 Gregory Nutt. All rights reserved.
#   Author: Gregory Nutt <spudmonkey at racsa.co.cr>
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
#
# 1. Redistributions of source code must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#    notice, this list of conditions and the following disclaimer in
#    the documentation and/or other materials provided with the
#    distribution.
# 3. Neither the name NuttX nor the names of its contributors may be
#    used to endorse or promote products derived from this software
#    without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
# COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
# OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
# AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
# ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGE.
#
############################################################################

# NSH shell
CONFIGURED_APPS += examples/nsh
CONFIGURED_APPS += system/readline
CONFIGURED_APPS += nshlib


# Path to example in apps/examples
#CONFIGURED_APPS += examples/hello
CONFIGURED_APPS += vsn/poweroff
#CONFIGURED_APPS += examples/ostest
CONFIGURED_APPS += examples/nxtext
#CONFIGURED_APPS += examples/nxhello
#CONFIGURED_APPS += examples/nxlines
#CONFIGURED_APPS += examples/nximage

--nextPart2762333.I70qBvf3Po
Content-Disposition: attachment; filename="defconfig"
Content-Transfer-Encoding: 7Bit
Content-Type: text/x-matlab; charset="UTF-8"; name="defconfig"

############################################################################
# configs/compal_e99/nsh_highram/defconfig
#
#   Copyright (C) 2007-2012 Gregory Nutt. All rights reserved.
#   Author: Gregory Nutt <gnutt at nuttx.org>
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
#
# 1. Redistributions of source code must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#    notice, this list of conditions and the following disclaimer in
#    the documentation and/or other materials provided with the
#    distribution.
# 3. Neither the name NuttX nor the names of its contributors may be
#    used to endorse or promote products derived from this software
#    without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
# FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
# COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
# OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
# AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
# ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGE.
#
############################################################################
#
# architecture selection
#
# CONFIG_ARCH - identifies the arch subdirectory and, hence, the
#   processor architecture.
# CONFIG_ARCH_family - for use in C code.  This identifies the
#   particular chip family that the architecture is implemented
#   in.
# CONFIG_ARCH_architecture - for use in C code.  This identifies the
#   specific architecture within the chip familyl.
# CONFIG_ARCH_CHIP - Identifies the arch/*/chip subdirectory
# CONFIG_ARCH_CHIP_name - For use in C code
# CONFIG_ARCH_BOARD - identifies the configs subdirectory and, hence,
#   the board that supports the particular chip or SoC.
# CONFIG_ARCH_BOARD_name - for use in C code
# CONFIG_BOARD_LOOPSPERMSEC - for delay loops
# CONFIG_ENDIAN_BIG - define if big endian (default is little endian)
# CONFIG_ROM_VECTORS - unique to c5471
# CONFIG_DRAM_END - the size of installed DRAM.
#   Unique to c5471
# CONFIG_ARCH_LEDS - Use LEDs to show state. Unique to c5471.
# CONFIG_ARCH_INTERRUPTSTACK - This architecture supports an interrupt
#   stack. If defined, this symbol is the size of the interrupt
#   stack in bytes.  If not defined, the user task stacks will be
#   used during interrupt handling.
# CONFIG_ARCH_STACKDUMP - Do stack dumps after assertions
#
CONFIG_ARCH=arm
CONFIG_ARCH_ARM=y
CONFIG_ARCH_ARM7TDMI=y
CONFIG_ARCH_CHIP=calypso
CONFIG_ARCH_CHIP_CALYPSO=y
CONFIG_ARCH_BOARD=compal_e99
CONFIG_ARCH_BOARD_COMPALE99=y
CONFIG_BOARD_LOOPSPERMSEC=1250
CONFIG_ROM_VECTORS=n
CONFIG_DRAM_END=0x00840000
CONFIG_ARCH_LEDS=n
CONFIG_ARCH_INTERRUPTSTACK=1024
CONFIG_ARCH_STACKDUMP=y

#
# C5471 specific device driver settings
#
# CONFIG_SERIAL_IRDA_CONSOLE - selects the IRDA UART for the
#   console ant ttys0 (default is the modem UART).
# CONFIG_UART_*_HWFLOWCONTROL - enables hardware flow control
# CONFIG_UART_*_RXBUFSIZE - Characters are buffered as received.
#   This specific the size of the receive buffer
# CONFIG_UART_*_TXBUFSIZE - Characters are buffered before
#   being sent.  This specific the size of the transmit buffer
# CONFIG_UART_*_BAUD - The configure BAUD of the UART.  Must be
# CONFIG_UART_*_BITS - The number of bits.  Must be either 7 or 8.
# CONFIG_UART_*_PARTIY - 0=no parity, 1=odd parity, 2=even parity
# CONFIG_UART_*_2STOP - Two stop bits
#
CONFIG_SERIAL_IRDA_CONSOLE=n
CONFIG_UART_IRDA_HWFLOWCONTROL=n
CONFIG_UART_MODEM_HWFLOWCONTROL=n
CONFIG_UART_IRDA_RXBUFSIZE=256
CONFIG_UART_MODEM_RXBUFSIZE=256
CONFIG_UART_IRDA_TXBUFSIZE=256
CONFIG_UART_MODEM_TXBUFSIZE=256
CONFIG_UART_IRDA_BAUD=115200
CONFIG_UART_MODEM_BAUD=115200
CONFIG_UART_IRDA_BITS=8
CONFIG_UART_MODEM_BITS=8
CONFIG_UART_IRDA_PARITY=0
CONFIG_UART_MODEM_PARITY=0
CONFIG_UART_IRDA_2STOP=0
CONFIG_UART_MODEM_2STOP=0

#
# C5471 Ethernet Driver settings
CONFIG_C5471_NET_STATS=n
ETHERNET_PHY_LU3X31T_T64=1
ETHERNET_PHY_AC101L=2
CONFIG_C5471_ETHERNET_PHY=ETHERNET_PHY_LU3X31T_T64
CONFIG_NET_C5471_AUTONEGOTIATION=y
CONFIG_NET_C5471_BASET100=n
CONFIG_NET_C5471_BASET10=n

#
# General build options
#
# CONFIG_RRLOAD_BINARY - make the rrload binary format used with
#   BSPs from www.ridgerun.com using the tools/mkimage.sh script
# CONFIG_INTELHEX_BINARY - make the Intel HEX binary format
#   used with many different loaders using the GNU objcopy program
#   Should not be selected if you are not using the GNU toolchain.
# CONFIG_RAW_BINARY - make a raw binary format file used with many
#   different loaders using the GNU objcopy program.  This option
#   should not be selected if you are not using the GNU toolchain.
# CONFIG_HAVE_LIBM - toolchain supports libm.a
#
CONFIG_RRLOAD_BINARY=n
CONFIG_INTELHEX_BINARY=n
CONFIG_RAW_BINARY=y
CONFIG_HAVE_LIBM=n

#
# General OS setup
#
# CONFIG_APPS_DIR - Identifies the relative path to the directory
#   that builds the application to link with NuttX.  Default: ../apps
# CONFIG_DEBUG - enables built-in debug options
# CONFIG_DEBUG_VERBOSE - enables verbose debug output
# CONFIG_DEBUG_SYMBOLS - build without optimization and with
#   debug symbols (needed for use with a debugger).
# CONFIG_MM_REGIONS - If the architecture includes multiple
#   regions of memory to allocate from, this specifies the
#   number of memory regions that the memory manager must
#   handle and enables the API mm_addregion(start, end);
# CONFIG_ARCH_LOWPUTC - architecture supports low-level, boot
#   time console output
# CONFIG_TICKS_PER_MSEC - The default system timer is 100Hz
#   or TICKS_PER_MSEC=10.  This setting may be defined to
#   inform NuttX that the processor hardware is providing
#   system timer interrupts at some interrupt interval other
#   than 10 msec.
# CONFIG_RR_INTERVAL - The round robin timeslice will be set
#   this number of milliseconds;  Round robin scheduling can
#   be disabled by setting this value to zero.
# CONFIG_SCHED_INSTRUMENTATION - enables instrumentation in
#   scheduler to monitor system performance
# CONFIG_TASK_NAME_SIZE - Spcifies that maximum size of a
#   task name to save in the TCB.  Useful if scheduler
#   instrumentation is selected.  Set to zero to disable.
# CONFIG_START_YEAR, CONFIG_START_MONTH, CONFIG_START_DAY -
#   Used to initialize the internal time logic.
# CONFIG_JULIAN_TIME - Enables Julian time conversions
# CONFIG_DEV_CONSOLE - Set if architecture-specific logic
#   provides /dev/console.  Enables stdout, stderr, stdin.
# CONFIG_DEV_LOWCONSOLE - Use the simple, low-level serial console
#   driver (minimul support)
# CONFIG_MUTEX_TYPES: Set to enable support for recursive and
#   errorcheck mutexes. Enables pthread_mutexattr_settype().
# CONFIG_PRIORITY_INHERITANCE : Set to enable support for priority
#   inheritance on mutexes and semaphores.
# CONFIG_SEM_PREALLOCHOLDERS: This setting is only used if priority
#   inheritance is enabled.  It defines the maximum number of
#   different threads (minus one) that can take counts on a
#   semaphore with priority inheritance support.  This may be
#   set to zero if priority inheritance is disabled OR if you
#   are only using semaphores as mutexes (only one holder) OR
#   if no more than two threads participate using a counting
#   semaphore.
# CONFIG_SEM_NNESTPRIO.  If priority inheritance is enabled,
#   then this setting is the maximum number of higher priority
#   threads (minus 1) than can be waiting for another thread
#   to release a count on a semaphore.  This value may be set
#   to zero if no more than one thread is expected to wait for
#   a semaphore.
# CONFIG_FDCLONE_DISABLE. Disable cloning of all file descriptors
#   by task_create() when a new task is started.  If set, all
#   files/drivers will appear to be closed in the new task.
# CONFIG_FDCLONE_STDIO. Disable cloning of all but the first
#   three file descriptors (stdin, stdout, stderr) by task_create()
#   when a new task is started. If set, all files/drivers will
#   appear to be closed in the new task except for stdin, stdout,
#   and stderr.
# CONFIG_SDCLONE_DISABLE. Disable cloning of all socket
#   desciptors by task_create() when a new task is started. If
#   set, all sockets will appear to be closed in the new task.
# CONFIG_NXFLAT. Enable support for the NXFLAT binary format.
#  This format will support execution of NuttX binaries located
#  in a ROMFS filesystem (see examples/nxflat).
#
#CONFIG_APPS_DIR=
CONFIG_DEBUG=n
CONFIG_DEBUG_VERBOSE=n
CONFIG_DEBUG_SYMBOLS=n
CONFIG_MM_REGIONS=2
CONFIG_ARCH_LOWPUTC=y
CONFIG_RR_INTERVAL=200
CONFIG_SCHED_INSTRUMENTATION=n
CONFIG_TASK_NAME_SIZE=0
CONFIG_START_YEAR=2007
CONFIG_START_MONTH=2
CONFIG_START_DAY=13
CONFIG_JULIAN_TIME=n
CONFIG_DEV_CONSOLE=y
CONFIG_DEV_LOWCONSOLE=n
CONFIG_MUTEX_TYPES=n
CONFIG_PRIORITY_INHERITANCE=n
CONFIG_SEM_PREALLOCHOLDERS=0
CONFIG_SEM_NNESTPRIO=0
CONFIG_FDCLONE_DISABLE=n
CONFIG_FDCLONE_STDIO=n
CONFIG_SDCLONE_DISABLE=y
CONFIG_NXFLAT=n

#
# The following can be used to disable categories of
# APIs supported by the OS.  If the compiler supports
# weak functions, then it should not be necessary to
# disable functions unless you want to restrict usage
# of those APIs.
#
# There are certain dependency relationships in these
# features.
#
# o mq_notify logic depends on signals to awaken tasks
#   waiting for queues to become full or empty.
# o pthread_condtimedwait() depends on signals to wake
#   up waiting tasks.
#
CONFIG_DISABLE_CLOCK=n
CONFIG_DISABLE_POSIX_TIMERS=n
CONFIG_DISABLE_PTHREAD=n
CONFIG_DISABLE_SIGNALS=n
CONFIG_DISABLE_MQUEUE=y
CONFIG_DISABLE_MOUNTPOINT=n
CONFIG_DISABLE_ENVIRON=n
CONFIG_STDIO_LINE_BUFFER=y
CONFIG_DISABLE_POLL=y

#
# FAT filesystem configuration
# CONFIG_FS_FAT - Enable FAT filesystem support
# CONFIG_FAT_SECTORSIZE - Max supported sector size
# CONFIG_FS_ROMFS - Enable ROMFS filesystem support
CONFIG_FS_FAT=n
CONFIG_FS_ROMFS=n

#
# Misc libc settings
#
# CONFIG_NOPRINTF_FIELDWIDTH - sprintf-related logic is a
#   little smaller if we do not support fieldwidthes
#
CONFIG_NOPRINTF_FIELDWIDTH=n

#
# Allow for architecture optimized implementations
#
# The architecture can provide optimized versions of the
# following to improve sysem performance
#
CONFIG_ARCH_MEMCPY=n
CONFIG_ARCH_MEMCMP=n
CONFIG_ARCH_MEMMOVE=n
CONFIG_ARCH_MEMSET=n
CONFIG_ARCH_STRCMP=n
CONFIG_ARCH_STRCPY=n
CONFIG_ARCH_STRNCPY=n
CONFIG_ARCH_STRLEN=n
CONFIG_ARCH_STRNLEN=n
CONFIG_ARCH_BZERO=n

#
# Sizes of configurable things (0 disables)
#
# CONFIG_MAX_TASKS - The maximum number of simultaneously
#   active tasks.  This value must be a power of two.
# CONFIG_MAX_TASK_ARGS - This controls the maximum number of
#   of parameters that a task may receive (i.e., maxmum value
#   of 'argc')
# CONFIG_NPTHREAD_KEYS - The number of items of thread-
#   specific data that can be retained
# CONFIG_NFILE_DESCRIPTORS - The maximum number of file
#   descriptors (one for each open)
# CONFIG_NFILE_STREAMS - The maximum number of streams that
#   can be fopen'ed
# CONFIG_NAME_MAX - The maximum size of a file name.
# CONFIG_STDIO_BUFFER_SIZE - Size of the buffer to allocate
#   on fopen. (Only if CONFIG_NFILE_STREAMS > 0)
# CONFIG_NUNGET_CHARS - Number of characters that can be
#   buffered by ungetc() (Only if CONFIG_NFILE_STREAMS > 0)
# CONFIG_PREALLOC_MQ_MSGS - The number of pre-allocated message
#   structures.  The system manages a pool of preallocated
#   message structures to minimize dynamic allocations
# CONFIG_MQ_MAXMSGSIZE - Message structures are allocated with
#   a fixed payload size given by this settin (does not include
#   other message structure overhead.
# CONFIG_MAX_WDOGPARMS - Maximum number of parameters that
#   can be passed to a watchdog handler
# CONFIG_PREALLOC_WDOGS - The number of pre-allocated watchdog
#   structures.  The system manages a pool of preallocated
#   watchdog structures to minimize dynamic allocations
# CONFIG_PREALLOC_TIMERS - The number of pre-allocated POSIX
#   timer structures.  The system manages a pool of preallocated
#   timer structures to minimize dynamic allocations.  Set to
#   zero for all dynamic allocations.
#
CONFIG_MAX_TASKS=16
CONFIG_MAX_TASK_ARGS=4
CONFIG_NPTHREAD_KEYS=4
CONFIG_NFILE_DESCRIPTORS=8
CONFIG_NFILE_STREAMS=8
CONFIG_NAME_MAX=32
CONFIG_STDIO_BUFFER_SIZE=1024
CONFIG_NUNGET_CHARS=2
CONFIG_PREALLOC_MQ_MSGS=0
CONFIG_MQ_MAXMSGSIZE=32
CONFIG_MAX_WDOGPARMS=4
CONFIG_PREALLOC_WDOGS=8
CONFIG_PREALLOC_TIMERS=8

# SPI driver
# CONFIG_SPI_OWNBUS - Set if there is only one active device
#   on the SPI bus.  No locking or SPI configuration will be performed.
#   It is not necessary for clients to lock, re-configure, etc..
# CONFIG_SPI_EXCHANGE - Driver supports a single exchange method
#   (vs a recvblock() and sndblock ()methods)
#
CONFIG_SPI_OWNBUS=y
CONFIG_SPI_EXCHANGE=y

#
# TCP/IP and UDP support via uIP
# CONFIG_NET - Enable or disable all network features
# CONFIG_NET_IPv6 - Build in support for IPv6
# CONFIG_NSOCKET_DESCRIPTORS - Maximum number of socket descriptors per task/thread.
# CONFIG_NET_SOCKOPTS - Enable or disable support for socket options
# CONFIG_NET_BUFSIZE - uIP buffer size
# CONFIG_NET_TCP - TCP support on or off
# CONFIG_NET_TCP_CONNS - Maximum number of TCP connections (all tasks)
# CONFIG_NET_TCP_READAHEAD_BUFSIZE - Size of TCP read-ahead buffers
# CONFIG_NET_NTCP_READAHEAD_BUFFERS - Number of TCP read-ahead buffers (may be zero)
# CONFIG_NET_TCPBACKLOG - Incoming connections pend in a backlog until
#   accept() is called. The size of the backlog is selected when listen() is called.
# CONFIG_NET_MAX_LISTENPORTS - Maximum number of listening TCP ports (all tasks)
# CONFIG_NET_UDP - UDP support on or off
# CONFIG_NET_UDP_CHECKSUMS - UDP checksums on or off
# CONFIG_NET_UDP_CONNS - The maximum amount of concurrent UDP connections
# CONFIG_NET_ICMP - ICMP ping response support on or off
# CONFIG_NET_ICMP_PING - ICMP ping request support on or off
# CONFIG_NET_PINGADDRCONF - Use "ping" packet for setting IP address
# CONFIG_NET_STATISTICS - uIP statistics on or off
# CONFIG_NET_RECEIVE_WINDOW - The size of the advertised receiver's window
# CONFIG_NET_ARPTAB_SIZE - The size of the ARP table
# CONFIG_NET_BROADCAST - Broadcast support
# CONFIG_NET_FWCACHE_SIZE - number of packets to remember when looking for duplicates
#
CONFIG_NET=n
CONFIG_NET_IPv6=n
CONFIG_NSOCKET_DESCRIPTORS=8
CONFIG_NET_SOCKOPTS=y
CONFIG_NET_BUFSIZE=420
CONFIG_NET_TCP=y
CONFIG_NET_TCP_CONNS=8
CONFIG_NET_NTCP_READAHEAD_BUFFERS=32
CONFIG_NET_TCPBACKLOG=n
CONFIG_NET_MAX_LISTENPORTS=8
CONFIG_NET_UDP=y
CONFIG_NET_UDP_CHECKSUMS=y
#CONFIG_NET_UDP_CONNS=4
CONFIG_NET_ICMP=y
CONFIG_NET_ICMP_PING=n
#CONFIG_NET_PINGADDRCONF=0
CONFIG_NET_STATISTICS=y
#CONFIG_NET_RECEIVE_WINDOW=
#CONFIG_NET_ARPTAB_SIZE=8
CONFIG_NET_BROADCAST=n
#CONFIG_NET_FWCACHE_SIZE=2

#
# UIP Network Utilities
# CONFIG_NET_DHCP_LIGHT - Reduces size of DHCP
# CONFIG_NET_RESOLV_ENTRIES - Number of resolver entries
CONFIG_NET_DHCP_LIGHT=n
CONFIG_NET_RESOLV_ENTRIES=4

#
# Settings for examples/uip
CONFIG_EXAMPLE_UIP_NOMAC=y
CONFIG_EXAMPLE_UIP_IPADDR=(10<<24|0<<16|0<<8|2)
CONFIG_EXAMPLE_UIP_DRIPADDR=(10<<24|0<<16|0<<8|1)
CONFIG_EXAMPLE_UIP_NETMASK=(255<<24|255<<16|255<<8|0)
CONFIG_EXAMPLE_UIP_DHCPC=n

#
# Settings for examples/nettest
CONFIG_EXAMPLE_NETTEST_SERVER=n
CONFIG_EXAMPLE_NETTEST_PERFORMANCE=n
CONFIG_EXAMPLE_NETTEST_NOMAC=y
CONFIG_EXAMPLE_NETTEST_IPADDR=(10<<24|0<<16|0<<8|2)
CONFIG_EXAMPLE_NETTEST_DRIPADDR=(10<<24|0<<16|0<<8|1)
CONFIG_EXAMPLE_NETTEST_NETMASK=(255<<24|255<<16|255<<8|0)
CONFIG_EXAMPLE_NETTEST_CLIENTIP=(10<<24|0<<16|0<<8|1)

#
# Settings for examples/nsh
CONFIG_NSH_CONSOLE=y
CONFIG_NSH_TELNET=n
CONFIG_NSH_IOBUFFER_SIZE=512
CONFIG_NSH_CMD_SIZE=40
CONFIG_NSH_STACKSIZE=4096
CONFIG_NSH_DHCPC=n
CONFIG_NSH_NOMAC=y
CONFIG_NSH_IPADDR=(10<<24|0<<16|0<<8|2)
CONFIG_NSH_DRIPADDR=(10<<24|0<<16|0<<8|1)
CONFIG_NSH_NETMASK=(255<<24|255<<16|255<<8|0)
CONFIG_NSH_BUILTIN_APPS=y


#
# LCD Drivers settings
CONFIG_NX_LCDDRIVER=y
CONFIG_LCD_SSD1783=y

#
# Graphics
CONFIG_NX=y
CONFIG_NXCONSOLE=n
CONFIG_NX_KBD=y
CONFIG_LCD_MAXPOWER=1
CONFIG_NX_BLOCKING=y
CONFIG_NX_DISABLE_1BPP=y
CONFIG_NX_DISABLE_2BPP=y
CONFIG_NX_DISABLE_4BPP=y
CONFIG_NX_DISABLE_8BPP=n
CONFIG_NX_DISABLE_16BPP=y
CONFIG_NX_DISABLE_32BPP=y
CONFIG_NXCONSOLE_BPP=8
CONFIG_NXCONSOLE_NOGETRUN=y
CONFIG_NXFONT_SANS17X22=y
CONFIG_NX_MULTIUSER=n
CONFIG_EXAMPLES_NXTEXT_BPP=8
CONFIG_EXAMPLES_NXTEXT_DEVNO=0

#
# Settings for examples/hello
CONFIG_EXAMPLES_HELLO_BUILTIN=y
CONFIG_EXAMPLES_NXHELLO_BUILTIN=y
CONFIG_EXAMPLES_NXTEXT_BUILTIN=y
CONFIG_EXAMPLES_NXIMAGE_BUILTIN=y
CONFIG_EXAMPLES_NXLINES_BUILTIN=y
CONFIG_EXAMPLES_NXLINES_EXTERNINIT=y
CONFIG_EXAMPLES_NXHELLO_EXTERNINIT=y
CONFIG_EXAMPLES_NXTEXT_EXTERNINIT=y
CONFIG_EXAMPLES_NXIMAGE_EXTERNINIT=y

#
# Settings for examples/wget
# CONFIG_EXAMPLE_WGET_URL - The URL of the file to get
# CONFIG_EXAMPLE_WGET_NOMAC - (May be defined to use software assigned MAC)
# CONFIG_EXAMPLE_WGET_IPADDR - Target IP address
# CONFIG_EXAMPLE_WGET_DRIPADDR - Default router IP addess
# CONFIG_EXAMPLE_WGET_NETMASK - Network mask
CONFIG_EXAMPLE_WGET_URL="http://www.nuttx.org/index.html"
CONFIG_EXAMPLE_WGET_NOMAC=y
CONFIG_EXAMPLE_WGET_IPADDR=(10L<<24|0L<<16|0L<<8|2L)
CONFIG_EXAMPLE_WGET_DRIPADDR=(10L<<24|0L<<16|0L<<8|1L)
CONFIG_EXAMPLE_WGET_NETMASK=(255L<<24|255L<<16|255L<<8|0L)

#
# Stack and heap information
#
# CONFIG_BOOT_RUNFROMFLASH - Some configurations support XIP
#   operation from FLASH but must copy initialized .data sections to RAM.
# CONFIG_BOOT_COPYTORAM -  Some configurations boot in FLASH
#   but copy themselves entirely into RAM for better performance.
# CONFIG_CUSTOM_STACK - The up_ implementation will handle
#   all stack operations outside of the nuttx model.
# CONFIG_STACK_POINTER - The initial stack pointer (arm7tdmi only)
# CONFIG_IDLETHREAD_STACKSIZE - The size of the initial stack.
#  This is the thread that (1) performs the inital boot of the system up
#  to the point where user_start() is spawned, and (2) there after is the
#  IDLE thread that executes only when there is no other thread ready to
#  run.
# CONFIG_USERMAIN_STACKSIZE - The size of the stack to allocate
#  for the main user thread that begins at the user_start() entry point.
# CONFIG_PTHREAD_STACK_MIN - Minimum pthread stack size
# CONFIG_PTHREAD_STACK_DEFAULT - Default pthread stack size
# CONFIG_HEAP_BASE - The beginning of the heap
# CONFIG_HEAP_SIZE - The size of the heap
#
CONFIG_BOOT_RUNFROMFLASH=n
CONFIG_BOOT_COPYTORAM=n
CONFIG_CUSTOM_STACK=n
#CONFIG_STACK_POINTER
CONFIG_IDLETHREAD_STACKSIZE=4096
CONFIG_USERMAIN_STACKSIZE=4096
CONFIG_PTHREAD_STACK_MIN=256
CONFIG_PTHREAD_STACK_DEFAULT=4096
CONFIG_HEAP_BASE=
CONFIG_HEAP_SIZE=

# Application configuration

CONFIG_APPS_DIR="../apps"

--nextPart2762333.I70qBvf3Po--




From sebastien at lorquet.fr  Mon May 14 07:43:35 2012
From: sebastien at lorquet.fr (Sebastien Lorquet)
Date: Mon, 14 May 2012 09:43:35 +0200
Subject: alcatel bic phone?
Message-ID: <4FB0B7A7.4010202@lorquet.fr>

hello,

what do you specialist think of the "bic phone" as an osmocombb candidate?
it's very cheap and available in france at various suppliers (including grocery
shops!).
It seems to be an Alcaltel OneTouch S210 (1) and this wikipedia page (2), even
if it does not mention this model, have several models with a MTK or Calypso
chipset indication.

I searched the best as I could but I didn't find any accurate info. Maybe one of
you may have already investigated this thing?

(1) http://en.wikipedia.org/wiki/Bic_Phone

(2) http://en.wikipedia.org/wiki/Alcatel_Mobile_Phones

Regards,
Sebastien



From laforge at gnumonks.org  Tue May 15 06:25:48 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 15 May 2012 08:25:48 +0200
Subject: alcatel bic phone?
In-Reply-To: <4FB0B7A7.4010202@lorquet.fr>
References: <4FB0B7A7.4010202@lorquet.fr>
Message-ID: <20120515062548.GD24346@prithivi.gnumonks.org>

Hi Sebastien,

On Mon, May 14, 2012 at 09:43:35AM +0200, Sebastien Lorquet wrote:
> what do you specialist think of the "bic phone" as an osmocombb candidate?

the problem is not so much to find inexpensive phones that are
available.

The problem is finding somebody who is willing to do the weeks to months
of reverse engineering the required hardware components and the DSP/ARM
API.  In case of (older) MTK chipsets, all that is missing IMHO is
somebody to look at the way the ARM drives the DSP (shared memory based
API) and write some code on the ARM side that can interface with our
existing L1.   But still this is something that requires both reverse
engineering skills, a lot of knowledge on GSM Layer1, as well as
probably some MS measurement equipment plus quite a bit of time.

At the moment, I don't think any of the classic OsmocomBB developers has
that time, as there are many other systems to investigate and play with.
We already have a working solution for GSM on both the MS side (with
inexpensive phones that are still available in decent quantitites), so
people are looking at 3G, Thuraya, TETRA, Inmarsat, etc...

Also, regarding TI Calypso, you will not find any current-day phone that
is still using it.  It was end of life in 2007/2008.

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 gouchengcheng at gmail.com  Mon May 14 13:27:32 2012
From: gouchengcheng at gmail.com (Chengcheng Gou)
Date: Mon, 14 May 2012 21:27:32 +0800
Subject: How to construct a "Slient SMS"
Message-ID: <CANV9D0=CNEJi7bMBBKQWt3RfuR1H4o2a1hu=w7MYu_Z2uTG1eQ@mail.gmail.com>

I want to study the Slient SMS, How can it be constructed? Anyone kowns?



From lukash at backstep.net  Mon May 14 13:33:33 2012
From: lukash at backstep.net (Lukas Kuzmiak)
Date: Mon, 14 May 2012 15:33:33 +0200
Subject: How to construct a "Slient SMS"
In-Reply-To: <CANV9D0=CNEJi7bMBBKQWt3RfuR1H4o2a1hu=w7MYu_Z2uTG1eQ@mail.gmail.com>
References: <CANV9D0=CNEJi7bMBBKQWt3RfuR1H4o2a1hu=w7MYu_Z2uTG1eQ@mail.gmail.com>
Message-ID: <CABV5EtGbWAMZ8HG_cwoHZc3RyHgo0SAaev8uVmLuaGGar_BcXQ@mail.gmail.com>

Hi,

depends :) basically a change of PID and/or DCS should help, refer to TS
03.40 specification, however this will require some testing and/or
device/gateway to send the sms with.

What do you intend to use silent sms for?

Cheers,
Lukas

On Mon, May 14, 2012 at 3:27 PM, Chengcheng Gou <gouchengcheng at gmail.com>wrote:

> I want to study the Slient SMS, How can it be constructed? Anyone kowns?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20120514/26e0a7fa/attachment.htm>

From dario.lombardo at libero.it  Tue May 15 07:30:43 2012
From: dario.lombardo at libero.it (Dario Lombardo)
Date: Tue, 15 May 2012 09:30:43 +0200
Subject: How to construct a "Slient SMS"
In-Reply-To: <CANV9D0=CNEJi7bMBBKQWt3RfuR1H4o2a1hu=w7MYu_Z2uTG1eQ@mail.gmail.com>
References: <CANV9D0=CNEJi7bMBBKQWt3RfuR1H4o2a1hu=w7MYu_Z2uTG1eQ@mail.gmail.com>
Message-ID: <CAOYJJfvLmthq+_G7TAj_PL5t8HW_HQ-d0BiBY_y1s5DEGvi+AA@mail.gmail.com>

Do you mean using osmocom or not?
If not the answer is a bit OT, but you can do it easily using AT commands
that almost every phone support.
Have a look at the command AT+CSMP.

On Mon, May 14, 2012 at 3:27 PM, Chengcheng Gou <gouchengcheng at gmail.com>wrote:

> I want to study the Slient SMS, How can it be constructed? Anyone kowns?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20120515/72fed3a6/attachment.htm>

From luca.bongiorni1 at studenti.unimi.it  Tue May 15 07:43:57 2012
From: luca.bongiorni1 at studenti.unimi.it (Luca Bongiorni)
Date: Tue, 15 May 2012 09:43:57 +0200
Subject: How to construct a "Slient SMS"
In-Reply-To: <CAOYJJfvLmthq+_G7TAj_PL5t8HW_HQ-d0BiBY_y1s5DEGvi+AA@mail.gmail.com>
References: <CANV9D0=CNEJi7bMBBKQWt3RfuR1H4o2a1hu=w7MYu_Z2uTG1eQ@mail.gmail.com>
	<CAOYJJfvLmthq+_G7TAj_PL5t8HW_HQ-d0BiBY_y1s5DEGvi+AA@mail.gmail.com>
Message-ID: <3E05663C-9CCE-4E44-A834-382A3CE64110@studenti.unimi.it>

Hei,
consider also, that some operators detects silent sms and restores automatically TP-PID and TP-DCS.

Moreover changing TP-PID/TP-DCS I suggest you to use also Message Waiting Indication-Discard option [1].

Some examples: 

#pdu='0011000C91'+str(num)+'0000AA0141'        # SMS Classic
#pdu='0011000C91'+str(num)+'4000AA0141'        # 0x40 (TP-PID) 
#pdu='0011000C91'+str(num)+'40C0AA0141'	  # 0x40(TP-PID) and 0xC0(Message Waiting Indication-Discard)

Cheers,
Luca

[1] http://mobiletidings.com/2009/07/08/voicemail-waiting-indication-sms/


> On Mon, May 14, 2012 at 3:27 PM, Chengcheng Gou <gouchengcheng at gmail.com> wrote:
> I want to study the Slient SMS, How can it be constructed? Anyone kowns?
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20120515/00d39f0e/attachment.htm>

From gouchengcheng at gmail.com  Tue May 15 02:46:41 2012
From: gouchengcheng at gmail.com (Chengcheng Gou)
Date: Tue, 15 May 2012 10:46:41 +0800
Subject: BB can`t send SMS successfully 100%?
Message-ID: <CANV9D0nXzndq-YrricntPi5NpO-wz+NivnB51H6cE8UEOtT3wg@mail.gmail.com>

I use the BB sending SMS, but it can`t be success to  do it 100%, Why?



From peter at stuge.se  Tue May 15 03:50:38 2012
From: peter at stuge.se (Peter Stuge)
Date: Tue, 15 May 2012 05:50:38 +0200
Subject: BB can`t send SMS successfully 100%?
In-Reply-To: <CANV9D0nXzndq-YrricntPi5NpO-wz+NivnB51H6cE8UEOtT3wg@mail.gmail.com>
References: <CANV9D0nXzndq-YrricntPi5NpO-wz+NivnB51H6cE8UEOtT3wg@mail.gmail.com>
Message-ID: <20120515035038.26746.qmail@stuge.se>

Chengcheng Gou wrote:
> I use the BB sending SMS, but it can`t be success to  do it 100%, Why?

It is impossible to give advice unless you provide all neccessary
information to describe the problem.

Please read this short document:
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

Consider the role of the different software components and include as
complete debug output as possible from the relevant parts. In this
case that could be the console output from the mobile program, and
additionally it would be nice if you attach a pcap file covering your
session and nothing but your session, including one successful SMS
send and one failed SMS send.

I guess that this may be a network problem, but your console messages
and packet capture will explain in detail what happens.


//Peter



From gouchengcheng at gmail.com  Tue May 15 13:14:17 2012
From: gouchengcheng at gmail.com (Chengcheng Gou)
Date: Tue, 15 May 2012 21:14:17 +0800
Subject: Has the TMSI has the limitation of using count?
Message-ID: <CANV9D0kiR4aU1qZyZmMfqFU_VqOsE7sxTmC2EXLvWmoCYcDXHA@mail.gmail.com>

I stat the TMSI of my near cell in CCCH, and not find a TMSI occurs
more than 6 times;
that`s Why?



From altaf329 at gmail.com  Wed May 16 14:49:02 2012
From: altaf329 at gmail.com (Altaf)
Date: Wed, 16 May 2012 07:49:02 -0700 (PDT)
Subject: Osmocom-bb Making a call
Message-ID: <1337179742649-3997264.post@n3.nabble.com>

Hello.

*Can someone help me out at this point of the Osmocom-bb project [making a
call]....

I am done with all the steps involved in the project. 
1. i have added the /.osmocom/bb/mobile.cfg
2. i am in the branch sylvian/testing

I used       git checkout --track -b remotes/origin/sylvian/testing     
command to enter this branch. It worked right... Am i RIGHT here?

3. when i download the firmware layer 1 on the phone it worked pretty good.
it says..*

handle_write(): finished
got 1 bytes from modem, data looks like: 1b  .
got 1 bytes from modem, data looks like: f6  .
got 1 bytes from modem, data looks like: 02  .
got 1 bytes from modem, data looks like: 00  .
got 1 bytes from modem, data looks like: 41  A
got 1 bytes from modem, data looks like: 03  .
got 1 bytes from modem, data looks like: 42  B
Received DOWNLOAD ACK from phone, your code is running now!
battery_compal_e88_init: starting up


OSMOCOM Layer 1 (revision osmocon_v0.0.0-1348-g083a2dc)
======================================================================
Device ID code: 0xb4fb
Device Version code: 0x0000
ARM ID code: 0xfff3
cDSP ID code: 0x0128
Die ID code: f2d81c119e039be2
======================================================================
REG_DPLL=0x2413
CNTL_ARM_CLK=0xf0a1
CNTL_CLK=0xff91
CNTL_RST=0xfff3
CNTL_ARM_DIV=0xfff9
======================================================================
Power up simcard:
Assert DSP into Reset
Releasing DSP from Reset
Setting some dsp_api.ndb values
Setting API NDB parameters
DSP Download Status: 0x0001
DSP API Version: 0x0000 0x0000
Finishing download phase
DSP Download Status: 0x0002
DSP API Version: 0x3606 0x0000
LOST 1161!
BAT-ADC: 549   6   0   0 1023 349 328 204  
	Charger at 51 mV.
	Battery at 3753 mV.
	Charging at 0 mA.
	Battery capacity is 69%.
	Battery range is 3199..3999 mV.
	Battery full at 468 LSB .. full at 585 LSB
	Charging at 239 LSB (204 mA).
	BCICTL2=0x3ff
	battery-info.flags=0x00000000
	bat_compal_e88_chg_state=0

*
4.  when i launch the MOBILE application it says like*

000f> sim.c:1223 init SIM client
<0006> gsm48_cc.c:63 init Call Control
<0007> gsm480_ss.c:231 init SS
<0017> gsm411_sms.c:63 init SMS
<0001> gsm48_rr.c:5479 init Radio Ressource process
<0005> gsm48_mm.c:1315 init Mobility Management process
<0005> gsm48_mm.c:1037 Selecting PLMN SEARCH state, because no SIM.
<0002> gsm322.c:5025 init PLMN process
<0003> gsm322.c:5026 init Cell Selection process
Mobile '1' initialized, please start phone now!
VTY available on port 4247.
<0005> subscriber.c:601 Requesting SIM file 0x2fe2
<000f> sim.c:209 got new job: SIM_JOB_READ_BINARY (handle=00000004)
<000f> sim.c:697 go MF
<000f> sim.c:241 SELECT (file=0x3f00)



000f> sim.c:949 command successfull
<000f> sim.c:151 sending result to callback function (type=0)
<0005> subscriber.c:360 received SMSP from SIM (sca=+49232********000)
<0005> subscriber.c:561 (ms 1) Done reading SIM card
(IMSI=26****************654 Germany, E-Plus)
<0005> subscriber.c:573 -> SIM card registered to 262 03 (Germany, E-Plus)
<0005> gsm48_mm.c:4379 (ms 1) Received 'MMR_REG_REQ' event
<0002> gsm322.c:3806 (ms 1) Event 'EVENT_SIM_INSERT' for automatic PLMN
selection in state 'A0 null'
<000e> gsm322.c:1372 Start search of last registered PLMN (mcc=262 mnc=03 
Germany, E-Plus)
<0002> gsm322.c:1376 Use RPLMN (mcc=262 mnc=03  Germany, E-Plus)
<0002> gsm322.c:800 new state 'A0 null' -> 'A1 trying RPLMN'
<0003> gsm322.c:4037 (ms 1) Event 'EVENT_NEW_PLMN' for Cell selection in
state 'C0 null'
<000e> gsm322.c:3619 Selecting PLMN (mcc=262 mnc=03  Germany, E-Plus)
<0003> gsm322.c:3628 Start normal cell selection.
<0003> gsm322.c:823 new state 'C0 null' -> 'C1 normal cell selection'
<0003> gsm322.c:2791 Scanning power for all frequencies.

*
Here its starts to search for frequencies and cells..... and see what
happens....
*

<0003> gsm322.c:2852 Scanning frequencies. (0..0)
<0003> gsm322.c:2913 Done with power scanning range.
<0003> gsm322.c:2791 Scanning power for all frequencies.
<0003> gsm322.c:2852 Scanning frequencies. (512(DCS)..512(DCS))
<0003> gsm322.c:2913 Done with power scanning range.
<0003> gsm322.c:2791 Scanning power for all frequencies.
<0003> gsm322.c:2852 Scanning frequencies. (975..975)
<0003> gsm322.c:2913 Done with power scanning range.
<0003> gsm322.c:2791 Scanning power for all frequencies.
<0003> gsm322.c:2813 Found no frequency.


This repeats all the TIME........


*I am able to login to the vty terminal and able to execute some
instructions.....
*
enable
show ms
show subscriber
etc*

when I try to make a call..... see what happens*

<0009> mnccms.c:570 Make call to 01747180018
<0009> mnccms.c:150  support TCH/H also
<0009> mnccms.c:174  support full rate v2
<0009> mnccms.c:178  support full rate v1
<0009> mnccms.c:187  support half rate v1
<0006> transaction.c:76 ms 1 allocates transaction (proto 3 trans_id 255
callref 1 mem 0x8cf7370)
<0006> gsm48_cc.c:243 new state NULL -> MM_CONNECTION_PEND
<0006> gsm48_cc.c:507 Sending MMCC_EST_REQ
<0005> gsm48_mm.c:3774 (ms 1) Received 'MMCC_EST_REQ' event in state MM idle
<0005> gsm48_mm.c:3777 -> substate PLMN search
<0005> gsm48_mm.c:3779 -> callref 1, transaction_id 255
<0005> gsm48_mm.c:3042 Init MM Connection, not in normal state.
<0006> gsm48_cc.c:2161 (ms 1) Received 'MMCC_REL_IND' in CC state
MM_CONNECTION_PEND
<0006> gsm48_cc.c:196 (ms 1 ti ff) Sending 'MNCC_REL_IND' to MNCC.
<0006> gsm48_cc.c:243 new state MM_CONNECTION_PEND -> NULL
<0006> transaction.c:104 ms 1 frees transaction (mem 0x8cf7370)
<0009> mnccms.c:372 Call has been released (cause 21)
<0009> mnccms.c:71 (call 1) Call removed.


0003> gsm322.c:2889 Getting PM for ARFCN 858(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 859(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 860(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 861(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 862(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 863(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 864(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 865(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 866(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 867(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 868(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 869(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 870(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 871(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 872(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 873(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 874(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 875(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 876(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 877(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 878(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 879(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 880(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 881(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 882(DCS) twice. Overwriting the
first! Please fix prim_pm.c
<0003> gsm322.c:2889 Getting PM for ARFCN 883(DCS) twice

I even find this sometimes................

can someone fix this for me.... where could be the error......

Looking forward for a helping hand.....


Thank you..



--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Osmocom-bb-Making-a-call-tp3997264.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From roladunjoye at gmail.com  Sun May 20 02:33:00 2012
From: roladunjoye at gmail.com (rola)
Date: Sat, 19 May 2012 19:33:00 -0700 (PDT)
Subject: Osmocom-bb Making a call
In-Reply-To: <1337179742649-3997264.post@n3.nabble.com>
References: <1337179742649-3997264.post@n3.nabble.com>
Message-ID: <1337481180142-4002984.post@n3.nabble.com>

First we are in the same shoe of fixing prim.c and I can assure you that if
you
find anyone that respond you must be lucky.

Secondly, you jumped the gun by making call when you very well know that
MS has not camped on any cell. There is no point in going ahead, just relax
take your time and open the damn code as only solution proffer for a case
as yours and mine.

Just to give a nudge, find more information about gsm servcie in your
location,
get a registered sim that work with 900Mhz. If you are lucky that the band
function
in your area, then set sim parameter too 900 band only and make use of stick
option
AFRCN. I believe by that OBB should work for you.

However, if you are so unlucky as I am with PCS band only working in my
area, then you
will have to roll up your sleeve, google GSM 03.22 TS and read through it.
That will
give you an idea of IDLE MODE state work. After that, bury yourself in OBB
code and open
file gsm322.c where the IDLE MODE is implemented. Doing this I assumed that
you are
already familiar with basic GSM technology. Thus, you can troubleshoot what
might be the
issue and find solution to it.

That is my best recipes for you now cause I am as well still battling with
the actual issue
you are having. If thing works out for you please let me know.

Best of luck.

Sincerely,

Rasak


--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Osmocom-bb-Making-a-call-tp3997264p4002984.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From altaf329 at gmail.com  Mon May 21 16:10:04 2012
From: altaf329 at gmail.com (Altaf)
Date: Mon, 21 May 2012 09:10:04 -0700 (PDT)
Subject: Osmocom-bb Making a call
In-Reply-To: <1337481180142-4002984.post@n3.nabble.com>
References: <1337179742649-3997264.post@n3.nabble.com>
	<1337481180142-4002984.post@n3.nabble.com>
Message-ID: <1337616604963-4005068.post@n3.nabble.com>

Thank you so much for your help....

I had bought a new SIM and started testing. and its WORKING. I am able to
make call and also sms.

I have two Motorola c123 handsets. One work very good and the other is also
camping onto a cell, doing all other scanning for frequencies and other
stuff but provides only emergency calls... I cud nt make calls from the
second handset.

Where do u stay. How come you dont have a GSM band in your area.

I started with the layer23 application. I didnt understand where to  use
this command. In which path??

    ./layer23 -a 871 -i 127.0.0.1

I dont understand where and how to launch this application. Can you kindly
explain me this.



Thanks in advance

Yours Sincerely

Altaf


--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Osmocom-bb-Making-a-call-tp3997264p4005068.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From onny at project-insanity.org  Mon May 21 16:14:35 2012
From: onny at project-insanity.org (Jonas Heinrich)
Date: Mon, 21 May 2012 16:14:35 +0000 (UTC)
Subject: Osmocom-bb Making a call
In-Reply-To: <1337616604963-4005068.post@n3.nabble.com>
References: <1337179742649-3997264.post@n3.nabble.com>
	<1337481180142-4002984.post@n3.nabble.com>
	<1337616604963-4005068.post@n3.nabble.com>
Message-ID: <alpine.LNX.2.02.1205211613410.5542@localhost.localdomain>

Layer23 only exists in the burst_ind branch as far as I know.
(see my buildscript here: 
https://aur.archlinux.org/packages/os/osmocombb-git/PKGBUILD )

On Mon, 21 May 2012, Altaf wrote:

> Thank you so much for your help....
>
> I had bought a new SIM and started testing. and its WORKING. I am able to
> make call and also sms.
>
> I have two Motorola c123 handsets. One work very good and the other is also
> camping onto a cell, doing all other scanning for frequencies and other
> stuff but provides only emergency calls... I cud nt make calls from the
> second handset.
>
> Where do u stay. How come you dont have a GSM band in your area.
>
> I started with the layer23 application. I didnt understand where to  use
> this command. In which path??
>
>    ./layer23 -a 871 -i 127.0.0.1
>
> I dont understand where and how to launch this application. Can you kindly
> explain me this.
>
>
>
> Thanks in advance
>
> Yours Sincerely
>
> Altaf
>
>
> --
> View this message in context: http://baseband-devel.722152.n3.nabble.com/Osmocom-bb-Making-a-call-tp3997264p4005068.html
> Sent from the baseband-devel mailing list archive at Nabble.com.
>
>



From altaf329 at gmail.com  Thu May 24 16:49:14 2012
From: altaf329 at gmail.com (Altaf)
Date: Thu, 24 May 2012 09:49:14 -0700 (PDT)
Subject: Osmocom-bb Making a call
In-Reply-To: <alpine.LNX.2.02.1205211613410.5542@localhost.localdomain>
References: <1337179742649-3997264.post@n3.nabble.com>
	<1337481180142-4002984.post@n3.nabble.com>
	<1337616604963-4005068.post@n3.nabble.com>
	<alpine.LNX.2.02.1205211613410.5542@localhost.localdomain>
Message-ID: <1337878154114-4013909.post@n3.nabble.com>

When I run the Layer23(ccch_scan) application it gives me the following
output on the terminal....

Failed to connect to '/tmp/osmocom_sap'.
Failed during sap_open(), no SIM reader
<000c> l1ctl.c:114 FBSB RESP: result=255

What does it mean.. Can some one help me at this point..

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Osmocom-bb-Making-a-call-tp3997264p4013909.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From pere5027 at vandals.uidaho.edu  Thu May 24 17:33:29 2012
From: pere5027 at vandals.uidaho.edu (Joshua Pereyda)
Date: Thu, 24 May 2012 10:33:29 -0700
Subject: Osmocom-bb Making a call
In-Reply-To: <1337878154114-4013909.post@n3.nabble.com>
References: <1337179742649-3997264.post@n3.nabble.com>
	<1337481180142-4002984.post@n3.nabble.com>
	<1337616604963-4005068.post@n3.nabble.com>
	<alpine.LNX.2.02.1205211613410.5542@localhost.localdomain>
	<1337878154114-4013909.post@n3.nabble.com>
Message-ID: <CAGPHiNkbG-oUkkEonK40boGdRzQCMW6e1_tysJTMfEQURSnTEQ@mail.gmail.com>

http://lists.osmocom.org/pipermail/baseband-devel/2012-April/002946.html

On Thu, May 24, 2012 at 9:49 AM, Altaf <altaf329 at gmail.com> wrote:
> When I run the Layer23(ccch_scan) application it gives me the following
> output on the terminal....
>
> Failed to connect to '/tmp/osmocom_sap'.
> Failed during sap_open(), no SIM reader
> <000c> l1ctl.c:114 FBSB RESP: result=255
>
> What does it mean.. Can some one help me at this point..
>
> --
> View this message in context: http://baseband-devel.722152.n3.nabble.com/Osmocom-bb-Making-a-call-tp3997264p4013909.html
> Sent from the baseband-devel mailing list archive at Nabble.com.
>
>




From pere5027 at vandals.uidaho.edu  Thu May 24 17:36:24 2012
From: pere5027 at vandals.uidaho.edu (Joshua Pereyda)
Date: Thu, 24 May 2012 10:36:24 -0700
Subject: Osmocom-bb Making a call
In-Reply-To: <CAGPHiNkbG-oUkkEonK40boGdRzQCMW6e1_tysJTMfEQURSnTEQ@mail.gmail.com>
References: <1337179742649-3997264.post@n3.nabble.com>
	<1337481180142-4002984.post@n3.nabble.com>
	<1337616604963-4005068.post@n3.nabble.com>
	<alpine.LNX.2.02.1205211613410.5542@localhost.localdomain>
	<1337878154114-4013909.post@n3.nabble.com>
	<CAGPHiNkbG-oUkkEonK40boGdRzQCMW6e1_tysJTMfEQURSnTEQ@mail.gmail.com>
Message-ID: <CAGPHiNk+L_9jGdc+isoByiVfYEbrWe8o+m7g2oxCNPDYqy3EPg@mail.gmail.com>

http://lists.osmocom.org/pipermail/baseband-devel/2012-May/003004.html

On Thu, May 24, 2012 at 10:33 AM, Joshua Pereyda
<pere5027 at vandals.uidaho.edu> wrote:
> http://lists.osmocom.org/pipermail/baseband-devel/2012-April/002946.html
>
> On Thu, May 24, 2012 at 9:49 AM, Altaf <altaf329 at gmail.com> wrote:
>> When I run the Layer23(ccch_scan) application it gives me the following
>> output on the terminal....
>>
>> Failed to connect to '/tmp/osmocom_sap'.
>> Failed during sap_open(), no SIM reader
>> <000c> l1ctl.c:114 FBSB RESP: result=255
>>
>> What does it mean.. Can some one help me at this point..
>>
>> --
>> View this message in context: http://baseband-devel.722152.n3.nabble.com/Osmocom-bb-Making-a-call-tp3997264p4013909.html
>> Sent from the baseband-devel mailing list archive at Nabble.com.
>>
>>




From roladunjoye at gmail.com  Mon May 21 17:16:39 2012
From: roladunjoye at gmail.com (rola)
Date: Mon, 21 May 2012 10:16:39 -0700 (PDT)
Subject: Osmocom-bb Making a call
In-Reply-To: <1337616604963-4005068.post@n3.nabble.com>
References: <1337179742649-3997264.post@n3.nabble.com>
	<1337481180142-4002984.post@n3.nabble.com>
	<1337616604963-4005068.post@n3.nabble.com>
Message-ID: <1337620599359-4005183.post@n3.nabble.com>


Hi,

Good to hear that at least you can make calls with one and the other camped
perfectly with limited service. That is milestone you just covered with
ease.


>Where do u stay. How come you dont have a GSM band in your area.

I stay in US where GSM band is a bit different from the rest of the World
and as well the phone rf radio in some cases differ. The bands around me are
850 and PCS1900. My SIM career uses PCS1900. Also Motorola c123 with the
radio band serving my area is hard to come by. So I guess, that is where my
predicament lies. Hopefully I might get help eventually. 


> I started with the layer23 application. I didnt understand where to  use
> this command. In which path??
>  ./layer23 -a 871 -i 127.0.0.1

layer23 app has been demoted for ccch app for a very long time ago. So
disregard any instruction related to running of layer23, it should be
ccch-app.

I will implore that you first search the mailing list archive for solution
before making a post; by that you can easily find solution to many problems
and learn from others mistakes.

Best of luck.

Sincerely,

Rasak


--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Osmocom-bb-Making-a-call-tp3997264p4005183.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From pere5027 at vandals.uidaho.edu  Mon May 21 19:43:04 2012
From: pere5027 at vandals.uidaho.edu (Joshua Pereyda)
Date: Mon, 21 May 2012 12:43:04 -0700
Subject: Osmocom-bb Making a call
In-Reply-To: <1337620599359-4005183.post@n3.nabble.com>
References: <1337179742649-3997264.post@n3.nabble.com>
	<1337481180142-4002984.post@n3.nabble.com>
	<1337616604963-4005068.post@n3.nabble.com>
	<1337620599359-4005183.post@n3.nabble.com>
Message-ID: <CAGPHiNkQoFU7iYZBKKRhH+uaJmPXrDsYwB9vSLn=KTc58ABqYg@mail.gmail.com>

For what it's worth, you can get the Motorola c155 (barely) on Amazon
right now.  It seems to work with OsmocomBB, but my SIM is locked and
customer support either didn't want to or was unable to give me the
PIN.


Josh

On Mon, May 21, 2012 at 10:16 AM, rola <roladunjoye at gmail.com> wrote:
>
> Hi,
>
> Good to hear that at least you can make calls with one and the other camped
> perfectly with limited service. That is milestone you just covered with
> ease.
>
>
>>Where do u stay. How come you dont have a GSM band in your area.
>
> I stay in US where GSM band is a bit different from the rest of the World
> and as well the phone rf radio in some cases differ. The bands around me are
> 850 and PCS1900. My SIM career uses PCS1900. Also Motorola c123 with the
> radio band serving my area is hard to come by. So I guess, that is where my
> predicament lies. Hopefully I might get help eventually.
>
>
>> I started with the layer23 application. I didnt understand where to ?use
>> this command. In which path??
>> ?./layer23 -a 871 -i 127.0.0.1
>
> layer23 app has been demoted for ccch app for a very long time ago. So
> disregard any instruction related to running of layer23, it should be
> ccch-app.
>
> I will implore that you first search the mailing list archive for solution
> before making a post; by that you can easily find solution to many problems
> and learn from others mistakes.
>
> Best of luck.
>
> Sincerely,
>
> Rasak
>
>
> --
> View this message in context: http://baseband-devel.722152.n3.nabble.com/Osmocom-bb-Making-a-call-tp3997264p4005183.html
> Sent from the baseband-devel mailing list archive at Nabble.com.
>
>




From roladunjoye at gmail.com  Tue May 29 16:31:06 2012
From: roladunjoye at gmail.com (rola)
Date: Tue, 29 May 2012 09:31:06 -0700 (PDT)
Subject: Osmocom-bb Making a call
In-Reply-To: <CAGPHiNkQoFU7iYZBKKRhH+uaJmPXrDsYwB9vSLn=KTc58ABqYg@mail.gmail.com>
References: <1337179742649-3997264.post@n3.nabble.com>
	<1337481180142-4002984.post@n3.nabble.com>
	<1337616604963-4005068.post@n3.nabble.com>
	<1337620599359-4005183.post@n3.nabble.com>
	<CAGPHiNkQoFU7iYZBKKRhH+uaJmPXrDsYwB9vSLn=KTc58ABqYg@mail.gmail.com>
Message-ID: <1338309066299-4021037.post@n3.nabble.com>

Hi all:

thanks for the responds and I appreciate all your support.

@Josh:
I actually started with C155 that is SIM locked by tracphone.
I believe you had the same issueas you've mentioned. My main concern
is not really with the phone but with the PCS1900band because the 850 band
that works for many is not functioning in my area. If there is anyway round
to 
make PCS1900 works please let me know.
Presently, to circumvent the SIM lock issue of C155 I opted for Pirelli.
By the way if you have a clue how to break the bond of tracphone on C155
please do not hesitate to let me know. I know someone in the mailing list
was able to overwrite the firmware to support any SIM.
Thanks.

@Harald Welte-3
Thanks for taking time out of your busy schedule to make a response. This
is what I should let you know, this project is something I see in the
category of Linux. I believe with time it will be the most essential tool
for all
telecommunications students in the world. So I strongly thanks every single
programmers that participated in this work for making this possible.
I hope I could do a bit but not all of us are as sound as you guys.
My technical competence is nothing compare to your
recommendation, but I truly appreciate the response.
Thanks so much.

@ Luca
I've been on Pirelli with the same issue for a while. I made some posts
related
to these a long time ago. I eventual switched to C139 which I thought would
work but ended up having similar problem. But recently, I realized that the
issue
might be peculiar to PCS1900 band.  Right now, I am sticking with Pirelli to
see
if by chance thing will work out. I've made my observation known to Sylvain
as
a response to my unfix bug post. I hope something can be done.

Thanks to all and I sincerely appreciate all your response.

From,

Rasak

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Osmocom-bb-Making-a-call-tp3997264p4021037.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From laforge at gnumonks.org  Mon May 21 20:32:22 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 21 May 2012 22:32:22 +0200
Subject: Osmocom-bb Making a call
In-Reply-To: <1337620599359-4005183.post@n3.nabble.com>
References: <1337179742649-3997264.post@n3.nabble.com>
	<1337481180142-4002984.post@n3.nabble.com>
	<1337616604963-4005068.post@n3.nabble.com>
	<1337620599359-4005183.post@n3.nabble.com>
Message-ID: <20120521203222.GY19343@prithivi.gnumonks.org>

Hi Rasak,

On Mon, May 21, 2012 at 10:16:39AM -0700, rola wrote:

> I stay in US where GSM band is a bit different from the rest of the World
> and as well the phone rf radio in some cases differ. The bands around me are
> 850 and PCS1900. My SIM career uses PCS1900. Also Motorola c123 with the
> radio band serving my area is hard to come by. So I guess, that is where my
> predicament lies. Hopefully I might get help eventually. 

you could always use a european band version and do the filter re-work.
After that, the phone should work in all bands, as there are no band
filters anymore.  Of course the phone will be sensitive to out-of-band
interference from other strong transmitters, but apart from that it
should solve the difficulty obtaining US-band versions of the phone.
-- 
- 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 luca.bongiorni1 at studenti.unimi.it  Mon May 21 20:37:22 2012
From: luca.bongiorni1 at studenti.unimi.it (Luca Bongiorni)
Date: Mon, 21 May 2012 22:37:22 +0200
Subject: Osmocom-bb Making a call
In-Reply-To: <20120521203222.GY19343@prithivi.gnumonks.org>
References: <1337179742649-3997264.post@n3.nabble.com>
	<1337481180142-4002984.post@n3.nabble.com>
	<1337616604963-4005068.post@n3.nabble.com>
	<1337620599359-4005183.post@n3.nabble.com>
	<20120521203222.GY19343@prithivi.gnumonks.org>
Message-ID: <2753A1BF-FDA9-41E6-BEFD-0423FAEA7268@studenti.unimi.it>

Hi all,
 
I would also suggest the Pirelli DP-l10 since it works on PCS too (IIRC).

Cheers,
Luca

>> I stay in US where GSM band is a bit different from the rest of the World
>> and as well the phone rf radio in some cases differ. The bands around me are
>> 850 and PCS1900. My SIM career uses PCS1900. Also Motorola c123 with the
>> radio band serving my area is hard to come by. So I guess, that is where my
>> predicament lies. Hopefully I might get help eventually. 
> 
> you could always use a european band version and do the filter re-work.
> After that, the phone should work in all bands, as there are no band
> filters anymore.  Of course the phone will be sensitive to out-of-band
> interference from other strong transmitters, but apart from that it
> should solve the difficulty obtaining US-band versions of the phone.




From kalle.pietila at gmail.com  Wed May 16 18:28:03 2012
From: kalle.pietila at gmail.com (Kalle Pietila)
Date: Wed, 16 May 2012 21:28:03 +0300
Subject: The SMOS project / 72h civil emergency communications system
Message-ID: <CABvL=T3nA-7OP+e=ZDT=0p5F7S2R_HqT0yw7OXEqCsdULovz2Q@mail.gmail.com>

Dear baseband enthusiasts,

on SMOS project we had this crazy idea for catastrophe communications
in which cellular base stations would be miniaturized enough to be
airdropped into disaster zones. We felt that this might
be possible if all functionality except SMS was stripped from the base
stations (hence SMOS, SMS Our Souls). Most ideally such technology
would come in near cellphone size (excluding batteries), something
like osmocom's earlier "Phone acting as BTS" hackwork.

We did not have the guts nor skills to start doing this by ourselves,
so we just published our findings and studies under Creative Commons
BY license. As we wish to keep this idea open to everyone, our
web-documentation would benefit on this regard from some more in-depth
HW-related analysis and suggestions  (our team fell short on this
area). Once it's all published, it cannot be patented. I personally
see some humanitarian & karma-improving angle in doing it this way.
Helping human kinds in disaster should not be bound by patent laws.

So I'm asking for constructive criticism and also offering possibility
to write some informal blogs about your views on
www.zygomatica.com/smos (with our team's editorial support) . At the
same time it should be noted that such technically oriented blog
writings at my friends' site zygomatica.com would likely reach 50
readers at most. To put it more nicely, reaching the widest possible
audience is not our focus here anyways.

My technical vision is presented at
http://www.zygomatica.com/wp-content/uploads/2012/04/SMOS6-Technical-goals-System-requirements-v10.pdf
.. and the full list of formal documents at end of
http://www.zygomatica.com/smos/ . The other provided background
material might be even more valuable to those that start considering
this idea more seriously.

So, For instance, can stripping  down the functionality just to
supporting SMS delivery bring down the power consumption in any
significant manner?

Thanks and regards,

  Kalle Pietil?

P.S. Mailed to this list as suggested by Harald.



From alexander.chemeris at gmail.com  Thu May 17 07:17:31 2012
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Thu, 17 May 2012 11:17:31 +0400
Subject: The SMOS project / 72h civil emergency communications system
In-Reply-To: <CABvL=T3nA-7OP+e=ZDT=0p5F7S2R_HqT0yw7OXEqCsdULovz2Q@mail.gmail.com>
References: <CABvL=T3nA-7OP+e=ZDT=0p5F7S2R_HqT0yw7OXEqCsdULovz2Q@mail.gmail.com>
Message-ID: <CABmJbFUXsDUA5Tss+sp9-6Es6mLbRPN88aLSmkxEmPi41-711A@mail.gmail.com>

Hi Kalle,

BTS has to transmit constantly on it's main ARFCN, no matter do you
make calls or just send SMS. So while you operate a single ARFCN you
can't save power by employing only SMS. On the other hand, for SMS a
single ARFCN would be enough to provide a good capacity, while support
for calls would require a multi-ARFCN config which would be quite
power hungry.

Have you thought about using a balloon for carrying a BTS instead of
dropping to a ground? This would give you much better coverage easily
then on-the-ground installation.

PS I think this would get more responses from the OpenBTS mailing
list, then from OsmocomBB mailing list, as this is definitely a
network-side question.

On Wed, May 16, 2012 at 10:28 PM, Kalle Pietila <kalle.pietila at gmail.com> wrote:
> Dear baseband enthusiasts,
>
> on SMOS project we had this crazy idea for catastrophe communications
> in which cellular base stations would be miniaturized enough to be
> airdropped into disaster zones. We felt that this might
> be possible if all functionality except SMS was stripped from the base
> stations (hence SMOS, SMS Our Souls). Most ideally such technology
> would come in near cellphone size (excluding batteries), something
> like osmocom's earlier "Phone acting as BTS" hackwork.
>
> We did not have the guts nor skills to start doing this by ourselves,
> so we just published our findings and studies under Creative Commons
> BY license. As we wish to keep this idea open to everyone, our
> web-documentation would benefit on this regard from some more in-depth
> HW-related analysis and suggestions ?(our team fell short on this
> area). Once it's all published, it cannot be patented. I personally
> see some humanitarian & karma-improving angle in doing it this way.
> Helping human kinds in disaster should not be bound by patent laws.
>
> So I'm asking for constructive criticism and also offering possibility
> to write some informal blogs about your views on
> www.zygomatica.com/smos (with our team's editorial support) . At the
> same time it should be noted that such technically oriented blog
> writings at my friends' site zygomatica.com would likely reach 50
> readers at most. To put it more nicely, reaching the widest possible
> audience is not our focus here anyways.
>
> My technical vision is presented at
> http://www.zygomatica.com/wp-content/uploads/2012/04/SMOS6-Technical-goals-System-requirements-v10.pdf
> .. and the full list of formal documents at end of
> http://www.zygomatica.com/smos/ . The other provided background
> material might be even more valuable to those that start considering
> this idea more seriously.
>
> So, For instance, can stripping ?down the functionality just to
> supporting SMS delivery bring down the power consumption in any
> significant manner?
>
> Thanks and regards,
>
> ?Kalle Pietil?
>
> P.S. Mailed to this list as suggested by Harald.
>



-- 
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ??? ???????
http://fairwaves.ru



From kalle.pietila at gmail.com  Thu May 17 10:32:31 2012
From: kalle.pietila at gmail.com (Kalle Pietila)
Date: Thu, 17 May 2012 13:32:31 +0300
Subject: The SMOS project / 72h civil emergency communications system
In-Reply-To: <CABmJbFUXsDUA5Tss+sp9-6Es6mLbRPN88aLSmkxEmPi41-711A@mail.gmail.com>
References: <CABvL=T3nA-7OP+e=ZDT=0p5F7S2R_HqT0yw7OXEqCsdULovz2Q@mail.gmail.com>
	<CABmJbFUXsDUA5Tss+sp9-6Es6mLbRPN88aLSmkxEmPi41-711A@mail.gmail.com>
Message-ID: <CABvL=T1FVK18XvfcbkctD5OpMxCTaX5RKkm45SmmbSU7kGHhUQ@mail.gmail.com>

Hi Alexander,

yes I'm aware that a BTS would need to be transmitting all time, which
is not best starting point for being power-efficient. However good to
get confirmation that multi-ARFCN can be avoided. I mailed to BB list
as I see this part as most probable technical show stopper for this
initiative. The chip designs seem to be targeted for mobile broandband
applications with all that unnecessary functionality at a silicon
screaming for more power. Also proprietary L1 can be a major problem
when cost of BTS module needs to be kept minimal (modules getting
lost, damaged, stolen, or vandalized) and also this stuff would need
to be affordably available for the developers. Actually, SMS-only
supporting base-stations could be a first viable application for an
open L1 implementation?

We're though about balloon raising the antenna up and also flying
drones with BTS as payload. Flying or floating might work well on
still weather, but probably not at all under heavy winds. Not sure
whether this would acceptable shortcoming for the imaginary
"customer". Balloon-approach might just have worked better in case
Haiti, I see the point.

Thanks for hinting the OpenBTS mailing list, I'll drop a line there too.

Best Wishes,

   Kalle Pietil?

On Thu, May 17, 2012 at 10:17 AM, Alexander Chemeris
<alexander.chemeris at gmail.com> wrote:
> Hi Kalle,
>
> BTS has to transmit constantly on it's main ARFCN, no matter do you
> make calls or just send SMS. So while you operate a single ARFCN you
> can't save power by employing only SMS. On the other hand, for SMS a
> single ARFCN would be enough to provide a good capacity, while support
> for calls would require a multi-ARFCN config which would be quite
> power hungry.
>
> Have you thought about using a balloon for carrying a BTS instead of
> dropping to a ground? This would give you much better coverage easily
> then on-the-ground installation.
>
> PS I think this would get more responses from the OpenBTS mailing
> list, then from OsmocomBB mailing list, as this is definitely a
> network-side question.
>
> On Wed, May 16, 2012 at 10:28 PM, Kalle Pietila <kalle.pietila at gmail.com> wrote:
>> Dear baseband enthusiasts,
>>
>> on SMOS project we had this crazy idea for catastrophe communications
>> in which cellular base stations would be miniaturized enough to be
>> airdropped into disaster zones. We felt that this might
>> be possible if all functionality except SMS was stripped from the base
>> stations (hence SMOS, SMS Our Souls). Most ideally such technology
>> would come in near cellphone size (excluding batteries), something
>> like osmocom's earlier "Phone acting as BTS" hackwork.
>>
>> We did not have the guts nor skills to start doing this by ourselves,
>> so we just published our findings and studies under Creative Commons
>> BY license. As we wish to keep this idea open to everyone, our
>> web-documentation would benefit on this regard from some more in-depth
>> HW-related analysis and suggestions ?(our team fell short on this
>> area). Once it's all published, it cannot be patented. I personally
>> see some humanitarian & karma-improving angle in doing it this way.
>> Helping human kinds in disaster should not be bound by patent laws.
>>
>> So I'm asking for constructive criticism and also offering possibility
>> to write some informal blogs about your views on
>> www.zygomatica.com/smos (with our team's editorial support) . At the
>> same time it should be noted that such technically oriented blog
>> writings at my friends' site zygomatica.com would likely reach 50
>> readers at most. To put it more nicely, reaching the widest possible
>> audience is not our focus here anyways.
>>
>> My technical vision is presented at
>> http://www.zygomatica.com/wp-content/uploads/2012/04/SMOS6-Technical-goals-System-requirements-v10.pdf
>> .. and the full list of formal documents at end of
>> http://www.zygomatica.com/smos/ . The other provided background
>> material might be even more valuable to those that start considering
>> this idea more seriously.
>>
>> So, For instance, can stripping ?down the functionality just to
>> supporting SMS delivery bring down the power consumption in any
>> significant manner?
>>
>> Thanks and regards,
>>
>> ?Kalle Pietil?
>>
>> P.S. Mailed to this list as suggested by Harald.
>>
>
>
>
> --
> Regards,
> Alexander Chemeris.
> CEO, Fairwaves LLC / ??? ???????
> http://fairwaves.ru



From alexander.chemeris at gmail.com  Thu May 17 11:20:38 2012
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Thu, 17 May 2012 15:20:38 +0400
Subject: The SMOS project / 72h civil emergency communications system
In-Reply-To: <CABvL=T1FVK18XvfcbkctD5OpMxCTaX5RKkm45SmmbSU7kGHhUQ@mail.gmail.com>
References: <CABvL=T3nA-7OP+e=ZDT=0p5F7S2R_HqT0yw7OXEqCsdULovz2Q@mail.gmail.com>
	<CABmJbFUXsDUA5Tss+sp9-6Es6mLbRPN88aLSmkxEmPi41-711A@mail.gmail.com>
	<CABvL=T1FVK18XvfcbkctD5OpMxCTaX5RKkm45SmmbSU7kGHhUQ@mail.gmail.com>
Message-ID: <CABmJbFWB9q83cbuLhMZeiAPPsguB=iRO0GEKu4++ZAxdyB0Rjg@mail.gmail.com>

17.05.2012 14:32 ???????????? "Kalle Pietila" <kalle.pietila at gmail.com>
???????:
>
> Hi Alexander,
>
> yes I'm aware that a BTS would need to be transmitting all time, which
> is not best starting point for being power-efficient. However good to
> get confirmation that multi-ARFCN can be avoided. I mailed to BB list
> as I see this part as most probable technical show stopper for this
> initiative. The chip designs seem to be targeted for mobile broandband
> applications with all that unnecessary functionality at a silicon
> screaming for more power. Also proprietary L1 can be a major problem
> when cost of BTS module needs to be kept minimal (modules getting
> lost, damaged, stolen, or vandalized) and also this stuff would need
> to be affordably available for the developers. Actually, SMS-only
> supporting base-stations could be a first viable application for an
> open L1 implementation?

OpenBTS already has an open-source implementation of a base station.

> We're though about balloon raising the antenna up and also flying
> drones with BTS as payload. Flying or floating might work well on
> still weather, but probably not at all under heavy winds. Not sure
> whether this would acceptable shortcoming for the imaginary
> "customer". Balloon-approach might just have worked better in case
> Haiti, I see the point.

To get a reasonable coverage you have to elevate your antenna as high as
possible. So "dropping" it's not an option anyway, imho. You need a manual
labor to install this antennas.

> Thanks for hinting the OpenBTS mailing list, I'll drop a line there too.
>
> Best Wishes,
>
>   Kalle Pietil?
>
> On Thu, May 17, 2012 at 10:17 AM, Alexander Chemeris
> <alexander.chemeris at gmail.com> wrote:
> > Hi Kalle,
> >
> > BTS has to transmit constantly on it's main ARFCN, no matter do you
> > make calls or just send SMS. So while you operate a single ARFCN you
> > can't save power by employing only SMS. On the other hand, for SMS a
> > single ARFCN would be enough to provide a good capacity, while support
> > for calls would require a multi-ARFCN config which would be quite
> > power hungry.
> >
> > Have you thought about using a balloon for carrying a BTS instead of
> > dropping to a ground? This would give you much better coverage easily
> > then on-the-ground installation.
> >
> > PS I think this would get more responses from the OpenBTS mailing
> > list, then from OsmocomBB mailing list, as this is definitely a
> > network-side question.
> >
> > On Wed, May 16, 2012 at 10:28 PM, Kalle Pietila <kalle.pietila at gmail.com>
wrote:
> >> Dear baseband enthusiasts,
> >>
> >> on SMOS project we had this crazy idea for catastrophe communications
> >> in which cellular base stations would be miniaturized enough to be
> >> airdropped into disaster zones. We felt that this might
> >> be possible if all functionality except SMS was stripped from the base
> >> stations (hence SMOS, SMS Our Souls). Most ideally such technology
> >> would come in near cellphone size (excluding batteries), something
> >> like osmocom's earlier "Phone acting as BTS" hackwork.
> >>
> >> We did not have the guts nor skills to start doing this by ourselves,
> >> so we just published our findings and studies under Creative Commons
> >> BY license. As we wish to keep this idea open to everyone, our
> >> web-documentation would benefit on this regard from some more in-depth
> >> HW-related analysis and suggestions  (our team fell short on this
> >> area). Once it's all published, it cannot be patented. I personally
> >> see some humanitarian & karma-improving angle in doing it this way.
> >> Helping human kinds in disaster should not be bound by patent laws.
> >>
> >> So I'm asking for constructive criticism and also offering possibility
> >> to write some informal blogs about your views on
> >> www.zygomatica.com/smos (with our team's editorial support) . At the
> >> same time it should be noted that such technically oriented blog
> >> writings at my friends' site zygomatica.com would likely reach 50
> >> readers at most. To put it more nicely, reaching the widest possible
> >> audience is not our focus here anyways.
> >>
> >> My technical vision is presented at
> >>
http://www.zygomatica.com/wp-content/uploads/2012/04/SMOS6-Technical-goals-System-requirements-v10.pdf
> >> .. and the full list of formal documents at end of
> >> http://www.zygomatica.com/smos/ . The other provided background
> >> material might be even more valuable to those that start considering
> >> this idea more seriously.
> >>
> >> So, For instance, can stripping  down the functionality just to
> >> supporting SMS delivery bring down the power consumption in any
> >> significant manner?
> >>
> >> Thanks and regards,
> >>
> >>  Kalle Pietil?
> >>
> >> P.S. Mailed to this list as suggested by Harald.
> >>
> >
> >
> >
> > --
> > Regards,
> > Alexander Chemeris.
> > CEO, Fairwaves LLC / ??? ???????
> > http://fairwaves.ru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20120517/57036f0d/attachment.htm>

From pauldart at gmail.com  Fri May 18 08:24:18 2012
From: pauldart at gmail.com (Paul Dart)
Date: Fri, 18 May 2012 09:24:18 +0100
Subject: The SMOS project / 72h civil emergency communications system
In-Reply-To: <CABmJbFUXsDUA5Tss+sp9-6Es6mLbRPN88aLSmkxEmPi41-711A@mail.gmail.com>
References: <CABvL=T3nA-7OP+e=ZDT=0p5F7S2R_HqT0yw7OXEqCsdULovz2Q@mail.gmail.com>
	<CABmJbFUXsDUA5Tss+sp9-6Es6mLbRPN88aLSmkxEmPi41-711A@mail.gmail.com>
Message-ID: <CAOEO7soUiGdJ42Z6MR49PWcg1GsQaEbvdUsKfFThUQe_0V3VoQ@mail.gmail.com>

On 17 May 2012 08:17, Alexander Chemeris <alexander.chemeris at gmail.com> wrote:
> Have you thought about using a balloon for carrying a BTS instead of
> dropping to a ground? This would give you much better coverage easily
> then on-the-ground installation.

http://www.cellular-news.com/story/54354.php?s=h

It appears Softbank Mobile have!

(also I emailed the OP about Telecom Sans Frontier http://www.tsfi.org )

Good luck,

Paul



From kalle.pietila at gmail.com  Sun May 20 19:57:55 2012
From: kalle.pietila at gmail.com (Kalle Pietila)
Date: Sun, 20 May 2012 22:57:55 +0300
Subject: The SMOS project / 72h civil emergency communications system
Message-ID: <CABvL=T0Pa-1pTgx0ieQks2-9S_m+9N_gyO1u3m8LBU83G=44Yg@mail.gmail.com>

Thanks Paul for pointing to this Softbank's press release. Japanese
have recently witnessed their local need for civil emergency
communications and they also have money to make it happen, not to
mention good supporting infrastructure already in place. So it was
just matter of time to see someone there addressing this problem. I
guess in Japan there is no such earthquake that could compromise the
functionality of their mobile core (or at least locals think so). So
it is then "just" matter of deploying new balloon-basestations to the
disaster area. Someone will go there to the washed-out area with all
the required gear, and raise a new BTS-balloon every 3km. On poor
countries it will remain as a different story however.

it would be interesting to see what kind is that Softbank Mobile's
Balloon-BTS proof of concept. I do not know about Softbank but I just
directly assume that an operator do not have their own BTS R&D. They
must be relying on some existing technology and just make it fly with
the balloon. Keeping in mind that one weather sounding balloon can
raise 500g payload and probably they will need to feed the power via
some sort of cable from the ground level up to the high. So very
interesting to follow-up how this all will be implemented in practice.

 Best Wishes,

      - Kalle

> ---------- Forwarded message ----------
> From:?Paul Dart <pauldart at gmail.com>
> To:?baseband-devel at lists.osmocom.org
> Cc:
> Date:?Fri, 18 May 2012 09:24:18 +0100
> Subject:?Re: The SMOS project / 72h civil emergency communications system
> On 17 May 2012 08:17, Alexander Chemeris <alexander.chemeris at gmail.com> wrote:
>> Have you thought about using a balloon for carrying a BTS instead of
>> dropping to a ground? This would give you much better coverage easily
>> then on-the-ground installation.
>
> http://www.cellular-news.com/story/54354.php?s=h
>
> It appears Softbank Mobile have!
>
> (also I emailed the OP about Telecom Sans Frontier http://www.tsfi.org )
>
> Good luck,
>
> Paul



From gouchengcheng at gmail.com  Fri May 18 02:53:20 2012
From: gouchengcheng at gmail.com (Chengcheng Gou)
Date: Fri, 18 May 2012 10:53:20 +0800
Subject: the problem of burst_ind receive SMS in a cell
Message-ID: <CANV9D0nkLSXv4d=xcRrUHai_57brFC249_GecOOTpdU268FuWg@mail.gmail.com>

first,the network is not encrypt.

I test burst_ind to receive SMS in a cell, but I can`t receive the SMS
transfered in my two  phone, the two phone is lock to the cell,
do I miss anything ?

Another problem I am only interest in SMS but not voice,and how to
difference  the two types of SDCCH?

thanks!



From pere5027 at vandals.uidaho.edu  Fri May 18 16:47:36 2012
From: pere5027 at vandals.uidaho.edu (Joshua Pereyda)
Date: Fri, 18 May 2012 09:47:36 -0700
Subject: the problem of burst_ind receive SMS in a cell
In-Reply-To: <CANV9D0nkLSXv4d=xcRrUHai_57brFC249_GecOOTpdU268FuWg@mail.gmail.com>
References: <CANV9D0nkLSXv4d=xcRrUHai_57brFC249_GecOOTpdU268FuWg@mail.gmail.com>
Message-ID: <CAGPHiNk5_ia36HLf+YrP4WjkzuZfckU4BeUWfVz4LvLB-W4RZQ@mail.gmail.com>

I don't believe burst_ind is designed to sniff SMS.  Check out the
sniffing page on the website:
http://bb.osmocom.org/trac/wiki/Sniffing
(the site says layer23, but it's actually ccch_scan; I would update
but I don't have an account)

This presentation might help:
https://www.youtube.com/watch?v=ZrbatnnRxFc

You should probably also learn about GSM (not sure how far this
website can take you though):
http://gsmfordummies.com/

OsmocomBB, even burst_ind, is not really a sniffing tool; you will
need to do more work yourself.


Josh

On Thu, May 17, 2012 at 7:53 PM, Chengcheng Gou <gouchengcheng at gmail.com> wrote:
> first,the network is not encrypt.
>
> I test burst_ind to receive SMS in a cell, but I can`t receive the SMS
> transfered in my two ?phone, the two phone is lock to the cell,
> do I miss anything ?
>
> Another problem I am only interest in SMS but not voice,and how to
> difference ?the two types of SDCCH?
>
> thanks!
>
>




From holger at freyther.de  Fri May 18 16:56:27 2012
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Fri, 18 May 2012 18:56:27 +0200
Subject: the problem of burst_ind receive SMS in a cell
In-Reply-To: <CAGPHiNk5_ia36HLf+YrP4WjkzuZfckU4BeUWfVz4LvLB-W4RZQ@mail.gmail.com>
References: <CANV9D0nkLSXv4d=xcRrUHai_57brFC249_GecOOTpdU268FuWg@mail.gmail.com>
	<CAGPHiNk5_ia36HLf+YrP4WjkzuZfckU4BeUWfVz4LvLB-W4RZQ@mail.gmail.com>
Message-ID: <4FB67F3B.4070708@freyther.de>

On 05/18/2012 06:47 PM, Joshua Pereyda wrote:
> I don't believe burst_ind is designed to sniff SMS.  Check out the
> sniffing page on the website:
> http://bb.osmocom.org/trac/wiki/Sniffing
> (the site says layer23, but it's actually ccch_scan; I would update
> but I don't have an account)

then please create an account (instructions are on the login page) and update
the site.

thanks
	holger




From pere5027 at vandals.uidaho.edu  Fri May 18 17:58:26 2012
From: pere5027 at vandals.uidaho.edu (Joshua Pereyda)
Date: Fri, 18 May 2012 10:58:26 -0700
Subject: the problem of burst_ind receive SMS in a cell
In-Reply-To: <4FB67F3B.4070708@freyther.de>
References: <CANV9D0nkLSXv4d=xcRrUHai_57brFC249_GecOOTpdU268FuWg@mail.gmail.com>
	<CAGPHiNk5_ia36HLf+YrP4WjkzuZfckU4BeUWfVz4LvLB-W4RZQ@mail.gmail.com>
	<4FB67F3B.4070708@freyther.de>
Message-ID: <CAGPHiN=Wm0m3taNsX+41rbH++Gtovj6fLYM2_R3M_YDAX2eZjw@mail.gmail.com>

Emailed laforge at gnumonks.org 3 days ago; will update once I get on there.


Josh

On Fri, May 18, 2012 at 9:56 AM, Holger Hans Peter Freyther
<holger at freyther.de> wrote:
> On 05/18/2012 06:47 PM, Joshua Pereyda wrote:
>> I don't believe burst_ind is designed to sniff SMS. ?Check out the
>> sniffing page on the website:
>> http://bb.osmocom.org/trac/wiki/Sniffing
>> (the site says layer23, but it's actually ccch_scan; I would update
>> but I don't have an account)
>
> then please create an account (instructions are on the login page) and update
> the site.
>
> thanks
> ? ? ? ?holger
>
>
>




From roladunjoye at gmail.com  Fri May 18 20:08:33 2012
From: roladunjoye at gmail.com (rola)
Date: Fri, 18 May 2012 13:08:33 -0700 (PDT)
Subject: Return value for fucntion class_of_band in gsm322.c
Message-ID: <1337371713558-4001443.post@n3.nabble.com>

Hi All,

I just need a quick clarification on the return value of the
function class_of_band in gsm332.c. The switch
portion of the function takes care of other bands except 
900 band which happen to be isolated separately after the
switch statement. By that the 900 band is set to be default
and only band to be used. I just want to know if this is deliberate
or an oversight. If this situation is actually what I have in mind,
I think it will definitely have effect on anyone trying to use
Osmocom-bb for other band beside 900.

I've been trying to get OBB work for PCS that happen to be only
working GSM band in my location with no avail. For this, I need to
know if including the 900 band as part of the switch statement
will resolve the problem of having PCS band not working. Also is
that the only section that need to be corrected in order for 
PCS band to camp and register with any approved cell in a location.

Thank you.

Sincerely,

Rasak.


--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Return-value-for-fucntion-class-of-band-in-gsm322-c-tp4001443.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From gouchengcheng at gmail.com  Mon May 21 01:18:49 2012
From: gouchengcheng at gmail.com (Chengcheng Gou)
Date: Mon, 21 May 2012 09:18:49 +0800
Subject: the cause of error "l1ctl.c:238 Dropping frame with 93 bit errors"
Message-ID: <CANV9D0nCHKa4eKT8e2jcAarDOqD1jAPi1oq60EdoGMqO7Nw2Vw@mail.gmail.com>

I am running the ccch_scan, and the error occurs:

<000c> l1ctl.c:238 Dropping frame with 93 bit errors
Dropping frame with 84 bit errors
<000c> l1ctl.c:238 Dropping frame with 84 bit errors
Dropping frame with 83 bit errors
<000c> l1ctl.c:238 Dropping frame with 83 bit errors
Dropping frame with 86 bit errors
<000c> l1ctl.c:238 Dropping frame with 86 bit errors
Dropping frame with 85 bit errors
<000c> l1ctl.c:238 Dropping frame with 85 bit errors
Dropping frame with 71 bit errors
<000c> l1ctl.c:238 Dropping frame with 71 bit errors
Dropping frame with 78 bit errors
<000c> l1ctl.c:238 Dropping frame with 78 bit errors
Dropping frame with 80 bit errors
<000c> l1ctl.c:238 Dropping frame with 80 bit errors

in which situations the error may appear? Does anyone know?
Thanks!



From laforge at gnumonks.org  Mon May 21 07:46:25 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 21 May 2012 09:46:25 +0200
Subject: the cause of error "l1ctl.c:238 Dropping frame with 93 bit errors"
In-Reply-To: <CANV9D0nCHKa4eKT8e2jcAarDOqD1jAPi1oq60EdoGMqO7Nw2Vw@mail.gmail.com>
References: <CANV9D0nCHKa4eKT8e2jcAarDOqD1jAPi1oq60EdoGMqO7Nw2Vw@mail.gmail.com>
Message-ID: <20120521074625.GJ19343@prithivi.gnumonks.org>

On Mon, May 21, 2012 at 09:18:49AM +0800, Chengcheng Gou wrote:
> I am running the ccch_scan, and the error occurs:
> 
> <000c> l1ctl.c:238 Dropping frame with 93 bit errors
> Dropping frame with 84 bit errors

As the message states, the frame gets dropped because there are bit
errors.

> in which situations the error may appear? Does anyone know?

In any case that can cause bit errors, such as too weak signal,
interference, overpowering the input, etc.

-- 
- 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 gouchengcheng at gmail.com  Mon May 21 08:54:06 2012
From: gouchengcheng at gmail.com (Chengcheng Gou)
Date: Mon, 21 May 2012 16:54:06 +0800
Subject: How to transmit burst in different time slots at the same time
Message-ID: <CANV9D0nr-A+SZvPurVb0vzLSZje230N85B3FV36oaoEA9iGpvw@mail.gmail.com>

Hi

The BB can transmit burst in different  time slots at the same time?

Thanks!



From 246tnt at gmail.com  Mon May 21 16:46:22 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Mon, 21 May 2012 18:46:22 +0200
Subject: How to transmit burst in different time slots at the same time
In-Reply-To: <CANV9D0nr-A+SZvPurVb0vzLSZje230N85B3FV36oaoEA9iGpvw@mail.gmail.com>
References: <CANV9D0nr-A+SZvPurVb0vzLSZje230N85B3FV36oaoEA9iGpvw@mail.gmail.com>
Message-ID: <CAHL+j0_sz=iZ6DKHzwbd+tmL+S3rB6H7skOTT_UDqEuCuk2u6w@mail.gmail.com>

> The BB can transmit burst in different ?time slots at the same time?

The HW itself can do it.
But there is no support whatsoever at any of the software layer for it
so you're on your own.

Cheers,

    Sylvain



From gouchengcheng at gmail.com  Tue May 22 00:09:40 2012
From: gouchengcheng at gmail.com (gcc)
Date: Mon, 21 May 2012 17:09:40 -0700 (PDT)
Subject: How to transmit burst in different time slots at the same time
In-Reply-To: <CAHL+j0_sz=iZ6DKHzwbd+tmL+S3rB6H7skOTT_UDqEuCuk2u6w@mail.gmail.com>
References: <CANV9D0nr-A+SZvPurVb0vzLSZje230N85B3FV36oaoEA9iGpvw@mail.gmail.com>
	<CAHL+j0_sz=iZ6DKHzwbd+tmL+S3rB6H7skOTT_UDqEuCuk2u6w@mail.gmail.com>
Message-ID: <1337645380223-4005755.post@n3.nabble.com>

but how to so that,can you give me some suggestion?

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/How-to-transmit-burst-in-different-time-slots-at-the-same-time-tp4004541p4005755.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From roladunjoye at gmail.com  Mon May 21 13:07:51 2012
From: roladunjoye at gmail.com (rola)
Date: Mon, 21 May 2012 06:07:51 -0700 (PDT)
Subject: Unfix BUG in GSM322.c and prim_pm.c
Message-ID: <1337605671309-4004815.post@n3.nabble.com>


Hi All,

Many of us are striving to find a way to make use of OBB but due
to limited knowledge of programming we get stuck at one point
or the other. I've tried to make OBB work for me but nothing
has happened.

I've passed through the level of installation and file configuration
with everything set except for an assuming bug left unfix in
gsm322.c or prim_pm.c.

This bug is at the point of power measurement when cell selection is
in the state of any cell. The first band is always measured accurately
while the next band range works at layer1 with no response back to mobile.
Due to this, the same second band range power is measured twice 
and that leads to overwriting error.

I've look through the code to figure out where it is appropriate to make
correction in order for the process to flow accordingly. But, in as much
as I try, I end back at the same spot of not knowing where to effect
a change.

Two conspicuous identifiable issues are:

1. PCS arfcn range calculation seems to be incorrect. The initial arfcn and
final
are passed with extremely high range values in reverse order.

2. Perhaps as a result of the above, no response of measured power is
feed back to mobile and that breakdown the program flow in gsm322.c.
Thereby causing the same erring band to be measured twice and stuck in
that cycle of measurement.

I just need a guidance on what changes to make in order to fix these issues.

I will greatly appreciate it if the only response is just to confirm if I'm
right
or wrong in my assumptions.

Thanks.

Sincerely,

Rasaki


--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Unfix-BUG-in-GSM322-c-and-prim-pm-c-tp4004815.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From 246tnt at gmail.com  Mon May 21 13:22:01 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Mon, 21 May 2012 15:22:01 +0200
Subject: Unfix BUG in GSM322.c and prim_pm.c
In-Reply-To: <1337605671309-4004815.post@n3.nabble.com>
References: <1337605671309-4004815.post@n3.nabble.com>
Message-ID: <CAHL+j0-=Kw_6S5YgBXr5CHGzCN=UUeC+9fMq8Y4kay_VJAH_=Q@mail.gmail.com>

> 1. PCS arfcn range calculation seems to be incorrect. The initial arfcn and
> final
> are passed with extremely high range values in reverse order.

Are you sure the "high range" is not just caused by the ARFCN_PCS flags ?
(which is 16384 IIRC)

Since DCS and PCS arfcn # overlap, PCS is treated specially and
remapped with 16384 added to them.

Cheers,

    Sylvain



From roladunjoye at gmail.com  Tue May 29 15:35:39 2012
From: roladunjoye at gmail.com (rola)
Date: Tue, 29 May 2012 08:35:39 -0700 (PDT)
Subject: Unfix BUG in GSM322.c and prim_pm.c
In-Reply-To: <CAHL+j0-=Kw_6S5YgBXr5CHGzCN=UUeC+9fMq8Y4kay_VJAH_=Q@mail.gmail.com>
References: <1337605671309-4004815.post@n3.nabble.com>
	<CAHL+j0-=Kw_6S5YgBXr5CHGzCN=UUeC+9fMq8Y4kay_VJAH_=Q@mail.gmail.com>
Message-ID: <1338305739405-4020931.post@n3.nabble.com>

Hi Sylvain,

I've been going through the code all the while and making sure
that I set all the parameters as it should be before making any 
response to your reply. During this course I stumbled on the 
list modified file with changes made before 850 and 1900 bands
could be supported by Osmocom-BB 
(http://bb.osmocom.org/trac/changeset/58ac7e0e98c448dcece8e7dfa53f484c982e96cf).
I performed some
tests and I have my observation below.

I tested with two different working registered SIMs from two different 
GSM carriers.One of the SIMs stuck in the processing of reading SIM
information and the work with an hitch. My best guess reason for the
first SIM stuck situation is the SIM reader inability to retrieve large
number
supported PLM list stored in the SIM. I presumed this by comparing 
the result of the same SIM file request number to the outcome of
the second SIM.

The second SIM works perfectly, retrieved every SIM request
information except for the previously stored scanned cell-info.
Comparing the outcome of the SIM request file number to those 
posted by others on the mailing-list made me concluded that the unable 
information to be retrieved is the previously cell-scanned info.

Though this anomaly does not affect continuous functioning of the
mobile application but it affects the power scan state. Ordinary 
power scanning of the cell could have been done initially with the 
stored cell-info in the SIM but that is not the case. Due to this
the scan state starts with all available cells around.
I performed all the above test using Pirelli-dpl10. 

My question is could there be anything missing out in the process
of adopting PCS1900. I ask this because when never I configure
to use 850 band only, I do not not have any error except for the
fact that the carriers only use 1900band in my area.

Secondly, could inability to retrieve stored cell-info be due to different
in ARFCN. Because I have only seen people being successful with 850 band
and not 1900. My test of 850 with Pirelli ended with scanning stage of
fbsb without any info. I know that will not work because I've tried manually
selecting 850 on my regular phone ending with no service. So my hunch 
is still that somewhere along the line ARFCN for PCS1900 got tangled.

Now my contentions are,

1. Inability to read previously stored cell-info.
2. Breakdown of power scan for ARFCN of PCS1900 

I will be so grateful if these angles can be look into.
Thank you.

Sincerely,

Rasak



--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Unfix-BUG-in-GSM322-c-and-prim-pm-c-tp4004815p4020931.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From gouchengcheng at gmail.com  Tue May 22 02:01:32 2012
From: gouchengcheng at gmail.com (Chengcheng Gou)
Date: Tue, 22 May 2012 10:01:32 +0800
Subject: the Paging response can be received every time I get SMS?
Message-ID: <CANV9D0mQbKbeQjUk9pKjjbd5EuotyXg-GnhagX6vcoOCGPmh4g@mail.gmail.com>

the  Paging response is uplink, How can I received it?



From laforge at gnumonks.org  Tue May 22 06:27:38 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 22 May 2012 08:27:38 +0200
Subject: the Paging response can be received every time I get SMS?
In-Reply-To: <CANV9D0mQbKbeQjUk9pKjjbd5EuotyXg-GnhagX6vcoOCGPmh4g@mail.gmail.com>
References: <CANV9D0mQbKbeQjUk9pKjjbd5EuotyXg-GnhagX6vcoOCGPmh4g@mail.gmail.com>
Message-ID: <20120522062738.GC19343@prithivi.gnumonks.org>

Hi Chengchen Gou,

On Tue, May 22, 2012 at 10:01:32AM +0800, Chengcheng Gou wrote:
> the  Paging response is uplink, How can I received it?

I think there is noe of those "one line messages" from you on this list
every day.

While we all appreciate your interest in OsmocomBB, I would like you to
notice the following:

1) this list does not exist for your personal education or training, but
it is a community list where developers share their experience and
collaboratively work together.  So far, I yet have to see any
contribution from you.  This means, you are asking a lot of questions
(taking information and using other peoples' time for free) but at least
so far without giving something back.  Where are your patches for the
code?  Your updates to our documentation/wiki?  Where are your responses
to other peoples's questions?

2) If you are going to take advantage of the expertise present on this
list, it would be extremely polite to write mails that are longer than
one to five lines.  Please read the list archives, you will probably
find nobody ever on this list who has consistently written messages that
only consist of one line.  Please at least pay respect to the other
people on this list by properly explaining what you are trying to do

3) We are not your free teaching/training program about how GSM works,
and how the TI Calypso works.  OsmocomBB is the result of thousands of
hours of spare time work by lots of dedicated engineers.  So again, out
of respect to the work of others, I would like you to at least spend
some significant amount of time to try to resolve your questions by
yourse,f, _before_ you post to this list.   And once you post, please
describe what you have done so far in order to resolve your question.

I for my part have personally decided to no longer respond to your messages.

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 gouchengcheng at gmail.com  Tue May 22 07:01:40 2012
From: gouchengcheng at gmail.com (gcc)
Date: Tue, 22 May 2012 00:01:40 -0700 (PDT)
Subject: the Paging response can be received every time I get SMS?
In-Reply-To: <20120522062738.GC19343@prithivi.gnumonks.org>
References: <CANV9D0mQbKbeQjUk9pKjjbd5EuotyXg-GnhagX6vcoOCGPmh4g@mail.gmail.com>
	<20120522062738.GC19343@prithivi.gnumonks.org>
Message-ID: <1337670100422-4006121.post@n3.nabble.com>

Now , my knowledge is limited, so I need others' help, I would like to thank
all the people that helped me, I will do better later.
Thanks for your suggestions.

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/the-Paging-response-can-be-received-every-time-I-get-SMS-tp4005880p4006121.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From holger at freyther.de  Tue May 22 08:37:45 2012
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Tue, 22 May 2012 10:37:45 +0200
Subject: the Paging response can be received every time I get SMS?
In-Reply-To: <1337670100422-4006121.post@n3.nabble.com>
References: <CANV9D0mQbKbeQjUk9pKjjbd5EuotyXg-GnhagX6vcoOCGPmh4g@mail.gmail.com>
	<20120522062738.GC19343@prithivi.gnumonks.org>
	<1337670100422-4006121.post@n3.nabble.com>
Message-ID: <4FBB5059.6020100@freyther.de>

On 05/22/2012 09:01 AM, gcc wrote:
> Now , my knowledge is limited, so I need others' help, I would like to thank
> all the people that helped me, I will do better later.
> Thanks for your suggestions.

Hi,

this is an extremely selfish attitude. You might not be able to patch the DSP
firmware right now but you are certainly capable enough to update the wiki.
The decision to not give back speaks for itself.

holger

PS: ??????



From laforge at gnumonks.org  Wed May 23 07:46:13 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 23 May 2012 09:46:13 +0200
Subject: TODAY: May 23, 7pm / Osmocom meeting in Berlin
Message-ID: <20120523074613.GX19343@prithivi.gnumonks.org>

Hi all!

This is the announcement for the 4th incarnation of our bi-weekly
Osmocom Berlin meeting.

	May 23, 7pm @ CCC Berlin, Marienstr. 11, 10113 Berlin

There is no particular schedule for now, but if there is interest we
can do an introduction + demo of the new sysmoBTS.

Also, I'll have my SIMtrace with me, to read out TERMINAL PROFILE from
phones for https://terminal-profile.osmocom.org/ .  So if you have any
phones to read out: Please bring them (with charged battery or charger!)

So we'll just meet + talk.  There seem to be some SMSC related questions
that we would want to adress, so you have been warned ;)

If you are interested to show up, feel free to do so.  There is no
registration required.  The meeting is free as in "free beer", despite
no actual free beer being around ;)

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 dirk.bossenz at lipsia.de  Fri May 25 10:37:01 2012
From: dirk.bossenz at lipsia.de (dirk.bossenz at lipsia.de)
Date: Fri, 25 May 2012 12:37:01 +0200
Subject: TODAY: May 23, 7pm / Osmocom meeting in Berlin
In-Reply-To: <20120523074613.GX19343@prithivi.gnumonks.org>
References: <20120523074613.GX19343@prithivi.gnumonks.org>
Message-ID: <web-129756625@csc.de>

Hi,


Unfortunately I couldn't last and the next date is already occupied, 
but I'm intressed in participate of sysmoBTS-Access-Core-Side and can 
support with SMSC-knowledge by different vendors.

So you can adress questions over the list or confidentiality directly.

cu
Dirk


On Wed, 23 May 2012 09:46:13 +0200
  Harald Welte <laforge at gnumonks.org> wrote:
> Hi all!
> 
> This is the announcement for the 4th incarnation of our bi-weekly
> Osmocom Berlin meeting.
> 
> 	May 23, 7pm @ CCC Berlin, Marienstr. 11, 10113 Berlin
> 
> There is no particular schedule for now, but if there is interest we
> can do an introduction + demo of the new sysmoBTS.
> 
> Also, I'll have my SIMtrace with me, to read out TERMINAL PROFILE 
>from
> phones for https://terminal-profile.osmocom.org/ .  So if you have 
>any
> phones to read out: Please bring them (with charged battery or 
>charger!)
> 
> So we'll just meet + talk.  There seem to be some SMSC related 
>questions
> that we would want to adress, so you have been warned ;)
> 
> If you are interested to show up, feel free to do so.  There is no
> registration required.  The meeting is free as in "free beer", 
>despite
> no actual free beer being around ;)
> 
> 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 tigger at lipsia.de  Fri May 25 14:29:04 2012
From: tigger at lipsia.de (tigger at lipsia.de)
Date: Fri, 25 May 2012 16:29:04 +0200
Subject: TODAY: May 23, 7pm / Osmocom meeting in Berlin
In-Reply-To: <20120523074613.GX19343@prithivi.gnumonks.org>
References: <20120523074613.GX19343@prithivi.gnumonks.org>
Message-ID: <web-129757833@csc.de>

Hi,

Unfortunately I couldn't last and the next date is already occupied, 
but I'm (the guy with SDN, and had nothing else to say) intressed in 
participate (how?) of sysmoBTS-Access-Core-Side and can support i.a. 
with SMSC-knowledge by different vendors.

So you can adress questions over the list or confidential directly.

cu
Dirk


On Wed, 23 May 2012 09:46:13 +0200
  Harald Welte <laforge at gnumonks.org> wrote:
> Hi all!
> 
> This is the announcement for the 4th incarnation of our bi-weekly
> Osmocom Berlin meeting.
> 
> 	May 23, 7pm @ CCC Berlin, Marienstr. 11, 10113 Berlin
> 
> There is no particular schedule for now, but if there is interest we
> can do an introduction + demo of the new sysmoBTS.
> 
> Also, I'll have my SIMtrace with me, to read out TERMINAL PROFILE 
>from
> phones for https://terminal-profile.osmocom.org/ .  So if you have 
>any
> phones to read out: Please bring them (with charged battery or 
>charger!)
> 
> So we'll just meet + talk.  There seem to be some SMSC related 
>questions
> that we would want to adress, so you have been warned ;)
> 
> If you are interested to show up, feel free to do so.  There is no
> registration required.  The meeting is free as in "free beer", 
>despite
> no actual free beer being around ;)
> 
> 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  Fri May 25 16:46:23 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 25 May 2012 18:46:23 +0200
Subject: Osmocom user group meetings in Berlin
Message-ID: <20120525164623.GY14653@prithivi.gnumonks.org>

Hi all,

I have upated the wiki page at
http://openbsc.osmocom.org/trac/wiki/OsmoUserGroup/Berlin to indicate
the meeting dates for the next couple of months.  So now it is clear
that even without any explicit separate announcement, we will be meeting
at the indicated date:

    June 13, 2012
    June 27, 2012
    July 11, 2012
    July 25, 2012
    August 8, 2012
    August 22, 2012 

It had  been requested to start a bit later (8pm instead of 7pm), and
from the next meeting onwards we will follow that request.

Looking forward to meeting you!

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 gouchengcheng at gmail.com  Wed May 30 12:39:00 2012
From: gouchengcheng at gmail.com (Chengcheng Gou)
Date: Wed, 30 May 2012 20:39:00 +0800
Subject: the structure of "TCH + SACCH" is depend on timeslot?
Message-ID: <CANV9D0=toFnUfEXMUSzEKdyZaSv1vqQS5+HRnUksFykGoT1kHg@mail.gmail.com>

Hi,

I am studying the TCH channel, and read the BB source. I find that
the structure of  "TCH + SACCH" is depend on ts.that is when the timeslot
is even, the 12 of a TCH multiframes is SACCH,and the 25 is idle;and When
the timeslot is odd, the 25 of a TCH multiframes is SACCH,and the12 is idle.

is that right? if that`s right, why ? I can`t find any Material about
it. Thanks!



From 246tnt at gmail.com  Wed May 30 13:04:40 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 30 May 2012 17:04:40 +0400
Subject: the structure of "TCH + SACCH" is depend on timeslot?
In-Reply-To: <CANV9D0=toFnUfEXMUSzEKdyZaSv1vqQS5+HRnUksFykGoT1kHg@mail.gmail.com>
References: <CANV9D0=toFnUfEXMUSzEKdyZaSv1vqQS5+HRnUksFykGoT1kHg@mail.gmail.com>
Message-ID: <CAHL+j0_9HuFfmgoTqd0G=9oNbR_r3O2HiQQenzY_PZWbpaFReA@mail.gmail.com>

Hi

> I am studying the TCH channel, and read the BB source. I find that
> the structure of ?"TCH + SACCH" is depend on ts.that is when the timeslot
> is even, the 12 of a TCH multiframes is SACCH,and the 25 is idle;and When
> the timeslot is odd, the 25 of a TCH multiframes is SACCH,and the12 is idle.
>
> is that right?

Yes

> if that`s right, why ?

To share the load. So that the BTS doesn't have to process all the
SACCH of all the TCH at the same time.

> I can`t find any Material about

GSM 05.02 Clause 7 Table 1 of 9, the SACCH/TF entries

Cheers,

   Sylvain



From gouchengcheng at gmail.com  Thu May 31 14:04:14 2012
From: gouchengcheng at gmail.com (Chengcheng Gou)
Date: Thu, 31 May 2012 22:04:14 +0800
Subject: the airprobe port to BB
Message-ID: <CANV9D0n2ORf+GJ2cvhrYQL6Ejj2LGhHjBnAd8tTO2EZtGU-ywg@mail.gmail.com>

Hi,

I am studying the GSM voice interception of airprobe,and want to port
to BB,using
the ccch_scan.c .the problem is that,

the airprobe is written by C++,and the BB is C;

I find the useful part of airport is
airprobe/gsm-receiver/src/lib/decoder/openbtsstuff,
and  how to modify the makefile of BB to use the source of openbtsstuff?


Thanks!