baseband-devel

baseband-devel@lists.osmocom.org

2022 discussions

[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 14 Dec '11

14 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 14 Dec '11

14 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 14 Dec '11

14 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 14 Dec '11

14 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

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

13 Dec '11

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

1 0

Trouble with C117 while using osmocon
by Sreeraj R 12 Dec '11

12 Dec '11

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

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel