- baseband-devel - lists.osmocom.org

Please report all known bugs/issues to trac!
by Harald Welte 16 Dec '11

16 Dec '11

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

1 0

RFC: Osmocom developer workshop 2012
by Harald Welte 14 Dec '11

14 Dec '11

<DISCLAIMER> Please follow-up to openbsc(a)lists.osmocom.org </DISCLAIMER> Hi all, this idea has been around for quite some time, and for 2012 I really want to turn it into reality: I'd like to have a Osmocom developer workshop The idea here is to get all the active contributors of the project together for a couple of days (maybe 2-4 days), in order to exchange ideas, get to know each other better and last but not least work together on ironing out some of the more difficult issues. * City: Regarding the location: I think for me it is only possible to organize it if it is to be held in Berlin. I'mn happy if somebody else wants to host it at some other location, but then that person would also have to take care of local organization. Berlin also has good train and flight connections, which is definitely a plus. * Venue: If it is in Berlin, we might consider talking with c-base or Raumfahrtagentur as possible venues. * Date: Regarding a proposed date, I'm completely open for suggestions. Of course there shouldn't be any overlap with other major FOSS or Sescurity related conferences, and it should also not coincide with major public holidays, as that only makes travel + accomodation more expensive. * Funding: As we don't have that many commercial users of Osmocom projects, getting funding for e.g. travel / accomodation is probably going to be difficult. We can ask the "usual suspects" among those commercial users we know,, but I guess it will only be possible in exceptional cases to provide that kind of funding. Any ideas / comments / feedback is much appreciated. If somebody has a particular suggestion. <DISCLAIMER> Please follow-up to openbsc(a)lists.osmocom.org </DISCLAIMER> Cheers, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 2

[PATCH] osmocon: correct parsing of -m
by Alexander Huemer 14 Dec '11

14 Dec '11

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

3 10

Filter Replacement and sharing experience
by Holger Hans Peter Freyther 14 Dec '11

14 Dec '11

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/userm…

3 5

About DSP API
by Ethan Brown 13 Dec '11

13 Dec '11

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

2 10

Re: Creating a real usable phone using OsmocomBB
by Alexander Chemeris 13 Dec '11

13 Dec '11

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(a)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(a)gnumonks.org> http://laforge.gnumonks.org/ ===================...

2 1

Re: Creating a real usable phone using OsmocomBB
by Alexander Chemeris 13 Dec '11

13 Dec '11

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

1 0

Re: Creating a real usable phone using OsmocomBB
by Alexander Chemeris 13 Dec '11

13 Dec '11

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

4 3

Re: Creating a real usable phone using OsmocomBB
by Alexander Chemeris 13 Dec '11

13 Dec '11

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

3 2

Re: Creating a real usable phone using OsmocomBB
by msokolov＠ivan.Harhan.ORG 13 Dec '11

13 Dec '11

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

7 10