October 2010 - baseband-devel - lists.osmocom.org

by Sylvain Munaut

Hi, I've hacked something together to quickly test non-combined CCCH. However, I've hit a problem when trying to receive anything on another timeslot than 0. The TX side seems to work fine as the BTS can see my location update request and answers with a reject, but on the MS side, I never see the reject and wireshark only shows invalid incohrent data on the RX. The frames for SDCCH/8 show really nothing valid (looks like random bytes), things like 09 80 7f 47 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 09 00 47 d5 2d 06 1e 00 00 69 7c a0 91 3d 22 ff ab fe 6c 4f 56 4f 36 ... while the frames for the associated SAACH show at least something gsm-like : 03 03 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b but that's not quite a SI5/6 ... To RX/TX on TS=1, I just delayed the RX/TX window by 625 bits (4 * 156.25) when I'm in dedicated channel mode by chaning the 'start' in l1s_tx_win_ctrl / l1s_rx_win_ctrl Is there something else that should be done ? Cheers, Sylvain

11 years, 9 months

2
5
0 0

Use OsmocomBB as OpenBTS / airprobe clock generator

by Harald Welte

Hi! Recently we've had the idea of using OsmocomBB with a simple firmware that synchronizes to an existing GSM networks FCCH and use the resulting 13MHz clock to drive the USRP for airprobe or OpenBTS. Ideally, we would even use the Calypso-internal PLL (for ARM or DSP) to multiply it up to the required 52 MHz. However, neither the Openmoko nor the Compal/Motorola phones expose any of the 3 clock output pads :( So the only choice is to use something along the lines of the http://focus.ti.com/docs/prod/folders/print/cdcvf25084.html as a quad clock multiplier and attach it to the CLK13OUT signal of the phone. The chip is available for 9 USD in single quantities at digikey, and possibly cheaper at other sources. Combined with a sub-20EUR phone it might be a very cheap but still accurate frequency source for OpenBTS - at least as long as there are any commercial gsm networks available. 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)

12 years, 1 month

8
17
0 0

Linux + u-boot port to MT6235

by Marcin Mielczarczyk

Hi All! That's true, I managed to run U-Boot on MT6235, but linux kernel is not fully functional yet (it's fresh stuff as I managed to ran it on Tuesday and then I was off to conference). For MT6235 development I chose Sciphone G2, which is pretty cheap. After some time I managed to download code to SRAM (just 64KB) using MTK's FlashTool. MTK FlashTool communicates over UART directly with MT6235 bootloader and sends its own chunk of code (about 58KB) which is executed in SRAM and communicates with FlashTool. I found on pudn.com some pack to customize code loaded by FlashTool, thanks to which I could download my own code to SRAM (without JTAG). The problem was that it had to be linked with some security libraries which occupied about 56KB and not much memory left for my own code. Then I decided to try find JTAG pins to get all control on MT6235. That took me sometime, but finally I succeeded. The other bigger issue was initializing DRAM controller to be able to download bigger code (linux kernel + uboot) to external RAM. In sciphone there is problem that all interesting chips are under metal shield which is pretty havily soldered. In this case I couldn't read what kind of RAM memory is mounted without destroying the board (I don't have such soldering machine which could unsolder so big metal shield). Thanks to JTAG I could attach to target and then dump DRAM controller registers from processor running MTK's software, but setting these values after processor start and configuration of PLL didn't work. I decided to disassemble bootloader which could show me how DRAM controller is initialized and how code fron NAND is loaded (to be able to flash U-Boot and kernel to NAND so MT6235 will start my code automatically and I will not have to use JTAG). Currently I have knowledge how internal MT6235 bootloader is loading code from memory during startup and I also extracted procedure of DRAM controller initialization. Thanks to that I'm able to run U-Boot from the very begining of processor startup. The problem is that I have just one piece of Sciphone G2 and I don't want to flash it yet to not break existing code in it. Thanks to running device I'm able to attach with JTAG and check how peripherals are configured (i.e. LCD, MMC, etc.). I have backup of flash, but I'm not 100% sure if I will flash it back, phone will startup. That's why I bought second piece of Sciphone G2 and should receive it today or on Tuesday (this Monday is holiday in Poland). In this case I'll flash U-Boot to NAND and try to make it working. Then we could load the rest of code from U-Boot (to RAM or NAND over serial). You can see how my setup looks on attached picture. The good thing about it is that the same bootloader is used in MT622x, so it should be fairly easy to do the same on phones based on that SoCs (but unfortuantely it's just ARM7). If it comes to code, of course I can share it on "git.osmocom.org". Currently it's just basic port of U-Boot and not much for linux kernel, but I'm working on this now so I'll push it when it'll be ready. Currently I'm working on driver for NAND memory for U-Boot, so we could flash linux kernel. When that will be ready I'll push the code. Then I'll switch to linux kernel and when it'll be functional I also push the code. At this stage you will not need to have JTAG and you could load the code over serial in U-Boot. If it comes to GSM I didn't work with it before. I actualy worked 6 months in L2/3 team for LTE (on RRC) but it's different story. That could be really outstanding thing if we could run first phone ever with whole code open (from BB up to APP). BR, Marcin

12 years, 3 months

13
37
0 0

Problems while building osmocomBB

by Begerad Stefan

Hi guys, I dunno if that is the right place for my concern about building the osmocomBB source. Here is what I already have done: - downloading the sources for osmocomBB and GNU toolchain for ARM, - setting the PATH for the arm-elf-* executables, - calling make in the src directory. Now, this appears as response of the make command in the terminal: cd shared/libosmocore/build-host && ../configure configure: error: cannot find install-sh, install.sh, or shtool in ".." "../.." "../../.." make: *** [shared/libosmocore/build-host/Makefile] Error 1. If you need details about my system, you can look at the following snippet from the config.log file: This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by libosmocore configure UNKNOWN, which was generated by GNU Autoconf 2.65. Invocation command line was $ ../configure ## --------- ## ## Platform. ## ## --------- ## hostname = ubuntu-stefan uname -m = x86_64 uname -r = 2.6.32-24-generic uname -s = Linux uname -v = #41-Ubuntu SMP Thu Aug 19 01:38:40 UTC 2010 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /usr/sbin PATH: /usr/bin PATH: /sbin PATH: /bin PATH: /usr/games PATH: /home/stefan/osmocomBB/gnuarm-4.0.2/bin ## ----------- ## ## Core tests. ## ## ----------- ## configure:2032: error: cannot find install-sh, install.sh, or shtool in ".." "../.." "../../..". So, I would be very glad, if someone could give me a hint to solve the problem. Thank you in advance. Regards, begy

12 years, 5 months

2
2
0 0

Linux + u-boot port to MT6235

by Harald Welte

Hi All! At my OpenBSC / OsmocomBB talk here at the Embedded Linux Conference Europe, one of the attendees (Marcin, see Cc) came to me after the talk and told me he had recently done a u-boot and Linux kernel port to the MT6235 (that's the ARM926 based chipsets found in the touchscreen MTK phones). He said he has no understanding of GSM or the existing MTK firmware, but is interested in working together with us to try to make the GSM part work. I think that chipset is very intesting, as we could implement the layer1 inside the Linux kernel (and submit that mainline, yay!) and run our layer2 and layer3 implementations as userspace processes on the Linux system, together with the user interface. The performance of those devices should be somewhere between the Openmoko GTA01 and GTA02, and the GSM stack is certainly not going to eat away a lot of the CPU either. I have asked Marcin to write mail to the OsmocomBB mailing list on where we can find the code. He has so far downloaded the code using JTAG. Combining his code with our ramloader might remove that JTAG dependency... Marcin: if you want to push your u-boot / kernel to git.osmocom.org, or want a separate trac installation for your mtk-linux work, pleaes let me know, I'd be happy to host that. 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, 1 month

2
1
0 0

Re: Trouble building Osmocom

by Holger Freyther

On 06/08/2010 09:41 PM, Huseyin Turan wrote: > root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# ls -l arm-elf-gcc > -rwxrwxrwx 1 name1 name1 112344 2006-02-17 23:59 arm-elf-gcc > root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# ./arm-elf-gcc > bash: ./arm-elf-gcc: cannot execute binary file > root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# uname -a > Linux name1-desktop 2.6.28-19-generic #61-Ubuntu SMP Wed May 26 23:35:15 > UTC 2010 i686 GNU/Linux > please try b.) again (you miss the file part) and also please reply to the mailinglist.

13 years, 2 months

6
10
0 0

Newbie: C123 + layer1.compalram.bin + layer23

by Nicolas Bareil

Hello, I try to use the 'host23/mobile' application on a C123 but without success. I followed Steve's instructions[1] with today's git tree (d95eddad): 1. osmocon -p /dev/ttyS0 -m c123xor layer1.compalram.bin 2. ./host/layer23/src/mobile/mobile 3. Power on the phone (output of theses commands is thereafter) But I'm not sure it really works: the firmware seems to freeze (not responding to the power button anymore) and the last output of 'mobile' is: <0003> gsm322.c:257 Sync to ARFCN=104 rxlev=-65 (No sysinfo yet, ccch mode NONE) Based on the low rxlevel, I guess it is not acquiring any meaningful signal? In [2], Steve said the internal antenna was switched off when the cable is plugged in, is it still true? I tried to RTFM but I am stuck here. Thanks for your patience, Footnotes: [1] http://baseband-devel.722152.n3.nabble.com/Running-osmocombb-on-a-Motorol-C… [2] http://lists.osmocom.org/pipermail/baseband-devel/2010-May/000435.html ,---- | % osmocon -p /dev/ttyS0 -m c123xor layer1.compalram.bin | ... | Received DOWNLOAD ACK from phone, your code is running now! | | OSMOCOM Layer 1 (revision osmocon_v0.0.0-598-gd95edda) | ====================================================================== | Device ID code: 0xb4fb | Device Version code: 0x0000 | ARM ID code: 0xfff3 | cDSP ID code: 0x0128 | Die ID code: ebd8283cba021198 | ====================================================================== | REG_DPLL=0x2413 | CNTL_ARM_CLK=0xf0a1 | CNTL_CLK=0xff91 | CNTL_RST=0xfff3 | CNTL_ARM_DIV=0xfff9 | ====================================================================== | | THIS FIRMWARE WAS COMPILED WITHOUT TX SUPPORT!!! | Assert DSP into Reset | Releasing DSP from Reset | Setting some dsp_api.ndb values | Setting API NDB parameters | DSP Download Status: 0x0001 | DSP API Version: 0x0000 0x0000 | Finishing download phase | DSP Download Status: 0x0002 | DSP API Version: 0x3606 0x0000 | LOST 7478! | L1CTL_RESET_REQ: FULL!L1CTL_PM_REQ start=0 end=124 | PM MEAS: ARFCN=0, 27 dBm at baseband, -110 dBm at RF | PM MEAS: ARFCN=0, 26 dBm at baseband, -112 dBm at RF | PM MEAS: ARFCN=1, 30 dBm at baseband, -107 dBm at RF | PM MEAS: ARFCN=2, 29 dBm at baseband, -108 dBm at RF | PM MEAS: ARFCN=3, 43 dBm at baseband, -94 dBm at RF | PM MEAS: ARFCN=4, 32 dBm at baseband, -105 dBm at RF | ../.. | PM MEAS: ARFCN=1023, 33 dBm at baseband, -104 dBm at RF | L1CTL_RESET_REQ: FULL!L1CTL_FBSB_REQ (arfcn=104, flags=0x7) | Starting FCCH RecognitionFB0 (1748:10): TOA=11712, Power=-106dBm, Angle=-22058Hz | FB0 (1775:11): TOA=12528, Power= -65dBm, Angle=-3818Hz | FB0 (1796:5): TOA= 5280, Power= -68dBm, Angle=-16117Hz | FB0 (1799:1): TOA= 96, Power=-109dBm, Angle= 7082Hz `---- ,---- | % ./host/layer23/src/mobile/mobile | ... | Failed to connect to '/tmp/osmocom_sap'. | Failed during sap_open(), no SIM reader | <000e> sim.c:1206 init SIM client | <0005> gsm48_cc.c:61 init Call Control | <0001> gsm48_rr.c:5330 init Radio Ressource process | <0004> gsm48_mm.c:1220 init Mobility Management process | <0004> gsm48_mm.c:971 Selecting PLMN SEARCH state, because no SIM. | <0002> gsm322.c:3466 init PLMN process | <0003> gsm322.c:3467 init Cell Selection process | <0003> gsm322.c:3521 No stored BA list | VTY available on port 4247. | Mobile initialized, please start phone now! | <0002> gsm322.c:3093 (ms 1) Event 'EVENT_SWITCH_ON' for automatic PLMN selection in state 'A0 null' | <000d> gsm322.c:1055 SIM is removed | <0002> gsm322.c:1056 SIM is removed | <0002> gsm322.c:511 new state 'A0 null' -> 'A6 no SIM inserted' | <0003> gsm322.c:3313 (ms 1) Event 'EVENT_SWITCH_ON' for Cell selection in state 'C0 null' | <0003> gsm322.c:2986 Switch on without SIM. | <0003> gsm322.c:540 new state 'C0 null' -> 'C6 any cell selection' | <0003> gsm322.c:2404 Getting PM for frequency 0 twice. Overwriting the first! Please fix prim_pm.c | <0003> gsm322.c:2415 Found signal (frequency 3 rxlev -94 (16)) | <0003> gsm322.c:2415 Found signal (frequency 8 rxlev -86 (24)) | <0003> gsm322.c:2415 Found signal (frequency 16 rxlev -93 (17)) | ... | <0003> gsm322.c:2415 Found signal (frequency 819 rxlev -97 (13)) | <0003> gsm322.c:2404 Getting PM for frequency 955 twice. Overwriting the first! Please fix prim_pm.c | <0003> gsm322.c:2415 Found signal (frequency 982 rxlev -98 (12)) | ... | <0003> gsm322.c:2415 Found signal (frequency 1004 rxlev -91 (19)) | <0003> gsm322.c:2415 Found signal (frequency 1007 rxlev -89 (21)) | <0003> gsm322.c:2415 Found signal (frequency 1009 rxlev -97 (13)) | <0003> gsm322.c:2415 Found signal (frequency 1010 rxlev -86 (24)) | <0003> gsm322.c:2415 Found signal (frequency 1011 rxlev -67 (43)) | <0003> gsm322.c:2415 Found signal (frequency 1012 rxlev -86 (24)) | <0003> gsm322.c:2415 Found signal (frequency 1013 rxlev -80 (30)) | <0003> gsm322.c:2415 Found signal (frequency 1014 rxlev -87 (23)) | <0003> gsm322.c:2415 Found signal (frequency 1021 rxlev -82 (28)) | <0003> gsm322.c:2415 Found signal (frequency 1022 rxlev -98 (12)) | <0003> gsm322.c:2348 Found 97 frequencies. | <0003> gsm322.c:257 Sync to ARFCN=104 rxlev=-65 (No sysinfo yet, ccch mode NONE) `----

13 years, 3 months

4
7
0 0

problem starting out...please help

by Scott Weisman

Hi All, I now have a V171 phone and cable so I thought I might get started with this. I checked out the code and started make. Osmocon built with no problem, but I got this error next: cd shared/libosmocore/build-target && ../configure \ --host=arm-elf-linux --disable-vty --enable-panic-infloop \ --disable-shared --disable-talloc --disable-tests \ CC="arm-elf-gcc" CFLAGS="-Os -ffunction-sections -I../../../../target/firmware/include" configure: WARNING: if you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for arm-elf-linux-strip... no checking for strip... strip checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make sets $(MAKE)... (cached) yes checking for arm-elf-linux-gcc... arm-elf-gcc checking whether the C compiler works... no configure: error: in `/mnt/site/osmocom-bb/src/shared/libosmocore/build-target': configure: error: C compiler cannot create executables See `config.log' for more details make: *** [shared/libosmocore/build-target/Makefile] Error 77 Checking config.log I can see it chokes here: /usr/bin/arm-elf-ld: this linker was not configured to use sysroots collect2: ld returned 1 exit status I am running Arch Linux and have the packages cross-arm-elf-binutils and cross-arm-elf-gcc-base installed. Does anyone have any suggestions to fix this? Thanks!

13 years, 5 months

3
3
0 0

Re: osmocom on windows

by eisencah eisenach

:D Yup the timers too. That's why I would like to keep that piece of code as it is and move only the serial port handling elsewhere (a different thread I) --- On Thu, 10/21/10, Holger Hans Peter Freyther <holger(a)freyther.de> wrote: From: Holger Hans Peter Freyther <holger(a)freyther.de> Subject: Re: osmocom on windows To: baseband-devel(a)lists.osmocom.org Date: Thursday, October 21, 2010, 8:09 PM On 10/21/2010 07:00 PM, eisencah eisenach wrote: > Here's another one. Regarding the select mechanism (the one in select.c). > Other then the serial port and sockets is anything else registered there? > Cause I would like to keep sockets for communication after all (but the select > function will not work on windows for serial ports handles). So I would use a > different mechanism only for serial port scheduling. > Cheers, > Mihai. well.. we handle the timers with it too.

13 years, 5 months

2
2
0 0

850Mhz support

by Hugo Fortier

Hi everyone, I am fairly new to OsmocomBB. Been in North America I acquired a C118(850Mhz/1900Mhz version of the C123) and a C156(850Mhz / 1900mhz version of the C155) but from what I understand at this point is that only 900Mhz and 1800Mhz are supported. I am trying to figure out what modification I need to do in order to implement North American support for OsmocomBB, do I need to modify the firmware or do I only need to modify the host application? Any pointer would be greatly appreciated. I tried to modify the host application but I didn't had any success so far... Also I am trying to acquire a C123 and I find it quite difficult to find in North America, anyone know where I could acquire it from? I have look online but I could only find it on https://www.samstores.com/ and it seem a bit pricey and I have no idea if this store is trust worthy. I am also interested to acquire a BTS for OpenBSC(I currently have OpenBTS running on my USRP) so if you have any pointer on how I could acquire one, let me know. Thanks, Hugo

13 years, 5 months

2
2
0 0

TCH/F

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,

13 years, 5 months

2
3
0 0

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

13 years, 5 months

2
1
0 0

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

13 years, 5 months

1
0
0 0

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

13 years, 6 months

3
3
0 0

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

13 years, 6 months

3
4
0 0

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.

13 years, 6 months

1
0
0 0

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

13 years, 6 months

2
1
0 0

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

13 years, 6 months

2
1
0 0

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

13 years, 6 months

2
1
0 0

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

13 years, 6 months

2
1
0 0

DSP TCH task : time to get/put FAACH

by Sylvain Munaut

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

13 years, 6 months

1
1
0 0

TCH.. OsmocomBB

by Marten Christophe

Hello Deiter ,Sylvian As u advised I completed reading GSM standard, and dig down source code AFAIK , i have recognized the files and parameters where i need to change values to tune for particular TCH, and also understood that how important signaling is to be involved . I just want to know one thing that is , during the channel request MS send burst on RACH with RA ref number, where this RAF or RA reference number stored on MS side , because when Immediate assignment send from the network it must be match before tuning to particular SDCCH, i want to apply a trick here i will copy the RA reference from the immediate assignment message and will replace with original one stored in MS, hence MS will think this channel is for me and tune to the SDCCH accordingly, further it will keep on listening all process like authentication, location updating , again the TCH channel information is send SDCCH without encryption as only authentication procedure needs Kc Ki and SRES, SDCCH is not encrypted and all MS hosting on that SDCCH can decode TCH parameter like FN , TS, ARFCN hopping sequence. but again i need to clarify how L1ctl.c and L23_api.c fetch the decoded data, from immediate assinment masseg. as it is written printf..........%u . From where this will scan or fetch. if i will be able to know, where MS kept stored the input values advised in signaling messages by BTS on PCH, or AGCH. so i can manipulate them and land on CCCH, and then SDCCH then TCH. kindly tell me if it is feasible , or there is more i need to think. Kind Regards,

13 years, 6 months

2
1
0 0

Re: osmocom on windows

by Dieter Spaar

Hello Peter, On Thu, 7 Oct 2010 11:54:28 +0200, "Peter Stuge" <peter(a)stuge.se> wrote: > > Does e.g. the CodeSourcery toolchain really need Cygwin? That would > suck. I don't know CodeSourcery, I use GNU ARM directly from www.gnuarm.com. According to the CodeSourcery FAQ, they do not require Cygwin. Are there any benefit using CodeSourcery ? I had issues in the past with the firmware using a different GNU ARM version, so I switched back to 4.0.2 which seems to be the same other use on Linux and so far it works OK. You don't seem to like Cygwin, my experience with it is not that bad, OpenBSC (not with GPRS yet due to the need for the TUN device), OsmocomBB, GNUradio and Airprobe run with minor adjustments (just to name GSM related stuff I use under Cygwin). Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

13 years, 6 months

4
4
0 0

AW: wrong decoding of bit vectors

by Andreas.Eversberg

> if (bv->data[bytenum] & (1 << bitnum) == bitval) > return H; i must correct: if ((bv->data[bytenum] & (1 << bitnum)) == bitval) return H;

13 years, 6 months

2
1
0 0

wrong decoding of bit vectors

by Andreas.Eversberg

/* check if the bit is L or H for a given position inside a bitvec */ enum bit_value bitvec_get_bit_pos_high(const struct bitvec *bv, unsigned int bitnr) { unsigned int bytenum = bytenum_from_bitnum(bitnr); unsigned int bitnum = 7 - (bitnr % 8); uint8_t bitval; if (bytenum >= bv->data_len) return -EINVAL; bitval = bitval2mask(H, bitnum); if (bv->data[bytenum] & bitval) return H; return L; } hi, this is part of bitvec.c of libosmocore. it returns if a given bit in the vector is "high" or "low". the bitval that represents "high" depends on the bit position. bitval2mask returns that. so we must check if the bit in the vector equals the returned bitval. i suggest to fix it that way: if (bv->data[bytenum] & (1 << bitnum) == bitval) return H; any complains? without it we cannot check the system information's rest octets. they are essential for any multiband mobile. regards, andreas

13 years, 6 months

1
0
0 0

Inquiry on osmocom

by Akilesh Sethu

Hey, I am working on Android Mobile Operating System. Is it possible for me to port osmocom GSM stack to any of the Android compatible mobiles. Regards, Akilesh Sethu

13 years, 6 months

2
1
0 0

Re: osmocom on windows

by Dieter Spaar

Hello Peter, On Thu, 7 Oct 2010 13:24:50 +0200, "Peter Stuge" <peter(a)stuge.se> wrote: > > In practise it can be negligeable, just another DLL, but it isn't > Windowsy, and for someone who wants Windowsy, Cygwin isn't a really > good answer. (But it can save plenty of time instead!) Exactly, saving time is the point. A software developer, regardless of coming from Windows or Linux should have no problem to understand OpenBSC/OsmocomBB/Airprobe from the OS or C language perspective (I don't talk about GSM specific things, this is something else). I want to use those project and develop for them and not waste my time with things like adopting C language specific issues. > OpenVPN has one, it's signed too. I know, but you have to use the TUN device differently than on Linux, so some adjustments are necessary (besides not knowing if Windows will do proper NAT with the IP traffic from the phone). So I run OpenBSC in a VM if I need GPRS support instead spending time on issues I don't care if I want to use this software or develop for it. > Cool, that's proof that Cygwin is pretty good stuff. It doesn't say > almost anything about how these projects run on Windows though. They work for me, I want to use them and I want to develop for them and so far I could do all I want. Of course this is something else if you for example want to run OpenBSC in a production environment with lots of BTSs. A native Windows port is surely possible, but for me I don't see any benefits besides wasting time. Of course if someone want to sponsor a native port, why not, than at least the time for this effort is paid ;-) > That isn't neccessarily a bad thing at all, evolving the project > internally or the featureset or whatever can be much more important > than adapting the project to work "on" more operating systems. I don't have the impression that more people would work on those GSM related projects if they would directly run on Windows. I think the main obstacle is that you need to know quite a lot of GSM to make use of them. And if you are able to learn and understand the GSM related stuff, using Windows and/or Linux should be no problem at all for you ;-) Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

13 years, 6 months

4
4
0 0

Removing the C123 RX filter

by Sylvain Munaut

Hi, As a prelude to various experimentations, I had to remove the RX filter on some C123. As this can be useful to others, I've done a little summary of how I do it. It's not for the faint of heart tough :) http://www.246tnt.com/gsm/rx_filter.html Comments welcome of course. Cheers, Sylvain Munaut

13 years, 6 months

4
3
0 0

AW: Newbie: C123 + layer1.compalram.bin + layer23

by Andreas.Eversberg

> But I'm not sure it really works: the firmware seems to freeze (not > responding to the power button anymore) and the last output of 'mobile' > is: > > <0003> gsm322.c:257 Sync to ARFCN=104 rxlev=-65 (No sysinfo yet, ccch mode NONE) hi nicolas, be sure to use the branch of sylvain: sylvain/testing (i think you did) the process freezes after many sync requests due to a memory leak that has not been fixed. without the fix, the full network search process should run several times without freeze. but in your case it looks like freezing every first sync request. can you watch the display of your c123? see if it gets a little darker at the point it freezes (when trying to sync). regards, andreas

13 years, 6 months

2
1
0 0

PATCH: Framebuffer for C123 and C155

by Christian Vogel

{Resent, it didn't appear on the list after 20 minutes.} Hi, I had some spare time the last days and put together a first attempt at a framebuffer for the OSMOCOM mobiles. It currently supports the C123 and the C155, the only two phones I own. > On Sat, 10 Apr 2010 10:26:05 +0300, Harald Welte > >1) we need a way to select between individual fonts ... > > Something like display_select_font(FONT_5x8) to be called > > before a display_puts() sounds like a reasonable API for this. the current API looks like this: fb_clear(); fb_setfg(FB_COLOR_GREEN); fb_setbg(FB_COLOR_WHITE); fb_setfont(FB_FONT_HELVB14); fb_gotoxy(2,20); fb_putstr("Hello World!",framebuffer->width-4); fb_setfg(FB_COLOR_RED); fb_setbg(FB_COLOR_BLUE); fb_gotoxy(2,25); fb_boxto(framebuffer->width-3,38); fb_setfg(FB_COLOR_WHITE); fb_setfont(FB_FONT_5X8); fb_gotoxy(8,33); fb_putstr("osmocom-bb",framebuffer->width-4); fb_flush(); Which results in an output such as: http://vogel.cx/git/20101011_hello_world_c123.jpg http://vogel.cx/git/20101011_hello_world_c155.jpg > - If we want to support arbitrary sized fonts, we either should buffer > the display in RAM (might be wasteful on high res color displays?) ... This patch keeps a image of the LCD in a RAM and only copies "dirty" parts upon changes. > >2) Removing all the special characters might not be the best idea to do. > > If at all, it should be a compile time option whether or not to drop > > the special characters. > > Also, the check for replacing a character with '?' needs to be > > a font-specific and not a global decision. This patch currently encodes only #32..#127 to conserve space, but it supports leaving out arbitrary characters. When the data is actually put into ROM we can spare additional space on more glyphs and/or fonts. I currently don't have commit access to the git-repo, so I couldn't upload my vogelchr/framebuffer branch. Please have a look at the patch you can download from http://vogel.cx/git/20101011_framebuffer.diff It removes the old display code completely and replaces it with the framebuffer, but currently only "hello world" makes use of it by creating the image in the photographs linked above. It should apply cleanly to today's master (11.Oct.2010) as it doesn't touch anything where currently work is being done. Please send me your comments on that patch. Greetings from the Dillberg, Chris

13 years, 6 months

1
1
0 0

PATCH: Framebuffer for C123 and C155

by Christian Vogel

Hi, I had some spare time the last days and put together a first attempt at a framebuffer for the OSMOCOM mobiles. It currently supports the C123 and the C155, the only two phones I own. > On Sat, 10 Apr 2010 10:26:05 +0300, Harald Welte > >1) we need a way to select between individual fonts ... > > Something like display_select_font(FONT_5x8) to be called > > before a display_puts() sounds like a reasonable API for this. the current API looks like this: fb_clear(); fb_setfg(FB_COLOR_GREEN); fb_setbg(FB_COLOR_WHITE); fb_setfont(FB_FONT_HELVB14); fb_gotoxy(2,20); fb_putstr("Hello World!",framebuffer->width-4); fb_setfg(FB_COLOR_RED); fb_setbg(FB_COLOR_BLUE); fb_gotoxy(2,25); fb_boxto(framebuffer->width-3,38); fb_setfg(FB_COLOR_WHITE); fb_setfont(FB_FONT_5X8); fb_gotoxy(8,33); fb_putstr("osmocom-bb",framebuffer->width-4); fb_flush(); Which results in an output such as: http://vogel.cx/git/20101011_hello_world_c123.jpg http://vogel.cx/git/20101011_hello_world_c155.jpg > - If we want to support arbitrary sized fonts, we either should buffer > the display in RAM (might be wasteful on high res color displays?) ... This patch keeps a image of the LCD in a RAM and only copies "dirty" parts upon changes. > >2) Removing all the special characters might not be the best idea to do. > > If at all, it should be a compile time option whether or not to drop > > the special characters. > > Also, the check for replacing a character with '?' needs to be > > a font-specific and not a global decision. This patch currently encodes only #32..#127 to conserve space, but it supports leaving out arbitrary characters. When the data is actually put into ROM we can spare additional space on more glyphs and/or fonts. I currently don't have commit access to the git-repo, so I couldn't upload my vogelchr/framebuffer branch. Please have a look at the patch you can download from http://vogel.cx/git/20101011_framebuffer.diff It removes the old display code completely and replaces it with the framebuffer, but currently only "hello world" makes use of it by creating the image in the photographs linked above. It should apply cleanly to today's master (11.Oct.2010) as it doesn't touch anything where currently work is being done. Please send me your comments on that patch. Greetings from the Dillberg, Chris

13 years, 6 months

1
1
0 0

Re: osmocom on windows

by Dieter Spaar

Hello Mihai, On Thu, 7 Oct 2010 05:25:27 -0700 (PDT), "eisencah eisenach" <wbg_1000(a)yahoo.com> wrote: > > PS. The thing is I've done windows programming up until now, but maybe I > should adapt instead of trying to the sw :) I am mainly doing Windows software development, but I don't see any benefits from spending lots of time to adopt C language specific things in the source code so that it compiles with the MS compiler (be it either gcc specific language features or missing language features in the MS compiler). So I use Cygwin which also emulates at least those Unix specific features used in OpenBSC/OsmocomBB/Airprobe. And the C standard libraries are not that different that you won't understand what is going on. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

13 years, 6 months

1
0
0 0

Re: OsmocomBB.TCH.

by Dieter Spaar

Hello Marten, just some basic technical note about what you are planning to do. The following _could_ work (to be sure if this is really usable in the planed environment much more research has to be investigated): - The BTS is based on a modified version of OpenBTS which allows to send a TCH without the need for signalling to setup the TCH. Similar everything on the uplink TCH will be played back. - The phones are based on OsmocomBB and receive the TCH from the BTS and play it back, they do not send anything on the TCH yet. - If you make sure that only one phone at once will send, it would be possible to press a button on the phone which will start transmitting on the TCH and then talk, similar to simple CB Radio handsets. On the BTS side you will hear the result. However all the adjustments to OpenBTS and OsmocomBB, even for a simple "Proof of concecpt" are not trivial. So you have to understand OpenBTS and OsmocomBB to make the required changes, you cannot expect that a short answere here on the list is the solution for the problem. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

13 years, 6 months

1
0
0 0

Re: osmocom on windows

by Dieter Spaar

On Thu, 7 Oct 2010 02:22:52 -0700 (PDT), "eisencah eisenach" <wbg_1000(a)yahoo.com> wrote: > > I would like to compile the hole thing for windows (change in the osmocore > lib the suport functions - use maybe pipes instead of sockets). What is the whole thing ? The phone firmware has to be compiled by an ARM compiler, and if you use GNU ARM, you need Cygwin anyway. If you want to use a different compiler for the host software, you most certainly have to adjust quite a lot of the source code, expecially when using the Microsoft C compiler. And why use pipes instead of sockets, Windows has sockets. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

13 years, 6 months

4
3
0 0

osmocom on windows

by eisencah eisenach

Hello everybody. I've done my reading on GSM these last months and have a general ideea how it works. I would like to try to run osmocom on Windows (hope don't get stoned for this :) ) I've been going throgh the files and see how interprocess communication is done (between osmocom and osmoload for example). Do you have any recommendation about what to use on windows as the interface between the 2 programs? Has anyone else tried it? Cheers, Mihai.

13 years, 6 months

4
4
0 0

Re: OsmocomBB.TCH.

by Marten Christophe

> > Hello All, > > How can i download the source code for sylvain/testing branch . > to my PC ? > > I just downloaded git://git.osmocom.org/osmocom-bb.git, > but it is not reflecting / having the file addition and modification or > the changes sylvain/testing branch commited one hour before. > > is there any new trunck for this. or other command then git clone git:// > git.osmocom.org/osmocom-bb.git, > > Kind Regards, > > >

13 years, 6 months

8
15
0 0

Re: OsmocomBB.TCH.

by Dieter Spaar

Hello Sylvain, On Mon, 4 Oct 2010 22:13:13 +0200, "Sylvain Munaut" <246tnt(a)gmail.com> wrote: > > And Dieter's code probably worked on some internal version of the code > that were never even commited on the public tree and he may not even > have any more ... Yes, exactly, this code was never commited. Its main purpose was to get the TCH up and running. BTW, I still do not fully understand what Marten wants to do: - send a TCH ? If yes, with which device, a BTS or a GSM testset like I did with the HP8922 ? If it is the HP8922, this sending of audio data over one the external connectors of the testset also works with a full MOC or MTC, so no need to hack anything. Just use Sylvain's TCH testing branch and perform a MOC or MTC. This of course works with any GSM phone, so no need to use OsmocomBB at all... - something else I have not understand yet which requires just TCH receiving and no signalling ? Or recieve the same TCH on multiple phones ? Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

13 years, 6 months

2
1
0 0

Re: OsmocomBB.TCH.

by Dieter Spaar

Hello Nordin, On Mon, 04 Oct 2010 09:43:36 +0200, "Nordin" <bouchtaoui(a)gmail.com> wrote: > Maybe he needs just a simple example how you guys do that. That might > help him to see some logic in the code and can pick it up quickly. Also, > you never know what experience he has, maybe with some help he can help > you back more. But than again, it's all up to your free time, which is > always too short. The code I used when I started to implement the TCH in Layer-1 will no longer work with the current version of OsmocomBB so it is of no help. This means I have to rewrite it and test it to be sure that it works as expected which will take some time, time as you already mentioned, is my free time and this free time is valuable. I have the impression that in this case a quite detailed explanation including a working example is necessary and some hints won't help but only result in more questions. Although it might sound harsh, but knowledge in GSM and being able to read/understand/modify foreign source code is necessary, noone can expect this to learn here by asking the list. If one takes OsmocomBB as it is and registers to a cell and makes a call, the logging output should give a lot of hints what calls to L1CTL have to be done. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

13 years, 6 months

4
4
0 0

Re: OsmocomBB.TCH.

by Dieter Spaar

Hello Marten, First of all please be aware that OsmocomBB is now in a state where it can be used for voice calls without any special tricks so there is no need to tune on the voice traffic of the HP8922 GSM testset, you can use the GSM testset as a normal basestation. On Wed, 29 Sep 2010 23:00:44 +0000, "Marten Christophe" <technosabby(a)gmail.com> wrote: > > Q.1) i learned from wiki how to change ARFCN from Layer on application by > using below command, but how to tune right TS ? > > ./layer23 -a 871 -i 127.0.0.1 For my inital TCH testing I did not use Layer23 at all, I only used Layer1 in the phone with special test code using a fixed ARFCN. > Q.2) even If OsmocomBB Layer1 CTL is able to tune to right ARFCN and Time > Slot, will i be able to listen what so ever broadcasting from HP8922 from > C123 speaker or PC speaker. non-encrypted, debugging non-hopping) Yes. > Q.3) what command and interface will be used to enter the frequency hoping > parameter, in case i will use FH option? to tune OsmocomBB l1CTL You have to write your one code if you want to do this without Signalling beeing involved. > Q.4) How to enter Minimalistic L1 interface, what is interface available to > insert theses command to layer1 You can use the L1CTL API to setup a TCH with your own code, but its probably easier to setup the TCH with signalling (either MOC or MTC), this way you don't need to modify the code and still get the TCH running. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

13 years, 6 months

5
8
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel October 2010