baseband-devel

baseband-devel@lists.osmocom.org

2022 discussions

SIM
by azrael01 22 Feb '10

22 Feb '10

Hi, I'm new at this project and I've no experience to program a complete SIM card. But I've experience to implement the ISO-7816 standard on a ARM-Cortex-M3, so that you have a SIM-interface (SIM emulation) between the PC an the Mobile equipment. However, if I can help I'll be pleased to hear from you. cheers, Carsten

2 1

some questions
by Ilya Petrov 22 Feb '10

22 Feb '10

Hi! I read few pages at http://bb.osmocom.org but didnt find answer for some little questions. What this code is based on? Is this a port of some rtos to calypso? -- wbr, Ilya ICQ: none, Jabber: ilya.muromec(a)jabber.ru

3 4

Memory Leaking. _talloc_zero panics
by Sylvain Munaut 22 Feb '10

22 Feb '10

Hi, I've noticed that hello_world and compal_dsp_dump now crash pretty early. I've traced it down to talloc_zero panicing by running out of free msgb. Augmenting the number to 64 makes the software go a little further but they still crash in the end. I'm hoping that the person who wrote this part will see an obvious place where the problem lies :) Sylvain

2 2

Sim
by Sébastien Lorquet 21 Feb '10

21 Feb '10

Hi all, congrats for your awesome research and work, this is truly impressive. The little ant that I am (compared to you) was interested in helping you with the SIM aspects of the project. I think I know javacard sufficiently to implement a basic sim card that can be totally controlled. I already started to think on how to do that. This will include making host side tools, too. If javacard is not open enough, we can also look at native cards using PIC, for example. In our previous discussions, the main problem was the availability of SIM sized cards, be them javacards or not. pros and cons - javacard is an industry standard, coupled with GlobalPlatform specs this is a portable way to put an application on a card without being locked with a card manufacturer. - native PIC cards benefit from a lot of open tools such as the gp* PIC tools, asm, sdcc for compiler and gpsim for simulation. - some projects exists already, I don't know them well, maybe they can be used, forked, improved. - availability must be checked. I'd like to request precisions on how the things should be done, what are the minimal requirements (files, etc) and when the openSim project will be needed regarding to your progress. Regards Sebastien

3 3

Links to schematics in the wiki ?
by Sylvain Munaut 21 Feb '10

21 Feb '10

Hi, I'm wondering if it's ok or not to put links (and only links obviously) to schematics of GSM in the Wiki ? IANAL so I'm not sure exactly what the situation is ... and I'd rather ask before I start adding too much of them :) Cheers, Sylvain

2 1

New build process / libosmocore
by Harald Welte 21 Feb '10

21 Feb '10

Hi! After much delibeation I have devoted today to 'fix' the way how we build the project and how things depend on each other. We have a couple of challenges: 1) there is (and should be!) a lot of infrastructure code sharing between OpenBSC and OsmocomBB Layer2/3. I'm referring to stuff like linuxlist.h, msgb.[hc], bitvec.[hc], the various GSM protocol header files, timers, etc. 2) we want to do the layer2/layer3 development on the PC, while the layer1 resides on the target phone. However, the code should be API compatible and just compile when we later decide to move (parts of) it into the phone. 3) there is already some code like "msgb" which is used both in layer2(PC) and the phone. 4) I don't want to have too many build dependencies as it makes it unneccesarily difficult to get started with the project. So everything should build from the git tree we provide 5) we dislike the idea of code duplication or copy+paste. This means that we need to build some stuff like libosmocore twice; for the host PC and for ARM The solution looks like this: * libosmocore lives in its own git://git.osmocom.org/libosmocore.git repository. This is where we make changes to it. * libosmocore is 'squashed' into the osmocom-bb.git repository by means of git-subtree[1] to make sure challenge '4' is fulfilled. This is transparent to the user who clones our tree. However, if you want to make changes, please ensure that a commit either only touches files within src/shared/libosmocore or outside of that directory. Mixed commits will require manual action and are tiresome. * everything is built using autotools, except for the 'firmware' (what used to be hello_world) * there's now a top-level Makefile, which * builds libosmocore for the host * builds libosmocore for the target * builds osmocon for the host * builds layer2 for the host * builds the target firmware I understand that this process is quite a bit more complex than what we used to have, but it is the best option that I could come up with. I particularly hope that I didn't do something stupid which would break Cygwin builds... we want to keep Dieter as productive as he currently is, after all :) Regards, Harald [1] git://github.com/apenwarr/git-subtree.git -- - 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

[PATCH] fix typo in documentation
by Timo Juhani Lindfors 21 Feb '10

21 Feb '10

--- src/README.building | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/README.building b/src/README.building index f940d09..bfd86b6 100644 --- a/src/README.building +++ b/src/README.building @@ -23,5 +23,5 @@ we do not officially support this. # cd osmocom-bb/src/host/layer2 # autoreconf -i - # ./confiugre + # ./configure # make -- 1.5.6.5

2 1

OpenBSC questions
by Christopher Friedt 21 Feb '10

21 Feb '10

So let me ask a couple of questions about OpenBSC to clarify things for myself. What are the requirements for running OpenBSC ? a) a USRP2 b) some kind of computer with gigabit ethernet (recommended hardware? what kind of load would this be responsible for?) b) a broadband internet connection c) anything else? Some kind of VOIP account somewhere? The reason I'm asking is that I've been doing quite a bit of work with the USRP2 at university, and have been considering buying one for myself for quite some time (although as a student, it's hard to justify the price). My professional / academic / hobby interests definitely involve hacking mobiles, investigating mobile radio, hacking various arm devices, even hardware design, etc, and I guess that OpenBSC would be ideal to for testing out osmocom baseband firmware (rather than having a commercial provider's black box for a BS). I guess another question I could pose to the list would be: Is the USRP2 hardware-capable of supporting something UMTS, EDGE, etc? I know that the spec sheets say that it's capable of 50 MHz of instantaneous bandwidth, but I believe that the high data rate 3G (and further) protocols are using wideband OFDM. From my understanding, I would imagine that it would be necessary to support much more than 50 MHz of instantaneous bandwidth, or somehow be able to load the transceiver buffers quickly and sequentially. then push a broad spectrum in parallel. Perhaps this can be achieved with a MIMO configuration, or with a specialized daughter card. Any thoughts? C

5 5

newer more expensive phones
by Mohammad Hosein 20 Feb '10

20 Feb '10

i've got a couple of newer Motorola phones like the milestone also some new HTC phones around any chance these can be used to start playing ?

3 2

Layer2 Wireshark integration
by Harald Welte 20 Feb '10

20 Feb '10

Hi! I've recycled the old GSMTAP wireshark plugin that I originally wrote for project airprobe. Using this patch (now in our git tree as well, applies against current wireshark svn) and the layer2 host program as well as the l1test.bin target program, you can watch BCCH messages in realtime. The architecture is like this: * DSP forwards decoded normal burst data to layer1/sync.c * layer1/sync.c generates L1A_L23 protocol message and sends it via the SERCOMM HDLC layer over RS232 * "osmocon" receives the HDLC frame and relays it to the Unix domain socket * "layer2" receives the L1A_L23 protocol message on the Unix domain socket, adds a GSMTAP header and sends it to the GSMTAP UDP port on localhost * wireshark captures on the 'lo' interface and calls the GSMTAP dissector plugin for everything received on the GSMTAP UDP port number. Have fun! -- - 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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel