baseband-devel December 2011

baseband-devel@lists.osmocom.org

32 participants
39 discussions

Re: Creating a real usable phone using OsmocomBB

by Alexander Chemeris

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

13 years, 6 months

Re: Creating a real usable phone using OsmocomBB

by Alexander Chemeris

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

13 years, 6 months

Re: Creating a real usable phone using OsmocomBB

by Alexander Chemeris

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)

13 years, 6 months

Re: Creating a real usable phone using OsmocomBB

by msokolov＠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

13 years, 6 months

Re: Creating a real usable phone using OsmocomBB

by msokolov＠ivan.Harhan.ORG

Denis 'GNUtoo' Carikli <GNUtoo(a)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

13 years, 6 months

Trouble with C117 while using osmocon

by Sreeraj R

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

13 years, 6 months

Re: gnuarm version

by R M

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(a)yahoo.es> wrote: > > Hello, what version of gnuarm uses? > thank >

13 years, 6 months

Re: RFC: Osmocom developer workshop 2012

by Harald Welte

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

13 years, 6 months

Script for parsing boot loader into COFF

by R M

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

13 years, 7 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel December 2011