baseband-devel October 2010

baseband-devel@lists.osmocom.org

19 participants
39 discussions

by Marten Christophe

Hello All, Can Any one expert in programming add new command line in full stack GSM application like , ./mobile. to tune or enter for particular. ARFCN , Time slot, hopping sequence. my understanding here is , once i will logged to any cell , it will automatically find FCCH, and SCH and my MS will synchronize, to a cell and read bcch. only thing left over to finish my work is to tune to right ARFN and TS with appropriate HS i want signaling to be involved without it it wont receive TCH. see, to be frank my not expert in C language and even lots of try i couldn't make API for it . so any one can help me . Kind Regards,

14 years, 10 months

L1 TCH code status

by Sylvain Munaut

Hi, Just a quick update for those that don't follow the git or IRC: A few days ago, I merged most of was in my sylvain/testing branch into master. It's now in a state where you can place a call on a BS11 or nanobts. It took a while for me to go from the raw prototype from Dieter to a state I was happy with. (especially because I wanted to understand the purpose of every line I was rewriting since my main goal is to learn :) There were also some extensions (mode switching / bugs fixes / partial HR support / ...). There are still somethings that are only in my testing/ because they're hacks (or even missing): - SIM support: The code is clearly [WIP]. I may get to cleaning it myself at some point, but that's not a priority for me ... - TS change fixup: There is a bug when going from a high TS to a low TS that's tricky to fix. I'm still thinking about the best way to handle this. There is a hack to work around it in my testing branch. This case can't happen on nanoBTS or BS-11 but it may happen on a real network. - TOA loop: I want to check if I can re-use the common code from our AFC/AGC loop rather than adding some other regulation stuff. - Enabling HR: Well ... it doesn't work yet, so no point in putting it in master :) All theses will be added when I have the time to do it. Cheers, Sylvain Munaut

14 years, 10 months

osmocom and map

by Andreas.Eversberg

hi, recently i committed a conversion tool to convert logged cell information ("SYSTEM INFORMATION" messages) from "cell_log" application into a geographical KML map layer. the quick and dirty name "gsmmap" is about confusing. MAP is actually a short term for "mobile application part", which has absolutely nothing todo with a geographical map. does anyone have a name for it? (my best idea so far: "bcch2kml") regards, andreas

14 years, 10 months

libosmocom VERSION doesn't get set properly

by jakob borg

hi, when building libosmocom in osmocom-bb/src/shared (using the git-subtree script to keep everything up to date), the Makefile in src/shared/libosmocore/build-host doesn't have the version information set properly, instead i get: PACKAGE_VERSION = UNKNOWN VERSION = UNKNOWN this is causing problems compiling stuff that require libosmocom at a specific version, like some of the airprobe tools. i'm running mac os x 10.6.4, using autoconf 2.68, automake 1.11.1, binutils 2.20.1, gcc 4.5.1. when building the master git branch of libosmocom outside of osmocom-bb (bootstrapping using the bootstrap script from airprobe/gsm-receiver), the version gets set properly. thanks jakob -- jakob borg jakborg(a)fastmail.fm -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/docs/quotes.html

14 years, 10 months

command line options for layer23 apps

by Andreas.Eversberg

hi, i like to change the handling of command line options in layer23 applications, because different layer23 applications require different individual options, and common options also. (e.g. the "mobile" application does not required "--arfcn" option, but "--vty-port". others do not require "--vty-port", but might require a "--gps-device". all apps together require "--socket" and "--gsmtap-ip".) therefore i like to leave all common options in common/main.c. additional options i like to put in the individual app_*.c files. each options i like to check at the individual app file. if it doesn't exist there, the main.c checks if the option is a common option: ... c = l23_app_handle_options(); if (c == -1) c = getopt_long(argc, argv, "hs:S:a:i:v:d:", long_options, &option_index); if (c == -1) break; ... an individual help for each application: l23_app_print_help(); any suggestions or complains? best regards, andreas

14 years, 10 months

AW: LAPDm bug: How to exit LAPDm_STATE_TIMER_RECOV state

by Andreas.Eversberg

>> you are right. in case of an RR "response" (or an I frame) with the F >> bit set to "1", there is no clearing of the "timer recovery state". in >> other cases (RNR, REJ) it is handled. > Where did you see that an I-Frame with the F bit set should clear the > condition ? you are right. i searched through the document. the I-Frame is handled during "timer recovery state", but this state is not cleared then. anyway: i am missing the description for "Receiving RR frames". A general description for RR, RNR, REJ is given in 5.5.3, but it does not describe what todo on a valid RR response with F bit set to "1". this is why i missed it.

14 years, 10 months

AW: LAPDm bug: How to exit LAPDm_STATE_TIMER_RECOV state

by Andreas.Eversberg

> The timer recovery condition is only cleared if the data link layer > entity receives a valid supervisory frame response > with the F bit set to "1". If the N(R) of this received supervisory > frame is within the range from its current state variable > V(A) to its current send state variable V(S) inclusive, it shall set > its send state variable V(S) to the value of the received > N(R). Timer T200 shall be reset if the received supervisory frame > response is an RR or REJ response with F bit set to > "1". The data link layer entity shall then resume with I frame > transmission or retransmission, as appropriate. > Timer T200 shall be set if the received supervisory response is an RNR > response, and the data link layer shall proceed > with the enquiry process in accordance with subclause 5.5.5. hi sylvain, you are right. in case of an RR "response" (or an I frame) with the F bit set to "1", there is no clearing of the "timer recovery state". in other cases (RNR, REJ) it is handled. i would like to test this with a prepared frame drop tonight. if this works, i will commit it. regards, andreas

14 years, 10 months

Switching to TCH

by Sylvain Munaut

> but when i doing so , it is chasing up to SDCCH , and after this it is > started to dropping frames .. and not getting tune to any TCH/F Have you even _read_ the code of layer23 ... it _will_ not do what you want directly. It's a starting point, but you're gonna have to learn to write things by yourself. > though there is no encryption being used. A5/0, i have seen , no ciphering. > in traces. Well it's a perfectly normal behavior that after some time you only see lost frames. I suggest you re-read the code and the specs until you understand _why_ it's normal. > kindly confirm with layer1.compalram.bin , if i will be able to listen > TCH/F assign to some other MS , Not out of the box, as I said, you will need to do some programming. Given the question you ask, you obviously don't understand GSM or the code enough yet to do it. Cheers, Sylvain PS: Please don't hijack a thread that has nothing to do with what you're writing about by just clicking the reply button and not even bothering to change the subject ... seems like you need to read the emails RFC as well ...

14 years, 10 months

LAPDm bug: How to exit LAPDm_STATE_TIMER_RECOV state

by Sylvain Munaut

Hi, In GSM 05.06 Section 5.5.7 at the end it says : --- The timer recovery condition is only cleared if the data link layer entity receives a valid supervisory frame response with the F bit set to "1". If the N(R) of this received supervisory frame is within the range from its current state variable V(A) to its current send state variable V(S) inclusive, it shall set its send state variable V(S) to the value of the received N(R). Timer T200 shall be reset if the received supervisory frame response is an RR or REJ response with F bit set to "1". The data link layer entity shall then resume with I frame transmission or retransmission, as appropriate. Timer T200 shall be set if the received supervisory response is an RNR response, and the data link layer shall proceed with the enquiry process in accordance with subclause 5.5.5. --- And I don't see where this is supposed to be handled in the code. I tried this quick fix: diff --git a/src/host/layer23/src/common/lapdm.c b/src/host/layer23/src/common/lapdm.c index b1c0d40..8bd42a7 100644 --- a/src/host/layer23/src/common/lapdm.c +++ b/src/host/layer23/src/common/lapdm.c @@ -1081,8 +1081,12 @@ static int lapdm_rx_s(struct msgb *msg, struct lapdm_msg_ctx *mctx) /* 5.4.2.2: Inidcate error on supervisory reponse F=1 */ if (LAPDm_ADDR_CR(mctx->addr) == CR_BS2MS_RESP && LAPDm_CTRL_PF_BIT(mctx->ctrl)) { - LOGP(DLAPDM, LOGL_NOTICE, "S frame response with F=1 error\n"); - rsl_rll_error(RLL_CAUSE_UNSOL_SPRV_RESP, mctx); + if (dl->state != LAPDm_STATE_TIMER_RECOV) { + LOGP(DLAPDM, LOGL_NOTICE, "S frame response with F=1 error\n"); + rsl_rll_error(RLL_CAUSE_UNSOL_SPRV_RESP, mctx); + } else { + dl->state = LAPDm_STATE_MF_EST; + } } switch (dl->state) { which seems to fix the issue I encountered but my understanding of how lapdm.c works is very limited and I doubt that it's all that's needed to properly handle this case. Cheers, Sylvain Munaut

14 years, 10 months

cross-compiling osmocom on mac os x

by jakob borg

hi, i'm struggling to get a working cross-compile toolchain for osmocom-bb on os x, i've been playing with a script called summon-arm-toolchain (http://github.com/esden/summon-arm-toolchain) for a while now without success, my toolchain seems to build fine, but when trying to compile for my target, i get: checking for arm-elf-linux-gcc... arm-elf-gcc checking whether the C compiler works... no config.log says: configure:3106: checking whether the C compiler works configure:3128: arm-elf-gcc -Os -ffunction-sections -I../../../../target/firmware/include conftest.c >&5 /usr/local/arm-elf/lib/gcc/arm-elf/4.5.1/../../../../arm-elf/lib/libc.a(lib_a-exit.o): In function `exit': /usr/local/src/summon-arm-toolchain/build/arm-elf/newlib/libc/stdlib/../../../../../newlib-1.18.0/newlib/libc/stdlib/exit.c:65: undefined reference to `_exit' collect2: ld returned 1 exit status i'm running mac os x 10.6.4, using autoconf 2.68, automake 1.11.1, binutils 2.20.1, gcc 4.5.1. any idea what i might be doing wrong? has anybody successfully cross-compiled the arm part of osmocom-bb on osx? thanks jakob -- jakob borg jakborg(a)fastmail.fm -- http://www.fastmail.fm - Faster than the air-speed velocity of an unladen european swallow

14 years, 10 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel October 2010