baseband-devel

baseband-devel@lists.osmocom.org

1 participants
2024 discussions

L1 TCH code status
by Sylvain Munaut 29 Oct '10

29 Oct '10

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

2 1

osmocom and map
by Andreas.Eversberg 27 Oct '10

27 Oct '10

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

1 0

libosmocom VERSION doesn't get set properly
by jakob borg 26 Oct '10

26 Oct '10

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

3 3

command line options for layer23 apps
by Andreas.Eversberg 26 Oct '10

26 Oct '10

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

3 4

AW: LAPDm bug: How to exit LAPDm_STATE_TIMER_RECOV state
by Andreas.Eversberg 25 Oct '10

25 Oct '10

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

1 0

AW: LAPDm bug: How to exit LAPDm_STATE_TIMER_RECOV state
by Andreas.Eversberg 25 Oct '10

25 Oct '10

> 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

2 1

Switching to TCH
by Sylvain Munaut 24 Oct '10

24 Oct '10

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

2 1

LAPDm bug: How to exit LAPDm_STATE_TIMER_RECOV state
by Sylvain Munaut 24 Oct '10

24 Oct '10

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

2 1

cross-compiling osmocom on mac os x
by jakob borg 24 Oct '10

24 Oct '10

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

2 1

DSP TCH task : time to get/put FAACH
by Sylvain Munaut 22 Oct '10

22 Oct '10

Hi Dieter, Hi everyone, (cc'd the list, for the record and if other people are interested in the inner workings :) I'm pretty satisfied with the current state of the TCH primitive (as it is in my testing branch now). But there is still two things I'm stumbling upon: * When to put / read data for FACCH. Getting downlink FACCH blocks looks quite logic: just check the B_BLUD bit on the TCH response of the last burst of the block. So with rx_time being the time at which the burst was received (i.e., one frame before the response is executed) - For TCH/F: (rx_time.fn % 13) % 4 == 3 - For TCH/H: (rx_time.t2 - subchannel) in {6,15,23} But for when to load the next FACCH block, it seems weird. From what I understand of what you did and what the TSM30 does, you need to load the data on the TCH cmd corresponding to the bursts _before_ the first burst. So with tx_time being the time at which the burst will transmitted (i.e., one frame after the command is executed = l1s.next_time) - For TCH/F (tx_time.fn % 13) % 4 == 3 - For TCH/H (tx_time.t2 - subchannel) in {6,15,23} (2 TDMA before the first burst because on TCH/H, we're executed one once every two frame) Why the need to load it one burst in advance ? (while on the RX side, which seems more complex to do, data is available directly after the last burst is received). * TCH/H support: AFAIK, I did everything that should be required for it to work: - set fn_report properly for TCH/H - set chan_type to TCH_H in dsp_load_tch_parameters - Use a different condition for when to put/read FACCH bursts (according to 05.02) - Schedule the TCH task appropriately ... But still can't get it to work (testing with the racal). SACCH seems to work fine (I see the SI messages), but I don't see a single FACCH message (and eventually the racal says T3107 expired, assignement to TCH failed). Do you see anything else that would be required ? Cheers, Sylvain

1 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel