From jokaj at o2.pl  Sun Jan  8 18:08:34 2012
From: jokaj at o2.pl (wizer12)
Date: Sun, 8 Jan 2012 10:08:34 -0800 (PST)
Subject: Linux + u-boot port to MT6235
In-Reply-To: <20101109045739.GA11763@asus.wolf>
References: <AANLkTinPr8WdFxs7tEDhULhk_=e=gMobv77na4fc5yXo@mail.gmail.com>
	<20101029161141.GN3544@prithivi.gnumonks.org>
	<AANLkTimgKdhsi1wouZk1ziSHqSYpwFa_W4A41NF9=DG9@mail.gmail.com>
	<20101030142554.GL8939@prithivi.gnumonks.org>
	<AANLkTimDpqMkoSe=FsOkLDXq+=8hzOxhWDOqVLXCUu7v@mail.gmail.com>
	<AANLkTinLjpOk4cT2sGP7kxWY6Qk+t=H+aTnfUydn6_U-@mail.gmail.com>
	<20101103174131.GA8814@asus.wolf>
	<AANLkTikFC6avOAb3Pv0iTwGW19tnJx0+0dV=bv66_X-W@mail.gmail.com>
	<20101109045739.GA11763@asus.wolf>
Message-ID: <1326046114400-3642449.post@n3.nabble.com>

jaki toolchain do arm-a u?ywacie?
czy https://sourcery.mentor.com/sgpp/lite/arm/portal/release1592   ?

How toolchain for arm-and do you use?
or https://sourcery.mentor.com/sgpp/lite/arm/portal/release1592?

i have ubuntu 10.04

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Linux-u-boot-port-to-MT6235-tp1791738p3642449.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From jokaj at o2.pl  Wed Jan  4 10:56:54 2012
From: jokaj at o2.pl (wizer12)
Date: Wed, 4 Jan 2012 02:56:54 -0800 (PST)
Subject: Linux + u-boot port to MT6235
In-Reply-To: <AANLkTinPr8WdFxs7tEDhULhk_=e=gMobv77na4fc5yXo@mail.gmail.com>
References: <AANLkTinPr8WdFxs7tEDhULhk_=e=gMobv77na4fc5yXo@mail.gmail.com>
Message-ID: <1325674614407-3631570.post@n3.nabble.com>

no, kurde, my?la?em, ?e to rosjanie wrzucili linuxa na sciphona (bo z
rosyjskiego forum wyczyta?em o tym) a tu m?j krajan :)
no szacun wielki panie Marcinie! 

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Linux-u-boot-port-to-MT6235-tp1791738p3631570.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From laforge at gnumonks.org  Wed Jan  4 14:00:32 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 4 Jan 2012 15:00:32 +0100
Subject: Linux + u-boot port to MT6235
In-Reply-To: <1325674614407-3631570.post@n3.nabble.com>
References: <AANLkTinPr8WdFxs7tEDhULhk_=e=gMobv77na4fc5yXo@mail.gmail.com>
	<1325674614407-3631570.post@n3.nabble.com>
Message-ID: <20120104140032.GM13276@prithivi.gnumonks.org>

Hi !

On Wed, Jan 04, 2012 at 02:56:54AM -0800, wizer12 wrote:
> no, kurde, my?la?em, ?e to rosjanie wrzucili linuxa na sciphona (bo z
> rosyjskiego forum wyczyta?em o tym) a tu m?j krajan :)
> no szacun wielki panie Marcinie! 

I would appreciate if you could post in English language to this mailing
list.  Don't hesitate even if you think your english is bad.  Most
people here (including me) are non-native English speakers.

-- 
- 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 jtd1959 at gmail.com  Wed Jan  4 14:05:34 2012
From: jtd1959 at gmail.com (J T Dsouza)
Date: Wed, 4 Jan 2012 19:35:34 +0530
Subject: Linux + u-boot port to MT6235
In-Reply-To: <20120104140032.GM13276@prithivi.gnumonks.org>
References: <AANLkTinPr8WdFxs7tEDhULhk_=e=gMobv77na4fc5yXo@mail.gmail.com>
	<1325674614407-3631570.post@n3.nabble.com>
	<20120104140032.GM13276@prithivi.gnumonks.org>
Message-ID: <CACE1qH4aLOd-WmCsSqhD9z=nTKDsfiFEziA2wwdrcNAGgJnd-Q@mail.gmail.com>

On Wed, Jan 4, 2012 at 7:30 PM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi !
>
> On Wed, Jan 04, 2012 at 02:56:54AM -0800, wizer12 wrote:
> > no, kurde, my?la?em, ?e to rosjanie wrzucili linuxa na sciphona (bo z
> > rosyjskiego forum wyczyta?em o tym) a tu m?j krajan :)
> > no szacun wielki panie Marcinie!
>
> I would appreciate if you could post in English language to this mailing
> list.  Don't hesitate even if you think your english is bad.  Most
> people here (including me) are non-native English speakers.
>
>
 Well, fuck, I thought it was Russians threw Linux on SciPhone (because of the
Russian forum I read about it) and my countryman here:) no estimates of the
great Mr. Martin!

Courtesy google translate.

> --
> - 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)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20120104/cc7672e3/attachment.htm>

From jokaj at o2.pl  Sat Jan  7 11:05:22 2012
From: jokaj at o2.pl (wizer12)
Date: Sat, 7 Jan 2012 03:05:22 -0800 (PST)
Subject: Linux + u-boot port to MT6235
In-Reply-To: <CACE1qH4aLOd-WmCsSqhD9z=nTKDsfiFEziA2wwdrcNAGgJnd-Q@mail.gmail.com>
References: <AANLkTinPr8WdFxs7tEDhULhk_=e=gMobv77na4fc5yXo@mail.gmail.com>
	<1325674614407-3631570.post@n3.nabble.com>
	<20120104140032.GM13276@prithivi.gnumonks.org>
	<CACE1qH4aLOd-WmCsSqhD9z=nTKDsfiFEziA2wwdrcNAGgJnd-Q@mail.gmail.com>
Message-ID: <1325934322361-3639991.post@n3.nabble.com>

sorry 
ok, I will be writing in English :P

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Linux-u-boot-port-to-MT6235-tp1791738p3639991.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From rojasvictor at cableat.net  Thu Jan 26 16:02:02 2012
From: rojasvictor at cableat.net (Victor Rojas)
Date: Thu, 26 Jan 2012 13:02:02 -0300
Subject: Linux + u-boot port to MT6235
Message-ID: <000e01ccdc43$e6b9af30$b42d0d90$@net>

Nacesito temas y confaguracion 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20120126/5d0717b7/attachment.htm>

From h.v.neerven at home.nl  Mon Jan  2 14:27:53 2012
From: h.v.neerven at home.nl (hanzie)
Date: Mon, 2 Jan 2012 06:27:53 -0800 (PST)
Subject: R: GPRS decode tutorial
In-Reply-To: <770083acc73d.4e9ffc1f@studenti.unimi.it>
References: <CAOYJJftBQ1+TWhVTk2y4fwjHRxGGsOn7Am0jcehg4k9Nq6wV0g@mail.gmail.com>
	<770083acc73d.4e9ffc1f@studenti.unimi.it>
Message-ID: <1325514473010-3626678.post@n3.nabble.com>



Luca Bongiorni-2 wrote
> 
> Hi Dario,
> ?i suggest you to download the last Sylvain's burst_ind, because is
> improved of some features and patch it manually with Nohl's patch.
> 
> Then you will be able to dump the bursts using ccch_scan, instead of
> layer23.
> 
> 

Hello Luca,

Can you explain in detailed steps how to do what you describe above.

thnx in advanced.

Hans

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/GPRS-decode-tutorial-tp3437051p3626678.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From benny at benny.de  Wed Jan 11 20:24:42 2012
From: benny at benny.de (Benjamin Hagemann)
Date: Wed, 11 Jan 2012 21:24:42 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <20111211105427.GE10252@prithivi.gnumonks.org>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
Message-ID: <20120111202442.GW12352@quelle.benny.de>

Hello,

last days I read about sourcecode release of Tizen.
Here the project page: https://www.tizen.org/

(german news about: http://www.golem.de/1201/88938.html )

Could Tizen be a way to a free mobile phone?

-- 
Regards,

	Benny

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

From acassis at gmail.com  Wed Jan 11 20:58:02 2012
From: acassis at gmail.com (Alan Carvalho de Assis)
Date: Wed, 11 Jan 2012 18:58:02 -0200
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <20120111202442.GW12352@quelle.benny.de>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<20120111202442.GW12352@quelle.benny.de>
Message-ID: <CAG4Y6eQcwsddFZekd2cxgkK20G2FaoQBm5JqoofnA09kTzC8UQ@mail.gmail.com>

Hi Benjamin,

No, it is not.

Tizen is just a Linux running in the Application Processor (AP), just
like Android.

OsmocomBB is a GSM stack which should run in the Baseband Processor (BP).

Best Regards,

Alan

On 1/11/12, Benjamin Hagemann <benny at benny.de> wrote:
> Hello,
>
> last days I read about sourcecode release of Tizen.
> Here the project page: https://www.tizen.org/
>
> (german news about: http://www.golem.de/1201/88938.html )
>
> Could Tizen be a way to a free mobile phone?
>
> --
> Regards,
>
> 	Benny
>
> gpg     0xFC505AB0
> jabber  benny at benny.de
> sip     benny at benny.de
>



From benny at benny.de  Thu Jan 12 06:34:38 2012
From: benny at benny.de (Benjamin Hagemann)
Date: Thu, 12 Jan 2012 07:34:38 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <CAG4Y6eQcwsddFZekd2cxgkK20G2FaoQBm5JqoofnA09kTzC8UQ@mail.gmail.com>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<20120111202442.GW12352@quelle.benny.de>
	<CAG4Y6eQcwsddFZekd2cxgkK20G2FaoQBm5JqoofnA09kTzC8UQ@mail.gmail.com>
Message-ID: <20120112063438.GZ12352@quelle.benny.de>

Hello Alan,

* Alan Carvalho de Assis <acassis at gmail.com> [2012-01-11 22:00]:
> 
> No, it is not.
> 
> Tizen is just a Linux running in the Application Processor (AP), just
> like Android.
> 
> OsmocomBB is a GSM stack which should run in the Baseband Processor (BP).

yes, right I know.
OsmocomBB is today ready to initiate/receive a phone call and
send/receive SMS. That the low level function in baseband.

So I think the question was to combinate this baseband function with
free software in the AP, which handle the "userland", GUI, contactlist
and so on. I though is there a OsmocomBB compatible "userland" /AP-OS
or should this software be developed completly new?

-- 
Regards,

	Benny

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

From peter at stuge.se  Thu Jan 12 08:00:18 2012
From: peter at stuge.se (Peter Stuge)
Date: Thu, 12 Jan 2012 09:00:18 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <20120112063438.GZ12352@quelle.benny.de>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<20120111202442.GW12352@quelle.benny.de>
	<CAG4Y6eQcwsddFZekd2cxgkK20G2FaoQBm5JqoofnA09kTzC8UQ@mail.gmail.com>
	<20120112063438.GZ12352@quelle.benny.de>
Message-ID: <20120112080018.16845.qmail@stuge.se>

Benjamin Hagemann wrote:
> I think the question was to combinate this baseband function with
> free software in the AP, which handle the "userland", GUI, contactlist
> and so on. I though is there a OsmocomBB compatible "userland" /AP-OS
> or should this software be developed completly new?

Since no other open source AP projects run on the Calypso and fit
the Motorola phones this is the exact discussion that has already
happened in this thread. Check out the archives.


//Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20120112/fa10a9ff/attachment.bin>

From fabio.pasini at gmail.com  Fri Jan 27 13:14:56 2012
From: fabio.pasini at gmail.com (Fabio Pasini)
Date: Fri, 27 Jan 2012 05:14:56 -0800 (PST)
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <20120112080018.16845.qmail@stuge.se>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<20120111202442.GW12352@quelle.benny.de>
	<CAG4Y6eQcwsddFZekd2cxgkK20G2FaoQBm5JqoofnA09kTzC8UQ@mail.gmail.com>
	<20120112063438.GZ12352@quelle.benny.de>
	<20120112080018.16845.qmail@stuge.se>
Message-ID: <1327670096061-3693227.post@n3.nabble.com>

>Since no other open source AP projects run on the Calypso and fit
>the Motorola phones this is the exact discussion that has already
>happened in this thread. Check out the archives. 
Please, would it be possible to include here a link for the other thread
discussing that matter? 
The main question posted by Harald Welte, 
("whether we focus on  the Openmoko FreeRunner / Neo1973 phones, or the
Motorola/Compal C1xx phones")
remais open, or that other thread Benjamin mentioned have some detail that
resolves Harald's first post?
The previous message somehow halted the discussion...


So far, it seems that Motorola/Compal C1xx have more adepts:
- Peter Stuge - Dec 11, 2011; 12:11pm
- Andreas Eversberg - Dec 11, 2011; 3:18pm
- Scott Weisman - Dec 12, 2011; 8:17am
Did I missed someone?


>But maybe the best thing is to actually stat working on the power
>management aspects, as we will need them in both cases. 
That would add even more momentum to the project. 
And perhaps bring up other details to help choosing between
Motorola/OpenMoko.    

Best regards,
F?bio

--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Creating-a-real-usable-phone-using-OsmocomBB-tp3577131p3693227.html
Sent from the baseband-devel mailing list archive at Nabble.com.



From khorben at defora.org  Tue Jan 31 23:27:31 2012
From: khorben at defora.org (Pierre Pronchery)
Date: Wed, 01 Feb 2012 00:27:31 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <1327670096061-3693227.post@n3.nabble.com>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<20120111202442.GW12352@quelle.benny.de>
	<CAG4Y6eQcwsddFZekd2cxgkK20G2FaoQBm5JqoofnA09kTzC8UQ@mail.gmail.com>
	<20120112063438.GZ12352@quelle.benny.de>
	<20120112080018.16845.qmail@stuge.se>
	<1327670096061-3693227.post@n3.nabble.com>
Message-ID: <4F2878E3.6070605@defora.org>

			Hi,

(sorry for not participating earlier)

On 27/01/2012 14:14, Fabio Pasini wrote:
> [...]
> So far, it seems that Motorola/Compal C1xx have more adepts:
> - Peter Stuge - Dec 11, 2011; 12:11pm
> - Andreas Eversberg - Dec 11, 2011; 3:18pm
> - Scott Weisman - Dec 12, 2011; 8:17am
> Did I missed someone?

my impression would be that the truly embedded solution is the most
sustainable approach, or certainly the one with fewer uncertainties with
regard to hardware quality and availability. I feel comforted in this
direction when I see the current progress, as blogged by Harald recently:
http://laforge.gnumonks.org/weblog/2012/01/28/#20120128-osmocombb_rssi

On the other hand, I am very interested by supporting the Openmoko
Freerunner, having already written a complete embedded telephony
environment for this platform (with interchangeable telephony backend).
See https://trac.hackable1.org/trac/wiki/DeforaOSSmartphone for more
details.

Considering this, I would say that what matters most would be an
easy-to-(re)use API to interact with the telephony subsystem, regardless
of its presence on a separate chip or not. Then both approaches would be
likely, and it should even be easier to hunt and catch bugs.

Easier said than done, but HTH nonetheless.

Cheers,
-- 
khorben



From laforge at gnumonks.org  Wed Jan 11 21:02:18 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 11 Jan 2012 22:02:18 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <20120111202442.GW12352@quelle.benny.de>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<20120111202442.GW12352@quelle.benny.de>
Message-ID: <20120111210218.GH30017@prithivi.gnumonks.org>

Hi Benny,

On Wed, Jan 11, 2012 at 09:24:42PM +0100, Benjamin Hagemann wrote:
 
> last days I read about sourcecode release of Tizen.
> Here the project page: https://www.tizen.org/
> 
> (german news about: http://www.golem.de/1201/88938.html )
> 
> Could Tizen be a way to a free mobile phone?

All that _all_ such projects (Android, Maemo, Mobiln, Greenphone/QTE,
evne Openmoko) were about is the PDA side of the feature phone.

None of them ever touched the baseband processor in any way

-- 
- 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 alexander.huemer at xx.vu  Tue Jan  3 13:03:37 2012
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Tue, 3 Jan 2012 14:03:37 +0100
Subject: Newbie DSP Questions
In-Reply-To: <1325369774.68042.YahooMailNeo@web122210.mail.ne1.yahoo.com>
References: <1325369774.68042.YahooMailNeo@web122210.mail.ne1.yahoo.com>
Message-ID: <20120103130337.GA17587@de.xx.vu>

On Sat, Dec 31, 2011 at 02:16:14PM -0800, Avner Ezra wrote:
> Hi
> 
> I'm newbie in DSP and SDR, but I'm really interested in this matter and I want to learn. I have bunch of questions which has short answers, if you can please answer them in easy terms and words, so I can understand them well. I hope this thread will help a lot of other newbies to understand DSP stuff better.
> 
> I have a Linux with every needed tools like osmocomm, gnuradio, openbts, kalibrate, uhd drivers, ... and USRP N210 hardware ready. Everything works normal and well. 
Hi Avner,

there are people on this list who are very skilled when it comes to DSP
stuff, although I think your questions are better suited for the
gnuradio ML.



From ttsou at vt.edu  Tue Jan  3 19:11:42 2012
From: ttsou at vt.edu (Thomas Tsou)
Date: Tue, 3 Jan 2012 14:11:42 -0500
Subject: Newbie DSP Questions
In-Reply-To: <1325369774.68042.YahooMailNeo@web122210.mail.ne1.yahoo.com>
References: <1325369774.68042.YahooMailNeo@web122210.mail.ne1.yahoo.com>
Message-ID: <CAF5FEsCxcVXZT5gwhaXA7symafDTBA1R+-P64EKWUfDn8jTQRg@mail.gmail.com>

On Sat, Dec 31, 2011 at 5:16 PM, Avner Ezra <avner.ezra at yahoo.com> wrote:
> A) Sometimes when I scan a network bandwidth like GSM1800 using kalibrate, I
> see some channels like 820, 538, etc. When I re-scan, I cannot find them.
> Does this mean that kalibrate finds a channel when a mobile handset has a
> live conversation or sms send or receive in progress? or what?

No, it most cases it means a weak signal. Kalibrate performs
per-channel energy detection prior to offset calculation against the
FCCH, which is always active. The variance is probably just noise.

> B) I want to wideband capture for example 125 ARFCN. It needs 25MHz
> bandwidth which USRP N210 can handle and stream it easily. Even AFAIK I can
> double this number and capture 250 ARFCN using single N210 (50MHz, in
> USRPN210 data sheet it says it's capable of streaming 50MHz wide signals).

To capture 50MHz you need to 8-bit samples to avoid saturating the
Ethernet bus. So yes it's possible, though I'm not sure about the
current state of device or API support for the feature.

> How can I wideband capture 125 ARFCNs? I tried to do it using:
> ./uhd_rx_cfile.py -f `arfcncalc -a 512 -b 1800 -d` --samp-rate=25000000 -N
> 200000000 -g 70 b1.cfile
>
> What I understood and decided to write such command above:
>
> B-1) arfcncalc calculates frequency of first GSM1800 channel (512 ARFCN)
> which is start point (in above command)
> B-2) Sampling Rate is the bandwidth I want to capture, in our case it's
> 25MHz means 125 ARFCN which each ARFCN has 200kHz bandwidth
> B-3) 200M samples will be received (-N parameter)
> B-4) Gain value is 70, means it will boost antennas to maximum power to
> receive signals, I think USRPN210 max. gain is 80
> B-5) My decimation rate here using 25M sampling rate and USRP N210 which has
> 100MHz ADC, will be 4. So if I decided to read cfile I have to use 4 as
> decimation rate.

You want the centre frequency of the spectrum you want to capture -
not the start point. Also, the maximum gain value will also vary
depending on the daughterboard. Otherwise, you are correct.

> C) How can I seperate and process 200khz by 200khz channels in wideband
> captured file?

The brute force approach is to individually frequency translate each
channel down to baseband, low-pass filter, and perform sample rate
conversion. The more efficient method it to construct a multirate
channelizer. GNU Radio has blocks for either approach, though
construction may not be straightforward.

  Thomas



From avner.ezra at yahoo.com  Wed Jan  4 20:34:00 2012
From: avner.ezra at yahoo.com (Avner Ezra)
Date: Wed, 4 Jan 2012 12:34:00 -0800 (PST)
Subject: Newbie DSP Questions
In-Reply-To: <CAF5FEsCxcVXZT5gwhaXA7symafDTBA1R+-P64EKWUfDn8jTQRg@mail.gmail.com>
References: <1325369774.68042.YahooMailNeo@web122210.mail.ne1.yahoo.com>
	<CAF5FEsCxcVXZT5gwhaXA7symafDTBA1R+-P64EKWUfDn8jTQRg@mail.gmail.com>
Message-ID: <1325709240.83176.YahooMailNeo@web122210.mail.ne1.yahoo.com>

Hi

Thank you so much Thomas, I learned too much from you.

Is there a good sample for UHD USRPs like USRP N210 which can send and receive file in other side?

I connected 2 USRPs to 2 laptops, sent a file using rx_send_from_file.py in ARFCN channel no: 560 and in other side I listened for incoming signals on same frequency, same sampling rate, same gain, etc. Two USRPs was about 10 meters far from each other. But I was not able to see my file's context in rx_recv_cfile.py, it captures cfile from same ARFCN channel using same frequency and sampling rate, but I was not able to see any related data to my file being trasmitted, any reason you can see here?

I heard that USRPs need hardware modification to be able to capture GSM signals, is it correct for N210?

Could you guide me a little on translating frequency to channels, low-pass filter and performing sample rate conversation? When I receive file using rx_recv_cfile, it asks for sampling rate parameter, it will not do all those steps? If not, please help me on this part which is your previous email's last part, I need a little more detail here.

Thank you once again


________________________________
 From: Thomas Tsou <ttsou at vt.edu>
To: Avner Ezra <avner.ezra at yahoo.com> 
Cc: "baseband-devel at lists.osmocom.org" <baseband-devel at lists.osmocom.org> 
Sent: Tuesday, January 3, 2012 10:41 PM
Subject: Re: Newbie DSP Questions
 
On Sat, Dec 31, 2011 at 5:16 PM, Avner Ezra <avner.ezra at yahoo.com> wrote:
> A) Sometimes when I scan a network bandwidth like GSM1800 using kalibrate, I
> see some channels like 820, 538, etc. When I re-scan, I cannot find them.
> Does this mean that kalibrate finds a channel when a mobile handset has a
> live conversation or sms send or receive in progress? or what?

No, it most cases it means a weak signal. Kalibrate performs
per-channel energy detection prior to offset calculation against the
FCCH, which is always active. The variance is probably just noise.

> B) I want to wideband capture for example 125 ARFCN. It needs 25MHz
> bandwidth which USRP N210 can handle and stream it easily. Even AFAIK I can
> double this number and capture 250 ARFCN using single N210 (50MHz, in
> USRPN210 data sheet it says it's capable of streaming 50MHz wide signals).

To capture 50MHz you need to 8-bit samples to avoid saturating the
Ethernet bus. So yes it's possible, though I'm not sure about the
current state of device or API support for the feature.

> How can I wideband capture 125 ARFCNs? I tried to do it using:
> ./uhd_rx_cfile.py -f `arfcncalc -a 512 -b 1800 -d` --samp-rate=25000000 -N
> 200000000 -g 70 b1.cfile
>
> What I understood and decided to write such command above:
>
> B-1) arfcncalc calculates frequency of first GSM1800 channel (512 ARFCN)
> which is start point (in above command)
> B-2) Sampling Rate is the bandwidth I want to capture, in our case it's
> 25MHz means 125 ARFCN which each ARFCN has 200kHz bandwidth
> B-3) 200M samples will be received (-N parameter)
> B-4) Gain value is 70, means it will boost antennas to maximum power to
> receive signals, I think USRPN210 max. gain is 80
> B-5) My decimation rate here using 25M sampling rate and USRP N210 which has
> 100MHz ADC, will be 4. So if I decided to read cfile I have to use 4 as
> decimation rate.

You want the centre frequency of the spectrum you want to capture -
not the start point. Also, the maximum gain value will also vary
depending on the daughterboard. Otherwise, you are correct.

> C) How can I seperate and process 200khz by 200khz channels in wideband
> captured file?

The brute force approach is to individually frequency translate each
channel down to baseband, low-pass filter, and perform sample rate
conversion. The more efficient method it to construct a multirate
channelizer. GNU Radio has blocks for either approach, though
construction may not be straightforward.

? Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20120104/da1d3ba8/attachment.htm>

From laforge at gnumonks.org  Thu Jan  5 09:00:45 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 5 Jan 2012 10:00:45 +0100
Subject: [OT] Re: Newbie DSP Questions
In-Reply-To: <1325709240.83176.YahooMailNeo@web122210.mail.ne1.yahoo.com>
References: <1325369774.68042.YahooMailNeo@web122210.mail.ne1.yahoo.com>
	<CAF5FEsCxcVXZT5gwhaXA7symafDTBA1R+-P64EKWUfDn8jTQRg@mail.gmail.com>
	<1325709240.83176.YahooMailNeo@web122210.mail.ne1.yahoo.com>
Message-ID: <20120105090045.GE28075@prithivi.gnumonks.org>

Avner,

as it has been suggested in this thread before, please follow-up-to a
mailinglist where this is on-topic.

neither Kalibrate nor the USRP are used in OsmocomBB, for which this
mailinglist was creted.

Thanks for your attention.

-- 
- 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 peter at stuge.se  Sun Jan  1 06:53:33 2012
From: peter at stuge.se (Peter Stuge)
Date: Sun, 1 Jan 2012 07:53:33 +0100
Subject: Compiling failure with Ubuntu 11.10 64 bits
Message-ID: <20120101065333.9171.qmail@stuge.se>

Eric Tyberghien wrote:
> I'm using Ubuntu 11.10 64 bits and I try to compile osmocom-bb but
> it fails due to the enable-linker-buid-id option not supported by
> the ld linker

How do you come to that conclusion?


> make[1]: quittant le r?pertoire ?
> /home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target ?

Please keep in mind to always export LANG=C LC_ALL=C when posting
output, so that there are no translations from english which both
make everything more difficult to understand and usually also are
very very bad translations. Never send localized output unless asking
on a local-only mailing list.


> cd shared/libosmocore/build-host && ../configure 

Who runs this command? You or make?


> checking whether the C compiler works... no
> configure: error: in
> `/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-host':
> configure: error: C compiler cannot create executables
> See `config.log' for more details
> make: *** [sharedroland at redhat.com>
> /libosmocore/build-host/Makefile] Erreur 77
..

> $ ./configure configure -v --with-pkgversion=Ubuntu/Linaro 4.6.1-9ubuntu3
> --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
> --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
> --program-suffix=-4.6 --enable-shared --disable-linker-build-id
> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext
> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
> --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
> --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic
> --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
> --target=x86_64-linux-gnu

Who is running the above and why?


> configure:2839: checking for x86_64-linux-gnu-gcc
> configure:2855: found /usr/bin/x86_64-linux-gnu-gcc

So this is the compiler that would be used.


> Thread model: posix
> gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) 
> configure:3155: $? = 0
> configure:3144: x86_64-linux-gnu-gcc -V >&5
> x86_64-linux-gnu-gcc: error: unrecognized option '-V'
> x86_64-linux-gnu-gcc: fatal error: no input files
> compilation terminated.
> configure:3155: $? = 4
> configure:3144: x86_64-linux-gnu-gcc -qversion >&5
> x86_64-linux-gnu-gcc: error: unrecognized option '-qversion'
> x86_64-linux-gnu-gcc: fatal error: no input files
> compilation terminated.
> configure:3155: $? = 4
> configure:3175: checking whether the C compiler works
> configure:3197: x86_64-linux-gnu-gcc conftest.c >&5
> /usr/local/bin/ld: unrecognized option '--build-id'
> /usr/local/bin/ld: use the --help option for usage information
> collect2: ld returned 1 exit status

Find why /usr/bin/x86_64-linux-gnu-gcc invokes /usr/local/bin/ld.


> Any idea ?

I think you have simply created a broken build environment on your
system. I have no idea how you did that, but you seem to just have
a mess of toolchains. You need to clean that up and set up the
neccessary system and target toolchains. Nothing more, nothing less.


//Peter



From holger at freyther.de  Sun Jan  1 08:01:31 2012
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sun, 01 Jan 2012 09:01:31 +0100
Subject: Compiling failure with Ubuntu 11.10 64 bits
In-Reply-To: <005f01ccc816$48aa7c70$d9ff7550$@tyberghien@wanadoo.fr>
References: <005f01ccc816$48aa7c70$d9ff7550$@tyberghien@wanadoo.fr>
Message-ID: <4F0012DB.1080302@freyther.de>

On 01/01/2012 12:45 AM, Eric Tyberghien wrote:
> Hi all

> The config.log file is like that

I think the relevant part is not in the log file. Put it somewhere and post a
link, or preferable go through it yourself once more.

Are you sure that autoconf/automake deal well with the encoding of your
accents in the directories?

thanks




From eric.tyberghien at wanadoo.fr  Sun Jan  1 14:34:04 2012
From: eric.tyberghien at wanadoo.fr (Eric Tyberghien)
Date: Sun, 1 Jan 2012 15:34:04 +0100
Subject: Compling pb with Ubuntu 11.04 64 bits
Message-ID: <000901ccc892$69aba9e0$3d02fda0$@tyberghien@wanadoo.fr>

Hi all

 

I'll upgrade a Ubuntu 11.04 64 bits to 11.10 and it seems something was
wrong.

 

Now I have reinstall an "old" Ubuntu 11.04 64 bits from scratch and the
compile process is fairly better but I obtain this failure :

 

apps/hello_world/main.o: In function `console_rx_cb':

apps/hello_world/main.c:59: undefined reference to `msgb_free'

comm/libcomm.a(sercomm.o): In function `sercomm_alloc_msgb':

../../shared/libosmocore/include/osmocom/core/msgb.h:330: undefined
reference to `msgb_alloc'

comm/libcomm.a(sercomm.o): In function `sercomm_drv_rx_char':

comm/sercomm.c:246: undefined reference to `msgb_free'

comm/libcomm.a(sercomm.o): In function `dispatch_rx_msg':

comm/sercomm.c:227: undefined reference to `msgb_free'

comm/libcomm.a(sercomm.o): In function `sercomm_drv_pull':

comm/sercomm.c:161: undefined reference to `msgb_dequeue'

comm/sercomm.c:188: undefined reference to `msgb_free'

comm/libcomm.a(sercomm.o): In function `sercomm_sendmsg':

comm/sercomm.c:125: undefined reference to `msgb_enqueue'

comm/libcomm.a(sercomm_cons.o): In function `msgb_alloc_headroom':

../../shared/libosmocore/include/osmocom/core/msgb.h:330: undefined
reference to `msgb_alloc'

make[1]: *** [board/compal_e88/hello_world.compalram.elf] error 1

make[1]: Leaving directory `/srv/osmocom-bb/src/target/firmware'

make: *** [firmware] error 2

 

Any idea

 

Regards

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

From holger at freyther.de  Sun Jan  1 17:23:10 2012
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sun, 01 Jan 2012 18:23:10 +0100
Subject: Compling pb with Ubuntu 11.04 64 bits
In-Reply-To: <000901ccc892$69aba9e0$3d02fda0$@tyberghien@wanadoo.fr>
References: <000901ccc892$69aba9e0$3d02fda0$@tyberghien@wanadoo.fr>
Message-ID: <4F00967E.4090406@freyther.de>

On 01/01/2012 03:34 PM, Eric Tyberghien wrote:
> Hi all
> 

Hi Gustav,

it is your third mail (one private, two to the list) but it is sadly not much
of a dialogue. There is nothing wrong with Ubuntu 11.10 (11.04...) but
apparently you changed more than jut 11.10 -> 11.04. From the little
information you provide one can see you at least changed the place where you
keep the sourcecode. So please keep your environment stable because otherwise
you wasted the time of the ones that were kind enough to respond.

So the path to success:

1.) Think, try to understand what happens
2.) Provide context when you are writing an email, what do you do, why do you
do this? what you think should happen
3.) include complete output....

In this specific case:

Find where the sourcecode of msgb_free is (the answer will be msgb.c), find
the msgb.o (compiled object file) that was compiled for ARM. Look if there is
a msgb_free in it (objdump,nm..) or if there is something wrong with this file
(ls, file, readelf). My guess is that you did something funny during compile
and ended up with a zero byte msgb.o.

cheers
	holger



From pabs3 at bonedaddy.net  Tue Jan  3 03:01:08 2012
From: pabs3 at bonedaddy.net (Paul Wise)
Date: Tue,  3 Jan 2012 11:01:08 +0800
Subject: [PATCH] Switch to new gpsd API
Message-ID: <1325559668-21025-1-git-send-email-pabs3@bonedaddy.net>

---
 src/host/layer23/src/common/gps.c |   26 +++++++++++++-------------
 1 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/src/host/layer23/src/common/gps.c b/src/host/layer23/src/common/gps.c
index 38aae2c..2bdfb97 100644
--- a/src/host/layer23/src/common/gps.c
+++ b/src/host/layer23/src/common/gps.c
@@ -56,7 +56,7 @@ static struct osmo_fd gps_bfd;
 
 #ifdef _HAVE_GPSD
 
-static struct gps_data_t* gdata;
+static struct gps_data_t gdata;
 
 int osmo_gpsd_cb(struct osmo_fd *bfd, unsigned int what)
 {
@@ -66,25 +66,25 @@ int osmo_gpsd_cb(struct osmo_fd *bfd, unsigned int what)
 	g.valid = 0;
 
 	/* gps is offline */
-	if (gdata->online)
+	if (gdata.online)
 	    goto gps_not_ready;
 
 	/* gps has no data */
-	if (gps_waiting(gdata))
+	if (gps_waiting(&gdata, 500))
 	    goto gps_not_ready;
 
 	/* polling returned an error */
-	if (gps_poll(gdata))
+	if (gps_read(&gdata))
 	    goto gps_not_ready;
 
 	/* data are valid */
-	if (gdata->set & LATLON_SET) {
+	if (gdata.set & LATLON_SET) {
 		g.valid = 1;
-		g.gmt = gdata->fix.time;
+		g.gmt = gdata.fix.time;
 		tm = localtime(&g.gmt);
 		diff = time(NULL) - g.gmt;
-		g.latitude = gdata->fix.latitude;
-		g.longitude = gdata->fix.longitude;
+		g.latitude = gdata.fix.latitude;
+		g.longitude = gdata.fix.longitude;
 
 		LOGP(DGPS, LOGL_INFO, " time=%02d:%02d:%02d %04d-%02d-%02d, "
 			"diff-to-host=%d, latitude=%do%.4f, longitude=%do%.4f\n",
@@ -111,16 +111,15 @@ int osmo_gpsd_open(void)
 	gps_bfd.when = BSC_FD_READ;
 	gps_bfd.cb = osmo_gpsd_cb;
 
-	gdata = gps_open(g.gpsd_host, g.gpsd_port);
-	if (gdata == NULL) {
+	if (gps_open(g.gpsd_host, g.gpsd_port, &gdata) == -1) {
 		LOGP(DGPS, LOGL_ERROR, "Can't connect to gpsd\n");
 		return -1;
 	}
-	gps_bfd.fd = gdata->gps_fd;
+	gps_bfd.fd = gdata.gps_fd;
 	if (gps_bfd.fd < 0)
 		return gps_bfd.fd;
 
-	if (gps_stream(gdata, WATCH_ENABLE, NULL) == -1) {
+	if (gps_stream(&gdata, WATCH_ENABLE, NULL) == -1) {
 		LOGP(DGPS, LOGL_ERROR, "Error in gps_stream()\n");
 		return -1;
 	}
@@ -139,7 +138,8 @@ void osmo_gpsd_close(void)
 
 	osmo_fd_unregister(&gps_bfd);
 
-	gps_close(gdata);
+	gps_stream(&gdata, WATCH_DISABLE, NULL);
+	gps_close(&gdata);
 	gps_bfd.fd = -1; /* -1 or 0 indicates: 'close' */
 }
 
-- 
1.7.7.3




From stefan at datenfreihafen.org  Tue Jan  3 07:42:43 2012
From: stefan at datenfreihafen.org (Stefan Schmidt)
Date: Tue, 3 Jan 2012 08:42:43 +0100
Subject: [PATCH] Switch to new gpsd API
In-Reply-To: <1325559668-21025-1-git-send-email-pabs3@bonedaddy.net>
References: <1325559668-21025-1-git-send-email-pabs3@bonedaddy.net>
Message-ID: <20120103074243.GD31105@novatech.datenfreihafen.org>

Hello.

On Tue, 2012-01-03 at 11:01, Paul Wise wrote:
> ---
>  src/host/layer23/src/common/gps.c |   26 +++++++++++++-------------
>  1 files changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/src/host/layer23/src/common/gps.c b/src/host/layer23/src/common/gps.c
> index 38aae2c..2bdfb97 100644
> --- a/src/host/layer23/src/common/gps.c
> +++ b/src/host/layer23/src/common/gps.c
> @@ -56,7 +56,7 @@ static struct osmo_fd gps_bfd;
>  
>  #ifdef _HAVE_GPSD
>  
> -static struct gps_data_t* gdata;
> +static struct gps_data_t gdata;

This will break for people without the new gpsd API. At least check
for the new version in configure.ac or better make it buildable with
both versions.

regards
Stefan Schmidt



From pabs3 at bonedaddy.net  Tue Jan  3 08:37:35 2012
From: pabs3 at bonedaddy.net (Paul Wise)
Date: Tue,  3 Jan 2012 16:37:35 +0800
Subject: [PATCH] Add support for the new gpsd API
In-Reply-To: <20120103074243.GD31105@novatech.datenfreihafen.org>
References: <20120103074243.GD31105@novatech.datenfreihafen.org>
Message-ID: <1325579855-24215-1-git-send-email-pabs3@bonedaddy.net>

---
 src/host/layer23/src/common/gps.c |   57 +++++++++++++++++++++++++++++++++++++
 1 files changed, 57 insertions(+), 0 deletions(-)

diff --git a/src/host/layer23/src/common/gps.c b/src/host/layer23/src/common/gps.c
index 38aae2c..2ab4023 100644
--- a/src/host/layer23/src/common/gps.c
+++ b/src/host/layer23/src/common/gps.c
@@ -56,7 +56,11 @@ static struct osmo_fd gps_bfd;
 
 #ifdef _HAVE_GPSD
 
+#if GPSD_API_MAJOR_VERSION >= 5
+static struct gps_data_t gdata;
+#else /* GPSD_API_MAJOR_VERSION < 5 */
 static struct gps_data_t* gdata;
+#endif /* GPSD_API_MAJOR_VERSION < 5 */
 
 int osmo_gpsd_cb(struct osmo_fd *bfd, unsigned int what)
 {
@@ -65,6 +69,38 @@ int osmo_gpsd_cb(struct osmo_fd *bfd, unsigned int what)
 
 	g.valid = 0;
 
+#if GPSD_API_MAJOR_VERSION >= 5
+	/* gps is offline */
+	if (gdata.online)
+	    goto gps_not_ready;
+
+	/* gps has no data */
+	if (gps_waiting(&gdata, 500))
+	    goto gps_not_ready;
+
+	/* polling returned an error */
+	if (gps_read(&gdata))
+	    goto gps_not_ready;
+
+	/* data are valid */
+	if (gdata.set & LATLON_SET) {
+		g.valid = 1;
+		g.gmt = gdata.fix.time;
+		tm = localtime(&g.gmt);
+		diff = time(NULL) - g.gmt;
+		g.latitude = gdata.fix.latitude;
+		g.longitude = gdata.fix.longitude;
+
+		LOGP(DGPS, LOGL_INFO, " time=%02d:%02d:%02d %04d-%02d-%02d, "
+			"diff-to-host=%d, latitude=%do%.4f, longitude=%do%.4f\n",
+			tm->tm_hour, tm->tm_min, tm->tm_sec, tm->tm_year + 1900,
+			tm->tm_mday, tm->tm_mon + 1, diff,
+			(int)g.latitude,
+			(g.latitude - ((int)g.latitude)) * 60.0,
+			(int)g.longitude,
+			(g.longitude - ((int)g.longitude)) * 60.0);
+	}
+#else /* GPSD_API_MAJOR_VERSION < 5 */
 	/* gps is offline */
 	if (gdata->online)
 	    goto gps_not_ready;
@@ -95,6 +131,7 @@ int osmo_gpsd_cb(struct osmo_fd *bfd, unsigned int what)
 			(int)g.longitude,
 			(g.longitude - ((int)g.longitude)) * 60.0);
 	}
+#endif /* GPSD_API_MAJOR_VERSION < 5 */
 
 	return 0;
 
@@ -111,6 +148,20 @@ int osmo_gpsd_open(void)
 	gps_bfd.when = BSC_FD_READ;
 	gps_bfd.cb = osmo_gpsd_cb;
 
+#if GPSD_API_MAJOR_VERSION >= 5
+	if (gps_open(g.gpsd_host, g.gpsd_port, &gdata) == -1) {
+		LOGP(DGPS, LOGL_ERROR, "Can't connect to gpsd\n");
+		return -1;
+	}
+	gps_bfd.fd = gdata.gps_fd;
+	if (gps_bfd.fd < 0)
+		return gps_bfd.fd;
+
+	if (gps_stream(&gdata, WATCH_ENABLE, NULL) == -1) {
+		LOGP(DGPS, LOGL_ERROR, "Error in gps_stream()\n");
+		return -1;
+	}
+#else /* GPSD_API_MAJOR_VERSION < 5 */
 	gdata = gps_open(g.gpsd_host, g.gpsd_port);
 	if (gdata == NULL) {
 		LOGP(DGPS, LOGL_ERROR, "Can't connect to gpsd\n");
@@ -124,6 +175,7 @@ int osmo_gpsd_open(void)
 		LOGP(DGPS, LOGL_ERROR, "Error in gps_stream()\n");
 		return -1;
 	}
+#endif /* GPSD_API_MAJOR_VERSION < 5 */
 
 	osmo_fd_register(&gps_bfd);
 
@@ -139,7 +191,12 @@ void osmo_gpsd_close(void)
 
 	osmo_fd_unregister(&gps_bfd);
 
+#if GPSD_API_MAJOR_VERSION >= 5
+	gps_stream(&gdata, WATCH_DISABLE, NULL);
+	gps_close(&gdata);
+#else /* GPSD_API_MAJOR_VERSION < 5 */
 	gps_close(gdata);
+#endif /* GPSD_API_MAJOR_VERSION < 5 */
 	gps_bfd.fd = -1; /* -1 or 0 indicates: 'close' */
 }
 
-- 
1.7.7.3




From 246tnt at gmail.com  Tue Jan  3 08:51:31 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Tue, 3 Jan 2012 09:51:31 +0100
Subject: [PATCH] Add support for the new gpsd API
In-Reply-To: <1325579855-24215-1-git-send-email-pabs3@bonedaddy.net>
References: <20120103074243.GD31105@novatech.datenfreihafen.org>
	<1325579855-24215-1-git-send-email-pabs3@bonedaddy.net>
Message-ID: <CAHL+j09xfK1ir3cQm41ynK8xbscmL29Mwfwv_q0ydF=EY+1dGQ@mail.gmail.com>

Wow, that just looks too awful.

Something like this should work I think and limit the changes to the essential :

at the top:

static struct gps_data_t* gdata = NULL;

#if GPSD_API_MAJOR_VERSION >= 5
static struct gps_data_t _gdata;
#endif


and for the init :

#if GPSD_API_MAJOR_VERSION >= 5
gdata = gps_open(g.gpsd_host, g.gpsd_port);
#else
if (gps_open(g.gpsd_host, g.gpsd_port, &_gdata) == -1)
 gdata = NULL
else
 gdata = &_gdata;
#endif;


I don't have any setup to test here tough.

Cheers,

    Sylvain



From pabs3 at bonedaddy.net  Tue Jan  3 09:09:25 2012
From: pabs3 at bonedaddy.net (Paul Wise)
Date: Tue,  3 Jan 2012 17:09:25 +0800
Subject: [PATCH] Add support for the new gpsd API
In-Reply-To: <CAHL+j09xfK1ir3cQm41ynK8xbscmL29Mwfwv_q0ydF=EY+1dGQ@mail.gmail.com>
References: <CAHL+j09xfK1ir3cQm41ynK8xbscmL29Mwfwv_q0ydF=EY+1dGQ@mail.gmail.com>
Message-ID: <1325581765-6250-1-git-send-email-pabs3@bonedaddy.net>

---
 src/host/layer23/src/common/gps.c |   23 ++++++++++++++++++++++-
 1 files changed, 22 insertions(+), 1 deletions(-)

diff --git a/src/host/layer23/src/common/gps.c b/src/host/layer23/src/common/gps.c
index 38aae2c..e9aaa97 100644
--- a/src/host/layer23/src/common/gps.c
+++ b/src/host/layer23/src/common/gps.c
@@ -56,7 +56,12 @@ static struct osmo_fd gps_bfd;
 
 #ifdef _HAVE_GPSD
 
-static struct gps_data_t* gdata;
+static struct gps_data_t* gdata = NULL;
+
+#if GPSD_API_MAJOR_VERSION >= 5
+static struct gps_data_t _gdata;
+#define gps_poll gps_read
+#endif
 
 int osmo_gpsd_cb(struct osmo_fd *bfd, unsigned int what)
 {
@@ -69,9 +74,15 @@ int osmo_gpsd_cb(struct osmo_fd *bfd, unsigned int what)
 	if (gdata->online)
 	    goto gps_not_ready;
 
+#if GPSD_API_MAJOR_VERSION >= 5
+	/* gps has no data */
+	if (gps_waiting(gdata, 500))
+	    goto gps_not_ready;
+#else
 	/* gps has no data */
 	if (gps_waiting(gdata))
 	    goto gps_not_ready;
+#endif
 
 	/* polling returned an error */
 	if (gps_poll(gdata))
@@ -111,7 +122,14 @@ int osmo_gpsd_open(void)
 	gps_bfd.when = BSC_FD_READ;
 	gps_bfd.cb = osmo_gpsd_cb;
 
+#if GPSD_API_MAJOR_VERSION >= 5
+	if (gps_open(g.gpsd_host, g.gpsd_port, &_gdata) == -1)
+		gdata = NULL;
+	else
+		gdata = &_gdata;
+#else
 	gdata = gps_open(g.gpsd_host, g.gpsd_port);
+#endif
 	if (gdata == NULL) {
 		LOGP(DGPS, LOGL_ERROR, "Can't connect to gpsd\n");
 		return -1;
@@ -139,6 +157,9 @@ void osmo_gpsd_close(void)
 
 	osmo_fd_unregister(&gps_bfd);
 
+#if GPSD_API_MAJOR_VERSION >= 5
+	gps_stream(gdata, WATCH_DISABLE, NULL);
+#endif
 	gps_close(gdata);
 	gps_bfd.fd = -1; /* -1 or 0 indicates: 'close' */
 }
-- 
1.7.7.3




From pabs3 at bonedaddy.net  Tue Jan 17 04:32:22 2012
From: pabs3 at bonedaddy.net (Paul Wise)
Date: Tue, 17 Jan 2012 12:32:22 +0800
Subject: [PATCH] Add support for the new gpsd API
In-Reply-To: <1325581765-6250-1-git-send-email-pabs3@bonedaddy.net>
References: <CAHL+j09xfK1ir3cQm41ynK8xbscmL29Mwfwv_q0ydF=EY+1dGQ@mail.gmail.com>
	<1325581765-6250-1-git-send-email-pabs3@bonedaddy.net>
Message-ID: <CAKTje6HP5kSmN-f7vAM9eo-6t8PF_EUqes-89+MeJ62ma+-Wfw@mail.gmail.com>

On Tue, Jan 3, 2012 at 5:09 PM, Paul Wise wrote:
> ---
> ?src/host/layer23/src/common/gps.c | ? 23 ++++++++++++++++++++++-
> ?1 files changed, 22 insertions(+), 1 deletions(-)

Anything else need changing in this patch or could someone add it to master?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise



From laforge at gnumonks.org  Tue Jan 17 12:56:17 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 17 Jan 2012 13:56:17 +0100
Subject: [PATCH] Add support for the new gpsd API
In-Reply-To: <CAKTje6HP5kSmN-f7vAM9eo-6t8PF_EUqes-89+MeJ62ma+-Wfw@mail.gmail.com>
References: <CAHL+j09xfK1ir3cQm41ynK8xbscmL29Mwfwv_q0ydF=EY+1dGQ@mail.gmail.com>
	<1325581765-6250-1-git-send-email-pabs3@bonedaddy.net>
	<CAKTje6HP5kSmN-f7vAM9eo-6t8PF_EUqes-89+MeJ62ma+-Wfw@mail.gmail.com>
Message-ID: <20120117125617.GD7995@prithivi.gnumonks.org>

Hi Paul,

On Tue, Jan 17, 2012 at 12:32:22PM +0800, Paul Wise wrote:
> Anything else need changing in this patch or could someone add it to master?

it's always mostly up to the original author of a given program to apply
the patch.  As the mobile program and specifically the gps support was
written by jolly, he should review and apply 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 andreas at eversberg.eu  Tue Jan 17 14:32:00 2012
From: andreas at eversberg.eu (Andreas Eversberg)
Date: Tue, 17 Jan 2012 15:32:00 +0100
Subject: [PATCH] Add support for the new gpsd API
In-Reply-To: <CAKTje6HP5kSmN-f7vAM9eo-6t8PF_EUqes-89+MeJ62ma+-Wfw@mail.gmail.com>
References: <CAHL+j09xfK1ir3cQm41ynK8xbscmL29Mwfwv_q0ydF=EY+1dGQ@mail.gmail.com>	<1325581765-6250-1-git-send-email-pabs3@bonedaddy.net>
	<CAKTje6HP5kSmN-f7vAM9eo-6t8PF_EUqes-89+MeJ62ma+-Wfw@mail.gmail.com>
Message-ID: <4F158660.50102@eversberg.eu>

Paul Wise wrote:
> Anything else need changing in this patch or could someone add it to master?
>   
hi paul,

i don't care if you apply it to the master, but as i can see, it is
already applied.

best regards,

andreas




From peter at stuge.se  Tue Jan 17 04:56:09 2012
From: peter at stuge.se (Peter Stuge)
Date: Tue, 17 Jan 2012 05:56:09 +0100
Subject: [PATCH] Add support for the new gpsd API
In-Reply-To: <1325581765-6250-1-git-send-email-pabs3@bonedaddy.net>
References: <CAHL+j09xfK1ir3cQm41ynK8xbscmL29Mwfwv_q0ydF=EY+1dGQ@mail.gmail.com>
	<1325581765-6250-1-git-send-email-pabs3@bonedaddy.net>
Message-ID: <20120117045609.901.qmail@stuge.se>

Paul Wise wrote:
> ---
>  src/host/layer23/src/common/gps.c |   23 ++++++++++++++++++++++-
>  1 files changed, 22 insertions(+), 1 deletions(-)

Acked-by: Peter Stuge <peter at stuge.se>



From pabs3 at bonedaddy.net  Wed Jan 18 04:46:53 2012
From: pabs3 at bonedaddy.net (Paul Wise)
Date: Wed, 18 Jan 2012 12:46:53 +0800
Subject: [PATCH] Add support for the new gpsd API
In-Reply-To: <1325581765-6250-1-git-send-email-pabs3@bonedaddy.net>
References: <CAHL+j09xfK1ir3cQm41ynK8xbscmL29Mwfwv_q0ydF=EY+1dGQ@mail.gmail.com>
	<1325581765-6250-1-git-send-email-pabs3@bonedaddy.net>
Message-ID: <1326862013.2530.1.camel@chianamo>

On Tue, 2012-01-03 at 17:09 +0800, Paul Wise wrote:
> ---
>  src/host/layer23/src/common/gps.c |   23 ++++++++++++++++++++++-
>  1 files changed, 22 insertions(+), 1 deletions(-)

Thanks to Sylvain Munaut for adding this patch to master.

-- 
bye,
pabs

http://bonedaddy.net/pabs3/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20120118/f8851953/attachment.bin>

From pabs3 at bonedaddy.net  Tue Jan  3 03:06:52 2012
From: pabs3 at bonedaddy.net (Paul Wise)
Date: Tue,  3 Jan 2012 11:06:52 +0800
Subject: [osmocom-bb] [PATCH] Update .gitignore file for libosmocore
Message-ID: <1325560012-24641-1-git-send-email-pabs3@bonedaddy.net>

---
 src/shared/libosmocore/.gitignore |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/src/shared/libosmocore/.gitignore b/src/shared/libosmocore/.gitignore
index c77c750..5e75539 100644
--- a/src/shared/libosmocore/.gitignore
+++ b/src/shared/libosmocore/.gitignore
@@ -50,3 +50,6 @@ doc/html.tar
 
 src/crc*gen.c
 include/osmocom/core/crc*gen.h
+
+build-host
+build-target
-- 
1.7.7.3




From 246tnt at gmail.com  Tue Jan  3 07:48:11 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Tue, 3 Jan 2012 08:48:11 +0100
Subject: [osmocom-bb] [PATCH] Update .gitignore file for libosmocore
In-Reply-To: <1325560012-24641-1-git-send-email-pabs3@bonedaddy.net>
References: <1325560012-24641-1-git-send-email-pabs3@bonedaddy.net>
Message-ID: <CAHL+j09xbp0ORMjB4aLzgz3128xMCNbChoGpCux246UhdN8wuQ@mail.gmail.com>

> ?src/shared/libosmocore/.gitignore | ? ?3 +++
> ?1 files changed, 3 insertions(+), 0 deletions(-)

No, it can't be there because libosmocore subdir has to stay an exact
copy of the libosmocore git for git-subtree to work properly.

Cheers,

    Sylvain



From pabs3 at bonedaddy.net  Tue Jan  3 07:51:15 2012
From: pabs3 at bonedaddy.net (Paul Wise)
Date: Tue, 3 Jan 2012 15:51:15 +0800
Subject: [osmocom-bb] [PATCH] Update .gitignore file for libosmocore
In-Reply-To: <CAHL+j09xbp0ORMjB4aLzgz3128xMCNbChoGpCux246UhdN8wuQ@mail.gmail.com>
References: <1325560012-24641-1-git-send-email-pabs3@bonedaddy.net>
	<CAHL+j09xbp0ORMjB4aLzgz3128xMCNbChoGpCux246UhdN8wuQ@mail.gmail.com>
Message-ID: <CAKTje6EFrLO+QA4zXqOiXEG=3nm_y9xKoVb6P+kxHhE5byJkwQ@mail.gmail.com>

On Tue, Jan 3, 2012 at 3:48 PM, Sylvain Munaut wrote:

> No, it can't be there because libosmocore subdir has to stay an exact
> copy of the libosmocore git for git-subtree to work properly.

Please apply it there then.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise



From 246tnt at gmail.com  Tue Jan  3 08:28:20 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Tue, 3 Jan 2012 09:28:20 +0100
Subject: [osmocom-bb] [PATCH] Update .gitignore file for libosmocore
In-Reply-To: <CAKTje6EFrLO+QA4zXqOiXEG=3nm_y9xKoVb6P+kxHhE5byJkwQ@mail.gmail.com>
References: <1325560012-24641-1-git-send-email-pabs3@bonedaddy.net>
	<CAHL+j09xbp0ORMjB4aLzgz3128xMCNbChoGpCux246UhdN8wuQ@mail.gmail.com>
	<CAKTje6EFrLO+QA4zXqOiXEG=3nm_y9xKoVb6P+kxHhE5byJkwQ@mail.gmail.com>
Message-ID: <CAHL+j0_qWUyV0ORGrj7aRUT4pB20sPVD0W7kQCouO5TUvQmu9A@mail.gmail.com>

>> No, it can't be there because libosmocore subdir has to stay an exact
>> copy of the libosmocore git for git-subtree to work properly.
>
> Please apply it there then.

Well, no ... these have nothing to do in the global libosmocore, the
build-host build-target are just an artifact of the osmocom-bb build
system.
The correct solution is to use the top level osmocom-bb .gitignore



From pabs3 at bonedaddy.net  Tue Jan  3 08:41:46 2012
From: pabs3 at bonedaddy.net (Paul Wise)
Date: Tue,  3 Jan 2012 16:41:46 +0800
Subject: [PATCH] Add a list of dirs created during the build process for git
	to ignore.
In-Reply-To: <CAHL+j0_qWUyV0ORGrj7aRUT4pB20sPVD0W7kQCouO5TUvQmu9A@mail.gmail.com>
References: <CAHL+j0_qWUyV0ORGrj7aRUT4pB20sPVD0W7kQCouO5TUvQmu9A@mail.gmail.com>
Message-ID: <1325580106-25013-1-git-send-email-pabs3@bonedaddy.net>

---
 .gitignore |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)
 create mode 100644 .gitignore

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..66dc953
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,2 @@
+/src/shared/libosmocore/build-host
+/src/shared/libosmocore/build-target
-- 
1.7.7.3




From akibsayyed at gmail.com  Wed Jan  4 04:44:36 2012
From: akibsayyed at gmail.com (Akib Sayyed)
Date: Wed, 4 Jan 2012 10:14:36 +0530
Subject: phones are not working
Message-ID: <CAMG-S936rC+FTjB2KVKwC2C5nPNOtuVCZVvgQ1siOz55+whPtA@mail.gmail.com>

hello guys
i am facing problem with registering phone on network

what i am using

cellphone: motorola c139
cable : FDTI FT232RL cable given on ccc aug

++++++++++++++++++++++++++++++++++++++++
command used to load


./host/osmocon/osmocon -m c140xor -p /dev/ttyUSB0 -c
./target/firmware/board/compal_e86/layer1.highram.bin
./target/firmware/board/compal_e86/chainload.compalram.bin
++++++++++++++++++++++++++++++++++++++++
show ms 1 command o/p

MS '1' is up, MM connection active
  IMEI: 000000000000000
     IMEISV: 0000000000000000
     IMEI generation: fixed
  automatic network selection state: A1 trying RPLMN
                                     MCC=404 MNC=90 (India, AirTel)
  cell selection state: connected mode 1
                        ARFCN=613(DCS) MCC=404 MNC=90 LAC=0x0c2f
CELLID=0x0aa2
                        (India, AirTel)
  radio ressource layer state: connection pending
  mobility management layer state: wait for RR connection (location
updating)
++++++++++++++++++++++++++++++++++++++++


other tools tried :
celllog
works fine



++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++
Other issue

details getting error FTM_TOOL error

what i am using

cellphone: motorola c123
cable : FDTI FT232RL cable given on ccc aug

++++++++++++++++++++++++++++++++++++++++
command used to load


./host/osmocon/osmocon -m c123xor -p /dev/ttyUSB0
./target/firmware/board/compal_e88/layer1.compalram.bin

++++++++++++++++++++++++++++++++++++++++

here is log of error from c123


root at akib-laptop:~/osmocom_org/osmocom-bb/src# ./host/osmocon/osmocon -m
c123xor -p /dev/ttyUSB0
./target/firmware/board/compal_e88/layer1.compalram.bin
got 1 bytes from modem, data looks like: 00  .
got 2 bytes from modem, data looks like: 04 81  ..
got 4 bytes from modem, data looks like: 1b f6 02 00  ....
got 1 bytes from modem, data looks like: 41  A
got 1 bytes from modem, data looks like: 01  .
got 1 bytes from modem, data looks like: 40  @
Received PROMPT1 from phone, responding with CMD
read_file(./target/firmware/board/compal_e88/layer1.compalram.bin):
file_size=55840, hdr_len=4, dnload_len=55847
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: 02  .
got 1 bytes from modem, data looks like: 43  C
Received PROMPT2 from phone, starting download
handle_write(): 4096 bytes (4096/55847)
handle_write(): 4096 bytes (8192/55847)
handle_write(): 4096 bytes (12288/55847)
handle_write(): 4096 bytes (16384/55847)
handle_write(): 4096 bytes (20480/55847)
handle_write(): 4096 bytes (24576/55847)
handle_write(): 4096 bytes (28672/55847)
handle_write(): 4096 bytes (32768/55847)
handle_write(): 4096 bytes (36864/55847)
handle_write(): 4096 bytes (40960/55847)
handle_write(): 4096 bytes (45056/55847)
handle_write(): 4096 bytes (49152/55847)
handle_write(): 4096 bytes (53248/55847)
handle_write(): 2599 bytes (55847/55847)
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: 45  E
got 1 bytes from modem, data looks like: 53  S
got 1 bytes from modem, data looks like: 16  .
Received DOWNLOAD NACK from phone, something went wrong :(
got 1 bytes from modem, data looks like: 66  f
got 1 bytes from modem, data looks like: 74  t
got 1 bytes from modem, data looks like: 6d  m
got 1 bytes from modem, data looks like: 74  t
got 1 bytes from modem, data looks like: 6f  o
got 1 bytes from modem, data looks like: 6f  o
got 1 bytes from modem, data looks like: 6c  l
Received FTMTOOL from phone, ramloader has aborted
got 1 bytes from modem, data looks like: 65  e
got 1 bytes from modem, data looks like: 72  r
got 1 bytes from modem, data looks like: 72  r
got 1 bytes from modem, data looks like: 6f  o
got 1 bytes from modem, data looks like: 72  r
^C

+++++++++++++++++++++++

Note: phones are locked to perticular provider







-- 
Akib Sayyed
Matrix-Shell
akibsayyed at gmail.com
akibsayyed at matrixshell.com
Mob:- +91-966-514-2243
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20120104/aee4989c/attachment.htm>

From stefan.bauer at cubewerk.de  Fri Jan  6 22:54:10 2012
From: stefan.bauer at cubewerk.de (=?utf-8?Q?Stefan_Bauer?=)
Date: Fri, 6 Jan 2012 23:54:10 +0100
Subject: random net disconn. - o2 germany - motorola c123 + c140
Message-ID: <zarafa.4f077b92.268e.373e5eee3028972b@zarafa.cubewerk.int>

Dear developers and users,

i would like to know the current status of osmocom-bb on the motorola c123 and c140. I have both phones available and serious problems to keep in my operators network (o2 germany  -  262 07) longer than a few seconds. I'm using my real sim (sim reader) but the quality seems to be very poor with that kind of devices. Are there any known problems?

With several other devices (non osmocom firmware) and the same sim i have no problems at the same location.

thanks in advance

Stefan



From peter at stuge.se  Fri Jan  6 23:26:34 2012
From: peter at stuge.se (Peter Stuge)
Date: Sat, 7 Jan 2012 00:26:34 +0100
Subject: random net disconn. - o2 germany - motorola c123 + c140
In-Reply-To: <zarafa.4f077b92.268e.373e5eee3028972b@zarafa.cubewerk.int>
References: <zarafa.4f077b92.268e.373e5eee3028972b@zarafa.cubewerk.int>
Message-ID: <20120106232634.3002.qmail@stuge.se>

Stefan Bauer wrote:
> serious problems to keep in my operators network (o2 germany  -
> 262 07) longer than a few seconds.

Can you crank up the logging to max and share the logs from a clean
start of connection through disconnect?

pcap files help too of course.


//Peter



From stefan.bauer at cubewerk.de  Sat Jan  7 12:30:13 2012
From: stefan.bauer at cubewerk.de (=?utf-8?Q?Stefan_Bauer?=)
Date: Sat, 7 Jan 2012 13:30:13 +0100
Subject: random net disconn. - o2 germany - motorola c123 + c140
Message-ID: <zarafa.4f083ad5.4513.7d94876336ec5498@zarafa.cubewerk.int>

-----Urspr?ngliche Nachricht-----
Von:	Peter Stuge <peter at stuge.se>
Gesendet:	Sa 07.01.2012 00:31
Betreff:	Re: random net disconn. - o2 germany - motorola c123 + c140
An:	baseband-devel at lists.osmocom.org; 
> Stefan Bauer wrote:
> > serious problems to keep in my operators network (o2 germany  -
> > 262 07) longer than a few seconds.
> 
> Can you crank up the logging to max and share the logs from a clean
> start of connection through disconnect?

Hi Peter,

please find the log-file of mobile here:

http://www.plzk.de/mobile.log

I hope this will bring some light into my problem.

Thank you in advance

Stefan



From stefan.bauer at cubewerk.de  Sun Jan  8 15:27:12 2012
From: stefan.bauer at cubewerk.de (=?utf-8?Q?Stefan_Bauer?=)
Date: Sun, 8 Jan 2012 16:27:12 +0100
Subject: random net disconn. - o2 germany - motorola c123 + c140
Message-ID: <zarafa.4f09b5d0.02e8.16822d87737d3c6e@zarafa.cubewerk.int>

-----Urspr?ngliche Nachricht-----
> Hi Peter,
> 
> please find the log-file of mobile here:
> 
> http://www.plzk.de/mobile.log

PING. Nobody with an idea on my issue?

Regards

Stefan



From holger at freyther.de  Sun Jan  8 15:59:19 2012
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Sun, 08 Jan 2012 16:59:19 +0100
Subject: random net disconn. - o2 germany - motorola c123 + c140
In-Reply-To: <zarafa.4f09b5d0.02e8.16822d87737d3c6e@zarafa.cubewerk.int>
References: <zarafa.4f09b5d0.02e8.16822d87737d3c6e@zarafa.cubewerk.int>
Message-ID: <4F09BD57.5040205@freyther.de>

On 01/08/2012 04:27 PM, Stefan Bauer wrote:

> 
> PING. Nobody with an idea on my issue?

What about you? Reading the log, do you see anything that looks weird? E.g.
how likely is it that you simply have bad coverage of O2 for GSM in the area
you are. What do you think about log entries like this?


gsm48_mm.c:912 new MM IDLE state no cell available -> limited service
...
gsm48_mm.c:4329 (ms 1) Received 'MM_EVENT_LOST_COVERAGE' event in state MM
IDLE, limited service



From stefan.bauer at cubewerk.de  Sun Jan  8 16:34:22 2012
From: stefan.bauer at cubewerk.de (=?utf-8?Q?Stefan_Bauer?=)
Date: Sun, 8 Jan 2012 17:34:22 +0100
Subject: random net disconn. - o2 germany - motorola c123 + c140
Message-ID: <zarafa.4f09c58e.0578.31c33f1134ad932e@zarafa.cubewerk.int>

-----Urspr?ngliche Nachricht-----
Von:	Holger Hans Peter Freyther <holger at freyther.de>
Gesendet:	So 08.01.2012 17:03
Betreff:	Re: random net disconn. - o2 germany - motorola c123 + c140
An:	baseband-devel at lists.osmocom.org; 
> On 01/08/2012 04:27 PM, Stefan Bauer wrote:
> 
> > 
> > PING. Nobody with an idea on my issue?
> 
> What about you? Reading the log, do you see anything that looks weird? E.g.
> how likely is it that you simply have bad coverage of O2 for GSM in the area
> you are. What do you think about log entries like this?

Well, the coverage is perfect with my other cell phones at the exactly same position in my office.
Is it possible, that my provider does not like the random imei-feature of osmocom?
Is it best practise to use the real sim and not only extracting the key from original sim and fake it?

thank you

Stefan



From laforge at gnumonks.org  Sun Jan  8 20:18:48 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 8 Jan 2012 21:18:48 +0100
Subject: random net disconn. - o2 germany - motorola c123 + c140
In-Reply-To: <zarafa.4f09c58e.0578.31c33f1134ad932e@zarafa.cubewerk.int>
References: <zarafa.4f09c58e.0578.31c33f1134ad932e@zarafa.cubewerk.int>
Message-ID: <20120108201848.GB13667@prithivi.gnumonks.org>

Hi Stefan,

On Sun, Jan 08, 2012 at 05:34:22PM +0100, Stefan Bauer wrote:

> Well, the coverage is perfect with my other cell phones at the exactly
> same position in my office.  

Are you sure your other phones are using O2 in GSM mode, not 3G?  It
could be that the other phones use 3G and thus have better coverage
indication.

Furthermore, different phones can very well have different Rx
sensitivity...

> Is it possible, that my provider does not like the random imei-feature
> of osmocom?

That might very well be, but is completley unrelated to a RF signal
level as it is measured  by your phone (which leads to the problem you
are observing).

> Is it best practise to use the real sim and not only extracting the
> key from original sim and fake it?

Nice joke. I would be really surprised if you find SIM cards issued
during the last 14 years in western countrues that still can be cloned ;)

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



From stefan.bauer at cubewerk.de  Sun Jan  8 22:41:22 2012
From: stefan.bauer at cubewerk.de (=?utf-8?Q?Stefan_Bauer?=)
Date: Sun, 8 Jan 2012 23:41:22 +0100
Subject: random net disconn. - o2 germany - motorola c123 + c140
Message-ID: <zarafa.4f0a1b92.1324.4441ccf07e83d155@zarafa.cubewerk.int>

-----Urspr?ngliche Nachricht-----
Von:	Harald Welte <laforge at gnumonks.org>
> Are you sure your other phones are using O2 in GSM mode, not 3G?  It
> could be that the other phones use 3G and thus have better coverage
> indication.

Hi Harald,

i have a pretty old nokia phone (6310) and it's only able to do GSM. That was used for my comparison.


> > Is it possible, that my provider does not like the random imei-feature
> > of osmocom?
> 
> That might very well be, but is completley unrelated to a RF signal
> level as it is measured  by your phone (which leads to the problem you
> are observing).

I'm gonna try to move closer to the BTS tomorrow and collect some informations. If the quality stays poor, i can only attach an additional antenna to the phone.

Thank you.

Stefan



From stefan.bauer at cubewerk.de  Mon Jan  9 07:28:48 2012
From: stefan.bauer at cubewerk.de (=?utf-8?Q?Stefan_Bauer?=)
Date: Mon, 9 Jan 2012 08:28:48 +0100
Subject: AW: random net disconn. - o2 germany - motorola c123 + c140
Message-ID: <zarafa.4f0a9730.27ca.07b9cfd9584e3111@zarafa.cubewerk.int>

-----Urspr?ngliche Nachricht-----
Von:	Stefan Bauer <stefan.bauer at cubewerk.de>
> I'm gonna try to move closer to the BTS tomorrow and collect some informations. 
> If the quality stays poor, i can only attach an additional antenna to the phone.

Ok - here is the status - not quite surprising:

I moved closer to the cell. I got associated to the cell with much better quality. Then the channel switch was initiated by the software - without luck - logs attached:

http://www.plzk.de/mobile2.log

Any idea why the channel sync fails several times and even the fallback switch to the serving cell at the end?

I have doubts that it is an antenna/RX-issue. If i use the motorola with original firmware, i have no issues and can immediately start a phone-call.

Thank you in advance

Stefan



From stefan.bauer at cubewerk.de  Mon Jan  9 11:29:27 2012
From: stefan.bauer at cubewerk.de (=?utf-8?Q?Stefan_Bauer?=)
Date: Mon, 9 Jan 2012 12:29:27 +0100
Subject: AW: random net disconn. - o2 germany - motorola c123 + c140
Message-ID: <zarafa.4f0acf97.30e8.1e9533e46d851a43@zarafa.cubewerk.int>

-----Urspr?ngliche Nachricht-----
Von:	Stefan Bauer <stefan.bauer at cubewerk.de>
> I moved closer to the cell. I got associated to the cell with much better 
> quality. Then the channel switch was initiated by the software - without luck - 
> logs attached:

I tested another provider. This time Vodafone. The rx-quality is even better:
(my cell #33 is -64)

<0004> gsm322.c:4783 Measurement result for ARFCN 16: -95
<0004> gsm322.c:4783 Measurement result for ARFCN 20: -93
<0004> gsm322.c:4783 Measurement result for ARFCN 21: -96
<0004> gsm322.c:4783 Measurement result for ARFCN 22: -92
<0004> gsm322.c:4783 Measurement result for ARFCN 25: -92
<0004> gsm322.c:4783 Measurement result for ARFCN 33: -64
<0004> gsm322.c:4783 Measurement result for ARFCN 34: -84
<0004> gsm322.c:4783 Measurement result for ARFCN 43: -87
<0004> gsm322.c:4783 Measurement result for ARFCN 44: -86
<0004> gsm322.c:4783 Measurement result for ARFCN 48: -81
<0004> gsm322.c:4783 Measurement result for ARFCN 49: -94
<0004> gsm322.c:4783 Measurement result for ARFCN 82: -94
<0004> gsm322.c:4783 Measurement result for ARFCN 86: -74
<0004> gsm322.c:4783 Measurement result for ARFCN 87: -93
<0004> gsm322.c:4783 Measurement result for ARFCN 88: -92
<0004> gsm322.c:4783 Measurement result for ARFCN 95: -92
<0004> gsm322.c:4783 Measurement result for ARFCN 123: -84
<0004> gsm322.c:4783 Measurement result for ARFCN 124: -79
<0004> gsm322.c:4691 RLA_C of serving cell: -55
<0004> gsm322.c:374 A (RLA_C (-55) - RXLEV_ACC_MIN (-106)) = 51
<0004> gsm322.c:376 B (MS_TXPWR_MAX_CCH (33) - p (33)) = 0
<0004> gsm322.c:377 C1 (A - MAX(B,0)) = 51
<0004> gsm322.c:400 C2 = C1 - CELL_RESELECT_OFFSET (0) = 51 (special case)
<0004> gsm322.c:4746 #1 ARFCN=33 RLA_C=-64
<0004> gsm322.c:4746 #2 ARFCN=86 RLA_C=-75
<0004> gsm322.c:4746 #3 ARFCN=124 RLA_C=-80
<0004> gsm322.c:4746 #4 ARFCN=48 RLA_C=-82
<0004> gsm322.c:4746 #5 ARFCN=123 RLA_C=-82
<0004> gsm322.c:4746 #6 ARFCN=34 RLA_C=-83
<0004> gsm322.c:4569 Syncing to new neighbour cell 33.


For unknown reasons, the sync fails again:

<0003> gsm322.c:469 Sync to ARFCN=33 rxlev=-68 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2937 Channel synched. (ARFCN=33, snr=16, BSIC=25)
<0001> gsm322.c:2958 using DSC of 90
<0004> gsm322.c:4640 Synced to neighbour cell 33.
<0003> gsm322.c:692 Starting CS timer with 2 seconds.
<0003> gsm48_rr.c:4941 Channel provides data.
<0001> gsm48_rr.c:1887 New SYSTEM INFORMATION 2
<0001> sysinfo.c:719 New SYSTEM INFORMATION 3 (mcc 262 mnc 01 lac 0x430a)
<0001> gsm48_rr.c:2012 Changing CCCH_MODE to 1
<0003> gsm322.c:702 stopping pending CS timer.
<0003> gsm322.c:2567 Relevant sysinfo of neighbour cell is now received or updated.
<0004> gsm322.c:4661 Read from neighbour cell 33 (rxlev -68).
<0004> gsm322.c:4569 Syncing to new neighbour cell 86.
<0003> gsm322.c:469 Sync to ARFCN=86 rxlev=-78 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2980 Channel sync error, try again
<0003> gsm322.c:469 Sync to ARFCN=86 rxlev=-78 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=86
<0004> gsm322.c:4640 Failed to sync to neighbour cell 86.
<0004> gsm322.c:4569 Syncing to new neighbour cell 124.
<0003> gsm322.c:469 Sync to ARFCN=124 rxlev=-83 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2980 Channel sync error, try again
<0003> gsm322.c:469 Sync to ARFCN=124 rxlev=-83 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=124
<0004> gsm322.c:4640 Failed to sync to neighbour cell 124.
<0004> gsm322.c:4569 Syncing to new neighbour cell 48.
<0003> gsm322.c:469 Sync to ARFCN=48 rxlev=-83 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2980 Channel sync error, try again
<0003> gsm322.c:469 Sync to ARFCN=48 rxlev=-83 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=48
<0004> gsm322.c:4640 Failed to sync to neighbour cell 48.
<0004> gsm322.c:4569 Syncing to new neighbour cell 123.
<0003> gsm322.c:469 Sync to ARFCN=123 rxlev=-85 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2980 Channel sync error, try again
<0003> gsm322.c:469 Sync to ARFCN=123 rxlev=-85 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=123
<0004> gsm322.c:4640 Failed to sync to neighbour cell 123.
<0004> gsm322.c:4569 Syncing to new neighbour cell 34.
<0003> gsm322.c:469 Sync to ARFCN=34 rxlev=-86 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2980 Channel sync error, try again
<0003> gsm322.c:469 Sync to ARFCN=34 rxlev=-86 (No sysinfo yet, ccch mode NONE)
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=34
<0004> gsm322.c:4640 Failed to sync to neighbour cell 34.
<0004> gsm322.c:4122 Re-select using access class with Emergency class.
<0004> gsm322.c:4142 Checking cell of ARFCN 33 for cell re-selection.
<0004> gsm322.c:374 A (RLA_C (-64) - RXLEV_ACC_MIN (-106)) = 42
<0004> gsm322.c:376 B (MS_TXPWR_MAX_CCH (33) - p (33)) = 0
<0004> gsm322.c:377 C1 (A - MAX(B,0)) = 42
<0004> gsm322.c:400 C2 = C1 - CELL_RESELECT_OFFSET (0) = 42 (special case)
<0004> gsm322.c:4198 -> Cell of is in the same LA, so CRH = 0
<0004> gsm322.c:4142 Checking cell of ARFCN 86 for cell re-selection.
<0004> gsm322.c:4164 Skip cell: There are no system informations available.
<0004> gsm322.c:4142 Checking cell of ARFCN 124 for cell re-selection.
<0004> gsm322.c:4164 Skip cell: There are no system informations available.
<0004> gsm322.c:4142 Checking cell of ARFCN 48 for cell re-selection.
<0004> gsm322.c:4164 Skip cell: There are no system informations available.
<0004> gsm322.c:4142 Checking cell of ARFCN 123 for cell re-selection.
<0004> gsm322.c:4164 Skip cell: There are no system informations available.
<0004> gsm322.c:4142 Checking cell of ARFCN 34 for cell re-selection.
<0004> gsm322.c:4164 Skip cell: There are no system informations available.
<0004> gsm322.c:4624 Syncing back to serving cell
<0003> gsm322.c:463 Sync to ARFCN=46 rxlev=-56 (Sysinfo, ccch mode NON-COMB)
<0001> gsm48_rr.c:679 MON: no cell info
<0003> gsm322.c:2980 Channel sync error, try again
<0003> gsm322.c:463 Sync to ARFCN=46 rxlev=-56 (Sysinfo, ccch mode NON-COMB)
<0003> gsm322.c:2980 Channel sync error, try again
<0003> gsm322.c:463 Sync to ARFCN=46 rxlev=-56 (Sysinfo, ccch mode NON-COMB)
<0003> gsm322.c:2993 Channel sync error.
<0003> gsm322.c:2998 free sysinfo ARFCN=46
<0003> gsm322.c:3005 Unselect cell due to sync error!
<0003> gsm322.c:498 Unselecting serving cell.
<0003> gsm322.c:3072 Loss of CCCH, Trigger re-selection.
<0003> gsm322.c:4035 (ms 1) Event 'EVENT_CELL_RESEL' for Cell selection in state 'C7 camped on any cell'
<0003> gsm322.c:823 new state 'C7 camped on any cell' -> 'C8 any cell re-selection'
<0003> gsm322.c:4334 Checking cell with ARFCN 33 for cell re-selection. (C2 = 42)
<0003> gsm322.c:4334 Checking cell with ARFCN 86 for cell re-selection. (C2 = 0)
<0003> gsm322.c:4345 Skip cell: not suitable and/or allowable.
<0003> gsm322.c:4334 Checking cell with ARFCN 124 for cell re-selection. (C2 = 0)
<0003> gsm322.c:4345 Skip cell: not suitable and/or allowable.
<0003> gsm322.c:4334 Checking cell with ARFCN 48 for cell re-selection. (C2 = 0)
<0003> gsm322.c:4345 Skip cell: not suitable and/or allowable.
<0003> gsm322.c:4334 Checking cell with ARFCN 123 for cell re-selection. (C2 = 0)
<0003> gsm322.c:4345 Skip cell: not suitable and/or allowable.
<0003> gsm322.c:4334 Checking cell with ARFCN 34 for cell re-selection. (C2 = 0)
<0003> gsm322.c:4345 Skip cell: not suitable and/or allowable.
<0003> gsm322.c:4372 Best neighbour cell with ARFCN 33 selected. (normal priority)
<0003> gsm322.c:4405 Scanning ARFCN 33 of neighbour cell during cell reselection.
<0003> gsm322.c:469 Sync to ARFCN=33 rxlev=-68 (No sysinfo yet, ccch mode NONE)
<0005> gsm48_mm.c:4329 (ms 1) Received 'MM_EVENT_LOST_COVERAGE' event in state MM IDLE, limited service
<0005> gsm48_mm.c:1059 Selecting PLMN SEARCH state, because no cell selected.
<0005> gsm48_mm.c:912 new MM IDLE state limited service -> PLMN search


Is it possible, that i miss an important part in my setup? To be honest, i followed quite strictly all the informations in the public wiki.


Stefan



From 246tnt at gmail.com  Mon Jan  9 11:34:34 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Mon, 9 Jan 2012 12:34:34 +0100
Subject: random net disconn. - o2 germany - motorola c123 + c140
In-Reply-To: <zarafa.4f0acf97.30e8.1e9533e46d851a43@zarafa.cubewerk.int>
References: <zarafa.4f0acf97.30e8.1e9533e46d851a43@zarafa.cubewerk.int>
Message-ID: <CAHL+j0-tFFfzdDwmQ=9kuhz6a9HnXL_xNu0cz6eqt7C5uwMr7w@mail.gmail.com>

> Is it possible, that i miss an important part in my setup? To be honest, i followed quite strictly all the informations in the public wiki.

Post the L1 logs (from osmocon) ... because the log you post contain
no low level information whatsoever (those happen on the phone and not
on the pc software).


Cheers,

    Sylvain



From stefan.bauer at cubewerk.de  Mon Jan  9 11:47:57 2012
From: stefan.bauer at cubewerk.de (=?utf-8?Q?Stefan_Bauer?=)
Date: Mon, 9 Jan 2012 12:47:57 +0100
Subject: AW: random net disconn. - o2 germany - motorola c123 + c140
Message-ID: <zarafa.4f0ad3ed.31bb.6439c31314b4745c@zarafa.cubewerk.int>

-----Urspr?ngliche Nachricht-----
Von:	Sylvain Munaut <246tnt at gmail.com>
Gesendet:	Mo 09.01.2012 12:37
Betreff:	Re: random net disconn. - o2 germany - motorola c123 + c140
An:	Stefan Bauer <stefan.bauer at cubewerk.de>; 
CC:	baseband-devel at lists.osmocom.org; 
> > Is it possible, that i miss an important part in my setup? To be honest, i 
> followed quite strictly all the informations in the public wiki.
> 
> Post the L1 logs (from osmocon) ... because the log you post contain
> no low level information whatsoever (those happen on the phone and not
> on the pc software).

thank you for your time. Here is the L1-log:

http://www.plzk.de/layer1.log

Stefan



From 246tnt at gmail.com  Mon Jan  9 13:12:45 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Mon, 9 Jan 2012 14:12:45 +0100
Subject: random net disconn. - o2 germany - motorola c123 + c140
In-Reply-To: <zarafa.4f0ad3ed.31bb.6439c31314b4745c@zarafa.cubewerk.int>
References: <zarafa.4f0ad3ed.31bb.6439c31314b4745c@zarafa.cubewerk.int>
Message-ID: <CAHL+j0_M-9UbSggGemJg1-Qdg88cbj1xtvO2PajR2F5KO3Sxug@mail.gmail.com>

> thank you for your time. Here is the L1-log:
>
> http://www.plzk.de/layer1.log

Could you retry with this layer1 firmware :

http://minus.com/mdAV5dFRb

Cheers,

    Sylvain



From stefan.bauer at cubewerk.de  Mon Jan  9 13:20:39 2012
From: stefan.bauer at cubewerk.de (=?utf-8?Q?Stefan_Bauer?=)
Date: Mon, 9 Jan 2012 14:20:39 +0100
Subject: random net disconn. - o2 germany - motorola c123 + c140
Message-ID: <zarafa.4f0ae9a7.361d.11fa70a94db797d5@zarafa.cubewerk.int>

-----Urspr?ngliche Nachricht-----
Von:	Sylvain Munaut <246tnt at gmail.com>
Gesendet:	Mo 09.01.2012 14:12
Betreff:	Re: random net disconn. - o2 germany - motorola c123 + c140
An:	Stefan Bauer <stefan.bauer at cubewerk.de>; 
CC:	baseband-devel at lists.osmocom.org; 
> > thank you for your time. Here is the L1-log:
> >
> > http://www.plzk.de/layer1.log
> 
> Could you retry with this layer1 firmware :
> 
> http://minus.com/mdAV5dFRb

I just tried it. No luck. It seems, that this FW lacks TX-support?

http://www.plzk.de/layer1-newFW.log


Stefan



From 246tnt at gmail.com  Mon Jan  9 13:29:53 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Mon, 9 Jan 2012 14:29:53 +0100
Subject: random net disconn. - o2 germany - motorola c123 + c140
In-Reply-To: <zarafa.4f0ae9a7.361d.11fa70a94db797d5@zarafa.cubewerk.int>
References: <zarafa.4f0ae9a7.361d.11fa70a94db797d5@zarafa.cubewerk.int>
Message-ID: <CAHL+j09MzWZu=qkh_j=_CEVz4+jj_qdv3QiD+8s8n-OKfyar9g@mail.gmail.com>

Hi,

> I just tried it. No luck. It seems, that this FW lacks TX-support?
>
> http://www.plzk.de/layer1-newFW.log

Damnit, I forgot to enable TX ... sorry about that.

http://minus.com/mbiuqRunDm

Cheers,

    Sylvain



From stefan.bauer at cubewerk.de  Mon Jan  9 13:40:51 2012
From: stefan.bauer at cubewerk.de (=?utf-8?Q?Stefan_Bauer?=)
Date: Mon, 9 Jan 2012 14:40:51 +0100
Subject: AW: random net disconn. - o2 germany - motorola c123 + c140
Message-ID: <zarafa.4f0aee63.36ee.33e034180bb7d344@zarafa.cubewerk.int>

-----Urspr?ngliche Nachricht-----
Von:	Sylvain Munaut <246tnt at gmail.com>
> Damnit, I forgot to enable TX ... sorry about that.
> 
> http://minus.com/mbiuqRunDm

Sylvain,

now it behaves much more stable!! That is awesome. Thank you. What have you changed / what was the issue?

Now I'm in the network only with a single disconnect since a few minutes. I also had the chance to make a phone-call now.


Stefan



From 246tnt at gmail.com  Mon Jan  9 13:45:48 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Mon, 9 Jan 2012 14:45:48 +0100
Subject: random net disconn. - o2 germany - motorola c123 + c140
In-Reply-To: <zarafa.4f0aee63.36ee.33e034180bb7d344@zarafa.cubewerk.int>
References: <zarafa.4f0aee63.36ee.33e034180bb7d344@zarafa.cubewerk.int>
Message-ID: <CAHL+j0_BLpCQg4UZPAatmyVO2MJLg2gda3iHuAsMHbTkmVfuJg@mail.gmail.com>

> now it behaves much more stable!! That is awesome. Thank you. What have you changed / what was the issue?
>
> Now I'm in the network only with a single disconnect since a few minutes. I also had the chance to make a phone-call now.

I didn't change anything, I just compiled the git.

For some unknown reason, some ARM toolchain produce "half working"
binaries ... we have no idea why that happens.

What's the toolchain you use ?
Could you send be the binary you compiled ?

Cheers,

    Sylvain



From pauldart at gmail.com  Mon Jan  9 13:54:37 2012
From: pauldart at gmail.com (Paul Dart)
Date: Mon, 9 Jan 2012 13:54:37 +0000
Subject: random net disconn. - o2 germany - motorola c123 + c140
In-Reply-To: <CAHL+j0_BLpCQg4UZPAatmyVO2MJLg2gda3iHuAsMHbTkmVfuJg@mail.gmail.com>
References: <zarafa.4f0aee63.36ee.33e034180bb7d344@zarafa.cubewerk.int>
	<CAHL+j0_BLpCQg4UZPAatmyVO2MJLg2gda3iHuAsMHbTkmVfuJg@mail.gmail.com>
Message-ID: <CAOEO7sp93vTMt0cbYNd8OppM_mc7GfFC82OXp0UunLHCZ_ZQvw@mail.gmail.com>

On 9 January 2012 13:45, Sylvain Munaut <246tnt at gmail.com> wrote:
> I didn't change anything, I just compiled the git.
>
> For some unknown reason, some ARM toolchain produce "half working"
> binaries ... we have no idea why that happens.
>
> What's the toolchain you use ?
> Could you send be the binary you compiled ?
>
> Cheers,
>
> ? ?Sylvain
>

Hi,

I have had this with my Pirelli DP-L10. Steve|m on IRC gave me his
binaries and it worked. I am at work at the moment but can send
through some logs/details later if it helps as well.

Cheers,

Paul



From pauldart at gmail.com  Tue Jan 10 18:15:40 2012
From: pauldart at gmail.com (Paul Dart)
Date: Tue, 10 Jan 2012 18:15:40 +0000
Subject: random net disconn. - o2 germany - motorola c123 + c140
In-Reply-To: <CAOEO7sp93vTMt0cbYNd8OppM_mc7GfFC82OXp0UunLHCZ_ZQvw@mail.gmail.com>
References: <zarafa.4f0aee63.36ee.33e034180bb7d344@zarafa.cubewerk.int>
	<CAHL+j0_BLpCQg4UZPAatmyVO2MJLg2gda3iHuAsMHbTkmVfuJg@mail.gmail.com>
	<CAOEO7sp93vTMt0cbYNd8OppM_mc7GfFC82OXp0UunLHCZ_ZQvw@mail.gmail.com>
Message-ID: <CAOEO7spCpSmd4cnFWbn_w4-EDT17uWrs2tu=9k9bN0xqWXto6w@mail.gmail.com>

On 9 January 2012 13:54, Paul Dart <pauldart at gmail.com> wrote:
> Hi,
>
> I have had this with my Pirelli DP-L10. Steve|m on IRC gave me his
> binaries and it worked. I am at work at the moment but can send
> through some logs/details later if it helps as well.
>
> Cheers,
>
> Paul

Just for completeness here are my results:

1.
Compiled myself with gnuarm-3.4.3 (as suggested here
http://bb.osmocom.org/trac/wiki/GettingStarted ).
http://twigman.com/dev/layer1.highram.bin
MD5: 682d115436bf14a3abdd60b1032eb1aa  layer1.highram.bin

Results on running with osmocon (end of log):

Preparing the last block, filling 534 bytes, block checksum is 0x8a
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 51 finished
Finished, sent 51 blocks in total
Received block ack from phone
Sending checksum: 0x7c
Checksum on phone side matches, let's branch to your code
Branching to 0x00820000
Received branch ack, your code is running now!

and it just sits there.

2.
Using steve|m's bin file http://twigman.com/dev/pirelli.l1.highram.bin
MD5: 6b6a84199e9a1b272fc0e954bd2f1cef  pirelli.l1.highram.bin

Results on running with osmocon (end of log):

Preparing the last block, filling 1012 bytes, block checksum is 0xb6
handle_write_block(): 1024 bytes (1024/1024)
handle_write_block(): Block 52 finished
Finished, sent 52 blocks in total
Received block ack from phone
Sending checksum: 0xdc
Checksum on phone side matches, let's branch to your code
Branching to 0x00820000
Received branch ack, your code is running now!


OSMOCOM Layer 1 (revision osmocon_v0.0.0-1208-g506a344-modified)
======================================================================
Device ID code: 0xb496
Device Version code: 0x0000
ARM ID code: 0xfff3
cDSP ID code: 0x0128
Die ID code: e5140a2ee514551d
======================================================================
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 7333!

and then it seems to work.

So this seems to be some compilation error (clearly as they are
different sized files). I imagine it's due to that GettingStarted page
pointing to

http://bb.osmocom.org/trac/wiki/toolchain
and not
http://bb.osmocom.org/trac/wiki/GnuArmToolchain

Is this just a documentation problem? I think so. If everyone agrees
we should update the wiki...

Comments?

Paul



From izsh at fail0verflow.com  Mon Jan  9 14:58:58 2012
From: izsh at fail0verflow.com (iZsh)
Date: Mon, 9 Jan 2012 15:58:58 +0100
Subject: random net disconn. - o2 germany - motorola c123 + c140
In-Reply-To: <CAHL+j0_BLpCQg4UZPAatmyVO2MJLg2gda3iHuAsMHbTkmVfuJg@mail.gmail.com>
References: <zarafa.4f0aee63.36ee.33e034180bb7d344@zarafa.cubewerk.int>
	<CAHL+j0_BLpCQg4UZPAatmyVO2MJLg2gda3iHuAsMHbTkmVfuJg@mail.gmail.com>
Message-ID: <43DC5DD1-08CC-4A5F-A44D-2078E814DE75@fail0verflow.com>

On 9 janv. 2012, at 14:45, Sylvain Munaut wrote:

>> now it behaves much more stable!! That is awesome. Thank you. What have you changed / what was the issue?
>> 
>> Now I'm in the network only with a single disconnect since a few minutes. I also had the chance to make a phone-call now.
> 
> I didn't change anything, I just compiled the git.
> 
> For some unknown reason, some ARM toolchain produce "half working"
> binaries ... we have no idea why that happens.

FYI
During 28C3, I found out that the firmware compiled on Mac OS X with arm-none-eabi-gcc  (from macport) was not working for me, whereas arm-elf-gcc was working just fine.

iZsh




From stefan.bauer at cubewerk.de  Mon Jan  9 13:59:05 2012
From: stefan.bauer at cubewerk.de (=?utf-8?Q?Stefan_Bauer?=)
Date: Mon, 9 Jan 2012 14:59:05 +0100
Subject: random net disconn. - o2 germany - motorola c123 + c140
Message-ID: <zarafa.4f0af2a9.378d.037f44280f80be5a@zarafa.cubewerk.int>

-----Urspr?ngliche Nachricht-----
Von:	Sylvain Munaut <246tnt at gmail.com>
> I didn't change anything, I just compiled the git.
> 
> For some unknown reason, some ARM toolchain produce "half working"
> binaries ... we have no idea why that happens.

For me, i'm happy now as i can debug and test this gsm stuff further. thank you again.

> What's the toolchain you use ?

Well, i just used the following sources and put them together:

    wget http://www.gnuarm.com/binutils-2.17.tar.bz2
    wget http://www.gnuarm.com/gcc-4.1.1.tar.bz2
    wget http://www.gnuarm.com/newlib-1.14.0.tar.gz
    wget http://www.gnuarm.com/insight-6.5.tar.bz2
    wget http://ftp.gnu.org/gnu/gdb/gdb-6.7.tar.bz2 

According to some german howto from here:

http://www.alphapogo.de/


> Could you send be the binary you compiled ?

Sure - please find the binary here:

http://www.plzk.de/layer1.compalram.bin

4479603075372ce89c215178a9ad48f3  layer1.compalram.bin


Stefan



From 246tnt at gmail.com  Mon Jan  9 14:28:52 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Mon, 9 Jan 2012 15:28:52 +0100
Subject: random net disconn. - o2 germany - motorola c123 + c140
In-Reply-To: <zarafa.4f0af2a9.378d.037f44280f80be5a@zarafa.cubewerk.int>
References: <zarafa.4f0af2a9.378d.037f44280f80be5a@zarafa.cubewerk.int>
Message-ID: <CAHL+j0-Agpz=D6L=VuBYnrBQaHug=Vy9XnEYMvZZb=2AyO6jUg@mail.gmail.com>

Hi,

> ? ?wget http://www.gnuarm.com/binutils-2.17.tar.bz2
> ? ?wget http://www.gnuarm.com/gcc-4.1.1.tar.bz2
> ? ?wget http://www.gnuarm.com/newlib-1.14.0.tar.gz
> ? ?wget http://www.gnuarm.com/insight-6.5.tar.bz2
> ? ?wget http://ftp.gnu.org/gnu/gdb/gdb-6.7.tar.bz2

All those are pretty ancient.

Try the script attached to http://bb.osmocom.org/trac/wiki/GnuArmToolchain

You can even update some of the tools listed in the script.
I use

binutils 2.22
gcc 4.6.2
newlib 1.19.0

(I didn't build insight or gdb)

Cheers,

    Sylvain



From refreakt at gmail.com  Wed Jan 11 11:21:46 2012
From: refreakt at gmail.com (Todor Pirov)
Date: Wed, 11 Jan 2012 13:21:46 +0200
Subject: Control Update Location with osmocom
Message-ID: <17E18B06-7220-473E-85C3-C0BCDF99683F@gmail.com>

Hi All,
I'd like to know if it is possible to control with osmocom the UL requests sent from the handsets. More specifically the interval between the UL request iterations when there is no response from the HLR. Also is it possible to simulate manual registration to the network i.e. keep sending UL to the same network after the 4th UL has timed out?
I guess this could be a function of the baseband chip itself but some settings are controlled by the firmware.

BR,
Todor


From mailman at lists.osmocom.org  Thu Jan 12 06:37:51 2012
From: mailman at lists.osmocom.org (mailman at lists.osmocom.org)
Date: Thu, 12 Jan 2012 07:37:51 +0100
Subject: Bounce action notification
Message-ID: <mailman.42.1326350271.1472.baseband-devel@lists.osmocom.org>

This is a Mailman mailing list bounce action notice:

    List:       baseband-devel
    Member:     fabian at auth.se
    Action:     Subscription disabled.
    Reason:     Excessive or fatal bounces.
    


The triggering bounce notice is attached below.

Questions? Contact the Mailman site administrator at
mailman at lists.osmocom.org.
-------------- next part --------------
An embedded message was scrubbed...
From: Mail Delivery System <Mailer-Daemon at ganesha.gnumonks.org>
Subject: Mail delivery failed: returning message to sender
Date: Thu, 12 Jan 2012 07:37:49 +0100
Size: 4487
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20120112/d4155b17/attachment.eml>

From stefan.bauer at cubewerk.de  Thu Jan 12 17:10:51 2012
From: stefan.bauer at cubewerk.de (=?utf-8?Q?Stefan_Bauer?=)
Date: Thu, 12 Jan 2012 18:10:51 +0100
Subject: 3GPP - paging references
Message-ID: <zarafa.4f0f141b.4dfd.246decea516349a9@zarafa.cubewerk.int>

Dear developers & users,

can somebody please provide further documents to understand how paging works? In detail how can i match the paging for my specific imsi/tmsi to the data-channel assignment? I dont see my tmsi/imsi as reference in the data-channel request-frame in wireshark nor in the output of ccch_scan. I guess i have to do some math :)

Thank you.

Stefan



From 246tnt at gmail.com  Thu Jan 12 17:27:38 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Thu, 12 Jan 2012 18:27:38 +0100
Subject: 3GPP - paging references
In-Reply-To: <zarafa.4f0f141b.4dfd.246decea516349a9@zarafa.cubewerk.int>
References: <zarafa.4f0f141b.4dfd.246decea516349a9@zarafa.cubewerk.int>
Message-ID: <CAHL+j0_4Ea3VODVpd2iHUCX-tmJbLd3-hjgNf_5iJvJeKBJh+w@mail.gmail.com>

Hi,

> In detail how can i match the paging for my specific imsi/tmsi to the data-channel assignment?

You can't ... There is no relation between paging and the channel assignment.

When the phone sees he's being paged, he will initiate the channel
request procedure.

He sends a RACH at a given time fn with a random reference (8bits).
And then he looks for assignement matching his RACH (i.e. the time fn
and random reference are repeated back by the network in the
assignment so that a phone knows the channel was for it).

Cheers,

    Sylvain



From stefan.bauer at cubewerk.de  Thu Jan 12 23:10:55 2012
From: stefan.bauer at cubewerk.de (=?utf-8?Q?Stefan_Bauer?=)
Date: Fri, 13 Jan 2012 00:10:55 +0100
Subject: AW: 3GPP - paging references
Message-ID: <zarafa.4f0f687f.5bd9.20c2ca9128802bd5@zarafa.cubewerk.int>

-----Urspr?ngliche Nachricht-----
Von:	Sylvain Munaut <246tnt at gmail.com>
> When the phone sees he's being paged, he will initiate the channel
> request procedure.
> 
> He sends a RACH at a given time fn with a random reference (8bits).
> And then he looks for assignement matching his RACH (i.e. the time fn
> and random reference are repeated back by the network in the
> assignment so that a phone knows the channel was for it).

Sylvain,

so it goes like this: ?

1. BSC starts paging MS by either TMSI/IMSI
(Paging1: Normal paging chan any to imsi M(262073948077454))

2. MS sends channel request procedure to BSC over RACH
(MS uses special(random) parameters inside this request)
(is there a way to see the RACH-traffic in the "air" with regular tools?)

3. BSC sends Immediate Assignment message to MS and repeates the random
parameters from request
(GSM48 IMM ASS (ra=0x0f, chan_nr=0x49, ARFCN=667, TS=1, SS=1, TSC=5))

Greetings

Stefan



From stefan.bauer at cubewerk.de  Fri Jan 13 06:18:15 2012
From: stefan.bauer at cubewerk.de (=?utf-8?Q?Stefan_Bauer?=)
Date: Fri, 13 Jan 2012 07:18:15 +0100
Subject: 3GPP - paging references
Message-ID: <zarafa.4f0fcca7.6b93.6cbedf2a71f88d8c@zarafa.cubewerk.int>

-----Urspr?ngliche Nachricht-----
Von:	Joshua Lackey <jl at thre.at>
Gesendet:	Fr 13.01.2012 01:09
Betreff:	Re: AW: Re: 3GPP - paging references
An:	Stefan Bauer <stefan.bauer at cubewerk.de>; 
> On 01/12/2012 01:05 PM, Stefan Bauer wrote:
> > Hi,
> > 
> > Well thank you for your answer. I thought i could simply call my phone, the 
> network would page it and i would have the imsi/tmsi. As i'm in a very busy 
> cell, there are huge amounts of pagings. I have to rethink my first idea.
> 
> Call yourself 10 times.  The TMSI that appears 10 times will be yours.
> (With a high probability anyway.)

Hi Jushua,

i don't see a way to really narrow this down by this "technique". For example in my cell, the paging traffic is very high, so there are always several pagings with the same amount.

Also if i do 10 calls, i do not get put through after the first paging-request on all attempts so this is not quite precise.

Am i wrong?


Stefan



From stefan.bauer at cubewerk.de  Thu Jan 12 21:05:49 2012
From: stefan.bauer at cubewerk.de (=?utf-8?Q?Stefan_Bauer?=)
Date: Thu, 12 Jan 2012 22:05:49 +0100
Subject: AW: Re: 3GPP - paging references
Message-ID: <zarafa.4f0f4b2d.56b9.4206e66e5703e4ec@zarafa.cubewerk.int>

Hi,

Well thank you for your answer. I thought i could simply call my phone, the network would page it and i would have the imsi/tmsi. As i'm in a very busy cell, there are huge amounts of pagings. I have to rethink my first idea.

Stefan

----- Urspr?ngliche Nachricht -----
Von: Sylvain Munaut <246tnt at gmail.com>
Gesendet: Donnerstag, 12. Januar 2012 18:28
An: Stefan Bauer <stefan.bauer at cubewerk.de>
Cc: baseband-devel at lists.osmocom.org
Betreff: Re: 3GPP - paging references

Hi,

> In detail how can i match the paging for my specific imsi/tmsi to the data-channel assignment?

You can't ... There is no relation between paging and the channel assignment.

When the phone sees he's being paged, he will initiate the channel
request procedure.

He sends a RACH at a given time fn with a random reference (8bits).
And then he looks for assignement matching his RACH (i.e. the time fn
and random reference are repeated back by the network in the
assignment so that a phone knows the channel was for it).

Cheers,

    Sylvain




From stefan.bauer at cubewerk.de  Fri Jan 13 13:01:25 2012
From: stefan.bauer at cubewerk.de (=?utf-8?Q?Stefan_Bauer?=)
Date: Fri, 13 Jan 2012 14:01:25 +0100
Subject: AW: Re: 3GPP - paging references
Message-ID: <zarafa.4f102b25.7b39.50bd6f1a141f6f65@zarafa.cubewerk.int>

Sylvain,

I just red that if early assignment is used (non-oascu) in a ms terminating call, there is no channel request on RACH by ms. I still dont quite get then howto match imsi/tmsi to an immediate assignment.

stefan

----- Urspr?ngliche Nachricht -----
Von: Sylvain Munaut <246tnt at gmail.com>
Gesendet: Donnerstag, 12. Januar 2012 18:30
An: Stefan Bauer <stefan.bauer at cubewerk.de>
Cc: baseband-devel at lists.osmocom.org
Betreff: Re: 3GPP - paging references

Hi,

> In detail how can i match the paging for my specific imsi/tmsi to the data-channel assignment?

You can't ... There is no relation between paging and the channel assignment.

When the phone sees he's being paged, he will initiate the channel
request procedure.

He sends a RACH at a given time fn with a random reference (8bits).
And then he looks for assignement matching his RACH (i.e. the time fn
and random reference are repeated back by the network in the
assignment so that a phone knows the channel was for it).

Cheers,

    Sylvain





From 246tnt at gmail.com  Fri Jan 13 13:11:26 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Fri, 13 Jan 2012 14:11:26 +0100
Subject: 3GPP - paging references
In-Reply-To: <zarafa.4f102b25.7b39.50bd6f1a141f6f65@zarafa.cubewerk.int>
References: <zarafa.4f102b25.7b39.50bd6f1a141f6f65@zarafa.cubewerk.int>
Message-ID: <CAHL+j09vUcS67ZQCq-gdRcWimd1Vi7MKydcSvHwpS7dCZAnQgw@mail.gmail.com>

Hi,

> I just red that if early assignment is used (non-oascu) in a ms terminating call, there is no channel request on RACH by ms.

??? !!! ???

Where would you have read that in the spec ?


> I still dont quite get then howto match imsi/tmsi to an immediate assignment.

You can't ... I just said so in the previous mails ...

There is no indication in the imm.ass that would allow you to know for
which mobile identity a channel is intended. You can only know if it
matches _your_  request (by matching time and random reference)

Cheers,

    Sylvain



From stefan.bauer at cubewerk.de  Fri Jan 13 14:09:48 2012
From: stefan.bauer at cubewerk.de (=?utf-8?Q?Stefan_Bauer?=)
Date: Fri, 13 Jan 2012 15:09:48 +0100
Subject: AW: Re: 3GPP - paging references
Message-ID: <zarafa.4f103b2c.7e04.4cd20fca16a11427@zarafa.cubewerk.int>

Hi Peter,

I just use the motorola to listen to my providers arcfn. Then i watch for traffic from my regular non-osmocom cell phone operating in the same cell.

Are you talking about a hardware modification of the motorola phone to receive also uplink or just some software 'tuning'? I'm the transmitter in my case.

Thank you

Stefan

----- Urspr?ngliche Nachricht -----
Von: Peter Stuge <peter at stuge.se>
Gesendet: Freitag, 13. Januar 2012 14:47
An: baseband-devel at lists.osmocom.org
Betreff: Re: 3GPP - paging references

Stefan Bauer wrote:
> I could match the informations from imm.ass (downlink) against the
> paging response (uplink) on sdcch right? Anyway i still see no way
> to listen to uplink traffic on sdcch without usrp-hardware.

You already know what you send. If you want to listen to what someone
else sends you indeed need a receiver. The Motorola phone can be
modified to receive also uplink, but if the transmitter is far away
it might not work anyway.


//Peter





From peter at stuge.se  Fri Jan 13 17:17:55 2012
From: peter at stuge.se (Peter Stuge)
Date: Fri, 13 Jan 2012 18:17:55 +0100
Subject: 3GPP - paging references
In-Reply-To: <zarafa.4f103b2c.7e04.4cd20fca16a11427@zarafa.cubewerk.int>
References: <zarafa.4f103b2c.7e04.4cd20fca16a11427@zarafa.cubewerk.int>
Message-ID: <20120113171755.5399.qmail@stuge.se>

Stefan Bauer wrote:
> Are you talking about a hardware modification of the motorola phone

http://bb.osmocom.org/trac/wiki/Hardware/FilterReplacement


//Peter



From 246tnt at gmail.com  Fri Jan 13 17:22:44 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Fri, 13 Jan 2012 18:22:44 +0100
Subject: 3GPP - paging references
In-Reply-To: <20120113171755.5399.qmail@stuge.se>
References: <zarafa.4f103b2c.7e04.4cd20fca16a11427@zarafa.cubewerk.int>
	<20120113171755.5399.qmail@stuge.se>
Message-ID: <CAHL+j0_hg4MVYcQnRobnwbh6H90q_dPbq9Yd5UKbL2XrGFkTgQ@mail.gmail.com>

>> Are you talking about a hardware modification of the motorola phone
>
> http://bb.osmocom.org/trac/wiki/Hardware/FilterReplacement

Note that to receive a phone only a few meters next to you, it's not
necessary. The filters aren't that good.

Cheers,

    Sylvain



From stefan.bauer at cubewerk.de  Sat Jan 14 16:41:00 2012
From: stefan.bauer at cubewerk.de (=?utf-8?Q?Stefan_Bauer?=)
Date: Sat, 14 Jan 2012 17:41:00 +0100
Subject: 3GPP - paging references
Message-ID: <zarafa.4f11b01c.3a0a.561c2507760c440a@zarafa.cubewerk.int>

-----Urspr?ngliche Nachricht-----
Von:	Sylvain Munaut <246tnt at gmail.com>
Gesendet:	Fr 13.01.2012 18:24
Betreff:	Re: 3GPP - paging references
An:	baseband-devel at lists.osmocom.org; 
> >> Are you talking about a hardware modification of the motorola phone
> >
> > http://bb.osmocom.org/trac/wiki/Hardware/FilterReplacement
> 
> Note that to receive a phone only a few meters next to you, it's not
> necessary. The filters aren't that good.

Thank to you point this out. I'm not interested in traffic from other phones.

What i miss from the wiki or maybe just havent found yet is a statement whether i need to modify osmocom's default firmware to see uplink-traffic? (i want to see the MS response to a paging call) to understand the process of the imm.ass from BTS.

Have a nice weekend

stefan



From stefan.bauer at cubewerk.de  Fri Jan 13 13:31:41 2012
From: stefan.bauer at cubewerk.de (=?utf-8?Q?Stefan_Bauer?=)
Date: Fri, 13 Jan 2012 14:31:41 +0100
Subject: AW: Re: Re: 3GPP - paging references
Message-ID: <zarafa.4f10323d.7c75.4595816e5e993738@zarafa.cubewerk.int>

My information is from 'decoding gsm' master thesis from glendrange, hove, hvideberg (2010) norwegian university of science and technology, page 92, figure 5.4.

I,m getting closer to understand the process of assignment if i understand you correctly now.

 I could match the informations from imm.ass (downlink) against the paging response (uplink) on sdcch right? Anyway i still see no way to listen to uplink traffic on sdcch without usrp-hardware.

Greetings

stefan 

----- Urspr?ngliche Nachricht -----
Von: Sylvain Munaut <246tnt at gmail.com>
Gesendet: Freitag, 13. Januar 2012 14:12
An: Stefan Bauer <stefan.bauer at cubewerk.de>
Cc: baseband-devel at lists.osmocom.org
Betreff: Re: Re: 3GPP - paging references

Hi,

> I just red that if early assignment is used (non-oascu) in a ms terminating call, there is no channel request on RACH by ms.

??? !!! ???

Where would you have read that in the spec ?


> I still dont quite get then howto match imsi/tmsi to an immediate assignment.

You can't ... I just said so in the previous mails ...

There is no indication in the imm.ass that would allow you to know for
which mobile identity a channel is intended. You can only know if it
matches _your_  request (by matching time and random reference)

Cheers,

    Sylvain




From 246tnt at gmail.com  Fri Jan 13 13:39:24 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Fri, 13 Jan 2012 14:39:24 +0100
Subject: 3GPP - paging references
In-Reply-To: <zarafa.4f10323d.7c75.4595816e5e993738@zarafa.cubewerk.int>
References: <zarafa.4f10323d.7c75.4595816e5e993738@zarafa.cubewerk.int>
Message-ID: <CAHL+j09reBVUe0FTnHXrERCJp9kftBqYgOe-PjSsb4yp1hMVyQ@mail.gmail.com>

Hi

> My information is from 'decoding gsm' master thesis from glendrange, hove, hvideberg (2010) norwegian university of science and technology, page 92, figure 5.4.

Pretty much all his sequence diagram are missing the RACH ... that's
just plain wrong.


Cheers,

    Sylvain



From peter at stuge.se  Fri Jan 13 13:45:05 2012
From: peter at stuge.se (Peter Stuge)
Date: Fri, 13 Jan 2012 14:45:05 +0100
Subject: 3GPP - paging references
In-Reply-To: <zarafa.4f10323d.7c75.4595816e5e993738@zarafa.cubewerk.int>
References: <zarafa.4f10323d.7c75.4595816e5e993738@zarafa.cubewerk.int>
Message-ID: <20120113134505.18462.qmail@stuge.se>

Stefan Bauer wrote:
> I could match the informations from imm.ass (downlink) against the
> paging response (uplink) on sdcch right? Anyway i still see no way
> to listen to uplink traffic on sdcch without usrp-hardware.

You already know what you send. If you want to listen to what someone
else sends you indeed need a receiver. The Motorola phone can be
modified to receive also uplink, but if the transmitter is far away
it might not work anyway.


//Peter



From osmocom at ehlers.info  Sat Jan 14 12:26:36 2012
From: osmocom at ehlers.info (Tim Ehlers)
Date: Sat, 14 Jan 2012 13:26:36 +0100 (CET)
Subject: GSM 7bit encoding/decoding
Message-ID: <alpine.LNX.2.00.1201141307220.10464@ssn.gwdg.de>

Hello,

since I had problems with german umlauts when receiving (and probably also 
when sending) SMS, I looked today in the gsm translating part in 
libosmocore.

I first noticed a problem, when sending "NETZ Number" to "4636" in O2 
network, you get a response SMS saying in which network the number is 
located. Using osmocombb, I get:

[SMS from 66399]
Sehr geehrter Kunde, die angefragte Nummer ist im Netz von o2 aktiv 
(Angabe ohne Gew?hr).

So the umlaut "ae" is converted to "?".

The problem seems to be in the convert table in 
src/shared/libosmocore/src/gsm/gsm_utils.c, which is not bijective. "Ae" 
in gsm7 is "0x7b" and must be converted to latin1 "0xe4".

Looking in gsm_7bit_alphabet at place "0xe4", the is "0x7b". But there is 
also an "0x7b" at place "0xa7", which comes first and is indeed "?".


So the question is, are there mistakes in the table or is there a reason 
for the double entries?

Thanks

Tim

From osmocom at ehlers.info  Sat Jan 14 23:32:14 2012
From: osmocom at ehlers.info (Tim Ehlers)
Date: Sun, 15 Jan 2012 00:32:14 +0100 (CET)
Subject: GSM 7bit encoding/decoding
In-Reply-To: <alpine.LNX.2.00.1201141307220.10464@ssn.gwdg.de>
References: <alpine.LNX.2.00.1201141307220.10464@ssn.gwdg.de>
Message-ID: <alpine.LNX.2.00.1201150017050.19105@ssn.gwdg.de>

On Sat, 14 Jan 2012, Tim Ehlers wrote:

Hello again,

> src/shared/libosmocore/src/gsm/gsm_utils.c, which is not bijective. "Ae" in 
> gsm7 is "0x7b" and must be converted to latin1 "0xe4".
>
> Looking in gsm_7bit_alphabet at place "0xe4", the is "0x7b". But there is 
> also an "0x7b" at place "0xa7", which comes first and is indeed "?".

maybe its a good idea not to use one table for encoding and decoding. I 
introduced a reverse table for decoding gsm7 to latin1 like this:

--- osmocom-bb.120111.ori/src/shared/libosmocore/src/gsm/gsm_utils.c    2012-01-10 17:06:40.000000000 +0100
+++ osmocom-bb.120111/src/shared/libosmocore/src/gsm/gsm_utils.c2012-01-14 19:03:25.000000000 +0100
@@ -83,34 +83,65 @@
   * more complex
  */
  static unsigned char gsm_7bit_alphabet[] = {
-       0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x0a, 0xff, 0xff, 0x0d, 0xff,
-       0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-       0xff, 0xff, 0x20, 0x21, 0x22, 0x23, 0x02, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b, 0x2c,
-       0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3a, 0x3b,
-       0x3c, 0x3d, 0x3e, 0x3f, 0x00, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4a,
-       0x4b, 0x4c, 0x4d, 0x4e, 0x4f, 0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59,
-       0x5a, 0x3c, 0x2f, 0x3e, 0x14, 0x11, 0xff, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68,
-       0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f, 0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77,
-       0x78, 0x79, 0x7a, 0x28, 0x40, 0x29, 0x3d, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
-       0xff, 0xff, 0x0c, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5e, 0xff, 0xff,
-       0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x40, 0xff, 0x01, 0xff,
-       0x03, 0xff, 0x7b, 0x7d, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5c, 0xff, 0xff, 0xff, 0xff, 0xff,
-       0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5b, 0x7e, 0x5d, 0xff, 0x7c, 0xff, 0xff, 0xff,
-       0xff, 0x5b, 0x0e, 0x1c, 0x09, 0xff, 0x1f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5d,
-       0xff, 0xff, 0xff, 0xff, 0x5c, 0xff, 0x0b, 0xff, 0xff, 0xff, 0x5e, 0xff, 0xff, 0x1e, 0x7f,
-       0xff, 0xff, 0xff, 0x7b, 0x0f, 0x1d, 0xff, 0x04, 0x05, 0xff, 0xff, 0x07, 0xff, 0xff, 0xff,
-       0xff, 0x7d, 0x08, 0xff, 0xff, 0xff, 0x7c, 0xff, 0x0c, 0x06, 0xff, 0xff, 0x7e, 0xff, 0xff
+  0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x0a, 0xff, 0xff, 0x0d, 0xff, 0xff,
+  0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+  0x20, 0x21, 0x22, 0x23, 0x02, 0x25, 0x26, 0x27, 0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f,
+  0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e, 0x3f,
+  0x00, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f,
+  0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57, 0x58, 0x59, 0x5a, 0xfe, 0xfe, 0xfe, 0xfe, 0x11,
+  0x27, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f,
+  0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78, 0x79, 0x7a, 0xfe, 0xfe, 0xfe, 0xfe, 0xff,
+  0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+  0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+  0xff, 0x40, 0xff, 0x01, 0x24, 0x03, 0xff, 0x5f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+  0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x60,
+  0xff, 0xff, 0xff, 0xff, 0x5b, 0x0e, 0x1c, 0x09, 0xff, 0x1f, 0xff, 0xff, 0xff, 0xff, 0xff, 0x60,
+  0xff, 0x5d, 0xff, 0xff, 0xff, 0xff, 0x5c, 0xff, 0x0b, 0xff, 0xff, 0xff, 0x5e, 0xff, 0xff, 0x1e,
+  0x7f, 0xff, 0xff, 0xff, 0x7b, 0x0f, 0x1d, 0xff, 0x04, 0x05, 0xff, 0xff, 0x07, 0xff, 0xff, 0xff,
+  0xff, 0x7d, 0x08, 0xff, 0xff, 0xff, 0x7c, 0xff, 0x0c, 0x06, 0xff, 0xff, 0x7e, 0xff, 0xff, 0xff
+};
+
+static unsigned char gsm_7bit_alphabet_rev[] = {
+    0x40, 0xa3, 0x24, 0xa5, 0xe8, 0xe9, 0xf9, 0xec,
+    0xf2, 0xc7, 0x0a, 0xd8, 0xf8, 0x0d, 0xc5, 0xe5,
+    0xff, 0x5f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+    0xff, 0xff, 0xff, 0x20, 0xc6, 0xe6, 0xdf, 0xc9,
+    0x20, 0x21, 0x22, 0x23, 0xa4, 0x25, 0x26, 0x27,
+    0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f,
+    0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
+    0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e, 0x3f,
+    0xa1, 0x41, 0x42, 0x43, 0x44, 0x45, 0x46, 0x47,
+    0x48, 0x49, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f,
+    0x50, 0x51, 0x52, 0x53, 0x54, 0x55, 0x56, 0x57,
+    0x58, 0x59, 0x5a, 0xc4, 0xd6, 0xd1, 0xdc, 0xa7,
+    0xbf, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67,
+    0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e, 0x6f,
+    0x70, 0x71, 0x72, 0x73, 0x74, 0x75, 0x76, 0x77,
+    0x78, 0x79, 0x7a, 0xe4, 0xf6, 0xf1, 0xfc, 0xe0,
+
+    0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+    0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+    0xff, 0xff, 0xff, 0x5e, 0xff, 0xff, 0xff, 0xff,
+    0xff, 0xff, 0x20, 0xff, 0xff, 0xff, 0xff, 0xff,
+    0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x7b,
+    0x7d, 0xff, 0xff, 0xff, 0xff, 0xff, 0x5c, 0xff,
+    0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+    0xff, 0xff, 0xff, 0x5b, 0x7e, 0x5d, 0xff, 0x7c,
+    0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+    0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+    0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+    0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+    0xff, 0xff, 0xff, 0xff, 0x65, 0xff, 0xff, 0xff
  };

  /* GSM 03.38 6.2.1 Character lookup for decoding */
  static int gsm_septet_lookup(uint8_t ch)
  {
-       int i = 0;
-       for (; i < sizeof(gsm_7bit_alphabet); i++) {
-               if (gsm_7bit_alphabet[i] == ch)
-                       return i;
-       }
-       return -1;
+        char c = gsm_7bit_alphabet_rev[ch];
+        if (c) {
+          return c;
+       } else {
+       return -1; }
  }

  /* Compute the number of octets from the number of septets, for instance: 
47 septets needs 41,125 = 42 octets */
@@ -152,7 +183,7 @@
                 /* this is an extension character */
                 if(rtext[i] == 0x1b && i + 1 < septet_l){
                         tmp = rtext[i+1];
-                       *(text++) = gsm_7bit_alphabet[0x7f + tmp];
+                       *(text++) = gsm_7bit_alphabet_rev[0x7f + tmp];
                         i++;
                         continue;
                 }



Maybe someone could have a look on the code, if I missed something? Since 
we are using latin1, I don't know how to convert characters like ? and 
others not in latin1. The ? sign is converted to e in the above code.

cheers

Tim

From stefan.bauer at cubewerk.de  Sat Jan 14 22:43:23 2012
From: stefan.bauer at cubewerk.de (=?utf-8?Q?Stefan_Bauer?=)
Date: Sat, 14 Jan 2012 23:43:23 +0100
Subject: Paging Request3 - not standard compliant? o2-germany
Message-ID: <zarafa.4f12050b.4770.0e44c79c657d254f@zarafa.cubewerk.int>

Good evening,

according to EN 300 940 - V7.7.1 - Digital cellular telecommunications system (Phase 2+); Mobile radio interface layer 3 specification (GSM 04.08 version 7.7.1 Release 1998)

9.1.24 Paging request type 3

such requests shall only address MSs by T/MSIs but i notice Type3-Requests with IMSI in o2-germany network.

<0001> app_ccch_scan.c:378 Paging3: Normal paging chan n/a  to imsi M(2261022118380XX)

What do i miss?


Stefan



From 246tnt at gmail.com  Sat Jan 14 22:56:37 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Sat, 14 Jan 2012 23:56:37 +0100
Subject: Paging Request3 - not standard compliant? o2-germany
In-Reply-To: <zarafa.4f12050b.4770.0e44c79c657d254f@zarafa.cubewerk.int>
References: <zarafa.4f12050b.4770.0e44c79c657d254f@zarafa.cubewerk.int>
Message-ID: <CAHL+j08-NvfyZR38K5YwiV=JmYCgzYFC8O3dft2=fiF9v5Fc0A@mail.gmail.com>

Hi,

> according to EN 300 940 - V7.7.1 - Digital cellular telecommunications system (Phase 2+); Mobile radio interface layer 3 specification (GSM 04.08 version 7.7.1 Release 1998)
>
> 9.1.24 Paging request type 3
>
> such requests shall only address MSs by T/MSIs but i notice Type3-Requests with IMSI in o2-germany network.
>
> <0001> app_ccch_scan.c:378 Paging3: Normal paging chan n/a ?to imsi M(2261022118380XX)
>
> What do i miss?

The typo in app_ccch_scan.c:378 ...

The function is called gsm48_rx_paging_p2  but prints "Paging3"
And gsm48_rx_paging_p1  but prints "Paging2" ...

Cheers,

    Sylvain



From emp618 at internode.on.net  Wed Jan 18 00:13:49 2012
From: emp618 at internode.on.net (EMP)
Date: Wed, 18 Jan 2012 11:13:49 +1100
Subject: Strange issues booting layer1
Message-ID: <4F160EBD.6090202@internode.on.net>

Hi all

I have compiled osmocombb and everything seems ok. Now i'm having a 
strange issue which I can replicate across a number of phones. Using a 
C118 I could boot everything and run the mobile app. Using a C139 I 
could do the same. However, now the phones dont seem to want to boot?

I start everything up (after running the mobile app a few times, 
stopping the phone and PC etc) and then when I press the Power Off key, 
nothing happens. It just refuses to download anything.

Am wondering if i'm damaging the phones somehow as its now two phones 
that will no longer start via the USB cable. The phones boot the normal 
phone firmware fine but wont respond to osmocom.

Guess i'm just curious as to others thoughts as i'm unsure where its 
breaking?





From osmocom at ehlers.info  Thu Jan 19 23:06:32 2012
From: osmocom at ehlers.info (Tim Ehlers)
Date: Fri, 20 Jan 2012 00:06:32 +0100 (CET)
Subject: read Kc with osmocombb
Message-ID: <alpine.LNX.2.00.1201192357110.24997@ssn.gwdg.de>

Hi,

today I seached for a possibility to read the temporary session key "Kc" 
from my phone in osmocombb. I did not find a function. So I used the 
function, which writes SMS into sms.txt to write the Kc. Since I never 
used the Kc to decode something I would like to ask if I did it correct 
this way:

--- old/host/layer23/src/mobile/subscriber.c        2012-01-10 17:06:40.000000000 +0100
+++ new/host/layer23/src/mobile/subscriber.c        2012-01-19 23:52:36.000000000 +0100
@@ -60,6 +60,39 @@
         return NULL;
  }

+static int gsm_kc(struct osmocom_ms *ms, uint8_t *kc)
+{
+        const char osmocomkc[] = ".osmocom/bb/kc.txt";
+        int len;
+        const char *home;
+        char *kc_file;
+        FILE *fp;
+
+        home = getenv("HOME");
+        if (!home) {
+fail:
+                fprintf(stderr, "Can't deliver SMS, be sure to create '%s' in "
+                        "your home directory.\n", osmocomkc);
+                return NULL;
+        }
+        len = strlen(home) + 1 + sizeof(osmocomkc);
+        kc_file = talloc_size(l23_ctx, len);
+        if (!kc_file)
+                goto fail;
+        snprintf(kc_file, len, "%s/%s", home, osmocomkc);
+
+        fp = fopen(kc_file, "a");
+        if (!fp)
+                goto fail;
+        fprintf(fp, "%s %02X%02X%02X%02X%02X%02X%02X%02X\n", ms->name, kc[0], kc[1], kc[2], kc[3], kc[4], kc[5], kc[6], kc[7], kc[8]);
+        fclose(fp);
+
+        talloc_free(kc_file);
+
+        return 0;
+}
+
+
  static char *sim_decode_bcd(uint8_t *data, uint8_t length)
  {
         int i, j = 0;
@@ -377,6 +410,7 @@
         subscr->key_seq = data[8] & 0x07;

         LOGP(DMM, LOGL_INFO, "received KEY from SIM\n");
+       gsm_kc(subscr->ms, subscr->key);

         return 0;
  }



Maybe it would be a better way to implement a function in VTY. BTW, am I 
wrong or why did nobody do that until present?

Thanks

Tim



From 246tnt at gmail.com  Thu Jan 19 23:17:30 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Fri, 20 Jan 2012 00:17:30 +0100
Subject: read Kc with osmocombb
In-Reply-To: <alpine.LNX.2.00.1201192357110.24997@ssn.gwdg.de>
References: <alpine.LNX.2.00.1201192357110.24997@ssn.gwdg.de>
Message-ID: <CAHL+j087FBa5JYpochs_p8Su3N5eBGBhS2xeotmZ7C5aonE=Ag@mail.gmail.com>

> Maybe it would be a better way to implement a function in VTY.

like ... 'show subscriber' ...

Cheers,

    Sylvain



From osmocom at ehlers.info  Thu Jan 19 23:22:58 2012
From: osmocom at ehlers.info (Tim Ehlers)
Date: Fri, 20 Jan 2012 00:22:58 +0100 (CET)
Subject: read Kc with osmocombb
In-Reply-To: <CAHL+j087FBa5JYpochs_p8Su3N5eBGBhS2xeotmZ7C5aonE=Ag@mail.gmail.com>
References: <alpine.LNX.2.00.1201192357110.24997@ssn.gwdg.de>
	<CAHL+j087FBa5JYpochs_p8Su3N5eBGBhS2xeotmZ7C5aonE=Ag@mail.gmail.com>
Message-ID: <alpine.LNX.2.00.1201200021570.24997@ssn.gwdg.de>

On Fri, 20 Jan 2012, Sylvain Munaut wrote:

>> Maybe it would be a better way to implement a function in VTY.
>
> like ... 'show subscriber' ...

ahh, I knew I missed it somewhere...

Ok, thanks

Tim



From alphaflux at zoho.com  Sun Jan 22 02:33:28 2012
From: alphaflux at zoho.com (alphaflux)
Date: Sat, 21 Jan 2012 18:33:28 -0800
Subject: Creating unique features for a real OsmocomBB phone
Message-ID: <1350342dd33.1239505324267296929.-1307030310108300641@zoho.com>

A novel feature would be direct connections to other OsmocomBB handsets 
that are in range. So not only handsets communicate with towers but a handset 
also listens to announcements of compatible handsets within range. 
Reason is to have free communication between different buildings, floors, rooms.

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

From suraev at stud.ntnu.no  Wed Jan 25 09:27:50 2012
From: suraev at stud.ntnu.no (suraev at stud.ntnu.no)
Date: Wed, 25 Jan 2012 17:27:50 +0800
Subject: Creating unique features for a real OsmocomBB phone
In-Reply-To: <1350342dd33.1239505324267296929.-1307030310108300641@zoho.com>
References: <1350342dd33.1239505324267296929.-1307030310108300641@zoho.com>
Message-ID: <4F1FCB16.5090205@stud.ntnu.no>

22.01.2012 10:33, alphaflux ?????:
> A novel feature would be direct connections to other OsmocomBB handsets
> that are in range. So not only handsets communicate with towers but a handset
> also listens to announcements of compatible handsets within range.
> Reason is to have free communication between different buildings, floors, rooms.

Sorry to disappoint but that would require hardware modifications similar to those
made for traffic interception by Karsten et all. Normally phone do not see uplink
radio from other phone because of antennae filters.

Although I plan to make such modifications to my test phone anyway :)

cheers,
Max.






From andreas at eversberg.eu  Wed Jan 25 13:34:35 2012
From: andreas at eversberg.eu (Andreas Eversberg)
Date: Wed, 25 Jan 2012 14:34:35 +0100
Subject: Creating unique features for a real OsmocomBB phone
In-Reply-To: <4F1FCB16.5090205@stud.ntnu.no>
References: <1350342dd33.1239505324267296929.-1307030310108300641@zoho.com>
	<4F1FCB16.5090205@stud.ntnu.no>
Message-ID: <4F2004EB.2090109@eversberg.eu>

suraev at stud.ntnu.no wrote:
> Sorry to disappoint but that would require hardware modifications similar to those
> made for traffic interception by Karsten et all. Normally phone do not see uplink
> radio from other phone because of antennae filters.
>   
hi,

why should two phones use uplink frequency to communicate directly
together? why not using downlink frequency? iirc, a phone can transmit
on downlink, since there are no filters on tx side.




From Max.Suraev at fairwaves.ru  Wed Jan 25 14:32:49 2012
From: Max.Suraev at fairwaves.ru (Max.Suraev at fairwaves.ru)
Date: Wed, 25 Jan 2012 22:32:49 +0800
Subject: Creating unique features for a real OsmocomBB phone
In-Reply-To: <4F2004EB.2090109@eversberg.eu>
References: <1350342dd33.1239505324267296929.-1307030310108300641@zoho.com>
	<4F1FCB16.5090205@stud.ntnu.no> <4F2004EB.2090109@eversberg.eu>
Message-ID: <4F201291.1040906@fairwaves.ru>

25.01.2012 21:34, Andreas Eversberg ?????:

> why should two phones use uplink frequency to communicate directly
> together? why not using downlink frequency? iirc, a phone can transmit
> on downlink, since there are no filters on tx side.

Sounds great if
a) phone hw is powerful enough to run stripped down version of bts (osmobts?)
b) we do not interfere with transmissions of regular bts

And we have to adopt gsm stack for p2p purpose - add some sot of peer discovery at
the very least.

-- 
best regards,
Max, http://fairwaves.ru



From dvsm89 at gmx.com  Wed Jan 25 14:02:36 2012
From: dvsm89 at gmx.com (Dave Schmidt)
Date: Wed, 25 Jan 2012 15:02:36 +0100
Subject: Creating unique features for a real OsmocomBB phone
Message-ID: <20120125140237.73710@gmx.com>

> why should two phones use uplink frequency to communicate directly
> together? why not using downlink frequency? 

Because in most if not all counties transmission on downlink frequency requires a license?

(Sorry and please correct me if this is some obvious nonsense... to me, the original proposal was looking quite nonsensial because of this, but I'd love to learn if I'm wrong...)

Dave.



From 246tnt at gmail.com  Wed Jan 25 14:44:10 2012
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 25 Jan 2012 15:44:10 +0100
Subject: Creating unique features for a real OsmocomBB phone
In-Reply-To: <20120125140237.73710@gmx.com>
References: <20120125140237.73710@gmx.com>
Message-ID: <CAHL+j09kseQSq3FpBg+_wi6GoHikrHHB86QOze5AGq0wRMDfvw@mail.gmail.com>

Hi,

On Wed, Jan 25, 2012 at 3:02 PM, Dave Schmidt <dvsm89 at gmx.com> wrote:
>> why should two phones use uplink frequency to communicate directly
>> together? why not using downlink frequency?
>
> Because in most if not all counties transmission on downlink frequency requires a license?

Transmitting on uplink _also_ require a license ... you're just using
the license of your operator that delagated the right to you to
transmit in uplink when they sent you a IMMEDIATE ASSIGNEMENT.

But I can assure you if you start txing in the uplink of an operator,
they'll complain ...

Here in BE, the license clearly lists both the uplink and downlink
frequencies when you're allocated a GSM test license.

Cheers,

    Sylvain



From sean at seanharlow.info  Wed Jan 25 15:18:16 2012
From: sean at seanharlow.info (Sean Harlow)
Date: Wed, 25 Jan 2012 10:18:16 -0500
Subject: Creating unique features for a real OsmocomBB phone
In-Reply-To: <20120125140237.73710@gmx.com>
References: <20120125140237.73710@gmx.com>
Message-ID: <873DE59F-D2B2-48A3-8808-8D5F0504BF70@seanharlow.info>

In ITU region 2 there is an ISM and amateur band that overlaps with some of the GSM900 uplink and downlink frequencies.  At least in the US, unlicensed "part 15" operation is also permitted there, though part 15 has strict power limits that make it mostly useless beyond a few hundred feet.

One could legally implement and test this concept in the US or anywhere else in region 2 with similar laws as long as they can keep it within 902-928 MHz and were either licensed amateurs or keep the power within part 15 specs.

That said I had a related idea once about the feasibility of an amateur cellular network, but one of the main questions raised on IRC was about the filtration between TX and RX since the uplink/downlink spacing would have to be narrowed to fit within the available window.  This would likely have to be done to an even greater extent to support direct handset to handset communication, thus would be even more of a potential problem.

tl;dr: Legally possible if you're west of the Atlantic, but you may have some notable technical problems to overcome.
----------
Sean Harlow
sean at seanharlow.info

On Jan 25, 2012, at 9:02 AM, Dave Schmidt wrote:

>> why should two phones use uplink frequency to communicate directly
>> together? why not using downlink frequency? 
> 
> Because in most if not all counties transmission on downlink frequency requires a license?
> 
> (Sorry and please correct me if this is some obvious nonsense... to me, the original proposal was looking quite nonsensial because of this, but I'd love to learn if I'm wrong...)
> 
> Dave.
> 




From pabs at debian.org  Wed Jan 25 23:30:21 2012
From: pabs at debian.org (Paul Wise)
Date: Thu, 26 Jan 2012 07:30:21 +0800
Subject: Creating unique features for a real OsmocomBB phone
In-Reply-To: <1350342dd33.1239505324267296929.-1307030310108300641@zoho.com>
References: <1350342dd33.1239505324267296929.-1307030310108300641@zoho.com>
Message-ID: <CAKTje6G-y6+pbUKcmjnSYAapYOdHRHvBxB280P=MAgvo+iiUaw@mail.gmail.com>

On Sun, Jan 22, 2012 at 10:33 AM, alphaflux wrote:

> A novel feature would be direct connections to other OsmocomBB handsets
> that are in range. So not only handsets communicate with towers but a
> handset
> also listens to announcements of compatible handsets within range.
> Reason is to have free communication between different buildings, floors,
> rooms.

Sounds a fair bit like what these folks are doing with WiFi:

http://servalproject.org/

-- 
bye,
pabs

http://wiki.debian.org/PaulWise
http://bonedaddy.net/pabs3/



From alexander.huemer at xx.vu  Thu Jan 26 00:37:46 2012
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Thu, 26 Jan 2012 01:37:46 +0100
Subject: Creating unique features for a real OsmocomBB phone
In-Reply-To: <CAKTje6G-y6+pbUKcmjnSYAapYOdHRHvBxB280P=MAgvo+iiUaw@mail.gmail.com>
References: <1350342dd33.1239505324267296929.-1307030310108300641@zoho.com>
	<CAKTje6G-y6+pbUKcmjnSYAapYOdHRHvBxB280P=MAgvo+iiUaw@mail.gmail.com>
Message-ID: <20120126003746.GA1870@de.xx.vu>

On Thu, Jan 26, 2012 at 07:30:21AM +0800, Paul Wise wrote:
> Sounds a fair bit like what these folks are doing with WiFi:
> 
> http://servalproject.org/
Well, with WiFi that's not sooo difficult, right?
Providing an WiFi access point with a normal NIC is mostly just a mode
of the normal driver and additionally there is hostapd.
Mesh networking is already nicely implemented.
Is there anything great in that project that I miss?

Kind regards
-Alexander Huemer



From osmocom at ehlers.info  Sun Jan 22 12:12:57 2012
From: osmocom at ehlers.info (Tim Ehlers)
Date: Sun, 22 Jan 2012 13:12:57 +0100 (CET)
Subject: Asterisk GSM channel driver?
Message-ID: <alpine.LNX.2.00.1201221256520.17126@ssn.gwdg.de>

Hi,

I have seen, that there are channel driver for the DECT project, where you 
can connect your DECT handset to the Asterisk PBX. There is also somehow a 
possibility to connect a mobile GSM phone via openBSC and asterisk.

But has somebody thought about just connecting the osmocombb mobile phone 
(which is connected to a public mobile network [or openBSC]) to asterisk?

I would think of making a call through a channel driver, osmocombb is 
doing a call like "call ms number", but instead of using mike and speaker 
asterisk would send the already in GSM-codec modulated voice data through 
the serial port (maybe it would needed to use the non-standard USB-TTL 
version to handle full duplex GSM speech). And layer1 of osmocombb could 
send that nearly untouched on the air. For incoming calls this could be 
similar + signalling the call through the channel driver.

Has somebody already thought of that? Would that be a achieveable task or 
is it technically impossible?

Thanks

Tim



From peter at stuge.se  Sun Jan 22 12:49:40 2012
From: peter at stuge.se (Peter Stuge)
Date: Sun, 22 Jan 2012 13:49:40 +0100
Subject: Asterisk GSM channel driver?
In-Reply-To: <alpine.LNX.2.00.1201221256520.17126@ssn.gwdg.de>
References: <alpine.LNX.2.00.1201221256520.17126@ssn.gwdg.de>
Message-ID: <20120122124940.31664.qmail@stuge.se>

Tim Ehlers wrote:
> But has somebody thought about just connecting the osmocombb mobile phone 
> (which is connected to a public mobile network [or openBSC]) to asterisk?

Not yet, but it's a good idea.


> I would think of making a call through a channel driver,

Until the osmocombb channel driver is ready, you can use this with a
cheap Huawei dongle: http://code.google.com/p/asterisk-chan-dongle/


> Has somebody already thought of that? Would that be a achieveable
> task or is it technically impossible?

A channel driver would be great!


//Peter



From osmocom at ehlers.info  Sun Jan 22 20:59:13 2012
From: osmocom at ehlers.info (Tim Ehlers)
Date: Sun, 22 Jan 2012 21:59:13 +0100 (CET)
Subject: Asterisk GSM channel driver?
In-Reply-To: <20120122124940.31664.qmail@stuge.se>
References: <alpine.LNX.2.00.1201221256520.17126@ssn.gwdg.de>
	<20120122124940.31664.qmail@stuge.se>
Message-ID: <alpine.LNX.2.00.1201222158260.12309@ssn.gwdg.de>

On Sun, 22 Jan 2012, Peter Stuge wrote:

Hi Peter,

>> I would think of making a call through a channel driver,
>
> Until the osmocombb channel driver is ready, you can use this with a
> cheap Huawei dongle: http://code.google.com/p/asterisk-chan-dongle/

thanks for that. Ich will try that out.

But still dreaming of a channel driver for osmocombb. :)

Cheers

Tim



From mad at auth.se  Thu Jan 26 18:02:01 2012
From: mad at auth.se (mad)
Date: Thu, 26 Jan 2012 19:02:01 +0100
Subject: mobile DTMF timing
Message-ID: <20120126180201.6c1e9cff@mail.auth.se>

Hi list, hi Jolly,

I just tested the DTMF support on a real network and discovered that the timeout of 70ms for receiving the Start DTMF ACK is too short. The consequences are many repeated Start DTMF messages, never received ACKs and no tone is played. 
Using a timer value of 170ms in mnccms.c:759 fixes this for that network.
Unfortunately I didn't found - or overlooked - a mandatory timeout value for Ta in TS 23.014 which the MSC has to meet. 
Is that undefined in the standard and where came the 70ms from?


Regards,
  Mad



From andreas at eversberg.eu  Fri Jan 27 13:15:39 2012
From: andreas at eversberg.eu (Andreas Eversberg)
Date: Fri, 27 Jan 2012 14:15:39 +0100
Subject: mobile DTMF timing
In-Reply-To: <20120126180201.6c1e9cff@mail.auth.se>
References: <20120126180201.6c1e9cff@mail.auth.se>
Message-ID: <4F22A37B.8020301@eversberg.eu>

mad wrote:
> Hi list, hi Jolly,
>
> I just tested the DTMF support on a real network and discovered that the timeout of 70ms for receiving the Start DTMF ACK is too short. The consequences are many repeated Start DTMF messages, never received ACKs and no tone is played. 
> Using a timer value of 170ms in mnccms.c:759 fixes this for that network.
> Unfortunately I didn't found - or overlooked - a mandatory timeout value for Ta in TS 23.014 which the MSC has to meet. 
> Is that undefined in the standard and where came the 70ms from?
>
>
> Regards,
>   Mad
>
>   
hi mad,

the timeout is set after the reception of the DTMF ACK. this ensures
that the time to play the tone is at least 70ms. then the tones is
stooped, and after it has been acked, the timer is started again to wait
for the next tone. then the next tone, if any, is sent.

see: http://en.wikipedia.org/wiki/Dual-tone_multi-frequency_signaling

can you send me a log of the process when you send the dtmf tones?

regards,

andreas




From mad at auth.se  Fri Jan 27 18:07:38 2012
From: mad at auth.se (mad)
Date: Fri, 27 Jan 2012 19:07:38 +0100
Subject: mobile DTMF timing
In-Reply-To: <4F22A37B.8020301@eversberg.eu>
Message-ID: <20120127180738.21dd2b2b@mail.auth.se>

Hi Andreas!
> 
> the timeout is set after the reception of the DTMF ACK. this ensures
> that the time to play the tone is at least 70ms. then the tones is
> stooped, and after it has been acked, the timer is started again to wait
> for the next tone. then the next tone, if any, is sent.
> 
> see: http://en.wikipedia.org/wiki/Dual-tone_multi-frequency_signaling
> 
> can you send me a log of the process when you send the dtmf tones?
> 
Ok, I misread the dtmf_statemachine, I understand the 70ms are the minimum length a DTMF tone should last according to convention.
Actually I re-tested with this value and - of course - now it does work as expected. 
Unfortunately I don't have the layer23 log anymore, but my first test calls rather seem to had some issue with the MSC not confirming the Start DTMF frame. 
While changing the tone length value, the MSC might got responsive to that again and after testing, I draw a false conclusion. :)


Regards,
  Mad
 



From vogelchr at vogel.cx  Sat Jan 28 20:40:30 2012
From: vogelchr at vogel.cx (Christian Vogel)
Date: Sat, 28 Jan 2012 21:40:30 +0100
Subject: [PATCH 1/2] printf: Hack to support gcc printf() optimization
Message-ID: <20120128204030.GB7600@vogel.cx>

gcc optimizes printf("x") to putchar('x'), but we #define
putchar to be something else.

Now lib/printf.c defines a putchar() function that always prints
on the sercomm port, it will break uart consoles.
---
 src/target/firmware/lib/printf.c |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/src/target/firmware/lib/printf.c b/src/target/firmware/lib/printf.c
index a4fc687..887b5b4 100644
--- a/src/target/firmware/lib/printf.c
+++ b/src/target/firmware/lib/printf.c
@@ -17,3 +17,19 @@ int printf(const char *fmt, ...)
 
 	return r;
 }
+
+/* HACK: we define putchar to be sercomm_putchar,
+ * but gcc optimizes printf("x") to putchar('x')
+ * so it will generate a call to the function putchar().
+ *
+ * Note: This will break non-sercomm consoles!
+ */
+
+#ifdef putchar
+#undef putchar
+
+int putchar(char c){
+	return sercomm_putchar(c);
+}
+
+#endif
-- 
1.7.0.4




From vogelchr at vogel.cx  Sat Jan 28 20:41:35 2012
From: vogelchr at vogel.cx (Christian Vogel)
Date: Sat, 28 Jan 2012 21:41:35 +0100
Subject: [PATCH 2/2] rearm_timer: update run-time and re-activate
Message-ID: <20120128204135.GC7600@vogel.cx>

Instead of calling schedule_timer() inside the
callback (which causes list-reshuffling) just call
rearm_timer(self,milliseconds) to have it re-execute
after the specified time.
---
 src/target/firmware/comm/timer.c         |    6 ++++++
 src/target/firmware/include/comm/timer.h |    1 +
 2 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/src/target/firmware/comm/timer.c b/src/target/firmware/comm/timer.c
index 6a649ae..d135e24 100644
--- a/src/target/firmware/comm/timer.c
+++ b/src/target/firmware/comm/timer.c
@@ -63,6 +63,12 @@ void schedule_timer(struct osmo_timer_list *timer, int milliseconds)
 	add_timer(timer);
 }
 
+void rearm_timer(struct osmo_timer_list *timer, int milliseconds)
+{
+	timer->expires = jiffies + ((milliseconds * TIMER_HZ) / 1000);
+	timer->active = 1;
+}
+
 void del_timer(struct osmo_timer_list *timer)
 {
 	if (timer->in_list) {
diff --git a/src/target/firmware/include/comm/timer.h b/src/target/firmware/include/comm/timer.h
index db7d1a5..6ca51b5 100644
--- a/src/target/firmware/include/comm/timer.h
+++ b/src/target/firmware/include/comm/timer.h
@@ -60,6 +60,7 @@ extern unsigned long volatile jiffies;
  */
 void add_timer(struct osmo_timer_list *timer);
 void schedule_timer(struct osmo_timer_list *timer, int miliseconds);
+void rearm_timer(struct osmo_timer_list *timer, int milliseconds);
 void del_timer(struct osmo_timer_list *timer);
 int timer_pending(struct osmo_timer_list *timer);
 
-- 
1.7.0.4




From laforge at gnumonks.org  Sun Jan 29 08:33:24 2012
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 29 Jan 2012 09:33:24 +0100
Subject: [PATCH 2/2] rearm_timer: update run-time and re-activate
In-Reply-To: <20120128204135.GC7600@vogel.cx>
References: <20120128204135.GC7600@vogel.cx>
Message-ID: <20120129083324.GG1379@prithivi.gnumonks.org>

Hi Christian,

On Sat, Jan 28, 2012 at 09:41:35PM +0100, Christian Vogel wrote:
> Instead of calling schedule_timer() inside the
> callback (which causes list-reshuffling) just call
> rearm_timer(self,milliseconds) to have it re-execute
> after the specified time.

this may make sense from an efficiency point of view, but it is a
deviation from the API we use in libosmocore.  Which brings me to the
next issue:  The osmo_timer_* rename has not yet been applied to the
timer implementation.

If other developers agree to introduce a 'rearm_timer', then we should
also add it to osmo_timer_rearm() to libosmocore for consistency.

Also, it might be a good idea to verify that it actually is in the list,
at least durinig DEBUG / development builds.

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 dario.lombardo at libero.it  Tue Jan 31 08:52:41 2012
From: dario.lombardo at libero.it (Dario Lombardo)
Date: Tue, 31 Jan 2012 09:52:41 +0100
Subject: RSSI firmware
Message-ID: <CAOYJJfvAMyBZJcZobt3R4LvComRLqYhPDKxAFO4YzBNnXZ4qMw@mail.gmail.com>

Hello everybody
I'm trying to use the RSSI firmware on a c118 and c115. Both of them give
me this error

host/osmocon/osmocon -p /dev/ttyUSB0 -m c123xor
target/firmware/board/compal_e88/rssi.compalram.bin
got 1 bytes from modem, data looks like: 04  .
got 1 bytes from modem, data looks like: 81  .
got 5 bytes from modem, data looks like: 1b f6 02 00 41  ....A
got 1 bytes from modem, data looks like: 01  .
got 1 bytes from modem, data looks like: 40  @
Received PROMPT1 from phone, responding with CMD
The maximum file size is 64kBytes (65535 bytes)
read_file(target/firmware/board/compal_e88/rssi.compalram.bin) failed with
-27

Do I need to do something different to load this FW or simply my phones
have no enough room for it?

Thanks for your help.
Dario.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20120131/fae65310/attachment.htm>

From peter at stuge.se  Tue Jan 31 09:45:09 2012
From: peter at stuge.se (Peter Stuge)
Date: Tue, 31 Jan 2012 10:45:09 +0100
Subject: RSSI firmware
In-Reply-To: <CAOYJJfvAMyBZJcZobt3R4LvComRLqYhPDKxAFO4YzBNnXZ4qMw@mail.gmail.com>
References: <CAOYJJfvAMyBZJcZobt3R4LvComRLqYhPDKxAFO4YzBNnXZ4qMw@mail.gmail.com>
Message-ID: <20120131094509.19337.qmail@stuge.se>

Dario Lombardo wrote:
> The maximum file size is 64kBytes (65535 bytes)
> 
> Do I need to do something different to load this FW

Have you tried removing that size check?


//Peter



From dario.lombardo at libero.it  Tue Jan 31 10:05:31 2012
From: dario.lombardo at libero.it (Dario Lombardo)
Date: Tue, 31 Jan 2012 11:05:31 +0100
Subject: RSSI firmware
In-Reply-To: <20120131094509.19337.qmail@stuge.se>
References: <CAOYJJfvAMyBZJcZobt3R4LvComRLqYhPDKxAFO4YzBNnXZ4qMw@mail.gmail.com>
	<20120131094509.19337.qmail@stuge.se>
Message-ID: <CAOYJJfttLayV9fJy6wpQJZR9veO8zk0yeNR8AMvdW3emNbHhMw@mail.gmail.com>

That's what I get after removing that check

host/osmocon/osmocon -p /dev/ttyUSB0 -m c123xor
target/firmware/board/compal_e88/rssi.compalram.bin
got 2 bytes from modem, data looks like: 04 81  ..
got 5 bytes from modem, data looks like: 1b f6 02 00 41  ....A
got 1 bytes from modem, data looks like: 01  .
got 1 bytes from modem, data looks like: 40  @
Received PROMPT1 from phone, responding with CMD
read_file(target/firmware/board/compal_e88/rssi.compalram.bin):
file_size=80916, hdr_len=4, dnload_len=80923
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: 02  .
got 1 bytes from modem, data looks like: 43  C
Received PROMPT2 from phone, starting download
handle_write(): 4096 bytes (4096/80923)
handle_write(): 4096 bytes (8192/80923)
handle_write(): 4096 bytes (12288/80923)
handle_write(): 4096 bytes (16384/80923)
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: 45  E
got 1 bytes from modem, data looks like: 53  S
got 1 bytes from modem, data looks like: 16  .
Received DOWNLOAD NACK from phone, something went wrong :(
got 1 bytes from modem, data looks like: 66  f
got 1 bytes from modem, data looks like: 74  t
got 1 bytes from modem, data looks like: 6d  m
got 1 bytes from modem, data looks like: 74  t
got 1 bytes from modem, data looks like: 6f  o
got 1 bytes from modem, data looks like: 6f  o
got 1 bytes from modem, data looks like: 6c  l
Received FTMTOOL from phone, ramloader has aborted
got 1 bytes from modem, data looks like: 65  e
got 1 bytes from modem, data looks like: 72  r
got 1 bytes from modem, data looks like: 72  r
got 1 bytes from modem, data looks like: 6f  o
got 1 bytes from modem, data looks like: 72  r


On Tue, Jan 31, 2012 at 10:45 AM, Peter Stuge <peter at stuge.se> wrote:

> Dario Lombardo wrote:
> > The maximum file size is 64kBytes (65535 bytes)
> >
> > Do I need to do something different to load this FW
>
> Have you tried removing that size check?
>
>
> //Peter
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20120131/e692689f/attachment.htm>

From mardnh at gmx.de  Tue Jan 31 12:21:34 2012
From: mardnh at gmx.de (Martin Hauke)
Date: Tue, 31 Jan 2012 13:21:34 +0100
Subject: RSSI firmware
In-Reply-To: <CAOYJJfvAMyBZJcZobt3R4LvComRLqYhPDKxAFO4YzBNnXZ4qMw@mail.gmail.com>
References: <CAOYJJfvAMyBZJcZobt3R4LvComRLqYhPDKxAFO4YzBNnXZ4qMw@mail.gmail.com>
Message-ID: <4F27DCCE.8030504@gmx.de>

On 31.01.2012 09:52, Dario Lombardo wrote:
> Do I need to do something different to load this FW or simply my phones
> have no enough room for it?

the normal compal ramloader cannot be used with firmware sizes larger 
than 64k.
http://bb.osmocom.org/trac/wiki/CompalRamloader

Instead of loading 'monitor.compalram.bin' directly you have to load 
'loader.compalram.bin' and then use 'osmocon memload' to load the 
monitor-app into the RAM.

In my case (C123) i have to use this:
load the second stage bootloader, load monitor-app into highram and then 
jump to the proper address

sudo ./osmocon -p /dev/ttyUSB0 -m c123xor 
../../target/firmware/board/compal_e88/loader.compalram.bin
sudo ./osmoload memload 0x820000 
../../target/firmware/board/compal_e88/monitor.highram.bin
sudo ./osmoload jump 0x820000

Thanks to Andreas Eversberg who had provided the crucial tip.

Martin



From steve at steve-m.de  Tue Jan 31 12:58:01 2012
From: steve at steve-m.de (Steve Markgraf)
Date: Tue, 31 Jan 2012 13:58:01 +0100
Subject: RSSI firmware
In-Reply-To: <4F27DCCE.8030504@gmx.de>
References: <CAOYJJfvAMyBZJcZobt3R4LvComRLqYhPDKxAFO4YzBNnXZ4qMw@mail.gmail.com>
	<4F27DCCE.8030504@gmx.de>
Message-ID: <4F27E559.80601@steve-m.de>

Hi,

On 31.01.2012 13:21, Martin Hauke wrote:
> Instead of loading 'monitor.compalram.bin' directly you have to load
> 'loader.compalram.bin' and then use 'osmocon memload' to load the
> monitor-app into the RAM.

What also works is chainloading the binary with the Calypso romloader:

./osmocon -p /dev/ttyUSB0 -m c123xor -c
../../target/firmware/board/compal_e88/monitor.highram.bin
../../target/firmware/board/compal_e88/chainload.compalram.bin

But for that the size check in osmocon needs to be removed, as discussed
earlier in this thread.

Regards,
Steve