From laforge at gnumonks.org  Thu Dec  1 07:35:50 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 1 Dec 2011 08:35:50 +0100
Subject: cygwin / socklen_t (was Re: small problem)
In-Reply-To: <53BEABE19E8F48BB9F08CE8A1E3AE008@Maite>
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
	<1322089184-27512-8-git-send-email-alexander.huemer@xx.vu>
	<E317F36D6A484576B3C2E5FE1195D42F@Maite>
	<20111129064800.GE5843@prithivi.gnumonks.org>
	<53BEABE19E8F48BB9F08CE8A1E3AE008@Maite>
Message-ID: <20111201073550.GX16931@prithivi.gnumonks.org>

Hi!

Just a minor note:

On Tue, Nov 29, 2011 at 09:02:48AM +0100, Juantxi wrote:

> need socket.c change:
> int osmo_sockaddr_is_local(struct sockaddr *addr, unsigned int addrlen)

cygwin also defines a 'socklen_t', and it would be a better fix to
#include the file that provides this definition...

-- 
- 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 juantxipazos at yahoo.es  Thu Dec  1 01:10:58 2011
From: juantxipazos at yahoo.es (Juantxi)
Date: Thu, 1 Dec 2011 02:10:58 +0100
Subject: cygwin / socklen_t (was Re: small problem)
References: <1322089184-27512-1-git-send-email-alexander.huemer@xx.vu>
	<1322089184-27512-8-git-send-email-alexander.huemer@xx.vu>
	<E317F36D6A484576B3C2E5FE1195D42F@Maite>
	<20111129064800.GE5843@prithivi.gnumonks.org>
	<53BEABE19E8F48BB9F08CE8A1E3AE008@Maite>
	<20111201073550.GX16931@prithivi.gnumonks.org>
Message-ID: <D8582D069C1B45D39D6D3389B0479A69@Maite>

Thank you for your answers
but I do not answer if that's a hassle for you

months ago you had this version of gnuarm:

binutils-2.15, gcc-3.4.3-c-c++-java, newlib-1.12.0, insight-6.1, TAR BZ2 
[56.0MB]

is valid to compile today osmocom?


----- Original Message ----- 
From: "Harald Welte" <laforge at gnumonks.org>
To: "Juantxi" <juantxipazos at yahoo.es>
Cc: <baseband-devel at lists.osmocom.org>
Sent: Thursday, December 01, 2011 8:35 AM
Subject: cygwin / socklen_t (was Re: small problem)


> Hi!
>
> Just a minor note:
>
> On Tue, Nov 29, 2011 at 09:02:48AM +0100, Juantxi wrote:
>
>> need socket.c change:
>> int osmo_sockaddr_is_local(struct sockaddr *addr, unsigned int addrlen)
>
> cygwin also defines a 'socklen_t', and it would be a better fix to
> #include the file that provides this definition...
>
> -- 
> - Harald Welte <laforge at gnumonks.org> 
> http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. 
> A6) 




From laforge at gnumonks.org  Sun Dec  4 21:14:04 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 4 Dec 2011 22:14:04 +0100
Subject: RFC: Osmocom developer workshop 2012
Message-ID: <20111204211404.GC28966@prithivi.gnumonks.org>

Hi!

Thinking a bit more about timing, it seems that the second half of March
is a good idea.

April is a bad idea, at least for the first two weeks, as this is easter
holiday time in a lot of German states.  This will cause lots of
tourists, as well as full hotels, trains, flights, etc.

So I'd propose something like four days in the second half of march.
Should we try to overlap/extend a weekend?  I guess this would help
people with e regular dayjob, as not as many holidays would be required.

If there are no objections in the next 48 hours, I will talk to C-Base
about availability during that timeframe.

Regards,
	Harald

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



From 246tnt at gmail.com  Sun Dec  4 21:47:41 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Sun, 4 Dec 2011 22:47:41 +0100
Subject: RFC: Osmocom developer workshop 2012
In-Reply-To: <20111204211404.GC28966@prithivi.gnumonks.org>
References: <20111204211404.GC28966@prithivi.gnumonks.org>
Message-ID: <CAHL+j09hcp3zeN_YfsKwkHTC0X0E29HWk7pmb-=kpsugTK25vg@mail.gmail.com>

Hi,

> So I'd propose something like four days in the second half of march.
> Should we try to overlap/extend a weekend? ?I guess this would help
> people with e regular dayjob, as not as many holidays would be required.

Yes, over the weekend would be nice I think.

So this makes it 18-21 March or 25-28 March.

> If there are no objections in the next 48 hours, I will talk to C-Base
> about availability during that timeframe.

Cheers,

    Sylvain



From 246tnt at gmail.com  Sun Dec  4 22:03:45 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Sun, 4 Dec 2011 23:03:45 +0100
Subject: RFC: Osmocom developer workshop 2012
In-Reply-To: <CAHL+j09hcp3zeN_YfsKwkHTC0X0E29HWk7pmb-=kpsugTK25vg@mail.gmail.com>
References: <20111204211404.GC28966@prithivi.gnumonks.org>
	<CAHL+j09hcp3zeN_YfsKwkHTC0X0E29HWk7pmb-=kpsugTK25vg@mail.gmail.com>
Message-ID: <CAHL+j09M8-oooxUknbjXZ7fHEGX+7QDekbYjzhnfDGmQvidzUw@mail.gmail.com>

> So this makes it 18-21 March or 25-28 March.

Well, as usual I didn't miss the opportunity of making a fool of
myself by using the 2011 calendar ... (thanks steve for pointing this
out)

So make this 16-19 | 23-26 then.

Cheers,

    Sylvain



From roh at hyte.de  Mon Dec  5 00:27:30 2011
From: roh at hyte.de (Joachim Steiger)
Date: Mon, 05 Dec 2011 01:27:30 +0100
Subject: RFC: Osmocom developer workshop 2012
In-Reply-To: <20111204211404.GC28966@prithivi.gnumonks.org>
References: <20111204211404.GC28966@prithivi.gnumonks.org>
Message-ID: <4EDC0FF2.5000506@hyte.de>

Harald Welte wrote:
> Hi!
> 
> Thinking a bit more about timing, it seems that the second half of March
> is a good idea.

> So I'd propose something like four days in the second half of march.
> Should we try to overlap/extend a weekend?  I guess this would help
> people with e regular dayjob, as not as many holidays would be required.
> 
> If there are no objections in the next 48 hours, I will talk to C-Base
> about availability during that timeframe.

since there are not that many participants listed in the wiki and after
talking to my fellow hackers here at raumfahrtagentur i can state that
we would be happy to host the developer meeting in our location.

we haven't yet planned any events in 2012, so there should be no other
event blocking certain dates.

greetings

--

roh




From laforge at gnumonks.org  Mon Dec  5 04:20:56 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 5 Dec 2011 05:20:56 +0100
Subject: RFC: Osmocom developer workshop 2012
In-Reply-To: <4EDC0FF2.5000506@hyte.de>
References: <20111204211404.GC28966@prithivi.gnumonks.org>
	<4EDC0FF2.5000506@hyte.de>
Message-ID: <20111205042056.GG28966@prithivi.gnumonks.org>

Hi roh,

On Mon, Dec 05, 2011 at 01:27:30AM +0100, Joachim Steiger wrote:
> Harald Welte wrote:
> > Hi!
> > 
> > Thinking a bit more about timing, it seems that the second half of March
> > is a good idea.
> 
> > So I'd propose something like four days in the second half of march.
> > Should we try to overlap/extend a weekend?  I guess this would help
> > people with e regular dayjob, as not as many holidays would be required.
> > 
> > If there are no objections in the next 48 hours, I will talk to C-Base
> > about availability during that timeframe.
> 
> since there are not that many participants listed in the wiki and after
> talking to my fellow hackers here at raumfahrtagentur i can state that
> we would be happy to host the developer meeting in our location.

thanks a lot for bringing this up.

However, I wouldn't use the wiki as a reference.  Given that we are > 10
people at 28C3, I would also suspect something like 10 to 15 (max)
people at the OsmoDevCon.

Without any offence, I also think that c-base is easier to reach, more
centrally located [some people may want to go out at night], and might
have better facilities in terms of a separate 'conference room' style
setup.

Having said that, I don't want to rule out Raumfahrtagentur yet.  Those
are just my initial thoughts.

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



From laforge at gnumonks.org  Wed Dec 14 21:53:54 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 14 Dec 2011 22:53:54 +0100
Subject: RFC: Osmocom developer workshop 2012
In-Reply-To: <20111125081520.GL1730@prithivi.gnumonks.org>
References: <20111125081520.GL1730@prithivi.gnumonks.org>
Message-ID: <20111214215354.GB4696@prithivi.gnumonks.org>

Hi all,

following up my original mail:

On Fri, Nov 25, 2011 at 09:15:20AM +0100, Harald Welte wrote:
> 	I'd like to have a Osmocom developer workshop

I'd like to follow-up with one more posting to all our mailing lists:

The remaining discussion is happening at the openbsc at lists.osmocom.org
list, and it is not cross-posted to all other lists.

We've meanwhile settled on a date (March 23rd through 26th) and a venue
in Berlin.

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 evandersh at gmail.com  Fri Dec  2 19:28:16 2011
From: evandersh at gmail.com (Ethan Brown)
Date: Fri, 2 Dec 2011 15:28:16 -0400
Subject: About DSP API
Message-ID: <CAF5ehqammmNCPVMibNRBe44aap46U3vV39ACuE2CqMXz=QD7JA@mail.gmail.com>

Do any of you know where can I find documentation about the DSP API used in
Osmocom?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111202/a75e5b6d/attachment.htm>

From 246tnt at gmail.com  Fri Dec  2 21:50:31 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Fri, 2 Dec 2011 22:50:31 +0100
Subject: About DSP API
In-Reply-To: <CAF5ehqammmNCPVMibNRBe44aap46U3vV39ACuE2CqMXz=QD7JA@mail.gmail.com>
References: <CAF5ehqammmNCPVMibNRBe44aap46U3vV39ACuE2CqMXz=QD7JA@mail.gmail.com>
Message-ID: <CAHL+j0_Q+JLLkphbBaM4+LMnuUBDaneU1P_sS+oQdz2C0Mo4Gw@mail.gmail.com>

> Do any of you know where can I find documentation about the DSP API used in
> Osmocom?

Nowhere. There is no doc. (Not that we have access to anyway ... I'm
sure Texas Instruments has it ...)



From evandersh at gmail.com  Sat Dec  3 12:11:57 2011
From: evandersh at gmail.com (Ethan Brown)
Date: Sat, 3 Dec 2011 08:11:57 -0400
Subject: About DSP API
In-Reply-To: <CAHL+j0_Q+JLLkphbBaM4+LMnuUBDaneU1P_sS+oQdz2C0Mo4Gw@mail.gmail.com>
References: <CAF5ehqammmNCPVMibNRBe44aap46U3vV39ACuE2CqMXz=QD7JA@mail.gmail.com>
	<CAHL+j0_Q+JLLkphbBaM4+LMnuUBDaneU1P_sS+oQdz2C0Mo4Gw@mail.gmail.com>
Message-ID: <CAF5ehqYaz7NactL5qs8rX6Av349z5so1pAWB_x6wwgpOR-HMgg@mail.gmail.com>

So, does the dsp_api.ndb->a_du_0 member hold the audio data to be send to
the other peer, or that's something else?  How can I capture the audio data
(after codec), make a slight modification to that data, and send it to the
other mobile?  I can see that AUDIO_TX_TRAFFIC_REQ/AUDIO_RX_TRAFFIC_IND
audio mode were created for that purpose, but I'm not sure how to use
that.  Do I need to make the modifications I need on gsm_recv_voice and
gsm_send_voice (voice.c)?

On Fri, Dec 2, 2011 at 5:50 PM, Sylvain Munaut <246tnt at gmail.com> wrote:

> > Do any of you know where can I find documentation about the DSP API used
> in
> > Osmocom?
>
> Nowhere. There is no doc. (Not that we have access to anyway ... I'm
> sure Texas Instruments has it ...)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111203/0a18181c/attachment.htm>

From 246tnt at gmail.com  Sat Dec  3 15:31:51 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Sat, 3 Dec 2011 16:31:51 +0100
Subject: About DSP API
In-Reply-To: <CAF5ehqYaz7NactL5qs8rX6Av349z5so1pAWB_x6wwgpOR-HMgg@mail.gmail.com>
References: <CAF5ehqammmNCPVMibNRBe44aap46U3vV39ACuE2CqMXz=QD7JA@mail.gmail.com>
	<CAHL+j0_Q+JLLkphbBaM4+LMnuUBDaneU1P_sS+oQdz2C0Mo4Gw@mail.gmail.com>
	<CAF5ehqYaz7NactL5qs8rX6Av349z5so1pAWB_x6wwgpOR-HMgg@mail.gmail.com>
Message-ID: <CAHL+j09VN-dZhW=6ZPVvZFCvW0k6XFo3ria0RTSDaPhyGDO6XA@mail.gmail.com>

> So, does the dsp_api.ndb->a_du_0 member hold the audio data to be send to
> the other peer, or that's something else?? How can I capture the audio data
> (after codec), make a slight modification to that data, and send it to the
> other mobile?

Mmm, I'm not sure you can do that. You can 'peek' at the audio, but by
the time you see the data there it may have been processed into TCH
frames already.

When in 'PLAY_MODE', it will take data to send from a_du_1  (in
TCH/F). So it's possible that the data from the microphone would still
be in a_du_0 and so you could put it in play mode, do your
modification by copying data from a_du_0 to a_du_1 ...

As I said : No documentation so it's all been done by error / trial,
you'd have to try :)

> I can see that AUDIO_TX_TRAFFIC_REQ/AUDIO_RX_TRAFFIC_IND
> audio mode were created for that purpose, but I'm not sure how to use that.
> Do I need to make the modifications I need on gsm_recv_voice and
> gsm_send_voice (voice.c)?

Those are used to RX and TX frames from the host (rather than the
phone directly). The only way to use them "as is" is to interface
osmocom-bb with LCR (not sure if there is a howto ...).
But as you saw in voice.c you could modify the code yourself to feed
data if need be ...

Cheers,

    Sylvain



From evandersh at gmail.com  Tue Dec  6 13:45:58 2011
From: evandersh at gmail.com (Ethan Brown)
Date: Tue, 6 Dec 2011 09:45:58 -0400
Subject: About DSP API
In-Reply-To: <CAHL+j09VN-dZhW=6ZPVvZFCvW0k6XFo3ria0RTSDaPhyGDO6XA@mail.gmail.com>
References: <CAF5ehqammmNCPVMibNRBe44aap46U3vV39ACuE2CqMXz=QD7JA@mail.gmail.com>
	<CAHL+j0_Q+JLLkphbBaM4+LMnuUBDaneU1P_sS+oQdz2C0Mo4Gw@mail.gmail.com>
	<CAF5ehqYaz7NactL5qs8rX6Av349z5so1pAWB_x6wwgpOR-HMgg@mail.gmail.com>
	<CAHL+j09VN-dZhW=6ZPVvZFCvW0k6XFo3ria0RTSDaPhyGDO6XA@mail.gmail.com>
Message-ID: <CAF5ehqa8wYEEAD4=wK+9-frEe9OVs1E6a=dR7RvzoHL_nXqZ5A@mail.gmail.com>

Thank you, Sylvain
If I put the DSP in play mode (B_PLAY_UL) I can send some garbage on
dsp_api.ndb->a_du_1 and the peer will play it, but if I peek the data at
dsp_api.ndb->a_du_0, it's null filled.  If I revert the play mode, I can
see data on dsp_api.ndb->a_du_0.

I will keep trying to find out why DSP API works this way.  I just wanted
to ask if some of you know why this happens.



On Sat, Dec 3, 2011 at 11:31 AM, Sylvain Munaut <246tnt at gmail.com> wrote:

> > So, does the dsp_api.ndb->a_du_0 member hold the audio data to be send to
> > the other peer, or that's something else?  How can I capture the audio
> data
> > (after codec), make a slight modification to that data, and send it to
> the
> > other mobile?
>
> Mmm, I'm not sure you can do that. You can 'peek' at the audio, but by
> the time you see the data there it may have been processed into TCH
> frames already.
>
> When in 'PLAY_MODE', it will take data to send from a_du_1  (in
> TCH/F). So it's possible that the data from the microphone would still
> be in a_du_0 and so you could put it in play mode, do your
> modification by copying data from a_du_0 to a_du_1 ...
>
> As I said : No documentation so it's all been done by error / trial,
> you'd have to try :)
>
> > I can see that AUDIO_TX_TRAFFIC_REQ/AUDIO_RX_TRAFFIC_IND
> > audio mode were created for that purpose, but I'm not sure how to use
> that.
> > Do I need to make the modifications I need on gsm_recv_voice and
> > gsm_send_voice (voice.c)?
>
> Those are used to RX and TX frames from the host (rather than the
> phone directly). The only way to use them "as is" is to interface
> osmocom-bb with LCR (not sure if there is a howto ...).
> But as you saw in voice.c you could modify the code yourself to feed
> data if need be ...
>
> Cheers,
>
>    Sylvain
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111206/a4e789aa/attachment.htm>

From 246tnt at gmail.com  Tue Dec  6 14:04:59 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Tue, 6 Dec 2011 15:04:59 +0100
Subject: About DSP API
In-Reply-To: <CAF5ehqa8wYEEAD4=wK+9-frEe9OVs1E6a=dR7RvzoHL_nXqZ5A@mail.gmail.com>
References: <CAF5ehqammmNCPVMibNRBe44aap46U3vV39ACuE2CqMXz=QD7JA@mail.gmail.com>
	<CAHL+j0_Q+JLLkphbBaM4+LMnuUBDaneU1P_sS+oQdz2C0Mo4Gw@mail.gmail.com>
	<CAF5ehqYaz7NactL5qs8rX6Av349z5so1pAWB_x6wwgpOR-HMgg@mail.gmail.com>
	<CAHL+j09VN-dZhW=6ZPVvZFCvW0k6XFo3ria0RTSDaPhyGDO6XA@mail.gmail.com>
	<CAF5ehqa8wYEEAD4=wK+9-frEe9OVs1E6a=dR7RvzoHL_nXqZ5A@mail.gmail.com>
Message-ID: <CAHL+j09ZKha8GnXzJqCdR-TkpAKb7SVOQ-O88JBXU5T5=n4M4w@mail.gmail.com>

> If I put the DSP in play mode (B_PLAY_UL) I can send some garbage on
> dsp_api.ndb->a_du_1 and the peer will play it, but if I peek the data at
> dsp_api.ndb->a_du_0, it's null filled.? If I revert the play mode, I can see
> data on dsp_api.ndb->a_du_0.

I guess the play ul both enables the tx from a_du_1 and also disables
the audio compression stuff ...
You can try to modify the content of a_du_0 at the time of the
interrupt without leaving but I'm not sure it'll work or if the dsp
will already have taken the data ...

Cheers,

    Sylvain



From evandersh at gmail.com  Thu Dec  8 19:21:47 2011
From: evandersh at gmail.com (Ethan Brown)
Date: Thu, 8 Dec 2011 15:21:47 -0400
Subject: About DSP API
In-Reply-To: <CAHL+j09ZKha8GnXzJqCdR-TkpAKb7SVOQ-O88JBXU5T5=n4M4w@mail.gmail.com>
References: <CAF5ehqammmNCPVMibNRBe44aap46U3vV39ACuE2CqMXz=QD7JA@mail.gmail.com>
	<CAHL+j0_Q+JLLkphbBaM4+LMnuUBDaneU1P_sS+oQdz2C0Mo4Gw@mail.gmail.com>
	<CAF5ehqYaz7NactL5qs8rX6Av349z5so1pAWB_x6wwgpOR-HMgg@mail.gmail.com>
	<CAHL+j09VN-dZhW=6ZPVvZFCvW0k6XFo3ria0RTSDaPhyGDO6XA@mail.gmail.com>
	<CAF5ehqa8wYEEAD4=wK+9-frEe9OVs1E6a=dR7RvzoHL_nXqZ5A@mail.gmail.com>
	<CAHL+j09ZKha8GnXzJqCdR-TkpAKb7SVOQ-O88JBXU5T5=n4M4w@mail.gmail.com>
Message-ID: <CAF5ehqaukmj4Gzq+ViVgNwtw6eax2rYYtbwnzCLi2WQisJvhKg@mail.gmail.com>

I decided to test another route, writing on socket /tmp/ms_mncc_1 data with
the gsm_data_frame structure.  I see that this socket expects GSM FR data,
and setting the audiomode to AUDIO_TX_TRAFFIC_REQ | AUDIO_RX_TRAFFIC_IND.
It seems that the peer receives this data, but I cannot hear the audio
correctly.  Am I missing something? Was this feature tested before?



On Tue, Dec 6, 2011 at 10:04 AM, Sylvain Munaut <246tnt at gmail.com> wrote:

> > If I put the DSP in play mode (B_PLAY_UL) I can send some garbage on
> > dsp_api.ndb->a_du_1 and the peer will play it, but if I peek the data at
> > dsp_api.ndb->a_du_0, it's null filled.  If I revert the play mode, I can
> see
> > data on dsp_api.ndb->a_du_0.
>
> I guess the play ul both enables the tx from a_du_1 and also disables
> the audio compression stuff ...
> You can try to modify the content of a_du_0 at the time of the
> interrupt without leaving but I'm not sure it'll work or if the dsp
> will already have taken the data ...
>
> Cheers,
>
>    Sylvain
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111208/33493b7c/attachment.htm>

From 246tnt at gmail.com  Thu Dec  8 19:27:52 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Thu, 8 Dec 2011 20:27:52 +0100
Subject: About DSP API
In-Reply-To: <CAF5ehqaukmj4Gzq+ViVgNwtw6eax2rYYtbwnzCLi2WQisJvhKg@mail.gmail.com>
References: <CAF5ehqammmNCPVMibNRBe44aap46U3vV39ACuE2CqMXz=QD7JA@mail.gmail.com>
	<CAHL+j0_Q+JLLkphbBaM4+LMnuUBDaneU1P_sS+oQdz2C0Mo4Gw@mail.gmail.com>
	<CAF5ehqYaz7NactL5qs8rX6Av349z5so1pAWB_x6wwgpOR-HMgg@mail.gmail.com>
	<CAHL+j09VN-dZhW=6ZPVvZFCvW0k6XFo3ria0RTSDaPhyGDO6XA@mail.gmail.com>
	<CAF5ehqa8wYEEAD4=wK+9-frEe9OVs1E6a=dR7RvzoHL_nXqZ5A@mail.gmail.com>
	<CAHL+j09ZKha8GnXzJqCdR-TkpAKb7SVOQ-O88JBXU5T5=n4M4w@mail.gmail.com>
	<CAF5ehqaukmj4Gzq+ViVgNwtw6eax2rYYtbwnzCLi2WQisJvhKg@mail.gmail.com>
Message-ID: <CAHL+j0_jj7w5XK2SiKgS-jSLAc9w4ruvGdg=VSpFxiOQrVZa5g@mail.gmail.com>

> I decided to test another route, writing on socket /tmp/ms_mncc_1 data with
> the gsm_data_frame structure.? I see that this socket expects GSM FR data,
> and setting the audiomode to AUDIO_TX_TRAFFIC_REQ | AUDIO_RX_TRAFFIC_IND.
> It seems that the peer receives this data, but I cannot hear the audio
> correctly.? Am I missing something? Was this feature tested before?

Yes, it's used in the LCR integration and works fine, so you must be
doing something wrong.

Note that you must make sure to disable EFR support in the config or
the network might assign you a EFR channel and you send FR data which
is not going to work out ...

Cheers,

   Sylvain



From evandersh at gmail.com  Fri Dec  9 13:01:04 2011
From: evandersh at gmail.com (Ethan Brown)
Date: Fri, 9 Dec 2011 09:01:04 -0400
Subject: About DSP API
In-Reply-To: <CAHL+j0_jj7w5XK2SiKgS-jSLAc9w4ruvGdg=VSpFxiOQrVZa5g@mail.gmail.com>
References: <CAF5ehqammmNCPVMibNRBe44aap46U3vV39ACuE2CqMXz=QD7JA@mail.gmail.com>
	<CAHL+j0_Q+JLLkphbBaM4+LMnuUBDaneU1P_sS+oQdz2C0Mo4Gw@mail.gmail.com>
	<CAF5ehqYaz7NactL5qs8rX6Av349z5so1pAWB_x6wwgpOR-HMgg@mail.gmail.com>
	<CAHL+j09VN-dZhW=6ZPVvZFCvW0k6XFo3ria0RTSDaPhyGDO6XA@mail.gmail.com>
	<CAF5ehqa8wYEEAD4=wK+9-frEe9OVs1E6a=dR7RvzoHL_nXqZ5A@mail.gmail.com>
	<CAHL+j09ZKha8GnXzJqCdR-TkpAKb7SVOQ-O88JBXU5T5=n4M4w@mail.gmail.com>
	<CAF5ehqaukmj4Gzq+ViVgNwtw6eax2rYYtbwnzCLi2WQisJvhKg@mail.gmail.com>
	<CAHL+j0_jj7w5XK2SiKgS-jSLAc9w4ruvGdg=VSpFxiOQrVZa5g@mail.gmail.com>
Message-ID: <CAF5ehqbvcFXtz5MwtSKTxNxuNB0FshO9SHNWzGS_+4bjxJ-v2Q@mail.gmail.com>

As you said, I was doing something wrong.  Sorry, my mistake.  It works
perfectly now.

By the way, I wanted to include AMR support.  What should I do to make this
possible?


On Thu, Dec 8, 2011 at 3:27 PM, Sylvain Munaut <246tnt at gmail.com> wrote:

> > I decided to test another route, writing on socket /tmp/ms_mncc_1 data
> with
> > the gsm_data_frame structure.  I see that this socket expects GSM FR
> data,
> > and setting the audiomode to AUDIO_TX_TRAFFIC_REQ | AUDIO_RX_TRAFFIC_IND.
> > It seems that the peer receives this data, but I cannot hear the audio
> > correctly.  Am I missing something? Was this feature tested before?
>
> Yes, it's used in the LCR integration and works fine, so you must be
> doing something wrong.
>
> Note that you must make sure to disable EFR support in the config or
> the network might assign you a EFR channel and you send FR data which
> is not going to work out ...
>
> Cheers,
>
>   Sylvain
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111209/6823e530/attachment.htm>

From 246tnt at gmail.com  Fri Dec  9 13:03:54 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Fri, 9 Dec 2011 14:03:54 +0100
Subject: About DSP API
In-Reply-To: <CAF5ehqbvcFXtz5MwtSKTxNxuNB0FshO9SHNWzGS_+4bjxJ-v2Q@mail.gmail.com>
References: <CAF5ehqammmNCPVMibNRBe44aap46U3vV39ACuE2CqMXz=QD7JA@mail.gmail.com>
	<CAHL+j0_Q+JLLkphbBaM4+LMnuUBDaneU1P_sS+oQdz2C0Mo4Gw@mail.gmail.com>
	<CAF5ehqYaz7NactL5qs8rX6Av349z5so1pAWB_x6wwgpOR-HMgg@mail.gmail.com>
	<CAHL+j09VN-dZhW=6ZPVvZFCvW0k6XFo3ria0RTSDaPhyGDO6XA@mail.gmail.com>
	<CAF5ehqa8wYEEAD4=wK+9-frEe9OVs1E6a=dR7RvzoHL_nXqZ5A@mail.gmail.com>
	<CAHL+j09ZKha8GnXzJqCdR-TkpAKb7SVOQ-O88JBXU5T5=n4M4w@mail.gmail.com>
	<CAF5ehqaukmj4Gzq+ViVgNwtw6eax2rYYtbwnzCLi2WQisJvhKg@mail.gmail.com>
	<CAHL+j0_jj7w5XK2SiKgS-jSLAc9w4ruvGdg=VSpFxiOQrVZa5g@mail.gmail.com>
	<CAF5ehqbvcFXtz5MwtSKTxNxuNB0FshO9SHNWzGS_+4bjxJ-v2Q@mail.gmail.com>
Message-ID: <CAHL+j08Uf2A6+hwh_R9U-tPrWkrh5mvq0pv6y17J_CcOBVAoCA@mail.gmail.com>

> By the way, I wanted to include AMR support.? What should I do to make this
> possible?

No idea ... that's why it's not done, I have not yet analyzed how the
DSP must be driven to handle AMR.
I think it doesn't support it natively (or at least is bugged) and
some DSP patches must be loaded.

Cheers,

     Sylvain



From evandersh at gmail.com  Tue Dec 13 20:31:35 2011
From: evandersh at gmail.com (Ethan Brown)
Date: Tue, 13 Dec 2011 16:31:35 -0400
Subject: About DSP API
In-Reply-To: <CAF5ehqbvcFXtz5MwtSKTxNxuNB0FshO9SHNWzGS_+4bjxJ-v2Q@mail.gmail.com>
References: <CAF5ehqammmNCPVMibNRBe44aap46U3vV39ACuE2CqMXz=QD7JA@mail.gmail.com>
	<CAHL+j0_Q+JLLkphbBaM4+LMnuUBDaneU1P_sS+oQdz2C0Mo4Gw@mail.gmail.com>
	<CAF5ehqYaz7NactL5qs8rX6Av349z5so1pAWB_x6wwgpOR-HMgg@mail.gmail.com>
	<CAHL+j09VN-dZhW=6ZPVvZFCvW0k6XFo3ria0RTSDaPhyGDO6XA@mail.gmail.com>
	<CAF5ehqa8wYEEAD4=wK+9-frEe9OVs1E6a=dR7RvzoHL_nXqZ5A@mail.gmail.com>
	<CAHL+j09ZKha8GnXzJqCdR-TkpAKb7SVOQ-O88JBXU5T5=n4M4w@mail.gmail.com>
	<CAF5ehqaukmj4Gzq+ViVgNwtw6eax2rYYtbwnzCLi2WQisJvhKg@mail.gmail.com>
	<CAHL+j0_jj7w5XK2SiKgS-jSLAc9w4ruvGdg=VSpFxiOQrVZa5g@mail.gmail.com>
	<CAF5ehqbvcFXtz5MwtSKTxNxuNB0FshO9SHNWzGS_+4bjxJ-v2Q@mail.gmail.com>
Message-ID: <CAF5ehqbJv76fszERt37ETmJXzL-zmDaTj=tMhFHxoZmMXH9Yjw@mail.gmail.com>

Inside the socket client, I don't have access to the osmocom_ms instance,
so I cannot make/answer calls.  How did you do that in your LCR integration?


On Fri, Dec 9, 2011 at 9:01 AM, Ethan Brown <evandersh at gmail.com> wrote:

> As you said, I was doing something wrong.  Sorry, my mistake.  It works
> perfectly now.
>
> By the way, I wanted to include AMR support.  What should I do to make
> this possible?
>
>
>
> On Thu, Dec 8, 2011 at 3:27 PM, Sylvain Munaut <246tnt at gmail.com> wrote:
>
>> > I decided to test another route, writing on socket /tmp/ms_mncc_1 data
>> with
>> > the gsm_data_frame structure.  I see that this socket expects GSM FR
>> data,
>> > and setting the audiomode to AUDIO_TX_TRAFFIC_REQ |
>> AUDIO_RX_TRAFFIC_IND.
>> > It seems that the peer receives this data, but I cannot hear the audio
>> > correctly.  Am I missing something? Was this feature tested before?
>>
>> Yes, it's used in the LCR integration and works fine, so you must be
>> doing something wrong.
>>
>> Note that you must make sure to disable EFR support in the config or
>> the network might assign you a EFR channel and you send FR data which
>> is not going to work out ...
>>
>> Cheers,
>>
>>   Sylvain
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111213/f0152a5a/attachment.htm>

From rm.engineer84 at gmail.com  Sat Dec  3 05:38:02 2011
From: rm.engineer84 at gmail.com (R M)
Date: Sat, 3 Dec 2011 11:08:02 +0530
Subject: Script for parsing boot loader into COFF
Message-ID: <CADKJHGadgds=p0YD_H4Q8o1Bp_sZY2KHsOFRbu8MKAd+8juXSA@mail.gmail.com>

Hi,

Is there a script for parsing the boot loader code into a COFF format
so that it can be loaded into IDA?

Regards,
RM



From rm.engineer84 at gmail.com  Sat Dec 10 06:34:23 2011
From: rm.engineer84 at gmail.com (R M)
Date: Sat, 10 Dec 2011 12:04:23 +0530
Subject: gnuarm version
In-Reply-To: <CBEF7518D64D4B72A6A0DA7ECCD0E74F@Maite>
References: <CADKJHGadgds=p0YD_H4Q8o1Bp_sZY2KHsOFRbu8MKAd+8juXSA@mail.gmail.com>
	<CBEF7518D64D4B72A6A0DA7ECCD0E74F@Maite>
Message-ID: <CADKJHGbmbf_U5_ddK47yvY5P+G-QCJh6erVpLHXn-o-xh+WsDA@mail.gmail.com>

Hi,

I am using this version of GNU Arm.

http://www.gnuarm.com/bu-2.15_gcc-3.4.3-c-c++-java_nl-1.12.0_gi-6.1.exe

Regards,
RM

On 12/4/11, Juantxi <juantxipazos at yahoo.es> wrote:
>
> Hello, what version of gnuarm uses?
> thank
>



From rsreeraj at gmail.com  Fri Dec  9 05:06:19 2011
From: rsreeraj at gmail.com (Sreeraj R)
Date: Fri, 9 Dec 2011 05:06:19 +0000 (UTC)
Subject: Trouble with C117 while using osmocon
Message-ID: <loom.20111209T055523-839@post.gmane.org>

Hi all,

I am just a beginner and is using the following hardware 

Phone : C117
Serial Adapter : CP2102 based


The propt message that I am getting is different compared to that mentioned in
the wiki (http://bb.osmocom.org/trac/wiki/CompalRamloader).


Command: ./osmocon -d t -p /dev/ttyUSB0 -m c123
../../target/firmware/board/compal_e88/loader.compalram.bin

Gives me the following data

{00,f1,01,72,82,bf,7d,fd,7f,00,a6,51,d2,51,0a,3a,02,4d,a3,a3,da,00,00}


Entire log after short power button key press is http://pastebin.com/AqcNm6dq.

Can anyone give some pointers, or did I go wrong somewhere. The wiki specifies
C117 board is similar to C123.


regards
Sreeraj R




From kugghjul at gmail.com  Sun Dec 11 20:54:38 2011
From: kugghjul at gmail.com (Christoffer Jerkeby)
Date: Sun, 11 Dec 2011 21:54:38 +0100
Subject: Trouble with C117 while using osmocon
In-Reply-To: <loom.20111209T055523-839@post.gmane.org>
References: <loom.20111209T055523-839@post.gmane.org>
Message-ID: <CAPvAUgJwDeNNHLpfiUZtchFpDHoKVwwLyfev3JZU8fkvaqkDbg@mail.gmail.com>

On Fri, Dec 9, 2011 at 6:06 AM, Sreeraj R <rsreeraj at gmail.com> wrote:
> Hi all,
>
> I am just a beginner and is using the following hardware
>
> Phone : C117
> Serial Adapter : CP2102 based
>
>
> The propt message that I am getting is different compared to that mentioned in
> the wiki (http://bb.osmocom.org/trac/wiki/CompalRamloader).
>
>
> Command: ./osmocon -d t -p /dev/ttyUSB0 -m c123
> ../../target/firmware/board/compal_e88/loader.compalram.bin
>
> Gives me the following data
>
> {00,f1,01,72,82,bf,7d,fd,7f,00,a6,51,d2,51,0a,3a,02,4d,a3,a3,da,00,00}
>
>
> Entire log after short power button key press is http://pastebin.com/AqcNm6dq.
>
> Can anyone give some pointers, or did I go wrong somewhere. The wiki specifies
> C117 board is similar to C123.
>
>
> regards
> Sreeraj R
>
>

Hi Sreeraj,
I suggest you try
 ./osmocon -d t -p /dev/ttyUSB0 -m c123xor
../../target/firmware/board/compal_e88/loader.compalram.bin

Best regards Kugg



From laforge at gnumonks.org  Sun Dec 11 10:54:27 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 11 Dec 2011 11:54:27 +0100
Subject: Creating a real usable phone using OsmocomBB
Message-ID: <20111211105427.GE10252@prithivi.gnumonks.org>

Hi all!

I've mentioned this before, and I keep getting back to it:  With all the
great work that has been put into OsmocomBB, we are "at an arms lengh"
away from being able to create a true Free Software mobile phone.

We already have the hardware drivers, protocol stack and even the
'mobile' program which can be used for making and receiving voice calls
and sending/receiving SMS text messages on real GSM networks!

While the journey has been a lot of fun and everyone involved has
learned a lot, we have so far been catering mstly about "scratching our
own itch", i.e. implementing what we needed in order to satisfy our ego
and/or to implement the ideas we had regarding cellular security.

I believe we cannot miss the bigger opportunity here to put our code
into bigger use:  To create something like a very simple GSM feature
phone.

When we look at various areas of computing like Operating Systems or Web
browsers, Free Software is not just "the hobby project catching up" with
the vendors of proprietary software.  Free Software can compete.

In the cellular area, we have still not managed to even implement the
most basic GSM feature phone that existed 15 years ago using proprietary
software.  We need to work on closing that gap.  We need to show that a
small community of Free Software developers can actually implement what
teams of hundreds of engineers did in a proprietary software setting 15
years ago - despite all the lack of hardware documentation or any kind
of positive feedback from the cellular chipset, handset or operator
industry.

If we don't at least get a 2G GSM cellphone implemented now, it will
probably not happen before 2G networks become insignificant in large
parts of the world.

This is a call to all hands, please support this project!

Regards,
	Harald

== Technical aspects ==

I believe the first major decision is whether we focus on

1) the Openmoko FreeRunner / Neo1973 phones

Advantages:
 * large screen for UI with bells and whistles
 * lots of RAM and Flash, even script languages or compilation on the
   device itself possible
 * second processor doesn't require us to run stack + UI on once CPU
 * easier debugging of UI
 * various existing telephony middleware and phone dialer UI projects
   of which hopefully one could be recycled

or

2) the Motorola/Compal C1xx phones

Advantags:
 * many more phones available, even after our software is released
 * lower cost of the individual phone
 * less power consumption due to only one small ARM7 core
 * smaller screen also means less fancy UI requirements

Problems:
 * full stack + UI needs to run on calypso (L2/L3) and we'd probably
   some kind of RTOS like NuttX instead of our 'bare iron' code.

==== What we need in any case ====

 * power management on the baseband processor through all of the stack
   (though it's mostly a driver/L1 kind of thing)

== Summary / Opinion ==

It seems like running the OsmocomBB layer1 + 'mobile' as-is on the
Openmoko baseband + application processor might be the quicker road to
progress.  Sure, the power consumption will be horrible as the AP will
have to be woken up for each and every SI message, neighbor cell
measurment or paging request that ew see comining in in our paging group
(even in idle mode).  But then, there is always the negative impact of
using a relatively complex system, with two processors, a complex
software stack (Linux, X11, toolkit, etc.) on one of them, etc.

On the other hand, using the C1xx phones will result in a much more
widely available result.  The phones can still be bought in batches of
1,000 units, and they are small enough for lots of people to carry
around.  Furthermore, the battery lifetime is far beyond anything you
would ever be able to achieve on a power-hungry smartphone platform.  I
believe it would be the "smart' solution, as it means we need to get
everything integrated, etc.

What does the community on this list think?  Which way shoul we go?

But maybe the best thing is to actually stat working on the power
management aspects, as we will need them in both cases.

Happy hacking,
	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 peter at stuge.se  Sun Dec 11 14:11:50 2011
From: peter at stuge.se (Peter Stuge)
Date: Sun, 11 Dec 2011 15:11:50 +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: <20111211141150.2274.qmail@stuge.se>

Harald Welte wrote:
> What does the community on this list think?  Which way shoul we go?

I think that C1xx is the only worthwhile road.

Both phones need more work to get something useful, and I think that
making it as widely available and usable as possible is highest
priority, to boost the project by also getting users involved.

Currently the threshold is high to run osmocomBB. If there is a phone
which can dial out and receive incoming calls then the threshold is
very low. Almost no UI and no features needed. Only start with the
most basic functionality: calling, and then go from there.


//Peter



From andreas at eversberg.eu  Sun Dec 11 17:18:45 2011
From: andreas at eversberg.eu (Andreas Eversberg)
Date: Sun, 11 Dec 2011 18:18:45 +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: <4EE4E5F5.1050805@eversberg.eu>

hi,

Harald Welte wrote:
> Hi all!
>
> I've mentioned this before, and I keep getting back to it:  With all the
> great work that has been put into OsmocomBB, we are "at an arms lengh"
> away from being able to create a true Free Software mobile phone.
>
> We already have the hardware drivers, protocol stack and even the
> 'mobile' program which can be used for making and receiving voice calls
> and sending/receiving SMS text messages on real GSM networks!
>
> While the journey has been a lot of fun and everyone involved has
> learned a lot, we have so far been catering mstly about "scratching our
> own itch", i.e. implementing what we needed in order to satisfy our ego
> and/or to implement the ideas we had regarding cellular security.
>
>   
indeed it is allot of phun. the implementation of security features
(like imsi catcher detection) is not really a problem, but therefore we
must define them first.
> I believe we cannot miss the bigger opportunity here to put our code
> into bigger use:  To create something like a very simple GSM feature
> phone.
>
>   
we should not only try to implement a 10 euro phone. this is what we
already had before the osmocombb project. osmocombb should focus on
things that normal phones doesn't have. but yes, it must first do the
basic stuff correctly, like being stable and usable like a GSM phone.
otherwise it is a pain using it. i think of two issues still left for
the stack: reliable syncing and handover.
> When we look at various areas of computing like Operating Systems or Web
> browsers, Free Software is not just "the hobby project catching up" with
> the vendors of proprietary software.  Free Software can compete.
>
> In the cellular area, we have still not managed to even implement the
> most basic GSM feature phone that existed 15 years ago using proprietary
> software.  We need to work on closing that gap.  We need to show that a
> small community of Free Software developers can actually implement what
> teams of hundreds of engineers did in a proprietary software setting 15
> years ago - despite all the lack of hardware documentation or any kind
> of positive feedback from the cellular chipset, handset or operator
> industry.
>
> If we don't at least get a 2G GSM cellphone implemented now, it will
> probably not happen before 2G networks become insignificant in large
> parts of the world.
>
> This is a call to all hands, please support this project!
>
> Regards,
> 	Harald
>
> == Technical aspects ==
>
> I believe the first major decision is whether we focus on
>
> 1) the Openmoko FreeRunner / Neo1973 phones
>
> Advantages:
>  * large screen for UI with bells and whistles
>  * lots of RAM and Flash, even script languages or compilation on the
>    device itself possible
>  * second processor doesn't require us to run stack + UI on once CPU
>  * easier debugging of UI
>  * various existing telephony middleware and phone dialer UI projects
>    of which hopefully one could be recycled
>
> or
>
> 2) the Motorola/Compal C1xx phones
>
> Advantags:
>  * many more phones available, even after our software is released
>  * lower cost of the individual phone
>  * less power consumption due to only one small ARM7 core
>  * smaller screen also means less fancy UI requirements
>
> Problems:
>  * full stack + UI needs to run on calypso (L2/L3) and we'd probably
>    some kind of RTOS like NuttX instead of our 'bare iron' code.
>
>   
i prefer this one, because it will have (and already has) a much larger
audience. if we would have the RTOS working and finished the UI (as well
as defining an MMI interface for communication with the stack), we
should have almost made it.
> ==== What we need in any case ====
>
>  * power management on the baseband processor through all of the stack
>    (though it's mostly a driver/L1 kind of thing)
>
> == Summary / Opinion ==
>
> It seems like running the OsmocomBB layer1 + 'mobile' as-is on the
> Openmoko baseband + application processor might be the quicker road to
> progress.  Sure, the power consumption will be horrible as the AP will
> have to be woken up for each and every SI message, neighbor cell
> measurment or paging request that ew see comining in in our paging group
> (even in idle mode).  But then, there is always the negative impact of
> using a relatively complex system, with two processors, a complex
> software stack (Linux, X11, toolkit, etc.) on one of them, etc.
>
> On the other hand, using the C1xx phones will result in a much more
> widely available result.  The phones can still be bought in batches of
> 1,000 units, and they are small enough for lots of people to carry
> around.  Furthermore, the battery lifetime is far beyond anything you
> would ever be able to achieve on a power-hungry smartphone platform.  I
> believe it would be the "smart' solution, as it means we need to get
> everything integrated, etc.
>
> What does the community on this list think?  Which way shoul we go?
>
> But maybe the best thing is to actually stat working on the power
> management aspects, as we will need them in both cases.
>
> Happy hacking,
> 	Harald
>   
we should define all that at 28c3, so we can start to complete it.

regards,

andreas



From sweisman at pobox.com  Mon Dec 12 10:17:35 2011
From: sweisman at pobox.com (Scott Weisman)
Date: Mon, 12 Dec 2011 12:17:35 +0200
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <20111211105427.GE10252@prithivi.gnumonks.org>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
Message-ID: <CAMhwr9dH0_p++4Naaxpj6d+09Pn+XpyzwgXn=HDRx1pabqwrOg@mail.gmail.com>

I also vote for the C1xx phones. I didn't realize they were still available
in such large quantities, which itself is a huge advantage IMHO. But the
simpler development model and needed software stack, along with major power
advantages seems too good to ignore.

I don't know if the previous discussion/decision regarding NuttX stands.
This (limited) RTOS benchmark looked interesting to me:

http://www.yagarto.de/projects/rtoscomp/index.html

I am very interested in contributing what I can to such a project.

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111212/53faa1c4/attachment.htm>

From laforge at gnumonks.org  Mon Dec 12 11:07:43 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 12 Dec 2011 12:07:43 +0100
Subject: Nuttx / Performance (was Re: Creating a real usable phone using
	OsmocomBB)
In-Reply-To: <CAMhwr9dH0_p++4Naaxpj6d+09Pn+XpyzwgXn=HDRx1pabqwrOg@mail.gmail.com>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<CAMhwr9dH0_p++4Naaxpj6d+09Pn+XpyzwgXn=HDRx1pabqwrOg@mail.gmail.com>
Message-ID: <20111212110743.GN10252@prithivi.gnumonks.org>

Hi Scott,

On Mon, Dec 12, 2011 at 12:17:35PM +0200, Scott Weisman wrote:

> I don't know if the previous discussion/decision regarding NuttX stands.
> This (limited) RTOS benchmark looked interesting to me:
> 
> http://www.yagarto.de/projects/rtoscomp/index.html

I am not overly worried by that.  From my point of view, aspects like
the POSIX-style API and the general structure of the code have much more
significance than absolute scheduler latency.

It would be great to see some work on getting more of our existing
drivers for the calypso ported into NuttX.

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 acassis at gmail.com  Mon Dec 12 11:15:52 2011
From: acassis at gmail.com (Alan Carvalho de Assis)
Date: Mon, 12 Dec 2011 09:15:52 -0200
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <CAMhwr9dH0_p++4Naaxpj6d+09Pn+XpyzwgXn=HDRx1pabqwrOg@mail.gmail.com>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<CAMhwr9dH0_p++4Naaxpj6d+09Pn+XpyzwgXn=HDRx1pabqwrOg@mail.gmail.com>
Message-ID: <CAG4Y6eTgSUtbxQdweWDAQi-iamrO1rsfk2OG6eO9p9ofQ-8-dw@mail.gmail.com>

Hi Scott,

On 12/12/11, Scott Weisman <sweisman at pobox.com> wrote:
> I also vote for the C1xx phones. I didn't realize they were still available
> in such large quantities, which itself is a huge advantage IMHO. But the
> simpler development model and needed software stack, along with major power
> advantages seems too good to ignore.
>
> I don't know if the previous discussion/decision regarding NuttX stands.
> This (limited) RTOS benchmark looked interesting to me:
>
> http://www.yagarto.de/projects/rtoscomp/index.html
>

Please don't confuse Nut/OS with NuttX, they are different RTOS.
NuttX is a kind of POSIX/"Unix-like" for micro-controller.

> I am very interested in contributing what I can to such a project.
>

You can start looking the NuttX port for Calypso micro-controller
which Stefan (ichgeh at l--putt.de) developed.

Best Regards,

Alan



From msokolov at ivan.Harhan.ORG  Mon Dec 12 17:12:08 2011
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Mon, 12 Dec 2011 17:12:08 GMT
Subject: Creating a real usable phone using OsmocomBB
Message-ID: <1112121712.AA10641@ivan.Harhan.ORG>

Hello folks,

Just my two cents: one factor that seems to be overlooked in the C1xx
vs. GTA0x decision is the support for different GSM RF bands.  From my
reading of the OsmocomBB wiki, it appears that all those C1xx phones
support only EGSM and DCS1800 bands, but not PCS1900.  It seems like
most current active developers are located in world regions where EGSM
and DCS1800 bands are used, but in my area the only usable GSM band is
PCS1900, or maybe GSM850 too: haven't been able to try the latter as I
don't have any devices that support it.

OTOH, my Neo Freerunner (which is currently doing shelf duty as a
paperweight lacking functional source-enabled Calypso fw) supports the
PCS1900 band in addition to EGSM and DCS1800.

But if the community goes the C1xx route and produces GPL code that
runs fully on the Calypso, no PC needed, does power mgmt and
implements some UI on the Calypso-controlled LCD and keypad, I expect
no difficulty with taking that code, replacing the Calypso-based UI
with some simple protocol for interfacing with the UI over the modem
UART (maybe not the same as the infamous AT command interface, but
doing the same job on the same level of abstraction), and running it
on my GTA02, hence I'm not complaining.

As far as the power management etc advantages of the simpler phones
without an application processor: does anyone know of any basic
Leonardo-style phones which are like the famous C1xx, but support the
PCS1900 band, are physically available, and documented no worse than
C1xx in terms of the availability of schematics and docs for display
and other non-Calypso components?

The fact that C1xx phones can be bought in 1000 unit quantities is
great news for those living in areas with EGSM/DCS1800 services, but
doesn't do much good for those living in PCS1900/GSM850 lands...

MS



From lokkju at gmail.com  Mon Dec 12 17:27:46 2011
From: lokkju at gmail.com (Lokkju Brennr)
Date: Mon, 12 Dec 2011 09:27:46 -0800
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <1112121712.AA10641@ivan.Harhan.ORG>
References: <1112121712.AA10641@ivan.Harhan.ORG>
Message-ID: <CAOCX9DmpuqUndGuWB6WZbsDad+9RBxieh0LXeX00A=_DeE9RdA@mail.gmail.com>

I'm running a C117 on PCS1900 with no problems, in the USA.  It was an
old Tracfone I fixed the bootloader on and re-flashed.  I have no idea
if PCS1900 type C117 phones are widely available - but I do know they
exist.  Interestingly, I recently saw one in the local Walgreens for
$20, brand new.

Loki

On Mon, Dec 12, 2011 at 9:12 AM, Michael Sokolov
<msokolov at ivan.harhan.org> wrote:
> Hello folks,
>
> Just my two cents: one factor that seems to be overlooked in the C1xx
> vs. GTA0x decision is the support for different GSM RF bands. ?From my
> reading of the OsmocomBB wiki, it appears that all those C1xx phones
> support only EGSM and DCS1800 bands, but not PCS1900. ?It seems like
> most current active developers are located in world regions where EGSM
> and DCS1800 bands are used, but in my area the only usable GSM band is
> PCS1900, or maybe GSM850 too: haven't been able to try the latter as I
> don't have any devices that support it.
>
> OTOH, my Neo Freerunner (which is currently doing shelf duty as a
> paperweight lacking functional source-enabled Calypso fw) supports the
> PCS1900 band in addition to EGSM and DCS1800.
>
> But if the community goes the C1xx route and produces GPL code that
> runs fully on the Calypso, no PC needed, does power mgmt and
> implements some UI on the Calypso-controlled LCD and keypad, I expect
> no difficulty with taking that code, replacing the Calypso-based UI
> with some simple protocol for interfacing with the UI over the modem
> UART (maybe not the same as the infamous AT command interface, but
> doing the same job on the same level of abstraction), and running it
> on my GTA02, hence I'm not complaining.
>
> As far as the power management etc advantages of the simpler phones
> without an application processor: does anyone know of any basic
> Leonardo-style phones which are like the famous C1xx, but support the
> PCS1900 band, are physically available, and documented no worse than
> C1xx in terms of the availability of schematics and docs for display
> and other non-Calypso components?
>
> The fact that C1xx phones can be bought in 1000 unit quantities is
> great news for those living in areas with EGSM/DCS1800 services, but
> doesn't do much good for those living in PCS1900/GSM850 lands...
>
> MS
>



From GNUtoo at no-log.org  Mon Dec 12 18:02:21 2011
From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli)
Date: Mon, 12 Dec 2011 19:02:21 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <1112121712.AA10641@ivan.Harhan.ORG>
References: <1112121712.AA10641@ivan.Harhan.ORG>
Message-ID: <201112121902.21249.GNUtoo@no-log.org>

>But if the community goes the C1xx route and produces GPL code that
>runs fully on the Calypso, no PC needed, does power mgmt and
>implements some UI on the Calypso-controlled LCD and keypad, I expect
>no difficulty with taking that code, replacing the Calypso-based UI
>with some simple protocol for interfacing with the UI over the modem
>UART (maybe not the same as the infamous AT command interface, but
>doing the same job on the same level of abstraction), and running it
>on my GTA02, hence I'm not complaining.
That's exactly what I was thinking about, since running the layer23 on the 
Application CPU is not a so good idea, it renders the phone usable only for a 
small period of time(since,in that configuration, you cannot suspend the AP 
CPU because it has to run the telephony code).

>maybe not the same as the infamous AT command interface
Why is AT bad? what other protocol do you propose?

Denis.



From peter at stuge.se  Mon Dec 12 18:18:43 2011
From: peter at stuge.se (Peter Stuge)
Date: Mon, 12 Dec 2011 19:18:43 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <201112121902.21249.GNUtoo@no-log.org>
References: <1112121712.AA10641@ivan.Harhan.ORG>
	<201112121902.21249.GNUtoo@no-log.org>
Message-ID: <20111212181843.3870.qmail@stuge.se>

Denis 'GNUtoo' Carikli wrote:
> Why is AT bad?

Um, no, it's the other way around. AT is 30 years of horrible.


//Peter



From laforge at gnumonks.org  Mon Dec 12 21:02:47 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 12 Dec 2011 22:02:47 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <201112121902.21249.GNUtoo@no-log.org>
References: <1112121712.AA10641@ivan.Harhan.ORG>
	<201112121902.21249.GNUtoo@no-log.org>
Message-ID: <20111212210247.GZ10252@prithivi.gnumonks.org>

On Mon, Dec 12, 2011 at 07:02:21PM +0100, Denis 'GNUtoo' Carikli wrote:

> >maybe not the same as the infamous AT command interface
>
> Why is AT bad? what other protocol do you propose?

I've you've ever tried to write any fully-fledged AT command parser
(like the various incarnations of Openmoko gsmd/libgsm, fso gsmd, ofono,
etc.) then you know why.  It's nice for human beings, but it's horribly
overloaded for any machine based parsing, especially if you only have
one channels and need to deal with unsolicited results overlapping with
synchronous request/response type commands at the same time.

In any interface where you have asynchronous signalling, each command
should be tagged with an identifier, which is contained in the
corresponding response.  This is done e.g. very nicely in IMAP and you
can have as many outstanding/executing commands in parallel as you want,
without any difficulty parsing the responses whatsoever.

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 suraev at stud.ntnu.no  Tue Dec 13 04:56:08 2011
From: suraev at stud.ntnu.no (suraev at stud.ntnu.no)
Date: Tue, 13 Dec 2011 12:56:08 +0800
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <201112121902.21249.GNUtoo@no-log.org>
References: <1112121712.AA10641@ivan.Harhan.ORG>
	<201112121902.21249.GNUtoo@no-log.org>
Message-ID: <4EE6DAE8.5000706@stud.ntnu.no>

13.12.2011 02:02, Denis 'GNUtoo' Carikli ?????:

> That's exactly what I was thinking about, since running the layer23 on the 
> Application CPU is not a so good idea, it renders the phone usable only for a 
> small period of time(since,in that configuration, you cannot suspend the AP 
> CPU because it has to run the telephony code).

I've probably missed this part of discussion. Could you re-iterate: is it technical
limitations that prevent us from porting layer23 onto calypso BP or it's simply lack
of manpower?

bye,
Max.




From laforge at gnumonks.org  Tue Dec 13 07:32:03 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 13 Dec 2011 08:32:03 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <4EE6DAE8.5000706@stud.ntnu.no>
References: <1112121712.AA10641@ivan.Harhan.ORG>
	<201112121902.21249.GNUtoo@no-log.org>
	<4EE6DAE8.5000706@stud.ntnu.no>
Message-ID: <20111213073203.GN10252@prithivi.gnumonks.org>

On Tue, Dec 13, 2011 at 12:56:08PM +0800, suraev at stud.ntnu.no wrote:
> 13.12.2011 02:02, Denis 'GNUtoo' Carikli ?????:
> 
> > That's exactly what I was thinking about, since running the layer23 on the 
> > Application CPU is not a so good idea, it renders the phone usable only for a 
> > small period of time(since,in that configuration, you cannot suspend the AP 
> > CPU because it has to run the telephony code).
> 
> I've probably missed this part of discussion. Could you re-iterate: is it technical
> limitations that prevent us from porting layer23 onto calypso BP or it's simply lack
> of manpower?

It's really only the latter.  There are probably a number of external
references that need to be resolved (we don't have a full libc/libm in
the target), as well as issues related to unaligned accesses.

Also, the current 'mobile' code probably needs to be split into the
actual 'logic' code (L2, L3, cell [re]selection, etc.) and the
'application' part (the VTY based interface we have right now).  The
higher-level interface of the 'logic' code and the application needs to
be defined, probably as some kind of message queue of primitives.

A first incremental step could be to move L2 (LAPDm) into the phone and
use RSLms to talk with the existing PC-based 'mobile' application over
the UART.

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 peter at stuge.se  Tue Dec 13 08:30:17 2011
From: peter at stuge.se (Peter Stuge)
Date: Tue, 13 Dec 2011 09:30:17 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <20111213073203.GN10252@prithivi.gnumonks.org>
References: <1112121712.AA10641@ivan.Harhan.ORG>
	<201112121902.21249.GNUtoo@no-log.org>
	<4EE6DAE8.5000706@stud.ntnu.no>
	<20111213073203.GN10252@prithivi.gnumonks.org>
Message-ID: <20111213083017.29844.qmail@stuge.se>

Harald Welte wrote:
> There are probably a number of external references that need to be
> resolved (we don't have a full libc/libm in the target),

Look at libpayload. It's a libc-like project for writing coreboot
payloads, ie. running on bare metal, and implements some of libc
either on it's own or by borrowing from other OS projects. BSD
license.


> Also, the current 'mobile' code probably needs to be split into the
> actual 'logic' code (L2, L3, cell [re]selection, etc.) and the
> 'application' part (the VTY based interface we have right now).

I think this is a great first step, and a very easy way to get
involved for someone who is not yet so experienced with GSM, but
already has a good understanding of C on PCs.


//Peter



From andreas at eversberg.eu  Tue Dec 13 08:36:59 2011
From: andreas at eversberg.eu (Andreas Eversberg)
Date: Tue, 13 Dec 2011 09:36:59 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <20111213083017.29844.qmail@stuge.se>
References: <1112121712.AA10641@ivan.Harhan.ORG>	<201112121902.21249.GNUtoo@no-log.org>	<4EE6DAE8.5000706@stud.ntnu.no>	<20111213073203.GN10252@prithivi.gnumonks.org>
	<20111213083017.29844.qmail@stuge.se>
Message-ID: <4EE70EAB.5080100@eversberg.eu>

Peter Stuge wrote:
>> Also, the current 'mobile' code probably needs to be split into the
>> > actual 'logic' code (L2, L3, cell [re]selection, etc.) and the
>> > 'application' part (the VTY based interface we have right now).
>>     
> I think this is a great first step, and a very easy way to get
> involved for someone who is not yet so experienced with GSM, but
> already has a good understanding of C on PCs.
>   
i think it would help if we look at the VTY commands and what they tell
the stack and what they receive as response. i suggest defining "MMI_*"
message primitves for an interface. other applications, like the UI
could use and connect to the same interface. (possibly other
applications like AT command interface) i suggest defining the if at 28c3.



From peter at stuge.se  Tue Dec 13 08:50:02 2011
From: peter at stuge.se (Peter Stuge)
Date: Tue, 13 Dec 2011 09:50:02 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <4EE70EAB.5080100@eversberg.eu>
References: <1112121712.AA10641@ivan.Harhan.ORG>
	<201112121902.21249.GNUtoo@no-log.org>
	<4EE6DAE8.5000706@stud.ntnu.no>
	<20111213073203.GN10252@prithivi.gnumonks.org>
	<20111213083017.29844.qmail@stuge.se>
	<4EE70EAB.5080100@eversberg.eu>
Message-ID: <20111213085002.2117.qmail@stuge.se>

Andreas Eversberg wrote:
> Peter Stuge wrote:
> >> Also, the current 'mobile' code probably needs to be split into the
> >> > actual 'logic' code (L2, L3, cell [re]selection, etc.) and the
> >> > 'application' part (the VTY based interface we have right now).
> >>     
> > I think this is a great first step, and a very easy way to get
> > involved for someone who is not yet so experienced with GSM, but
> > already has a good understanding of C on PCs.
> >   
> i think it would help if we look at the VTY commands and what they tell
> the stack and what they receive as response. i suggest defining "MMI_*"
> message primitves for an interface. other applications, like the UI
> could use and connect to the same interface. (possibly other
> applications like AT command interface) i suggest defining the if at 28c3.

+1


//Peter



From suraev at stud.ntnu.no  Tue Dec 13 09:07:41 2011
From: suraev at stud.ntnu.no (suraev at stud.ntnu.no)
Date: Tue, 13 Dec 2011 17:07:41 +0800
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <20111213083017.29844.qmail@stuge.se>
References: <1112121712.AA10641@ivan.Harhan.ORG>
	<201112121902.21249.GNUtoo@no-log.org>
	<4EE6DAE8.5000706@stud.ntnu.no>
	<20111213073203.GN10252@prithivi.gnumonks.org>
	<20111213083017.29844.qmail@stuge.se>
Message-ID: <4EE715DD.9020409@stud.ntnu.no>

13.12.2011 16:30, Peter Stuge ?????:

> Look at libpayload. It's a libc-like project for writing coreboot
> payloads, ie. running on bare metal, and implements some of libc
> either on it's own or by borrowing from other OS projects. BSD
> license.

There's also uClibc port http://linux-c6x.org/wiki/index.php/Main_Page for another TI
dsp. But I'm not sure how much efforts it'll take to port it to calypso and others.

cheers,
Max.



From msokolov at ivan.Harhan.ORG  Mon Dec 12 18:43:13 2011
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Mon, 12 Dec 2011 18:43:13 GMT
Subject: Creating a real usable phone using OsmocomBB
Message-ID: <1112121843.AA10946@ivan.Harhan.ORG>

Denis 'GNUtoo' Carikli <GNUtoo at no-log.org> wrote:

> That's exactly what I was thinking about, since running the layer23 on the 
> Application CPU is not a so good idea, it renders the phone usable only for a 
> small period of time(since,in that configuration, you cannot suspend the AP 
> CPU because it has to run the telephony code).

It's obvious that running layer23 on the AP is a *terrible* idea.  It
needs to move into the Calypso (or other BP) before there can be any
serious thought of OsmocomBB truly replacing the existing proprietary
BP code.  However, my own skill & knowledge level is nowhere close to
what would be needed for that job.

But I was thinking of taking the current sorry state of things
(layer23 external to the BP) and making it run on a self-contained
GTA02: have the Samsung AP run layer23 instead of acting as a pass-
through to a PC, then add some UI to it: the very same UI I wanted to
implement in the first place before I got sidetracked to the baseband
issues.  The result of that would be having the GTA02 act as a
"normal" feature phone in every way except for draining the battery in
a couple of hours while doing nothing.  The last aspect would make it
rather unusable practically (unless perhaps one replaces the standard
Li-ion battery with an automotive-sized lead-acid one), but it would
be a tangible hands-on "teaser" of what would be possible if someone
with the necessary knowledge and skills took the bother to redesign
the code (move layer23 into the Calypso) such that proper PM could be
implemented.

> Why is AT bad? what other protocol do you propose?

What Peter said:

: Um, no, it's the other way around. AT is 30 years of horrible.

If I were able to lay my hands on some source for an *existing*
implementation of the AT command interface on the BP side, I would
have no problem with implementing it on the AP side in my UI.  But if
I have to write the code from scratch on both sides of the interface,
I'll probably implement some ad hoc protocol of my own rather than
attempt to implement the "standard" one and get it wrong.

MS



From jayrworthington at gmail.com  Mon Dec 12 23:59:08 2011
From: jayrworthington at gmail.com (Jay R. Worthington)
Date: Tue, 13 Dec 2011 00:59:08 +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: <CAB9sg6NKh5wuhHRa9Ef5a3e66KOa-bTgH6xvr-G4SH6rnLt59A@mail.gmail.com>

Hi Harald,

2011/12/11 Harald Welte <laforge at gnumonks.org>

> If we don't at least get a 2G GSM cellphone implemented now, it will
> probably not happen before 2G networks become insignificant in large
> parts of the world.
>

what do you expect to happen from a legal standpoint? My guess would be
that the providers will fight an opensource firmware with every
firebreathing lawyer in der reach, and if they won't do that, RegTP (or
whatever they are call themself this week ;)) for sure will, a firmware
that would reject some evil RRLP queries can't be tolerated :-S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111213/d41db1fa/attachment.htm>

From peter at stuge.se  Tue Dec 13 00:38:07 2011
From: peter at stuge.se (Peter Stuge)
Date: Tue, 13 Dec 2011 01:38:07 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <CAB9sg6NKh5wuhHRa9Ef5a3e66KOa-bTgH6xvr-G4SH6rnLt59A@mail.gmail.com>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<CAB9sg6NKh5wuhHRa9Ef5a3e66KOa-bTgH6xvr-G4SH6rnLt59A@mail.gmail.com>
Message-ID: <20111213003807.5542.qmail@stuge.se>

Jay R. Worthington wrote:
> what do you expect to happen from a legal standpoint? My guess
> would be that the providers will fight an opensource firmware with
> every firebreathing lawyer in der reach,

Translate your question to wifi.

Operators can of course try even harder to control in agreements what
device you are allowed to use their SIM in, but I don't think that
will hold for very long.


//Peter



From laforge at gnumonks.org  Tue Dec 13 07:52:46 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 13 Dec 2011 08:52:46 +0100
Subject: Legal aspects / Free Software GSM baseband code
In-Reply-To: <CAB9sg6NKh5wuhHRa9Ef5a3e66KOa-bTgH6xvr-G4SH6rnLt59A@mail.gmail.com>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<CAB9sg6NKh5wuhHRa9Ef5a3e66KOa-bTgH6xvr-G4SH6rnLt59A@mail.gmail.com>
Message-ID: <20111213075246.GO10252@prithivi.gnumonks.org>

On Tue, Dec 13, 2011 at 12:59:08AM +0100, Jay R. Worthington wrote:

> what do you expect to happen from a legal standpoint? My guess would be
> that the providers will fight an opensource firmware with every
> firebreathing lawyer in der reach, and if they won't do that, RegTP (or
> whatever they are call themself this week ;)) for sure will, a firmware
> that would reject some evil RRLP queries can't be tolerated :-S

Hi Jay,

in fact, my legal analysis had been quite optimistic, at least for
Europe.  the RT&TTE directive largely regulates the sale and
distribution of "devices" that transmit on radio frequencies.  Devices
need to have CE markings and a declaration of conformity.  As GSM
terminals are part of harmonized standards, the vendor can either
certify himself that the devices are CE compliant, or he can use a
'notified body' (a certification lab) to do that externally.  The
Procedure is described in Annex III of the directive.

The testing that needs to be done is in EN 301 511, and EN 301 489-7

However, this all only applies if you distribute the devices with
modified firmware.  The device with original firmware of course is
compliant to the directive and has a Motorola declaration of conformity.

Distributing the OsmocomBB firmware itself is certainly not a "device"
under the current legislation.

Installing + Using it as a user [on a public network] might pose a legal
risk, but to be honest I wouldn't know what kind of regulation that
would be.   There might be a breach of contract of your operator terms
of services.  And of course, if the firmware misbehaves and causes RF
interference, that would be transmission without a radio license, or in
the worst case interference with public communications networks.

But then, at the same time, lots of people already use Free Software
based firmware in their WiFi chips, and I think we've had a lot of
discussion in that area.  Nonetheless, many people do it...

An no, there is no real difference here due to the fact that 2.4 GHz ist
unregulated spectrum.  You also have to make sure that the frequency,
transmission power, harmonics, etc. fall within the rules set forth in
the harmonized standards.

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 mhtajik at gmail.com  Tue Dec 13 17:15:20 2011
From: mhtajik at gmail.com (Mohammad Hosein)
Date: Tue, 13 Dec 2011 20:45:20 +0330
Subject: Legal aspects / Free Software GSM baseband code
In-Reply-To: <20111213075246.GO10252@prithivi.gnumonks.org>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<CAB9sg6NKh5wuhHRa9Ef5a3e66KOa-bTgH6xvr-G4SH6rnLt59A@mail.gmail.com>
	<20111213075246.GO10252@prithivi.gnumonks.org>
Message-ID: <CAM4cd6DOVHY1OWj=eLt8MoWuZr4NswyORXGQCnBivfTPDi=rJg@mail.gmail.com>

can anybody point out an "open" project offering RF schemes and models plus
baseband and mac implementation of Wifi ? any HDL or embedded stack is
acceptable . i think the answer to this says a lot about other projects
claiming open approach toward any widespread commercial radio system

On Tue, Dec 13, 2011 at 11:22 AM, Harald Welte <laforge at gnumonks.org> wrote:

> On Tue, Dec 13, 2011 at 12:59:08AM +0100, Jay R. Worthington wrote:
>
> > what do you expect to happen from a legal standpoint? My guess would be
> > that the providers will fight an opensource firmware with every
> > firebreathing lawyer in der reach, and if they won't do that, RegTP (or
> > whatever they are call themself this week ;)) for sure will, a firmware
> > that would reject some evil RRLP queries can't be tolerated :-S
>
> Hi Jay,
>
> in fact, my legal analysis had been quite optimistic, at least for
> Europe.  the RT&TTE directive largely regulates the sale and
> distribution of "devices" that transmit on radio frequencies.  Devices
> need to have CE markings and a declaration of conformity.  As GSM
> terminals are part of harmonized standards, the vendor can either
> certify himself that the devices are CE compliant, or he can use a
> 'notified body' (a certification lab) to do that externally.  The
> Procedure is described in Annex III of the directive.
>
> The testing that needs to be done is in EN 301 511, and EN 301 489-7
>
> However, this all only applies if you distribute the devices with
> modified firmware.  The device with original firmware of course is
> compliant to the directive and has a Motorola declaration of conformity.
>
> Distributing the OsmocomBB firmware itself is certainly not a "device"
> under the current legislation.
>
> Installing + Using it as a user [on a public network] might pose a legal
> risk, but to be honest I wouldn't know what kind of regulation that
> would be.   There might be a breach of contract of your operator terms
> of services.  And of course, if the firmware misbehaves and causes RF
> interference, that would be transmission without a radio license, or in
> the worst case interference with public communications networks.
>
> But then, at the same time, lots of people already use Free Software
> based firmware in their WiFi chips, and I think we've had a lot of
> discussion in that area.  Nonetheless, many people do it...
>
> An no, there is no real difference here due to the fact that 2.4 GHz ist
> unregulated spectrum.  You also have to make sure that the frequency,
> transmission power, harmonics, etc. fall within the rules set forth in
> the harmonized standards.
>
> 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)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111213/472eed11/attachment.htm>

From laforge at gnumonks.org  Tue Dec 13 17:51:22 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 13 Dec 2011 18:51:22 +0100
Subject: OT / Wifi
In-Reply-To: <CAM4cd6DOVHY1OWj=eLt8MoWuZr4NswyORXGQCnBivfTPDi=rJg@mail.gmail.com>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<CAB9sg6NKh5wuhHRa9Ef5a3e66KOa-bTgH6xvr-G4SH6rnLt59A@mail.gmail.com>
	<20111213075246.GO10252@prithivi.gnumonks.org>
	<CAM4cd6DOVHY1OWj=eLt8MoWuZr4NswyORXGQCnBivfTPDi=rJg@mail.gmail.com>
Message-ID: <20111213175121.GF10252@prithivi.gnumonks.org>

Hi Mohammad,

On Tue, Dec 13, 2011 at 08:45:20PM +0330, Mohammad Hosein wrote:
> can anybody point out an "open" project offering RF schemes and models plus
> baseband and mac implementation of Wifi ? any HDL or embedded stack is
> acceptable . i think the answer to this says a lot about other projects
> claiming open approach toward any widespread commercial radio system

This is really OT here and should go to a more general SDR mailinglist
like the gnuradio list, but for your reference:
https://www.cgran.org/wiki/BBN80211

-- 
- 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 pabs3 at bonedaddy.net  Tue Dec 13 02:40:19 2011
From: pabs3 at bonedaddy.net (Paul Wise)
Date: Tue, 13 Dec 2011 10:40:19 +0800
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <20111211105427.GE10252@prithivi.gnumonks.org>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
Message-ID: <CAKTje6GEHV7W0q_3k4inYa7papK_cEDrK=TGBU0tSL+QdLVRvw@mail.gmail.com>

As a gta02 owner, I am biased towards that.

As a lurker and osmocom supporter, the C1xx phones seem to have more
of a future.

I also wonder which work will also help for future ports such as MTK.

The main issue with creating a usable phone though is getting people
to use it. For gta02 you can simply get osmocombb included in SHR,
QtMoko, Debian etc and voil?, instant users who care about software
freedom. For C1xx you would need to create a user community from
scratch and do a lot of work to reach the people who might be
interested.

In both cases there is the whole legality/certification hurdle though.

-- 
bye,
pabs

http://bonedaddy.net/pabs3/



From alexander.chemeris at gmail.com  Tue Dec 13 11:02:34 2011
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Tue, 13 Dec 2011 14:02:34 +0300
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <CABmJbFUg5_2zD9kxvnUf3v5ZK8cqzXQhj8jEWmQ_RJsGDYoD3w@mail.gmail.com>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<CABmJbFUg5_2zD9kxvnUf3v5ZK8cqzXQhj8jEWmQ_RJsGDYoD3w@mail.gmail.com>
Message-ID: <CABmJbFVEAfhUOUqoPGnWY9rHxd+vaiKfuK+mN-JFQ7eFWUnsVw@mail.gmail.com>

Hi Harald and all,

I want to point that except usual mobile phones there are GSM modems which
do not require any UI and thus require less work to be done. Also they are
often connected to a power grid and don't have strict power consumption
limits. And at last, but not at least modem users often need some peculiat
functionality, which they would love to see embedded. And that's where
OsmocomBB stands out significantly from all existing modems.

I'm not sure if there are any modems based on Calypso chipset, but even a
phone serving as a modem may suffice in some cases.

--
Alexander Chemeris
Sent from my Android device. Sorry for my brevity.

On Dec 11, 2011 2:55 PM, "Harald Welte" <laforge at gnumonks.org> wrote:

Hi all!

I've mentioned this before, and I keep getting back to it:  With all the
great work that has been put into OsmocomBB, we are "at an arms lengh"
away from being able to create a true Free Software mobile phone.

We already have the hardware drivers, protocol stack and even the
'mobile' program which can be used for making and receiving voice calls
and sending/receiving SMS text messages on real GSM networks!

While the journey has been a lot of fun and everyone involved has
learned a lot, we have so far been catering mstly about "scratching our
own itch", i.e. implementing what we needed in order to satisfy our ego
and/or to implement the ideas we had regarding cellular security.

I believe we cannot miss the bigger opportunity here to put our code
into bigger use:  To create something like a very simple GSM feature
phone.

When we look at various areas of computing like Operating Systems or Web
browsers, Free Software is not just "the hobby project catching up" with
the vendors of proprietary software.  Free Software can compete.

In the cellular area, we have still not managed to even implement the
most basic GSM feature phone that existed 15 years ago using proprietary
software.  We need to work on closing that gap.  We need to show that a
small community of Free Software developers can actually implement what
teams of hundreds of engineers did in a proprietary software setting 15
years ago - despite all the lack of hardware documentation or any kind
of positive feedback from the cellular chipset, handset or operator
industry.

If we don't at least get a 2G GSM cellphone implemented now, it will
probably not happen before 2G networks become insignificant in large
parts of the world.

This is a call to all hands, please support this project!

Regards,
       Harald

== Technical aspects ==

I believe the first major decision is whether we focus on

1) the Openmoko FreeRunner / Neo1973 phones

Advantages:
 * large screen for UI with bells and whistles
 * lots of RAM and Flash, even script languages or compilation on the
  device itself possible
 * second processor doesn't require us to run stack + UI on once CPU
 * easier debugging of UI
 * various existing telephony middleware and phone dialer UI projects
  of which hopefully one could be recycled

or

2) the Motorola/Compal C1xx phones

Advantags:
 * many more phones available, even after our software is released
 * lower cost of the individual phone
 * less power consumption due to only one small ARM7 core
 * smaller screen also means less fancy UI requirements

Problems:
 * full stack + UI needs to run on calypso (L2/L3) and we'd probably
  some kind of RTOS like NuttX instead of our 'bare iron' code.

==== What we need in any case ====

 * power management on the baseband processor through all of the stack
  (though it's mostly a driver/L1 kind of thing)

== Summary / Opinion ==

It seems like running the OsmocomBB layer1 + 'mobile' as-is on the
Openmoko baseband + application processor might be the quicker road to
progress.  Sure, the power consumption will be horrible as the AP will
have to be woken up for each and every SI message, neighbor cell
measurment or paging request that ew see comining in in our paging group
(even in idle mode).  But then, there is always the negative impact of
using a relatively complex system, with two processors, a complex
software stack (Linux, X11, toolkit, etc.) on one of them, etc.

On the other hand, using the C1xx phones will result in a much more
widely available result.  The phones can still be bought in batches of
1,000 units, and they are small enough for lots of people to carry
around.  Furthermore, the battery lifetime is far beyond anything you
would ever be able to achieve on a power-hungry smartphone platform.  I
believe it would be the "smart' solution, as it means we need to get
everything integrated, etc.

What does the community on this list think?  Which way shoul we go?

But maybe the best thing is to actually stat working on the power
management aspects, as we will need them in both cases.

Happy hacking,
       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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111213/67e12850/attachment.htm>

From laforge at gnumonks.org  Tue Dec 13 12:45:09 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 13 Dec 2011 13:45:09 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <CABmJbFVEAfhUOUqoPGnWY9rHxd+vaiKfuK+mN-JFQ7eFWUnsVw@mail.gmail.com>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<CABmJbFUg5_2zD9kxvnUf3v5ZK8cqzXQhj8jEWmQ_RJsGDYoD3w@mail.gmail.com>
	<CABmJbFVEAfhUOUqoPGnWY9rHxd+vaiKfuK+mN-JFQ7eFWUnsVw@mail.gmail.com>
Message-ID: <20111213124508.GW10252@prithivi.gnumonks.org>

Hi Alexander,

On Tue, Dec 13, 2011 at 02:02:34PM +0300, Alexander Chemeris wrote:

> I want to point that except usual mobile phones there are GSM modems which
> do not require any UI and thus require less work to be done. Also they are
> often connected to a power grid and don't have strict power consumption
> limits. And at last, but not at least modem users often need some peculiat
> functionality, which they would love to see embedded. And that's where
> OsmocomBB stands out significantly from all existing modems.
> 
> I'm not sure if there are any modems based on Calypso chipset, but even a
> phone serving as a modem may suffice in some cases.

I don't think thre is much point to that.  If you have an industrial
embedded/m2m application, then the first thing you worry about is
reliability.  There you want to have a GSM stack that is tested and
evaluated thoroughly, and which is deployed for a decade or two, in as
many networks as possible.

Sierra, Cinterion, Wavecom and others have a well-established market,
and their products do very well in adressing that markets needs.  I
don't see what OsmoocmBB would bring that they'd require.

The target user for the "OsmocomBB based phone" would be primarily a
"free software enthusiast", i.e. somebody who likes Free Software for
the fredom that it has.  And such users are interested in real
telephones, notin modems for embedded systems.

-- 
- 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  Tue Dec 13 12:58:37 2011
From: peter at stuge.se (Peter Stuge)
Date: Tue, 13 Dec 2011 13:58:37 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <20111213124508.GW10252@prithivi.gnumonks.org>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<CABmJbFUg5_2zD9kxvnUf3v5ZK8cqzXQhj8jEWmQ_RJsGDYoD3w@mail.gmail.com>
	<CABmJbFVEAfhUOUqoPGnWY9rHxd+vaiKfuK+mN-JFQ7eFWUnsVw@mail.gmail.com>
	<20111213124508.GW10252@prithivi.gnumonks.org>
Message-ID: <20111213125837.3569.qmail@stuge.se>

Harald Welte wrote:
> > I'm not sure if there are any modems based on Calypso chipset, but
> > even a phone serving as a modem may suffice in some cases.
> 
> I don't think thre is much point to that.

Don't be so sure. I've met competent engineers who have very weird
issues with their M2M equipment being suddenly unreachable on the
network without the modem reporting any error status.


> Sierra, Cinterion, Wavecom and others have a well-established market,
> and their products do very well in adressing that markets needs.  I
> don't see what OsmoocmBB would bring that they'd require.

This is also not neccessarily for us to see. I think it's an
interesting and relevant parallell track. There's no reason *not* to
do it when it is *easier* than the other things we want to do, is my
reasoning somehow.


> The target user for the "OsmocomBB based phone" would be primarily a
> "free software enthusiast", i.e. somebody who likes Free Software
> for the fredom that it has.

Also not neccessarily the only market we have. By now it's easy to
customize your smartphone with tons of apps and so on, but regular
users also like to change technology to fit them now and then. OK, it
could be argued that they fall under the definition of free software
enthusiasts, but the people I think of usually don't.


> And such users are interested in real telephones, notin modems for
> embedded systems.

Maybe they have laptops and would like to use open source internet
connectivity as well. In Berlin there's e.g. never 3G service
available anyway, so 2G-only may be fine.

Just because it's not for me or you doesn't mean that noone else will
not want it. :)


//Peter



From alexander.chemeris at gmail.com  Tue Dec 13 13:09:56 2011
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Tue, 13 Dec 2011 16:09:56 +0300
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <CABmJbFUjkiemQkjfD=zwFMFGsNLFOua9dg+JKET-M9NTxwChpQ@mail.gmail.com>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<CABmJbFUg5_2zD9kxvnUf3v5ZK8cqzXQhj8jEWmQ_RJsGDYoD3w@mail.gmail.com>
	<CABmJbFVEAfhUOUqoPGnWY9rHxd+vaiKfuK+mN-JFQ7eFWUnsVw@mail.gmail.com>
	<20111213124508.GW10252@prithivi.gnumonks.org>
	<20111213125837.3569.qmail@stuge.se>
	<CABmJbFXtZj3rx7XuTMVnb5QadxTi3cMsKeOf3sPdP_utMR-zFQ@mail.gmail.com>
	<CABmJbFUjkiemQkjfD=zwFMFGsNLFOua9dg+JKET-M9NTxwChpQ@mail.gmail.com>
Message-ID: <CABmJbFVO-s4sB7JRUfpuj1fk0WFV5UQcq-nDzu6gK6pbd8duzA@mail.gmail.com>

Excuse me for offtopic: I wonder why there is no 3G in Berlin? This looks
quite weird.

--
Alexander Chemeris
Sent from my Android device. Sorry for my brevity.

On Dec 13, 2011 4:59 PM, "Peter Stuge" <peter at stuge.se> wrote:

Harald Welte wrote:
> > I'm not sure if there are any modems based on Calypso chipset, but
> > even ...
Don't be so sure. I've met competent engineers who have very weird
issues with their M2M equipment being suddenly unreachable on the
network without the modem reporting any error status.



> Sierra, Cinterion, Wavecom and others have a well-established market,
> and their products do ve...
This is also not neccessarily for us to see. I think it's an
interesting and relevant parallell track. There's no reason *not* to
do it when it is *easier* than the other things we want to do, is my
reasoning somehow.



> The target user for the "OsmocomBB based phone" would be primarily a
> "free software enthusiast...
Also not neccessarily the only market we have. By now it's easy to
customize your smartphone with tons of apps and so on, but regular
users also like to change technology to fit them now and then. OK, it
could be argued that they fall under the definition of free software
enthusiasts, but the people I think of usually don't.



> And such users are interested in real telephones, notin modems for
> embedded systems.
Maybe they have laptops and would like to use open source internet
connectivity as well. In Berlin there's e.g. never 3G service
available anyway, so 2G-only may be fine.

Just because it's not for me or you doesn't mean that noone else will
not want it. :)


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

From laforge at gnumonks.org  Tue Dec 13 14:19:35 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 13 Dec 2011 15:19:35 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <CABmJbFVO-s4sB7JRUfpuj1fk0WFV5UQcq-nDzu6gK6pbd8duzA@mail.gmail.com>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<CABmJbFUg5_2zD9kxvnUf3v5ZK8cqzXQhj8jEWmQ_RJsGDYoD3w@mail.gmail.com>
	<CABmJbFVEAfhUOUqoPGnWY9rHxd+vaiKfuK+mN-JFQ7eFWUnsVw@mail.gmail.com>
	<20111213124508.GW10252@prithivi.gnumonks.org>
	<20111213125837.3569.qmail@stuge.se>
	<CABmJbFXtZj3rx7XuTMVnb5QadxTi3cMsKeOf3sPdP_utMR-zFQ@mail.gmail.com>
	<CABmJbFUjkiemQkjfD=zwFMFGsNLFOua9dg+JKET-M9NTxwChpQ@mail.gmail.com>
	<CABmJbFVO-s4sB7JRUfpuj1fk0WFV5UQcq-nDzu6gK6pbd8duzA@mail.gmail.com>
Message-ID: <20111213141935.GZ10252@prithivi.gnumonks.org>

Hi Alexander,

On Tue, Dec 13, 2011 at 04:09:56PM +0300, Alexander Chemeris wrote:
> Excuse me for offtopic: I wonder why there is no 3G in Berlin? This looks
> quite weird.

it depends on the Operator and where you are.  They all only use 2100
MHz for 3G, not the lower 900/1800 MHz bands (which they could do
legally after a EU regulation).  But yes, indoor coverage can be really
bad.  For example in my apartment it is difficult to have 3G of all
operators, and the one I use mostly (Eplus) barely has 2G coverage here.
T-mobile and Vodafone are generally better.

It's of course different if you're at major locations like train
stations or the big squares downtown...

Another note:  I've recently seen some operator predictions for Germany,
and they assume something like GSM being in operation until 2020 -
definitely significantly longer than the life time of their existing GSM
licenses (expiring in 2016).  This tells us a lot about the
installed/deployed user base, as well as the limited 3/3.5/4G coverage..

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 alexander.chemeris at gmail.com  Tue Dec 13 14:45:51 2011
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Tue, 13 Dec 2011 17:45:51 +0300
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <CABmJbFWn1Z_XGKaiVXz2uyPYHDxRxX7er2U+V26vVjnpwGTBEQ@mail.gmail.com>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<CABmJbFUg5_2zD9kxvnUf3v5ZK8cqzXQhj8jEWmQ_RJsGDYoD3w@mail.gmail.com>
	<CABmJbFVEAfhUOUqoPGnWY9rHxd+vaiKfuK+mN-JFQ7eFWUnsVw@mail.gmail.com>
	<20111213124508.GW10252@prithivi.gnumonks.org>
	<20111213125837.3569.qmail@stuge.se>
	<CABmJbFXtZj3rx7XuTMVnb5QadxTi3cMsKeOf3sPdP_utMR-zFQ@mail.gmail.com>
	<CABmJbFUjkiemQkjfD=zwFMFGsNLFOua9dg+JKET-M9NTxwChpQ@mail.gmail.com>
	<CABmJbFVO-s4sB7JRUfpuj1fk0WFV5UQcq-nDzu6gK6pbd8duzA@mail.gmail.com>
	<20111213141935.GZ10252@prithivi.gnumonks.org>
	<CABmJbFWn1Z_XGKaiVXz2uyPYHDxRxX7er2U+V26vVjnpwGTBEQ@mail.gmail.com>
Message-ID: <CABmJbFXi8OOS8wJm02tvTpjMsXyki1pVodh86vz8S+sVt1DL6w@mail.gmail.com>

Harald, interesting information!
Do you have a link to those carrier predictions?

--
Alexander Chemeris
Sent from my Android device. Sorry for my brevity.

On Dec 13, 2011 6:19 PM, "Harald Welte" <laforge at gnumonks.org> wrote:

Hi Alexander,


On Tue, Dec 13, 2011 at 04:09:56PM +0300, Alexander Chemeris wrote:
> Excuse me for offtopic: I won...
it depends on the Operator and where you are.  They all only use 2100
MHz for 3G, not the lower 900/1800 MHz bands (which they could do
legally after a EU regulation).  But yes, indoor coverage can be really
bad.  For example in my apartment it is difficult to have 3G of all
operators, and the one I use mostly (Eplus) barely has 2G coverage here.
T-mobile and Vodafone are generally better.

It's of course different if you're at major locations like train
stations or the big squares downtown...

Another note:  I've recently seen some operator predictions for Germany,
and they assume something like GSM being in operation until 2020 -
definitely significantly longer than the life time of their existing GSM
licenses (expiring in 2016).  This tells us a lot about the
installed/deployed user base, as well as the limited 3/3.5/4G coverage..

Regards,
       Harald

-- 
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
===================...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111213/73c1e70c/attachment.htm>

From laforge at gnumonks.org  Tue Dec 13 16:46:10 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 13 Dec 2011 17:46:10 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <CABmJbFXi8OOS8wJm02tvTpjMsXyki1pVodh86vz8S+sVt1DL6w@mail.gmail.com>
References: <CABmJbFUg5_2zD9kxvnUf3v5ZK8cqzXQhj8jEWmQ_RJsGDYoD3w@mail.gmail.com>
	<CABmJbFVEAfhUOUqoPGnWY9rHxd+vaiKfuK+mN-JFQ7eFWUnsVw@mail.gmail.com>
	<20111213124508.GW10252@prithivi.gnumonks.org>
	<20111213125837.3569.qmail@stuge.se>
	<CABmJbFXtZj3rx7XuTMVnb5QadxTi3cMsKeOf3sPdP_utMR-zFQ@mail.gmail.com>
	<CABmJbFUjkiemQkjfD=zwFMFGsNLFOua9dg+JKET-M9NTxwChpQ@mail.gmail.com>
	<CABmJbFVO-s4sB7JRUfpuj1fk0WFV5UQcq-nDzu6gK6pbd8duzA@mail.gmail.com>
	<20111213141935.GZ10252@prithivi.gnumonks.org>
	<CABmJbFWn1Z_XGKaiVXz2uyPYHDxRxX7er2U+V26vVjnpwGTBEQ@mail.gmail.com>
	<CABmJbFXi8OOS8wJm02tvTpjMsXyki1pVodh86vz8S+sVt1DL6w@mail.gmail.com>
Message-ID: <20111213164610.GC10252@prithivi.gnumonks.org>

On Tue, Dec 13, 2011 at 05:45:51PM +0300, Alexander Chemeris wrote:
> Harald, interesting information!
> Do you have a link to those carrier predictions?

they are some convoluted, lengthy German documents that are published
as part of the official gazette of the German regulatory authority
"Bundesnetzagentur"...

-- 
- 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 dburgess at jcis.net  Tue Dec 13 18:54:12 2011
From: dburgess at jcis.net (David A. Burgess)
Date: Tue, 13 Dec 2011 10:54:12 -0800
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <20111213141935.GZ10252@prithivi.gnumonks.org>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<CABmJbFUg5_2zD9kxvnUf3v5ZK8cqzXQhj8jEWmQ_RJsGDYoD3w@mail.gmail.com>
	<CABmJbFVEAfhUOUqoPGnWY9rHxd+vaiKfuK+mN-JFQ7eFWUnsVw@mail.gmail.com>
	<20111213124508.GW10252@prithivi.gnumonks.org>
	<20111213125837.3569.qmail@stuge.se>
	<CABmJbFXtZj3rx7XuTMVnb5QadxTi3cMsKeOf3sPdP_utMR-zFQ@mail.gmail.com>
	<CABmJbFUjkiemQkjfD=zwFMFGsNLFOua9dg+JKET-M9NTxwChpQ@mail.gmail.com>
	<CABmJbFVO-s4sB7JRUfpuj1fk0WFV5UQcq-nDzu6gK6pbd8duzA@mail.gmail.com>
	<20111213141935.GZ10252@prithivi.gnumonks.org>
Message-ID: <2055393E-3292-4C22-8E9D-F6B1D054E840@jcis.net>

Harald -

Some operators have told us that they expect to continue GSM/EDGE service for another 10-15 years, especially in rural areas.  At Range, we borrow a line from King James Bible, "GSM will be with us always, even unto the ends of the Earth." 

UMTS is designed to deliver high data rates over fairly short distances and has poor power-efficiency characteristics for both the Node B and the UE.  LTE is a step further in that direction.  As long as that trend continues, which it will because that's where the money is, 2.xG systems will have no cost-effective replacements in areas with low subscriber density.

-- David


On Dec 13, 2011, at 6:19 AM, Harald Welte wrote:

> 
> Another note:  I've recently seen some operator predictions for Germany,
> and they assume something like GSM being in operation until 2020 -
> definitely significantly longer than the life time of their existing GSM
> licenses (expiring in 2016).  This tells us a lot about the
> installed/deployed user base, as well as the limited 3/3.5/4G coverage..
> 




From peter at stuge.se  Tue Dec 13 14:46:31 2011
From: peter at stuge.se (Peter Stuge)
Date: Tue, 13 Dec 2011 15:46:31 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <CABmJbFVO-s4sB7JRUfpuj1fk0WFV5UQcq-nDzu6gK6pbd8duzA@mail.gmail.com>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<CABmJbFUg5_2zD9kxvnUf3v5ZK8cqzXQhj8jEWmQ_RJsGDYoD3w@mail.gmail.com>
	<CABmJbFVEAfhUOUqoPGnWY9rHxd+vaiKfuK+mN-JFQ7eFWUnsVw@mail.gmail.com>
	<20111213124508.GW10252@prithivi.gnumonks.org>
	<20111213125837.3569.qmail@stuge.se>
	<CABmJbFXtZj3rx7XuTMVnb5QadxTi3cMsKeOf3sPdP_utMR-zFQ@mail.gmail.com>
	<CABmJbFUjkiemQkjfD=zwFMFGsNLFOua9dg+JKET-M9NTxwChpQ@mail.gmail.com>
	<CABmJbFVO-s4sB7JRUfpuj1fk0WFV5UQcq-nDzu6gK6pbd8duzA@mail.gmail.com>
Message-ID: <20111213144631.28064.qmail@stuge.se>

Alexander Chemeris wrote:
> Excuse me for offtopic: I wonder why there is no 3G in Berlin? This
> looks quite weird.

Sorry - I was unclear. There are networks, but there is not nearly
enough capacity for all users. This isn't neccessarily because of
inadequate infrastructure, it may just be the best we can do with
the shared medium at the cost of what the market is prepared to pay.

When a Berlin friend visited Sweden his 3G USB modem LED was suddenly
shining with a color he had never seen before.


//Peter



From alexander.chemeris at gmail.com  Tue Dec 13 14:58:45 2011
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Tue, 13 Dec 2011 17:58:45 +0300
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <CABmJbFUjeBsx=dw4XmUUTCojTmK83crf9cXYfviDKRez-_j68Q@mail.gmail.com>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<CABmJbFUg5_2zD9kxvnUf3v5ZK8cqzXQhj8jEWmQ_RJsGDYoD3w@mail.gmail.com>
	<CABmJbFVEAfhUOUqoPGnWY9rHxd+vaiKfuK+mN-JFQ7eFWUnsVw@mail.gmail.com>
	<20111213124508.GW10252@prithivi.gnumonks.org>
	<20111213125837.3569.qmail@stuge.se>
	<CABmJbFXtZj3rx7XuTMVnb5QadxTi3cMsKeOf3sPdP_utMR-zFQ@mail.gmail.com>
	<CABmJbFUjkiemQkjfD=zwFMFGsNLFOua9dg+JKET-M9NTxwChpQ@mail.gmail.com>
	<CABmJbFVO-s4sB7JRUfpuj1fk0WFV5UQcq-nDzu6gK6pbd8duzA@mail.gmail.com>
	<20111213144631.28064.qmail@stuge.se>
	<CABmJbFUjeBsx=dw4XmUUTCojTmK83crf9cXYfviDKRez-_j68Q@mail.gmail.com>
Message-ID: <CABmJbFW9A-wB=wcpJN_=3XEFJPHWyqquxPQ5+WuNSbcQ6UTdzA@mail.gmail.com>

Interesting. In Moscow WiMAX quality is very unstable, but 3G/UMTS works
pretty well. At least it's much faster then EDGE. Coverage is another
topic, but it's not that bad given that 3G is still being rolled out.
Having only this experience I expected similar situation in other major
cities. Apparently different history and background make their corrections.

--
Alexander Chemeris
Sent from my Android device. Sorry for my brevity.

On Dec 13, 2011 6:47 PM, "Peter Stuge" <peter at stuge.se> wrote:

Alexander Chemeris wrote:
> Excuse me for offtopic: I wonder why there is no 3G in Berlin? This
> lo...
Sorry - I was unclear. There are networks, but there is not nearly
enough capacity for all users. This isn't neccessarily because of
inadequate infrastructure, it may just be the best we can do with
the shared medium at the cost of what the market is prepared to pay.

When a Berlin friend visited Sweden his 3G USB modem LED was suddenly
shining with a color he had never seen before.


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

From martin at hinner.info  Tue Dec 13 17:01:44 2011
From: martin at hinner.info (Martin Hinner)
Date: Tue, 13 Dec 2011 18:01:44 +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: <CAPVwjkxWS-LYReMcmuh5z+hYhCo2hPP46YV=q_tBJ8biFJNhZQ@mail.gmail.com>

Hi,

 my 2 cents to the topic: I think the discussed situation (or target
audience) will change rapidly if there is open-source "mobile phone",
easy-to-configure, but for modern "low-cost" chipsets. Chinese
manufacturers will then very likely use the code for mass-production.
With CE certification/etc. I think that most of low-cost phones that
come from China use Infineon ULC eGOLDvoice or MTK.

 I know one importer of Chinese phones who was complaining about
problems during development (mainly user interface stuff). Having
possibility to use open-source and change it the way they like would
definitely be interesting for them.

 And regarding argument about legality of modifying firmware in WiFi
devices, there is a huge difference. Re-flashing AP with Linux
(openwrt/etc) does not change anything in RF layer. osmocomBB is now
mostly about playing with RF :-).

Martin

PS: Has anyone  access to Infineon ULC (C166) reference design kit
code (or some source code or more detailed datasheets) ?



From laforge at gnumonks.org  Tue Dec 13 17:09:02 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 13 Dec 2011 18:09:02 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <CAPVwjkxWS-LYReMcmuh5z+hYhCo2hPP46YV=q_tBJ8biFJNhZQ@mail.gmail.com>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<CAPVwjkxWS-LYReMcmuh5z+hYhCo2hPP46YV=q_tBJ8biFJNhZQ@mail.gmail.com>
Message-ID: <20111213170902.GD10252@prithivi.gnumonks.org>

Hi Martin,

On Tue, Dec 13, 2011 at 06:01:44PM +0100, Martin Hinner wrote:

>  my 2 cents to the topic: I think the discussed situation (or target
> audience) will change rapidly if there is open-source "mobile phone",
> easy-to-configure, but for modern "low-cost" chipsets. Chinese
> manufacturers will then very likely use the code for mass-production.
> With CE certification/etc. I think that most of low-cost phones that
> come from China use Infineon ULC eGOLDvoice or MTK.

Why do you think so?  The chipset vendors provide their GSM stack
together with the chips anyway.  I would argue that it is even difficult
to get components (in quantity) + data sheets etc. from them _without_
also getting the baseband stack from them.

So why would any vendor be interested in switching to another stack?

Also, always remember, we have no GPRS/EDGE support, and we won't have
it any time soon due to the size of the task at hand.

>  I know one importer of Chinese phones who was complaining about
> problems during development (mainly user interface stuff). Having
> possibility to use open-source and change it the way they like would
> definitely be interesting for them.

Without wanting to insult anyone here, my experience in the industry
shows that no importer, not even the chinese phone manufacturers
typically have any where near the skills required to do meaningful
modifications to the GSM stack of a mobile phone.

The typical situation is to the opposite:  They run to MTK with all of
their issues, because they cannot even resolve the most simple one.
After all, they are hardware mass-manufacturing companies, and not
die-hard communications protocols and/or OS developers.

>  And regarding argument about legality of modifying firmware in WiFi
> devices, there is a huge difference. Re-flashing AP with Linux
> (openwrt/etc) does not change anything in RF layer. osmocomBB is now
> mostly about playing with RF :-).

I think you may be mistaken about a lot of the 'softmac', see
http://linuxwireless.org/en/developers/Documentation/Glossary#SoftMAC

In fact, a lot of wifi chips don't have any baseband firmware, but
simply let the driver/stack take care of that. 

Also see
http://www.softwarefreedom.org/resources/2007/fcc-sdr-whitepaper.html on
that subject.

-- 
- 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 sweisman at pobox.com  Tue Dec 13 18:24:46 2011
From: sweisman at pobox.com (Scott Weisman)
Date: Tue, 13 Dec 2011 20:24:46 +0200
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <20111213170902.GD10252@prithivi.gnumonks.org>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<CAPVwjkxWS-LYReMcmuh5z+hYhCo2hPP46YV=q_tBJ8biFJNhZQ@mail.gmail.com>
	<20111213170902.GD10252@prithivi.gnumonks.org>
Message-ID: <CAMhwr9fxbP1N0KoT4FO0vRnN--4WiNcq7z64kjMwDAsZG6JA=g@mail.gmail.com>

On Tue, Dec 13, 2011 at 7:09 PM, Harald Welte <laforge at gnumonks.org> wrote:

> Also, always remember, we have no GPRS/EDGE support, and we won't have
> it any time soon due to the size of the task at hand.


I think this is another reason to support the C1xx phones.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111213/82cb5566/attachment.htm>

From peter at stuge.se  Wed Dec 14 04:22:06 2011
From: peter at stuge.se (Peter Stuge)
Date: Wed, 14 Dec 2011 05:22:06 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <20111213170902.GD10252@prithivi.gnumonks.org>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<CAPVwjkxWS-LYReMcmuh5z+hYhCo2hPP46YV=q_tBJ8biFJNhZQ@mail.gmail.com>
	<20111213170902.GD10252@prithivi.gnumonks.org>
Message-ID: <20111214042206.19011.qmail@stuge.se>

Harald Welte wrote:
> Without wanting to insult anyone here, my experience in the industry
> shows that no importer, not even the chinese phone manufacturers
> typically have any where near the skills required to do meaningful
> modifications to the GSM stack of a mobile phone.
> 
> The typical situation is to the opposite:  They run to MTK with all of
> their issues, because they cannot even resolve the most simple one.
> After all, they are hardware mass-manufacturing companies, and not
> die-hard communications protocols and/or OS developers.

I think the point with an open source software based phone for
businesses is that it creates a new market for development service
and solution providers, meaning more products to choose from, and
products that can fill existing gaps. You of course know this too
since it's exactly the kind of services sysmocom provides. :)


//Peter



From martin at hinner.info  Wed Dec 14 08:28:29 2011
From: martin at hinner.info (Martin Hinner)
Date: Wed, 14 Dec 2011 09:28:29 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <20111213170902.GD10252@prithivi.gnumonks.org>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<CAPVwjkxWS-LYReMcmuh5z+hYhCo2hPP46YV=q_tBJ8biFJNhZQ@mail.gmail.com>
	<20111213170902.GD10252@prithivi.gnumonks.org>
Message-ID: <CAPVwjkw_4hVEtrDz805Z-nMpdC+N3W-fGAw1qXCtGvXG-kA+TA@mail.gmail.com>

Harald,

On Tue, Dec 13, 2011 at 6:09 PM, Harald Welte <laforge at gnumonks.org> wrote:
>> ?my 2 cents to the topic: I think the discussed situation (or target
>> audience) will change rapidly if there is open-source "mobile phone",
>> easy-to-configure, but for modern "low-cost" chipsets. Chinese
>> manufacturers will then very likely use the code for mass-production.
>> With CE certification/etc. I think that most of low-cost phones that
>> come from China use Infineon ULC eGOLDvoice or MTK.
>
> Why do you think so? ?The chipset vendors provide their GSM stack
> together with the chips anyway. ?I would argue that it is even difficult
> to get components (in quantity) + data sheets etc. from them _without_
> also getting the baseband stack from them.
> So why would any vendor be interested in switching to another stack?

The reason is simple, if the code (not just the GSM stack) provides
something more that MTK/Infineon RDK, they would be more than happy
to! My company is dealing with China. We are using them to purchase
low-cost parts, but they are also our competitors (they even copied
our products: have a look at our http://www.obdtester.com/focom vs.
http://sinosells.com/goods-7453-Ford+VCM+OBD.html - and thousands of
other Chinese webshops!). You would not believe how they are hungry
for even small improvements.

They are VERY GOOD at copying (in terms of both legal and illegal
copies), but if it comes to some improvements ... If OSS comes with
anything better than Infineon/MTK, they will surely use it. And I do
not think it's difficult to improve for example user interface (which
is horrible, btw).

> Without wanting to insult anyone here, my experience in the industry
> shows that no importer, not even the chinese phone manufacturers
> typically have any where near the skills required to do meaningful
> modifications to the GSM stack of a mobile phone.

Not all of them :-). This one I was talking about is capable of doing
many things. One of company shareholders (by the way, he is not even
programmer!) would be able to modify the user interface code
himself... but the point is not that some importer would play with the
code himself - Chinese manufacturer would do it for them. It's about
giving wider range of options to the customer.

Martin



From sebastien at lorquet.fr  Tue Dec 13 20:08:34 2011
From: sebastien at lorquet.fr (Sebastien Lorquet)
Date: Tue, 13 Dec 2011 21:08:34 +0100
Subject: Creating a real usable phone using OsmocomBB
In-Reply-To: <CAPVwjkxWS-LYReMcmuh5z+hYhCo2hPP46YV=q_tBJ8biFJNhZQ@mail.gmail.com>
References: <20111211105427.GE10252@prithivi.gnumonks.org>
	<CAPVwjkxWS-LYReMcmuh5z+hYhCo2hPP46YV=q_tBJ8biFJNhZQ@mail.gmail.com>
Message-ID: <4EE7B0C2.9010004@lorquet.fr>

(Sorry Martin that was for the list)

Le 13/12/2011 18:01, Martin Hinner a ?crit :
> Chinese manufacturers will then very likely use the code for mass-production.
> With CE certification/etc. 

Yeah... Do you mean... "China Export" certification? No problem to get
this one :-)

Regards
Sebastien



From alexander.huemer at xx.vu  Tue Dec 13 21:35:04 2011
From: alexander.huemer at xx.vu (Alexander Huemer)
Date: Tue, 13 Dec 2011 22:35:04 +0100
Subject: [PATCH] osmocon: correct parsing of -m
Message-ID: <1323812104-23695-1-git-send-email-alexander.huemer@xx.vu>

---
 src/host/osmocon/osmocon.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c
index 5f28992..fc29506 100644
--- a/src/host/osmocon/osmocon.c
+++ b/src/host/osmocon/osmocon.c
@@ -123,6 +123,7 @@ enum dnload_mode {
 	MODE_C155,
 	MODE_ROMLOAD,
 	MODE_MTK,
+	MODE_INVALID,
 };
 
 struct dnload {
@@ -1184,7 +1185,7 @@ static int parse_mode(const char *arg)
 	else if (!strcasecmp(arg, "mtk"))
 		return MODE_MTK;
 
-	return -1;
+	return MODE_INVALID;
 }
 
 #define HELP_TEXT \
@@ -1413,7 +1414,7 @@ int main(int argc, char **argv)
 			break;
 		case 'm':
 			dnload.mode = parse_mode(optarg);
-			if (dnload.mode < 0)
+			if (dnload.mode == MODE_INVALID)
 				usage(argv[0]);
 			break;
 		case 's':
-- 
1.7.8




From peter at stuge.se  Wed Dec 14 04:25:51 2011
From: peter at stuge.se (Peter Stuge)
Date: Wed, 14 Dec 2011 05:25:51 +0100
Subject: [PATCH] osmocon: correct parsing of -m
In-Reply-To: <1323812104-23695-1-git-send-email-alexander.huemer@xx.vu>
References: <1323812104-23695-1-git-send-email-alexander.huemer@xx.vu>
Message-ID: <20111214042551.19477.qmail@stuge.se>

Alexander Huemer wrote:
> diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c
> index 5f28992..fc29506 100644
> --- a/src/host/osmocon/osmocon.c
> +++ b/src/host/osmocon/osmocon.c
> @@ -123,6 +123,7 @@ enum dnload_mode {
>  	MODE_C155,
>  	MODE_ROMLOAD,
>  	MODE_MTK,
> +	MODE_INVALID,
>  };
>  
>  struct dnload {
> @@ -1184,7 +1185,7 @@ static int parse_mode(const char *arg)
>  	else if (!strcasecmp(arg, "mtk"))
>  		return MODE_MTK;
>  
> -	return -1;
> +	return MODE_INVALID;
>  }
>  
>  #define HELP_TEXT \
> @@ -1413,7 +1414,7 @@ int main(int argc, char **argv)
>  			break;
>  		case 'm':
>  			dnload.mode = parse_mode(optarg);
> -			if (dnload.mode < 0)
> +			if (dnload.mode == MODE_INVALID)
>  				usage(argv[0]);
>  			break;
>  		case 's':

How was it incorrect before?


//Peter



From 246tnt at gmail.com  Wed Dec 14 06:28:23 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 14 Dec 2011 07:28:23 +0100
Subject: [PATCH] osmocon: correct parsing of -m
In-Reply-To: <20111214042551.19477.qmail@stuge.se>
References: <1323812104-23695-1-git-send-email-alexander.huemer@xx.vu>
	<20111214042551.19477.qmail@stuge.se>
Message-ID: <CAHL+j08r_aO5oApYM87ZMKPeB+k6-scZQh_0K0Jx+Maw5LKRHA@mail.gmail.com>

> How was it incorrect before?

According to specs, enum types _can_ be unsigned and so the test would
be always false.

http://stackoverflow.com/questions/2579230/signedness-of-enum-in-c-c99-c-cx-gnu-c-gnu-c99


Cheers,

     Sylvain



From peter at stuge.se  Wed Dec 14 06:37:03 2011
From: peter at stuge.se (Peter Stuge)
Date: Wed, 14 Dec 2011 07:37:03 +0100
Subject: [PATCH] osmocon: correct parsing of -m
In-Reply-To: <CAHL+j08r_aO5oApYM87ZMKPeB+k6-scZQh_0K0Jx+Maw5LKRHA@mail.gmail.com>
References: <1323812104-23695-1-git-send-email-alexander.huemer@xx.vu>
	<20111214042551.19477.qmail@stuge.se>
	<CAHL+j08r_aO5oApYM87ZMKPeB+k6-scZQh_0K0Jx+Maw5LKRHA@mail.gmail.com>
Message-ID: <20111214063703.4810.qmail@stuge.se>

Sylvain Munaut wrote:
> > How was it incorrect before?
> 
> According to specs, enum types _can_ be unsigned and so the test
> would be always false.

Ok. I thought perhaps the first enum was set to 0, which guarantees
that all following enums are positive integers.


//Peter



From 246tnt at gmail.com  Wed Dec 14 06:50:02 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 14 Dec 2011 07:50:02 +0100
Subject: [PATCH] osmocon: correct parsing of -m
In-Reply-To: <20111214063703.4810.qmail@stuge.se>
References: <1323812104-23695-1-git-send-email-alexander.huemer@xx.vu>
	<20111214042551.19477.qmail@stuge.se>
	<CAHL+j08r_aO5oApYM87ZMKPeB+k6-scZQh_0K0Jx+Maw5LKRHA@mail.gmail.com>
	<20111214063703.4810.qmail@stuge.se>
Message-ID: <CAHL+j0-i8QCXKDRK+B-iqXK0Bv1KKaLd7U4zQbQbmWoPpnyZPw@mail.gmail.com>

>> > How was it incorrect before?
>>
>> According to specs, enum types _can_ be unsigned and so the test
>> would be always false.
>
> Ok. I thought perhaps the first enum was set to 0, which guarantees
> that all following enums are positive integers.

They are all positive integers ...
And since the enum type in this case is unsigned, an unsigned value
can never be inferior to 0 and so the test is always false.


Cheers,

    Sylvain



From peter at stuge.se  Wed Dec 14 06:55:03 2011
From: peter at stuge.se (Peter Stuge)
Date: Wed, 14 Dec 2011 07:55:03 +0100
Subject: [PATCH] osmocon: correct parsing of -m
In-Reply-To: <CAHL+j0-i8QCXKDRK+B-iqXK0Bv1KKaLd7U4zQbQbmWoPpnyZPw@mail.gmail.com>
References: <1323812104-23695-1-git-send-email-alexander.huemer@xx.vu>
	<20111214042551.19477.qmail@stuge.se>
	<CAHL+j08r_aO5oApYM87ZMKPeB+k6-scZQh_0K0Jx+Maw5LKRHA@mail.gmail.com>
	<20111214063703.4810.qmail@stuge.se>
	<CAHL+j0-i8QCXKDRK+B-iqXK0Bv1KKaLd7U4zQbQbmWoPpnyZPw@mail.gmail.com>
Message-ID: <20111214065503.7277.qmail@stuge.se>

Sylvain Munaut wrote:
> >> > How was it incorrect before?
> >>
> >> According to specs, enum types _can_ be unsigned and so the test
> >> would be always false.
> >
> > Ok. I thought perhaps the first enum was set to 0, which guarantees
> > that all following enums are positive integers.
> 
> They are all positive integers ...

That's only certain if one enum value is defined to >= 0, and no
later enum is defined to < 0. If no enum value is defined at all,
then they may very well be negative.


> And since the enum type in this case is unsigned, an unsigned value
> can never be inferior to 0 and so the test is always false.

enums don't have signedness AFAIU?


//Peter



From 246tnt at gmail.com  Wed Dec 14 07:03:32 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 14 Dec 2011 08:03:32 +0100
Subject: [PATCH] osmocon: correct parsing of -m
In-Reply-To: <20111214065503.7277.qmail@stuge.se>
References: <1323812104-23695-1-git-send-email-alexander.huemer@xx.vu>
	<20111214042551.19477.qmail@stuge.se>
	<CAHL+j08r_aO5oApYM87ZMKPeB+k6-scZQh_0K0Jx+Maw5LKRHA@mail.gmail.com>
	<20111214063703.4810.qmail@stuge.se>
	<CAHL+j0-i8QCXKDRK+B-iqXK0Bv1KKaLd7U4zQbQbmWoPpnyZPw@mail.gmail.com>
	<20111214065503.7277.qmail@stuge.se>
Message-ID: <CAHL+j09L5yeNyzpW26j19L+gr8dJyV4A6WKW1-Akde0ipm8vcQ@mail.gmail.com>

> That's only certain if one enum value is defined to >= 0, and no
> later enum is defined to < 0. If no enum value is defined at all,
> then they may very well be negative.

Well yes, I was talking about this particular case.


>> And since the enum type in this case is unsigned, an unsigned value
>> can never be inferior to 0 and so the test is always false.
>
> enums don't have signedness AFAIU?

They do (in the underlying type).

But it can be anything the compiler decides as long as it can fit all
the enumeration constant and is no larger than int. And since in this
case there is no negative constant (begin at 0 and go up), the
compiler is free to decide to use "unsigned int" as underlying type.
And gcc does that, yielding a bug in this case.

See the test case posted in IRC yesterday:
http://pastebin.com/raw.php?i=cqi0ipY9

If you compile with -Wextra, you will see the issue.

Cheers,

    Sylvain



From 246tnt at gmail.com  Wed Dec 14 07:07:35 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 14 Dec 2011 08:07:35 +0100
Subject: [PATCH] osmocon: correct parsing of -m
In-Reply-To: <20111214065503.7277.qmail@stuge.se>
References: <1323812104-23695-1-git-send-email-alexander.huemer@xx.vu>
	<20111214042551.19477.qmail@stuge.se>
	<CAHL+j08r_aO5oApYM87ZMKPeB+k6-scZQh_0K0Jx+Maw5LKRHA@mail.gmail.com>
	<20111214063703.4810.qmail@stuge.se>
	<CAHL+j0-i8QCXKDRK+B-iqXK0Bv1KKaLd7U4zQbQbmWoPpnyZPw@mail.gmail.com>
	<20111214065503.7277.qmail@stuge.se>
Message-ID: <CAHL+j09PHNrO6NUh-SR3WU+P+b=SQaqw72SvH0a5Spr7zzSf7w@mail.gmail.com>

> That's only certain if one enum value is defined to >= 0, and no
> later enum is defined to < 0. If no enum value is defined at all,
> then they may very well be negative.

Oh, I actually mis-read this in my last answer.

I'm pretty sure that the first value defaults to 0 if not forced to
another value.


Cheers,

    Sylvain



From peter at stuge.se  Wed Dec 14 07:33:58 2011
From: peter at stuge.se (Peter Stuge)
Date: Wed, 14 Dec 2011 08:33:58 +0100
Subject: [PATCH] osmocon: correct parsing of -m
In-Reply-To: <CAHL+j09PHNrO6NUh-SR3WU+P+b=SQaqw72SvH0a5Spr7zzSf7w@mail.gmail.com>
References: <1323812104-23695-1-git-send-email-alexander.huemer@xx.vu>
	<20111214042551.19477.qmail@stuge.se>
	<CAHL+j08r_aO5oApYM87ZMKPeB+k6-scZQh_0K0Jx+Maw5LKRHA@mail.gmail.com>
	<20111214063703.4810.qmail@stuge.se>
	<CAHL+j0-i8QCXKDRK+B-iqXK0Bv1KKaLd7U4zQbQbmWoPpnyZPw@mail.gmail.com>
	<20111214065503.7277.qmail@stuge.se>
	<CAHL+j09PHNrO6NUh-SR3WU+P+b=SQaqw72SvH0a5Spr7zzSf7w@mail.gmail.com>
Message-ID: <20111214073358.12509.qmail@stuge.se>

Sylvain Munaut wrote:
> > That's only certain if one enum value is defined to >= 0, and no
> > later enum is defined to < 0. If no enum value is defined at all,
> > then they may very well be negative.
> 
> Oh, I actually mis-read this in my last answer.
> 
> I'm pretty sure that the first value defaults to 0 if not forced to
> another value.

I think not neccessarily so. If there is no specified value for any
enum value then IIRC they are all undefined, and could thus also be
negative. Bad.


//Peter



From 246tnt at gmail.com  Wed Dec 14 07:43:02 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 14 Dec 2011 08:43:02 +0100
Subject: [PATCH] osmocon: correct parsing of -m
In-Reply-To: <20111214073358.12509.qmail@stuge.se>
References: <1323812104-23695-1-git-send-email-alexander.huemer@xx.vu>
	<20111214042551.19477.qmail@stuge.se>
	<CAHL+j08r_aO5oApYM87ZMKPeB+k6-scZQh_0K0Jx+Maw5LKRHA@mail.gmail.com>
	<20111214063703.4810.qmail@stuge.se>
	<CAHL+j0-i8QCXKDRK+B-iqXK0Bv1KKaLd7U4zQbQbmWoPpnyZPw@mail.gmail.com>
	<20111214065503.7277.qmail@stuge.se>
	<CAHL+j09PHNrO6NUh-SR3WU+P+b=SQaqw72SvH0a5Spr7zzSf7w@mail.gmail.com>
	<20111214073358.12509.qmail@stuge.se>
Message-ID: <CAHL+j0_0rEufdHaqs8mOJMrfo0v4bgTp6M6meAqkz+uj4QKNMA@mail.gmail.com>

Hi,

> I think not neccessarily so. If there is no specified value for any
> enum value then IIRC they are all undefined, and could thus also be
> negative. Bad.

The C99 standard clearly states ( 6.7.2.2 paragraph 3 )

"An enumerator with = defines its enumeration constant as the value of
the constant expression. If the first enumerator has no =, the value
of its enumeration constant is 0."

Cheers,

    Sylvain



From peter at stuge.se  Wed Dec 14 07:47:48 2011
From: peter at stuge.se (Peter Stuge)
Date: Wed, 14 Dec 2011 08:47:48 +0100
Subject: [PATCH] osmocon: correct parsing of -m
In-Reply-To: <CAHL+j0_0rEufdHaqs8mOJMrfo0v4bgTp6M6meAqkz+uj4QKNMA@mail.gmail.com>
References: <1323812104-23695-1-git-send-email-alexander.huemer@xx.vu>
	<20111214042551.19477.qmail@stuge.se>
	<CAHL+j08r_aO5oApYM87ZMKPeB+k6-scZQh_0K0Jx+Maw5LKRHA@mail.gmail.com>
	<20111214063703.4810.qmail@stuge.se>
	<CAHL+j0-i8QCXKDRK+B-iqXK0Bv1KKaLd7U4zQbQbmWoPpnyZPw@mail.gmail.com>
	<20111214065503.7277.qmail@stuge.se>
	<CAHL+j09PHNrO6NUh-SR3WU+P+b=SQaqw72SvH0a5Spr7zzSf7w@mail.gmail.com>
	<20111214073358.12509.qmail@stuge.se>
	<CAHL+j0_0rEufdHaqs8mOJMrfo0v4bgTp6M6meAqkz+uj4QKNMA@mail.gmail.com>
Message-ID: <20111214074748.14549.qmail@stuge.se>

Hi!

Sylvain Munaut wrote:
> > I think not neccessarily so. If there is no specified value for any
> > enum value then IIRC they are all undefined, and could thus also be
> > negative. Bad.
> 
> The C99 standard clearly states ( 6.7.2.2 paragraph 3 )
> 
> "An enumerator with = defines its enumeration constant as the value of
> the constant expression. If the first enumerator has no =, the value
> of its enumeration constant is 0."

Ah good! I guess we only care about C99 compilers.


//Peter



From holger at freyther.de  Tue Dec 13 23:56:58 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed, 14 Dec 2011 00:56:58 +0100
Subject: Filter Replacement and sharing experience
Message-ID: <4EE7E64A.7010800@freyther.de>

Hi all,

there appears to be moderate interest in doing the filter rework and I
encourage anyone that modified a phone to share the experience with all of us.
I have created a simple docbook that uses the pictures uploaded by Luka and
annotates them with a "calloutlist". The docbook xml can be found here[1] and
the draft PDF is in the wiki as well.

It would be nice if all of us could contribute about the motivation of the
rework, maybe a bit of history (how the RX path was identified, how new baluns
were selected, ...), experience/tools used during the rework, review the
draft, note the differences of the various phones.

cheers
	holger



[1]
http://bb.osmocom.org/trac/attachment/wiki/Hardware/FilterReplacement/usermanual.xml



From peter at stuge.se  Wed Dec 14 02:49:05 2011
From: peter at stuge.se (Peter Stuge)
Date: Wed, 14 Dec 2011 03:49:05 +0100
Subject: Filter Replacement and sharing experience
In-Reply-To: <4EE7E64A.7010800@freyther.de>
References: <4EE7E64A.7010800@freyther.de>
Message-ID: <20111214024905.6060.qmail@stuge.se>

Holger Hans Peter Freyther wrote:
> I have created a simple docbook that uses the pictures uploaded by
> Luka and annotates them with a "calloutlist". The docbook xml can
> be found here[1] and the draft PDF is in the wiki as well.

Great idea!

But please can we put the .xml in git, so that the workflow will also
be with patches?

I can take some more photos of how I do it.


//Peter



From holger at freyther.de  Wed Dec 14 09:43:25 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Wed, 14 Dec 2011 10:43:25 +0100
Subject: Filter Replacement and sharing experience
In-Reply-To: <20111214024905.6060.qmail@stuge.se>
References: <4EE7E64A.7010800@freyther.de> <20111214024905.6060.qmail@stuge.se>
Message-ID: <4EE86FBD.9040305@freyther.de>

On 12/14/2011 03:49 AM, Peter Stuge wrote:
> Holger Hans Peter Freyther wrote:

> Great idea!
> 
> But please can we put the .xml in git, so that the workflow will also
> be with patches?

osmocom-bb/doc/filter_replacement$ du -h
2.5M	./images (only lowres)
2.5M	.

is this too much for the osmocom-bb repository? With the high-res pictures we
would be at 33MB.

cheers
	holger



From peter at stuge.se  Wed Dec 14 09:48:29 2011
From: peter at stuge.se (Peter Stuge)
Date: Wed, 14 Dec 2011 10:48:29 +0100
Subject: Filter Replacement and sharing experience
In-Reply-To: <4EE86FBD.9040305@freyther.de>
References: <4EE7E64A.7010800@freyther.de> <20111214024905.6060.qmail@stuge.se>
	<4EE86FBD.9040305@freyther.de>
Message-ID: <20111214094829.31895.qmail@stuge.se>

Holger Hans Peter Freyther wrote:
> > Great idea!
> > 
> > But please can we put the .xml in git, so that the workflow will also
> > be with patches?
> 
> osmocom-bb/doc/filter_replacement$ du -h
> 2.5M	./images (only lowres)
> 2.5M	.
> 
> is this too much for the osmocom-bb repository? With the high-res
> pictures we would be at 33MB.

Maybe make a separate repo?


//Peter



From holger at freyther.de  Thu Dec 22 23:10:50 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Fri, 23 Dec 2011 00:10:50 +0100
Subject: Filter Replacement and sharing experience
In-Reply-To: <20111214094829.31895.qmail@stuge.se>
References: <4EE7E64A.7010800@freyther.de>
	<20111214024905.6060.qmail@stuge.se>	<4EE86FBD.9040305@freyther.de>
	<20111214094829.31895.qmail@stuge.se>
Message-ID: <4EF3B8FA.5020208@freyther.de>

On 12/14/2011 10:48 AM, Peter Stuge wrote:

>>
>> is this too much for the osmocom-bb repository? With the high-res
>> pictures we would be at 33MB.
> 
> Maybe make a separate repo?

I created osmocom-docs (http://cgit.osmocom.org/cgit/osmocom-docs) so
everyone please feel encouraged to provide documentation and start new
books/manuals for long-living documentation.

holger



From 246tnt at gmail.com  Wed Dec 14 06:11:27 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 14 Dec 2011 07:11:27 +0100
Subject: Filter Replacement and sharing experience
In-Reply-To: <4EE7E64A.7010800@freyther.de>
References: <4EE7E64A.7010800@freyther.de>
Message-ID: <CAHL+j08aj8RKeVDpZ5KD6aFxuwVbKWzFJhcJKEbeax-Y5R7L5w@mail.gmail.com>

> maybe a bit of history (how the RX path was identified, how new baluns
> were selected, ...),

It's explained here http://246tnt.com/gsm/rx_filter.html

Cheers,

    Sylvain



From laforge at gnumonks.org  Fri Dec 16 07:49:14 2011
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 16 Dec 2011 08:49:14 +0100
Subject: Please report all known bugs/issues to trac!
Message-ID: <20111216074914.GI14590@prithivi.gnumonks.org>

Hi all!

I would like to ask everyone to report known issues with OsmocomBB to
the trac at http://bb.osmocom.org/trac/newticket

I think there is a lot of knowledge already somwewhere in the project,
but it's not readily available.  Especially as there is some movement
towards creating an actual usable phone, it would be great to have a
collection of all known problems in the existing code.

Don't worry too much if you don't know the correct component to which to
attach the report, we will figure that out.

If you don't have a wiki account for bb.osmocom.org, just send me a mail
and I will create it.

Thanks for your cooperation!

-- 
- 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 lonelysurfer at web.de  Sat Dec 17 04:51:43 2011
From: lonelysurfer at web.de (lonelysurfer at web.de)
Date: Sat, 17 Dec 2011 05:51:43 +0100 (CET)
Subject: burst couter in app_cch_scan
Message-ID: <1661425778.3078306.1324097503354.JavaMail.fmail@mwmweb001>

is the burst couter in app_cch_scans local_burst_decode()

bid = -1;
...

if (bid == -1)
?return;
also working for tch?

Im asking, because "if (bid == -1)" is not triggered correctly with my tch samples.

Regards,
Tobias
___________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192



From 246tnt at gmail.com  Sat Dec 17 08:50:41 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Sat, 17 Dec 2011 09:50:41 +0100
Subject: burst couter in app_cch_scan
In-Reply-To: <1661425778.3078306.1324097503354.JavaMail.fmail@mwmweb001>
References: <1661425778.3078306.1324097503354.JavaMail.fmail@mwmweb001>
Message-ID: <CAHL+j0-6=KQDEuD2R7As-BdQmPa0Oy9USEN+hgX15caOX8Fw2A@mail.gmail.com>

Hi,

> is the burst couter in app_cch_scans local_burst_decode()
>
> bid = -1;
> ...
>
> if (bid == -1)
> ?return;
> also working for tch?
>
> Im asking, because "if (bid == -1)" is not triggered correctly with my tch samples.

It should work for the SACCH and SACCH but will _not_ decode the FACCH
messages, that's just not implemented. (patches welcome ...)

Cheers,

    Sylvain



From lonelysurfer at web.de  Sat Dec 17 15:03:41 2011
From: lonelysurfer at web.de (lonelysurfer at web.de)
Date: Sat, 17 Dec 2011 16:03:41 +0100 (CET)
Subject: burst couter in app_cch_scan
Message-ID: <946844155.2019344.1324134221818.JavaMail.fmail@mwmweb021>

>It should work for the SACCH and SACCH but will _not_ decode the FACCH


You mean the counter should work for SACH and FACCH?

I? know...other channels are decoded differently.
Thats why I am asking. I am trying to implement FACH and hopefully ASF.
I used your tch_h_1 mframe task to grab the tch.

Best regards,
Tobias
___________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192



From 246tnt at gmail.com  Sat Dec 17 15:25:42 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Sat, 17 Dec 2011 16:25:42 +0100
Subject: burst couter in app_cch_scan
In-Reply-To: <946844155.2019344.1324134221818.JavaMail.fmail@mwmweb021>
References: <946844155.2019344.1324134221818.JavaMail.fmail@mwmweb021>
Message-ID: <CAHL+j08xbnnKpTZgNWLBTfitC_kWpv1MJjSivp_FOyKCeJaO3g@mail.gmail.com>

> You mean the counter should work for SACH and FACCH?

No, I meant SACCH/H and SACCH/F ... (i.e.  SACCH for the TCH/H and
TCH/F physical channels)

> I? know...other channels are decoded differently.
> Thats why I am asking. I am trying to implement FACH and hopefully ASF.

What's ASF ?

Cheers,

    Sylvain



From lonelysurfer at web.de  Sat Dec 17 15:45:17 2011
From: lonelysurfer at web.de (lonelysurfer at web.de)
Date: Sat, 17 Dec 2011 16:45:17 +0100 (CET)
Subject: burst couter in app_cch_scan
Message-ID: <328069272.2027994.1324136717511.JavaMail.fmail@mwmweb021>

...ASF-Tables for the different channel codec modes
___________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192



From 246tnt at gmail.com  Sat Dec 17 15:50:05 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Sat, 17 Dec 2011 16:50:05 +0100
Subject: burst couter in app_cch_scan
In-Reply-To: <328069272.2027994.1324136717511.JavaMail.fmail@mwmweb021>
References: <328069272.2027994.1324136717511.JavaMail.fmail@mwmweb021>
Message-ID: <CAHL+j0-U3S8jtLgtyL7O_D2xxDDGJjZbBh0Tzm5+WJ1X1e2WfA@mail.gmail.com>

> ...ASF-Tables for the different channel codec modes

huh ...

Still have no idea what you're talking about.



From 246tnt at gmail.com  Sat Dec 17 15:53:51 2011
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Sat, 17 Dec 2011 16:53:51 +0100
Subject: burst couter in app_cch_scan
In-Reply-To: <CAHL+j0-U3S8jtLgtyL7O_D2xxDDGJjZbBh0Tzm5+WJ1X1e2WfA@mail.gmail.com>
References: <328069272.2027994.1324136717511.JavaMail.fmail@mwmweb021>
	<CAHL+j0-U3S8jtLgtyL7O_D2xxDDGJjZbBh0Tzm5+WJ1X1e2WfA@mail.gmail.com>
Message-ID: <CAHL+j09HBubcQ_RM2sHndYMKsc0=rFw5RJ7YDvr+gWkarX71kw@mail.gmail.com>

>> ...ASF-Tables for the different channel codec modes
>
> huh ...
>
> Still have no idea what you're talking about.

Do you mean the representation of the channel coding operation as a
matrix multiplication ?

Cheers,

    Sylvain



From lonelysurfer at web.de  Sat Dec 17 16:05:03 2011
From: lonelysurfer at web.de (lonelysurfer at web.de)
Date: Sat, 17 Dec 2011 17:05:03 +0100 (CET)
Subject: burst couter in app_cch_scan
Message-ID: <1067442357.2031475.1324137903602.JavaMail.fmail@mwmweb021>

the tables from your conv_tch_afs.c
I thought, that I need them to get the voice.
___________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192



From evandersh at gmail.com  Mon Dec 19 15:36:19 2011
From: evandersh at gmail.com (Ethan Brown)
Date: Mon, 19 Dec 2011 11:36:19 -0400
Subject: Fwd: SIM_JOB_RUN_GSM_ALGO fails
In-Reply-To: <CAF5ehqbsCSa52ZVm+V_86+DwpdhVZwvV30=penoRMnc+DcjUhQ@mail.gmail.com>
References: <CAF5ehqbsCSa52ZVm+V_86+DwpdhVZwvV30=penoRMnc+DcjUhQ@mail.gmail.com>
Message-ID: <CAF5ehqa=Dsfpi3BNX=xdv_k8fBqj9i0Q1p0aFpV=RR_4GvKwSA@mail.gmail.com>

Hello,

The command SIM_JOB_RUN_GSM_ALGO fails on one of my sim cards.  Here is the
log from mobile app:

<0005> gsm48_mm.c:1637 AUTHENTICATION REQUEST (seq
0)

<0005> subscriber.c:957 Generating KEY at
SIM

<000f> sim.c:209 got new job: SIM_JOB_RUN_GSM_ALGO
(handle=00000006)

<000f> sim.c:539 RUN GSM
ALGORITHM

<000f> sim.c:187 sending APDU (class 0xa0, ins 0x88, data=a0 88 00 00 10 92
15 a4 00 40 78 f7 7e b0 8c 31 19 99 56 01 93 )
<000f> sim.c:877 received APDU (len=0 sw1=0x00
sw2=0x00)

<000f> sim.c:953 command
failed

<000f> sim.c:151 sending result to callback function
(type=1)

<0005> subscriber.c:991 key generation on SIM failed (cause 2)


And this is the log from L1:

SIM Request (21): a0 88 00 00 10 92 15 a4 00 40 78 f7 7e b0 8c 31 19 99 56
01 93
Triggering SIM transmission Character underflow!Triggering SIM reception
Max characters received!SIM: ACK does not match request, response[0]=60,
sim_data[1]=88
SIM Response (2): 00 00


The SIM I used for that test is somewhat different than other SIMs I have
tested and worked before.  I attached a picture of two SIMs I used.  The
green SIM is the one that fails running SIM_JOB_RUN_GSM_ALGO.  The white
one works perfectly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111219/afcd7c16/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IMG_20111219_112407.jpg
Type: image/jpeg
Size: 39737 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111219/afcd7c16/attachment.jpg>

From sebastien at lorquet.fr  Mon Dec 19 16:01:53 2011
From: sebastien at lorquet.fr (Sebastien Lorquet)
Date: Mon, 19 Dec 2011 17:01:53 +0100
Subject: Fwd: SIM_JOB_RUN_GSM_ALGO fails
In-Reply-To: <CAF5ehqa=Dsfpi3BNX=xdv_k8fBqj9i0Q1p0aFpV=RR_4GvKwSA@mail.gmail.com>
References: <CAF5ehqbsCSa52ZVm+V_86+DwpdhVZwvV30=penoRMnc+DcjUhQ@mail.gmail.com>
	<CAF5ehqa=Dsfpi3BNX=xdv_k8fBqj9i0Q1p0aFpV=RR_4GvKwSA@mail.gmail.com>
Message-ID: <4EEF5FF1.20909@lorquet.fr>

Hi,

SW1SW2 = 0000 let me think that the command was not actually sent to the card,
or the card was mute, or the error is very low level.

is the failing sim OK in a real phone?

Regards,
Sebastien

PS: A very minor point, I don't know how the debug function is supposed to work,
but the "data=" field is not the data, but the whole command.

Le 19/12/2011 16:36, Ethan Brown a ?crit :
> Hello,
>
> The command SIM_JOB_RUN_GSM_ALGO fails on one of my sim cards.  Here is the
> log from mobile app:
>
> <0005> gsm48_mm.c:1637 AUTHENTICATION REQUEST (seq
> 0)                                                                            
> <0005> subscriber.c:957 Generating KEY at
> SIM                                                                                    
>
> <000f> sim.c:209 got new job: SIM_JOB_RUN_GSM_ALGO
> (handle=00000006)                                                             
> <000f> sim.c:539 RUN GSM
> ALGORITHM                                                                                               
>
> <000f> sim.c:187 sending APDU (class 0xa0, ins 0x88, data=a0 88 00 00 10 92 15
> a4 00 40 78 f7 7e b0 8c 31 19 99 56 01 93 )       
> <000f> sim.c:877 received APDU (len=0 sw1=0x00
> sw2=0x00)                                                                         
>
> <000f> sim.c:953 command
> failed                                                                                                  
>
> <000f> sim.c:151 sending result to callback function
> (type=1)                                                                    
> <0005> subscriber.c:991 key generation on SIM failed (cause 2)         
>
>
> And this is the log from L1:
>
> SIM Request (21): a0 88 00 00 10 92 15 a4 00 40 78 f7 7e b0 8c 31 19 99 56 01 93
> Triggering SIM transmission Character underflow!Triggering SIM reception Max
> characters received!SIM: ACK does not match request, response[0]=60,
> sim_data[1]=88
> SIM Response (2): 00 00
>
>
> The SIM I used for that test is somewhat different than other SIMs I have
> tested and worked before.  I attached a picture of two SIMs I used.  The green
> SIM is the one that fails running SIM_JOB_RUN_GSM_ALGO.  The white one works
> perfectly.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111219/7abc432c/attachment.htm>

From andresbf at gmail.com  Tue Dec 20 12:43:30 2011
From: andresbf at gmail.com (Andres Berroa)
Date: Tue, 20 Dec 2011 08:43:30 -0400
Subject: baseband-devel Digest, Vol 23, Issue 24
In-Reply-To: <mailman.0.1324378801.30246.baseband-devel@lists.osmocom.org>
References: <mailman.0.1324378801.30246.baseband-devel@lists.osmocom.org>
Message-ID: <CAPdfEjFV4JEtWLnKCPyie+W=99_HyT+GRF25fFPB2jAzrn-+TA@mail.gmail.com>

Yes, the SIM works on other phones, even on the same phone with the
original firmware, so I suspect it's a driver problem.

On Tue, Dec 20, 2011 at 7:00 AM,
<baseband-devel-request at lists.osmocom.org>wrote:

> Send baseband-devel mailing list submissions to
>        baseband-devel at lists.osmocom.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.osmocom.org/mailman/listinfo/baseband-devel
> or, via email, send a message with subject or body 'help' to
>        baseband-devel-request at lists.osmocom.org
>
> You can reach the person managing the list at
>        baseband-devel-owner at lists.osmocom.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of baseband-devel digest..."
>
> Today's Topics:
>
>   1. Re: Fwd: SIM_JOB_RUN_GSM_ALGO fails (Sebastien Lorquet)
>
>
> ---------- Forwarded message ----------
> From: Sebastien Lorquet <sebastien at lorquet.fr>
> To: baseband-devel at lists.osmocom.org
> Cc:
> Date: Mon, 19 Dec 2011 17:01:53 +0100
> Subject: Re: Fwd: SIM_JOB_RUN_GSM_ALGO fails
>  Hi,
>
> SW1SW2 = 0000 let me think that the command was not actually sent to the
> card, or the card was mute, or the error is very low level.
>
> is the failing sim OK in a real phone?
>
> Regards,
> Sebastien
>
> PS: A very minor point, I don't know how the debug function is supposed to
> work, but the "data=" field is not the data, but the whole command.
>
> Le 19/12/2011 16:36, Ethan Brown a ?crit :
>
> Hello,
>
> The command SIM_JOB_RUN_GSM_ALGO fails on one of my sim cards.  Here is
> the log from mobile app:
>
> <0005> gsm48_mm.c:1637 AUTHENTICATION REQUEST (seq
> 0)
>
> <0005> subscriber.c:957 Generating KEY at
> SIM
>
> <000f> sim.c:209 got new job: SIM_JOB_RUN_GSM_ALGO
> (handle=00000006)
>
> <000f> sim.c:539 RUN GSM
> ALGORITHM
>
> <000f> sim.c:187 sending APDU (class 0xa0, ins 0x88, data=a0 88 00 00 10
> 92 15 a4 00 40 78 f7 7e b0 8c 31 19 99 56 01 93 )
> <000f> sim.c:877 received APDU (len=0 sw1=0x00
> sw2=0x00)
>
> <000f> sim.c:953 command
> failed
>
> <000f> sim.c:151 sending result to callback function
> (type=1)
>
> <0005> subscriber.c:991 key generation on SIM failed (cause 2)
>
>
> And this is the log from L1:
>
> SIM Request (21): a0 88 00 00 10 92 15 a4 00 40 78 f7 7e b0 8c 31 19 99 56
> 01 93
> Triggering SIM transmission Character underflow!Triggering SIM reception
> Max characters received!SIM: ACK does not match request, response[0]=60,
> sim_data[1]=88
> SIM Response (2): 00 00
>
>
> The SIM I used for that test is somewhat different than other SIMs I have
> tested and worked before.  I attached a picture of two SIMs I used.  The
> green SIM is the one that fails running SIM_JOB_RUN_GSM_ALGO.  The white
> one works perfectly.
>
>
>
> _______________________________________________
> baseband-devel mailing list
> baseband-devel at lists.osmocom.org
> https://lists.osmocom.org/mailman/listinfo/baseband-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111220/a1468d16/attachment.htm>

From holger at freyther.de  Tue Dec 20 13:31:29 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Tue, 20 Dec 2011 14:31:29 +0100
Subject: baseband-devel Digest, Vol 23, Issue 24
In-Reply-To: <CAPdfEjFV4JEtWLnKCPyie+W=99_HyT+GRF25fFPB2jAzrn-+TA@mail.gmail.com>
References: <mailman.0.1324378801.30246.baseband-devel@lists.osmocom.org>
	<CAPdfEjFV4JEtWLnKCPyie+W=99_HyT+GRF25fFPB2jAzrn-+TA@mail.gmail.com>
Message-ID: <4EF08E31.6000203@freyther.de>

On 12/20/2011 01:43 PM, Andres Berroa wrote:
> Yes, the SIM works on other phones, even on the same phone with the original
> firmware, so I suspect it's a driver problem.

Hi,

please consider using gmane[1] instead of top-posting the digest.

thanks


[1] http://news.gmane.org/gmane.comp.mobile.osmocom.baseband.devel




From terrolokaust at gmail.com  Wed Dec 28 20:16:45 2011
From: terrolokaust at gmail.com (MArc Richter)
Date: Wed, 28 Dec 2011 21:16:45 +0100
Subject: Hide extension..
Message-ID: <CADPxBsb=tETYUpwe_Lt60cgr4Dt1F1sm3dLkTDbpPr_r8nz0Cw@mail.gmail.com>

Hey!

So is it possibel to to hide the sender extension with SMS ?

regards
Marc



From pabs3 at bonedaddy.net  Thu Dec 29 00:55:07 2011
From: pabs3 at bonedaddy.net (Paul Wise)
Date: Thu, 29 Dec 2011 08:55:07 +0800
Subject: Hide extension..
In-Reply-To: <CADPxBsb=tETYUpwe_Lt60cgr4Dt1F1sm3dLkTDbpPr_r8nz0Cw@mail.gmail.com>
References: <CADPxBsb=tETYUpwe_Lt60cgr4Dt1F1sm3dLkTDbpPr_r8nz0Cw@mail.gmail.com>
Message-ID: <CAKTje6F=jeJG7QHukw5tzcbVKRR_kH2dYY641zGAzFFOPsdidw@mail.gmail.com>

On Thu, Dec 29, 2011 at 4:16 AM, MArc Richter wrote:

> So is it possibel to to hide the sender extension with SMS ?

It can certainly be done, some SMS gateway service providers allow
setting the sender to a semi-arbitrary string. Not sure about from the
mobile side though.

-- 
bye,
pabs

http://bonedaddy.net/pabs3/



From terrolokaust at gmail.com  Thu Dec 29 13:08:18 2011
From: terrolokaust at gmail.com (MArc Richter)
Date: Thu, 29 Dec 2011 14:08:18 +0100
Subject: Hide extension..
In-Reply-To: <CAKTje6F=jeJG7QHukw5tzcbVKRR_kH2dYY641zGAzFFOPsdidw@mail.gmail.com>
References: <CADPxBsb=tETYUpwe_Lt60cgr4Dt1F1sm3dLkTDbpPr_r8nz0Cw@mail.gmail.com>
	<CAKTje6F=jeJG7QHukw5tzcbVKRR_kH2dYY641zGAzFFOPsdidw@mail.gmail.com>
Message-ID: <CADPxBsbSzKR9YR0N7d7v9Nn_6gM4CRgjDESRNxC1dAEvdW2izw@mail.gmail.com>

Is it possible to implement it in osmocom also maybe an option for silent SMS?

bye
Marc


On Thu, Dec 29, 2011 at 1:55 AM, Paul Wise <pabs3 at bonedaddy.net> wrote:
> On Thu, Dec 29, 2011 at 4:16 AM, MArc Richter wrote:
>
>> So is it possibel to to hide the sender extension with SMS ?
>
> It can certainly be done, some SMS gateway service providers allow
> setting the sender to a semi-arbitrary string. Not sure about from the
> mobile side though.
>
> --
> bye,
> pabs
>
> http://bonedaddy.net/pabs3/
>



From pabs3 at bonedaddy.net  Fri Dec 30 00:12:36 2011
From: pabs3 at bonedaddy.net (Paul Wise)
Date: Fri, 30 Dec 2011 08:12:36 +0800
Subject: Hide extension..
In-Reply-To: <CADPxBsbSzKR9YR0N7d7v9Nn_6gM4CRgjDESRNxC1dAEvdW2izw@mail.gmail.com>
References: <CADPxBsb=tETYUpwe_Lt60cgr4Dt1F1sm3dLkTDbpPr_r8nz0Cw@mail.gmail.com>
	<CAKTje6F=jeJG7QHukw5tzcbVKRR_kH2dYY641zGAzFFOPsdidw@mail.gmail.com>
	<CADPxBsbSzKR9YR0N7d7v9Nn_6gM4CRgjDESRNxC1dAEvdW2izw@mail.gmail.com>
Message-ID: <1325203956.4127.5.camel@chianamo>

On Thu, 2011-12-29 at 14:08 +0100, MArc Richter wrote:

> Is it possible to implement it in osmocom also maybe an option for silent SMS?

If you want it, if it is possible and if osmocom doesn't implement it
already, you will probably need to implement it yourself:

http://bb.osmocom.org/trac/wiki/PreliminaryRequirements
http://bb.osmocom.org/trac/wiki/GettingStarted
http://bb.osmocom.org/trac/wiki/SoftwareOverview

PS: I'm subscribed, no need to CC me.

-- 
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/20111230/b94bee79/attachment.bin>

From lukash at backstep.net  Fri Dec 30 02:18:28 2011
From: lukash at backstep.net (Lukas Kuzmiak)
Date: Fri, 30 Dec 2011 03:18:28 +0100
Subject: Hide extension..
In-Reply-To: <1325203956.4127.5.camel@chianamo>
References: <CADPxBsb=tETYUpwe_Lt60cgr4Dt1F1sm3dLkTDbpPr_r8nz0Cw@mail.gmail.com>
	<CAKTje6F=jeJG7QHukw5tzcbVKRR_kH2dYY641zGAzFFOPsdidw@mail.gmail.com>
	<CADPxBsbSzKR9YR0N7d7v9Nn_6gM4CRgjDESRNxC1dAEvdW2izw@mail.gmail.com>
	<1325203956.4127.5.camel@chianamo>
Message-ID: <-7641418963756218522@unknownmsgid>

Hi guys,

This is not really something you can fake i'd say.

Even if you try most of the sms-c i've seen deployed over the world
will force your MSISDN as a sender number unless there's a specific
rule there which can really just come from an operator.

If you want to have a special identifier it's probably better to pay
for a service like your own SMPP channel/connection to a sms-c from
some vendor like routomessaging or similar and set it up there.

Cheers,
Lukas

Sent from my iPhone

On Dec 30, 2011, at 1:36 AM, Paul Wise <pabs3 at bonedaddy.net> wrote:

> On Thu, 2011-12-29 at 14:08 +0100, MArc Richter wrote:
>
>> Is it possible to implement it in osmocom also maybe an option for silent SMS?
>
> If you want it, if it is possible and if osmocom doesn't implement it
> already, you will probably need to implement it yourself:
>
> http://bb.osmocom.org/trac/wiki/PreliminaryRequirements
> http://bb.osmocom.org/trac/wiki/GettingStarted
> http://bb.osmocom.org/trac/wiki/SoftwareOverview
>
> PS: I'm subscribed, no need to CC me.
>
> --
> bye,
> pabs
>
> http://bonedaddy.net/pabs3/



From t-osmocombb at tobias.org  Fri Dec 30 19:36:26 2011
From: t-osmocombb at tobias.org (Tobias Engel)
Date: Fri, 30 Dec 2011 20:36:26 +0100
Subject: Hide extension..
In-Reply-To: <CADPxBsb=tETYUpwe_Lt60cgr4Dt1F1sm3dLkTDbpPr_r8nz0Cw@mail.gmail.com>
References: <CADPxBsb=tETYUpwe_Lt60cgr4Dt1F1sm3dLkTDbpPr_r8nz0Cw@mail.gmail.com>
Message-ID: <4EFE12BA.7020501@tobias.org>

Hi Marc,

if you mean GSM/UMTS SMS when sent from a phone (MO, mobile originated),
the answer is no.

There is not even a field for the sender number in MO SMS, as it gets
inserted by the SMSC.

If you send SMS via an SMS provider who has a direct link to some
operators SMSC, you can set the sender field to any value, including an
empty field.

As for silent SMS, they can be sent from most phones / UMTS sticks with
AT commands by setting the TP-PID value to 64. Some operators however
reset that value to 0 so the message arrives as a normal SMS at its
destination - you have to try in advance.

For the actual coding of the TP-PDU take a look at 3GPP 23.040 and for
the AT commands for sending SMS 3GPP 27.005.

-Tobias


On 28.12.2011 21:16, MArc Richter wrote:
> Hey!
> 
> So is it possibel to to hide the sender extension with SMS ?
> 
> regards
> Marc
> 
> 




From holger at freyther.de  Thu Dec 29 21:42:28 2011
From: holger at freyther.de (Holger Hans Peter Freyther)
Date: Thu, 29 Dec 2011 22:42:28 +0100
Subject: Quick Recap of running the 28C3 network
Message-ID: <4EFCDEC4.5010706@freyther.de>

Hi all,

just a quick review of things we saw/learned during the congress

* OsmocomBB LAPDm and nanoBTS LAPDm appear to have some communication issues
leading to timeouts (nanoBTS resends a message with N(R) not incremented as a
response to our I frame with Identity Response (or timeout) but with the old
data). We don't have a fix/clear understanding of this yet... looks a bit like
a bug in the nanoBTS firmware (but then other phones appear to work just fine)

* CHANNEL ACTIVATION NACK on a TS. No idea why (maybe we closed a channel with
our auto-timer but the nanoBTS thinks it is open). IIRC the nanoBTS sends us a
report about open channels, we should cross-check every n-th report with our
view of the channels... on top of that we should block failed channels
(configurable, still to do).

* Open channels... E.g. with a nanoBTS reboot or "drop bts connection ", there
was a bug in libosmo-abis that the e1inp_event was not sent as the link was
already taken out of the list of sign links when close is called (fixed in
libosmo-abis and sharing code between rsl.c and ipaccess.c)

* one OML NACK drops all BTS.. The code is there to deal with a crashed BTS to
not have it connected in a bad state... (fixed in zecke/28c3)

* subscriber queue, thanks to jolly's SMS setup we increased the amount of SMS
and there still appear to be paths in the code that do not properly release
the transaction/subscr_put and the queue got stuck. We should start by merging
jolly's sms rework.. and see how we can move the queue out of process...

* Local End Release for SAPI > 0 should be done in the channel release code,
we need to implement T3109... thanks to jolly reading GSM 08.58/04.08 with me
and discussing the normal/abnormal case. I have some work in progress (only
tested the success case) patches in the zecke/28c3 branch.


* I uploaded our scripts but somehow the core dumping does not work correctly
(core_pattern appears to be right though) for running the network

* Purging subscribers from the VLR, we do it too aggressively (on failed
paging), it should take the periodic updating timer into account.

* Sometimes i miss dates.. e.g. when was the channel opened

probably some more things I forgot now, would be a great opportunity if
someone gives a hand in cleaning things up.

holger

PS: jenkins will be back in january, ZFS crashed, the secret key was on the
ZFS, grep didn't find the backup script...



From avner.ezra at yahoo.com  Sat Dec 31 22:16:14 2011
From: avner.ezra at yahoo.com (Avner Ezra)
Date: Sat, 31 Dec 2011 14:16:14 -0800 (PST)
Subject: Newbie DSP Questions
Message-ID: <1325369774.68042.YahooMailNeo@web122210.mail.ne1.yahoo.com>

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. 

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?

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

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.

Please explain and tell me if I'm correct or wrong about above statements.

Does this will work and I'll have a 125 ARFCN from 512 to 637 ARFCNs captures into b1.cfile?
If so why in http://gnuradio.org/doc/doxygen-3.4/classusrp__source__base.html#adf8529d74696b7476e78bb0ef7b630af documentation, it says set_rx_freq should set center of frequency, so for example if you want to capture from 512 to 637, you should set frequency to frequency of ARFCN 574?


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


Thank you so much for your time
Your help and answers will solve problem of a lot of newbies like me.
Best Wishes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20111231/cc752994/attachment.htm>

From eric.tyberghien at wanadoo.fr  Sat Dec 31 23:45:31 2011
From: eric.tyberghien at wanadoo.fr (Eric Tyberghien)
Date: Sun, 1 Jan 2012 00:45:31 +0100
Subject: Compiling failure with Ubuntu 11.10 64 bits
Message-ID: <005f01ccc816$48aa7c70$d9ff7550$@tyberghien@wanadoo.fr>

Hi all

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 

Here is the make :
root at erict-G5360fr-m:/home/erict/T?l?chargements/osmocom-bb/src# make

cd shared/libosmocore/build-target && ../configure \

--host=arm-elf --enable-embedded --disable-shared \

--disable-tests ac_cv_header_sys_select_h=no \

--disable-tests ac_cv_header_sys_socket_h=no \

CFLAGS="-Os -ffunction-sections
-I/home/erict/T?l?chargements/osmocom-bb/src/target/firmware/include
-nostartfiles -nodefaultlibs"

configure: WARNING: if you wanted to set the --build type, don't use --host.

If a cross compiler is detected then cross compile mode will be used

checking for a BSD-compatible install... /usr/bin/install -c

checking whether build environment is sane... yes

checking for arm-elf-strip... arm-elf-strip

checking for a thread-safe mkdir -p... /bin/mkdir -p

checking for gawk... gawk

checking whether make sets $(MAKE)... yes

checking whether make sets $(MAKE)... (cached) yes

checking for arm-elf-gcc... arm-elf-gcc

checking whether the C compiler works... yes

checking for C compiler default output file name... a.out

checking for suffix of executables... 

checking whether we are cross compiling... yes

checking for suffix of object files... o

checking whether we are using the GNU C compiler... yes

checking whether arm-elf-gcc accepts -g... yes

checking for arm-elf-gcc option to accept ISO C89... none needed

checking for style of include used by make... GNU

checking dependency style of arm-elf-gcc... gcc3

checking build system type... x86_64-unknown-linux-gnu

checking host system type... arm-unknown-elf

checking how to print strings... printf

checking for a sed that does not truncate output... /bin/sed

checking for grep that handles long lines and -e... /bin/grep

checking for egrep... /bin/grep -E

checking for fgrep... /bin/grep -F

checking for ld used by arm-elf-gcc...
/root/install/gnuarm-4.0.2/arm-elf/bin/ld

checking if the linker (/root/install/gnuarm-4.0.2/arm-elf/bin/ld) is GNU
ld... yes

checking for BSD- or MS-compatible name lister (nm)...
/root/install/gnuarm-4.0.2/bin/arm-elf-nm -B

checking the name lister (/root/install/gnuarm-4.0.2/bin/arm-elf-nm -B)
interface... BSD nm

checking whether ln -s works... yes

checking the maximum length of command line arguments... 3458764513820540925

checking whether the shell understands some XSI constructs... yes

checking whether the shell understands "+="... yes

checking how to convert x86_64-unknown-linux-gnu file names to
arm-unknown-elf format... func_convert_file_noop

checking how to convert x86_64-unknown-linux-gnu file names to toolchain
format... func_convert_file_noop

checking for /root/install/gnuarm-4.0.2/arm-elf/bin/ld option to reload
object files... -r

checking for arm-elf-objdump... arm-elf-objdump

checking how to recognize dependent libraries... unknown

checking for arm-elf-dlltool... no

checking for dlltool... no

checking how to associate runtime and link libraries... printf %s\n

checking for arm-elf-ar... arm-elf-ar

checking for archiver @FILE support... no

checking for arm-elf-strip... (cached) arm-elf-strip

checking for arm-elf-ranlib... arm-elf-ranlib

checking command to parse /root/install/gnuarm-4.0.2/bin/arm-elf-nm -B
output from arm-elf-gcc object... ok

checking for sysroot... no

checking for arm-elf-mt... no

checking for mt... mt

configure: WARNING: using cross tools not prefixed with host triplet

checking if mt is a manifest tool... no

checking how to run the C preprocessor... arm-elf-gcc -E

checking for ANSI C header files... yes

checking for sys/types.h... yes

checking for sys/stat.h... yes

checking for stdlib.h... yes

checking for string.h... yes

checking for memory.h... yes

checking for strings.h... no

checking for inttypes.h... yes

checking for stdint.h... yes

checking for unistd.h... yes

checking for dlfcn.h... no

checking for objdir... .libs

checking if arm-elf-gcc supports -fno-rtti -fno-exceptions... no

checking for arm-elf-gcc option to produce PIC... -fPIC -DPIC

checking if arm-elf-gcc PIC flag -fPIC -DPIC works... yes

checking if arm-elf-gcc static flag -static works... yes

checking if arm-elf-gcc supports -c -o file.o... yes

checking if arm-elf-gcc supports -c -o file.o... (cached) yes

checking whether the arm-elf-gcc linker
(/root/install/gnuarm-4.0.2/arm-elf/bin/ld) supports shared libraries... yes

checking dynamic linker characteristics... no

checking how to hardcode library paths into programs... immediate

checking whether stripping libraries is possible... yes

checking if libtool supports shared libraries... no

checking whether to build shared libraries... no

checking whether to build static libraries... yes

checking for ANSI C header files... (cached) yes

checking execinfo.h usability... no

checking execinfo.h presence... no

checking for execinfo.h... no

checking for sys/select.h... (cached) no

checking for sys/socket.h... (cached) no

checking syslog.h usability... no

checking syslog.h presence... no

checking for syslog.h... no

checking ctype.h usability... yes

checking ctype.h presence... yes

checking for ctype.h... yes

checking for size_t... yes

checking for working alloca.h... yes

checking for alloca... yes

checking for library containing dlopen... no

checking for doxygen... false

checking if arm-elf-gcc supports -fvisibility=hidden... yes

configure: creating ./config.status

config.status: creating libosmocore.pc

config.status: creating libosmocodec.pc

config.status: creating libosmovty.pc

config.status: creating libosmogsm.pc

config.status: creating include/osmocom/Makefile

config.status: creating include/osmocom/vty/Makefile

config.status: creating include/osmocom/codec/Makefile

config.status: creating include/osmocom/crypt/Makefile

config.status: creating include/osmocom/gsm/Makefile

config.status: creating include/osmocom/gsm/protocol/Makefile

config.status: creating include/osmocom/core/Makefile

config.status: creating include/Makefile

config.status: creating src/Makefile

config.status: creating src/vty/Makefile

config.status: creating src/codec/Makefile

config.status: creating src/gsm/Makefile

config.status: creating tests/Makefile

config.status: creating tests/timer/Makefile

config.status: creating tests/sms/Makefile

config.status: creating tests/msgfile/Makefile

config.status: creating tests/ussd/Makefile

config.status: creating tests/smscb/Makefile

config.status: creating tests/bits/Makefile

config.status: creating utils/Makefile

config.status: creating Doxyfile.core

config.status: creating Doxyfile.gsm

config.status: creating Doxyfile.vty

config.status: creating Doxyfile.codec

config.status: creating Makefile

config.status: creating config.h

config.status: config.h is unchanged

config.status: executing depfiles commands

config.status: executing libtool commands

cd shared/libosmocore/build-target && make

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

make all-recursive

make[2]: entrant dans le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target ?

Making all in include

make[3]: entrant dans le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/i
nclude ?

Making all in osmocom

make[4]: entrant dans le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/i
nclude/osmocom ?

Making all in codec

make[5]: entrant dans le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/i
nclude/osmocom/codec ?

make[5]: Rien ? faire pour ? all ?.

make[5]: quittant le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/i
nclude/osmocom/codec ?

Making all in crypt

make[5]: entrant dans le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/i
nclude/osmocom/crypt ?

make[5]: Rien ? faire pour ? all ?.

make[5]: quittant le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/i
nclude/osmocom/crypt ?

Making all in gsm

make[5]: entrant dans le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/i
nclude/osmocom/gsm ?

Making all in protocol

make[6]: entrant dans le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/i
nclude/osmocom/gsm/protocol ?

make[6]: Rien ? faire pour ? all ?.

make[6]: quittant le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/i
nclude/osmocom/gsm/protocol ?

make[6]: entrant dans le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/i
nclude/osmocom/gsm ?

make[6]: Rien ? faire pour ? all-am ?.

make[6]: quittant le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/i
nclude/osmocom/gsm ?

make[5]: quittant le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/i
nclude/osmocom/gsm ?

Making all in core

make[5]: entrant dans le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/i
nclude/osmocom/core ?

make[5]: Rien ? faire pour ? all ?.

make[5]: quittant le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/i
nclude/osmocom/core ?

make[5]: entrant dans le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/i
nclude/osmocom ?

make[5]: Rien ? faire pour ? all-am ?.

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

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

make[4]: entrant dans le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/i
nclude ?

make[4]: Rien ? faire pour ? all-am ?.

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

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

Making all in src

make[3]: entrant dans le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/s
rc ?

Making all in .

make[4]: entrant dans le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/s
rc ?

make[4]: Rien ? faire pour ? all-am ?.

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

Making all in vty

make[4]: entrant dans le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/s
rc/vty ?

make[4]: Rien ? faire pour ? all ?.

make[4]: quittant le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/s
rc/vty ?

Making all in codec

make[4]: entrant dans le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/s
rc/codec ?

make[4]: Rien ? faire pour ? all ?.

make[4]: quittant le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/s
rc/codec ?

Making all in gsm

make[4]: entrant dans le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/s
rc/gsm ?

make[4]: Rien ? faire pour ? all ?.

make[4]: quittant le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/s
rc/gsm ?

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

Making all in tests

make[3]: entrant dans le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/t
ests ?

make[4]: entrant dans le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/t
ests ?

make[4]: Rien ? faire pour ? all-am ?.

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

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

Making all in utils

make[3]: entrant dans le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target/u
tils ?

make[3]: Rien ? faire pour ? all ?.

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

make[3]: entrant dans le r?pertoire ?
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/build-target ?

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

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

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

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

checking for a BSD-compatible install... /usr/bin/install -c

checking whether build environment is sane... yes

checking for a thread-safe mkdir -p... /bin/mkdir -p

checking for gawk... gawk

checking whether make sets $(MAKE)... yes

checking whether make sets $(MAKE)... (cached) yes

checking for gcc... gcc

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


The config.log file is like that 

 

root at erict-G5360fr-m:/home/erict/T?l?chargements/osmocom-bb/src/shared/libos
moco
re# cat config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by libosmocore configure UNKNOWN-dirty, which was
generated by GNU Autoconf 2.68. Invocation command line was

$ ./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

## --------- ##
## Platform. ##
## --------- ##

hostname = erict-G5360fr-m
uname -m = x86_64
uname -r = 3.0.0-14-generic
uname -s = Linux
uname -v = #23-Ubuntu SMP Mon Nov 21 20:28:43 UTC 2011

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown

PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /sbin
PATH: /bin
PATH: /usr/games
PATH: /root/install/gnuarm-4.0.2/bin


## ----------- ##
## Core tests. ##
## ----------- ##

configure:2324: checking for a BSD-compatible install
configure:2392: result: /usr/bin/install -c
configure:2403: checking whether build environment is sane
configure:2453: result: yes
configure:2594: checking for a thread-safe mkdir -p
configure:2633: result: /bin/mkdir -p
configure:2646: checking for gawk
configure:2662: found /usr/bin/gawk
configure:2673: result: gawk
configure:2684: checking whether make sets $(MAKE)
configure:2706: result: yes
configure:2800: checking whether make sets $(MAKE)
configure:2822: result: yes
configure:2839: checking for x86_64-linux-gnu-gcc
configure:2855: found /usr/bin/x86_64-linux-gnu-gcc
configure:2866: result: x86_64-linux-gnu-gcc
configure:3135: checking for C compiler version
configure:3144: x86_64-linux-gnu-gcc --version >&5
x86_64-linux-gnu-gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:3155: $? = 0
configure:3144: x86_64-linux-gnu-gcc -v >&5
Using built-in specs.
COLLECT_GCC=x86_64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/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 --enable-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
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
configure:3201: $? = 1
configure:3239: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "libosmocore"
| #define PACKAGE_TARNAME "libosmocore"
| #define PACKAGE_VERSION "UNKNOWN-dirty"
| #define PACKAGE_STRING "libosmocore UNKNOWN-dirty"
| #define PACKAGE_BUGREPORT "openbsc-devel at lists.openbsc.org"
| #define PACKAGE_URL ""
| #define PACKAGE "libosmocore"
| #define VERSION "UNKNOWN-dirty"
| /* end confdefs.h. */
| 
| int
| main ()
| {
| 
| ;
| return 0;
| }
configure:3244: error: in
`/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore':
configure:3246: error: C compiler cannot create executables
See `config.log' for more details

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_build_alias_set=set
ac_cv_env_build_alias_value=x86_64-linux-gnu
ac_cv_env_host_alias_set=set
ac_cv_env_host_alias_value=x86_64-linux-gnu
ac_cv_env_target_alias_set=set
ac_cv_env_target_alias_value=x86_64-linux-gnu
ac_cv_path_install='/usr/bin/install -c'
ac_cv_path_mkdir=/bin/mkdir
ac_cv_prog_AWK=gawk
ac_cv_prog_CC=x86_64-linux-gnu-gcc
ac_cv_prog_make_make_set=yes

## ----------------- ##
## Output variables. ##
## ----------------- ##

ACLOCAL='${SHELL}
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/missing --run
aclocal-1.11'
ALLOCA=''
AMDEPBACKSLASH=''
AMDEP_FALSE=''
AMDEP_TRUE=''
AMTAR='${SHELL}
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/missing --run
tar'
AM_BACKSLASH='\'
AM_DEFAULT_VERBOSITY='0'
AR=''
AUTOCONF='${SHELL}
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/missing --run
autoconf'
AUTOHEADER='${SHELL}
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/missing --run
autoheader'
AUTOMAKE='${SHELL}
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/missing --run
automake-1.11'
AWK='gawk'
CC='x86_64-linux-gnu-gcc'
CCDEPMODE=''
CFLAGS=''
CPP=''
CPPFLAGS=''
CYGPATH_W='echo'
DEFS=''
DEPDIR=''
DLLTOOL=''
DOXYGEN=''
DSYMUTIL=''
DUMPBIN=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP=''
ENABLE_MSGFILE_FALSE=''
ENABLE_MSGFILE_TRUE=''
ENABLE_PLUGIN_FALSE=''
ENABLE_PLUGIN_TRUE=''
ENABLE_SERIAL_FALSE=''
ENABLE_SERIAL_TRUE=''
ENABLE_TALLOC_FALSE=''
ENABLE_TALLOC_TRUE=''
ENABLE_TESTS_FALSE=''
ENABLE_TESTS_TRUE=''
ENABLE_UTILITIES_FALSE=''
ENABLE_UTILITIES_TRUE=''
ENABLE_VTY_FALSE=''
ENABLE_VTY_TRUE=''
EXEEXT=''
FGREP=''
GREP=''
HAVE_DOXYGEN_FALSE=''
HAVE_DOXYGEN_TRUE=''
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
INSTALL_STRIP_PROGRAM='$(install_sh) -c -s'
LD=''
LDFLAGS=''
LIBOBJS=''
LIBRARY_DL=''
LIBS=''
LIBTOOL=''
LIPO=''
LN_S=''
LTLIBOBJS=''
MAKEINFO='${SHELL}
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/missing --run
makeinfo'
MANIFEST_TOOL=''
MKDIR_P='/bin/mkdir -p'
NM=''
NMEDIT=''
OBJDUMP=''
OBJEXT=''
OTOOL64=''
OTOOL=''
PACKAGE='libosmocore'
PACKAGE_BUGREPORT='openbsc-devel at lists.openbsc.org'
PACKAGE_NAME='libosmocore'
PACKAGE_STRING='libosmocore UNKNOWN-dirty'
PACKAGE_TARNAME='libosmocore'
PACKAGE_URL=''
PACKAGE_VERSION='UNKNOWN-dirty'
PATH_SEPARATOR=':'
RANLIB=''
SED=''
SET_MAKE=''
SHELL='/bin/bash'
STRIP=''
SYMBOL_VISIBILITY=''
VERSION='UNKNOWN-dirty'
ac_ct_AR=''
ac_ct_CC=''
ac_ct_DUMPBIN=''
am__EXEEXT_FALSE=''
am__EXEEXT_TRUE=''
am__fastdepCC_FALSE=''
am__fastdepCC_TRUE=''
am__include=''
am__isrc=''
am__leading_dot='.'
am__quote=''
am__tar='${AMTAR} chof - "$$tardir"'
am__untar='${AMTAR} xf -'
bindir='${exec_prefix}/bin'
build='x86_64-linux-gnu'
build_alias='x86_64-linux-gnu'
build_cpu=''
build_os=''
build_vendor=''
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
dvidir='${docdir}'
exec_prefix='NONE'
host='x86_64-linux-gnu'
host_alias='x86_64-linux-gnu'
host_cpu=''
host_os=''
host_vendor=''
htmldir='${docdir}'
includedir='${prefix}/include'
infodir='${datarootdir}/info'
install_sh='${SHELL}
/home/erict/T?l?chargements/osmocom-bb/src/shared/libosmocore/install-sh'
libdir='/usr/lib'
libexecdir='/usr/lib'
localedir='${datarootdir}/locale'
localstatedir='${prefix}/var'
mandir='${datarootdir}/man'
mkdir_p='/bin/mkdir -p'
oldincludedir='/usr/include'
pdfdir='${docdir}'
prefix='/usr'
program_transform_name='s&$$&-4.6&'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target_alias='x86_64-linux-gnu'

## ----------- ##
## confdefs.h. ##
## ----------- ##

/* confdefs.h */
#define PACKAGE_NAME "libosmocore"
#define PACKAGE_TARNAME "libosmocore"
#define PACKAGE_VERSION "UNKNOWN-dirty"
#define PACKAGE_STRING "libosmocore UNKNOWN-dirty"
#define PACKAGE_BUGREPORT "openbsc-devel at lists.openbsc.org"
#define PACKAGE_URL ""
#define PACKAGE "libosmocore"
#define VERSION "UNKNOWN-dirty"

configure: exit 77
oot at erict-G5360fr-m:/home/erict/T?l?chargements/osmocom-bb/src/shared/libosm
ocore# 

Any idea ?

Best greetings for the new year
Eric

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