baseband-devel

baseband-devel@lists.osmocom.org

2022 discussions

state of layer23
by Andreas.Eversberg 07 Jun '10

07 Jun '10

hi, if you pull the git, you will notice that i submitted the lapdm code i was working on. location update with app_mobile works now. (at least for the combined BCCH+CCCH+SDCCH4) the best way to test the location update is to setup a mobile test card to manual network selection, and to set the registered PLMN to the tester's network. see VTY interface for more. what happens: - the previously store ba-list of frequencies is used to search for the registered PLMN. since there is only one frequency on a tester, the power measurement is done on this frequency only. - the power measurement result is positive, so a sync request is made to that channel. - the sync is indicated by layer 1. - the BCCH data is received. the cell is "suitable and allowable". - a sync request is done again, because this cell is the one to "camp on". - a sync request is done again, because the mobility management process makes a location update and requests a channel from the radio ressource. - the sync is confirmed by layer 1. - after syncing to the channel the layer 2 is activated by the BTS. - the location updating request is sent and messages are exchanged until the location update is complete. - the layer 2 is de-activated by the BTS. - the release of layer 2 is currently not processed by RR, so the timout aborts the radio link. (but this is fixed soon) but there are problem: 1. the layer 1 sometimes crashes when sending frames. i guess there is no queue inside... i currently don't care about any confirm of a frame, so i send all frames i need to send. i would like to get a confirm when a frame is sent, so i can send the next frame without making layer 1 overflow. this confirm would also be handy for RACH requests when they are sent. since there are only few message during a location update or a call, i think this is not much overhead. when requesting sync/rach again, all pending frames (RACH request / transmit data) shall be removed inside layer 1. 2. when sending two sync requests to layer 1 without a delay, the layer 1 crashes. i expect to do a sync request at any time. also when sending a sync request before i got a response, i do not know to which the response belongs to which request. (delayed on the serial line) a confirm of every sync request would be handy, so i can wait for this confirm until i make another sync request to a different channel. this confirm just tells me that the layer 1 has received the sync request and is able to receive another sync request. also when syncing to a different channel, i skip any sync result or received frames until i get the confirm, so i can skip any data from the last channel i was synced to. andreas

1 0

Building Osmocom
by Zaki Ud Din 06 Jun '10

06 Jun '10

Hello, I am a little new to ubuntu and am trying to build osmocom-bb but i am facing some problems in doing so. I found your emial address in the .c files present in the Osmocom-bb folder. I have downloaded the GNU toolchain for ARM which is the first step in building Osmocom. But I am not able to understand the second step in which I have to set a path to include the arm-elf-* executables of the toolchain. Would you please help me on this? Awaiting your response, Zaki.

4 3

Finally... FB/SB Layer1 changes working/merged
by Harald Welte 21 May '10

21 May '10

Hi all! I've merged a number of layer1 related changes that I've been working on for quite some time. The major difference is: there is no L1CTL_NEW_CCCH_REQ anymore, it has been replaced by L1CTL_FBSB_REQ. When issuing FBSB_REQ, you can specify what tasks you want the layer1 to perform (any bitmask of FB0, FB1, SB). Also, if the acquisition fails completely, you will get a L1CTL_FBSB_RESP with result=0xff. This means there is now proper error reporting. Let's say you want a relatively quick indication if the ARFCN specified could at all be a BCCH, then issuing FBSB_REQ only with FB0 should return even more quickly. You will definitely get a response after some 15 TDMA frames if there was a frequency burst or not. Furthermore, I have changed some details of the FB/SB acquisition process: Rather than waiting for a fixed amount (500) TDMA frames before switching from FB0->FB1 or FB1->SB, the switch is now done based on thesholds for frequency delta and SNR. The frequency thresholds can actually be specified by L1CTL, the SNR thresholds are hardcoded. One problem with fast scanning was that by erroneous FB0 reports, we tuned our VCO so far off the desired frequency that it never synced to any cell at all anymore. I have reduced that problem by simply resetting the AFC-DAC to its default value every time we start a FBSB acquisition. Andreas: I think it would make sense to use the S_L1CTL_FBSB_RESP and S_L1CTL_FBSB_ERR signals in 'mobile', especially if you receive an _ERR, you can immediately switch to the next ARFCN without wasting further time. My next API change will be to introduce a separate command, i.e. FBSB_REQ will no longer start the multiframe task for BCCH NORMAL/EXTENDED, but the application will have to explicitly request that. However, I don't think I'll find much time throughout the next 10 days or so.. .sorry :/ 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)

1 0

Re: [PATCH 2/2] Add new board gta0x (for Openmoko Freerunner devices) and build it
by Nico Golde 20 May '10

20 May '10

Hi, * Daniel Willmann <daniel(a)totalueberwachung.de> [2010-05-17 11:48]: > For now just copied over the compal_e88 init.c and adapted the RF > frontend functions. For osmocon to work with the GSM download cable > SERCOMM_UART_NR and CONS_UART_NR need to be switched. [...] > +/* describe how the RF frontend is wired on the Openmoko GTA0x boards */ > + > +#define RITA_RESET TSPACT(0) /* Reset of the Rita TRF6151 */ > +#define PA_ENABLE TSPACT(9) /* Enable the Power Amplifier */ > +#define GSM_TX TSPACT(3) /* PA GSM switch, low-active */ > + > +/* All VCn controls are low-active */ > +#define ASM_VC1 TSPACT(2) /* Antenna switch VC1 */ > +#define ASM_VC2 TSPACT(1) /* Antenna switch VC2 */ > +#define ASM_VC3 TSPACT(4) /* Antenna switch VC3 */ > + > +#define IOTA_STROBE TSPEN0 /* Strobe for the Iota TSP */ > +#define RITA_STROBE TSPEN2 /* Strobe for the Rita TSP */ > + > +/* switch RF Frontend Mode */ > +void rffe_mode(enum gsm_band band, int tx) > +{ > + uint16_t tspact = tsp_act_state(); > + > + /* First we mask off all bits from the state cache */ > + tspact &= ~PA_ENABLE; > + tspact |= GSM_TXEN; /* low-active */ [...] I'm not sure what the correct value is in this case but GSM_TXEN is not defined at this point. Cheers Nico

4 3

[PATCH 1/2] osmocon: extend hexdump to show all printable characters
by Jan Luebbe 20 May '10

20 May '10

--- src/host/osmocon/osmocon.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c index b823b5b..4ad48e2 100644 --- a/src/host/osmocon/osmocon.c +++ b/src/host/osmocon/osmocon.c @@ -22,6 +22,7 @@ * */ +#include <ctype.h> #include <stdio.h> #include <stdlib.h> #include <string.h> @@ -418,11 +419,16 @@ int read_file(const char *filename) static void hexdump(const uint8_t *data, unsigned int len) { - const uint8_t *bufptr = data; int n; - for (n=0; n < len; n++, bufptr++) - printf("%02x ", *bufptr); + for (n=0; n < len; n++) + printf("%02x ", data[n]); + printf(" "); + for (n=0; n < len; n++) + if (isprint(data[n])) + putchar(data[n]); + else + putchar('.'); printf("\n"); } -- 1.7.1

2 2

[PATCH 0/2] Add gta0x board support
by Daniel Willmann 17 May '10

17 May '10

Hello, these patches enable osmocom to be run on the Openmoko GTA0x devices (only tested with GTA02). The first patch fixes an issue with baudrate setting in osmocon.c (termios setting wasn't read prior to writing). The second patch adds a gta0x board (currently only copied from compal_e88) and implements the differences in controlling the RF frontend. Use it as follows (on the device): kill all processes communicating with the modem (fso, gsm0710muxd) gta02# echo 1 > /sys/bus/platform/devices/neo1973-pm-gsm.0/download Then on the PC connect the download cable and start osmocon: # ./osmocon -m romload -p /dev/ttyUSB0 ../../target/firmware/board/gta0x/l1test.osmoload.bin To initiate the download toggle baseband power on the phone: gta02# echo 0 >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on && > echo 1 >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on After the firmware is transferred the app should start. Regards, Daniel Willmann Daniel Willmann (2): osmocon.c: Fix serial_set_baudrate function Add new board gta0x (for Openmoko Freerunner devices) and build it src/host/osmocon/osmocon.c | 5 + src/target/firmware/Makefile | 4 +- .../firmware/board/common/rffe_gta0x_triband.c | 88 +++++++++++++ src/target/firmware/board/gta0x/init.c | 131 ++++++++++++++++++++ 4 files changed, 227 insertions(+), 1 deletions(-) create mode 100644 src/target/firmware/board/common/rffe_gta0x_triband.c create mode 100644 src/target/firmware/board/gta0x/init.c

1 0

MTK status update
by Steve Markgraf 16 May '10

16 May '10

Hi all, I wanted to give a short status update on the MTK platform, I spent the last day implementing a minimal subset of the MTK romloader protocol in osmocon. We can now run our own C-code on the MT622x, I started by modifying the linker script and run proms loader (because it doesn't need interrupts, the interrupt redirection isn't yet figured out). When writing something to the UART TX register, I see the output in osmocon, and writing to the Baseband powerup register works as well (otherwise you would have to hold down the power-button all the time). Unfortunately there are no schematics for the Mobistel phone I've been testing this with, so I haven't found out how to enable e.g. the backlight, nothing happens when activating PWM1/2. Today I tried to modify the Calypso UART driver for the MTK UART, but currently I'm stuck with a strange hang somewhere in the driver, maybe I'll look after it tomorrow. That was it for the moment... Regards, Steve

2 1

Newbie + questions: C123 and Racal 6103
by Joerg Albert 15 May '10

15 May '10

Hi, I've recently got pointed to this project. Haven't dealt with any GSM software since the mid-90ies, so I thought it may be some fun to look at the software and participate if I find enough time. I've got access to a Racal 6103 and a C123 to start with. A couple of questions: 1) Do I need attenuators if I wire the C123 to the Racal? Guess not, but I don't want to fry the input of the Racal. 2) External antenna connector on the C123 seems to be a MS-147. I got a couple of HF cables from a WLAN card with this connector: http://shop.meconet.de/artikeldet.php?suchspeicher=110448&proid=550&bez=Cri… but the inner conductor of the plug seems to be a bit short (may be my fault during assembly). Does the MS-147 jack on the C123 switch off the internal antenna if anything is plugged in? 3) Does the PA of the C123 survive without any antenna connected (i.e. if it gets most of the HF reflected back) e.g. in continuous transmit mode? 4) A C123 without battery doesn't start the vendor firmware, display is blank, LED are on, flicker from time to time. Is this a hardware problem or just the vendor firmware missing the battery, i.e. any problem to download osmocom software without any battery? Thanks for any answers!

2 1

PATCH: 5x8 font
by Christian Vogel 14 May '10

14 May '10

Hi, I converted the X font 5x8 for use in BB and added an goto_xy routine in case anyone wants to put something entertaining on the LCD (besides Hello World). Compared to the old 8x8 font.. - doesn't miss the topmost line of pixels :-) - needs 475 bytes instead of 4k (only includes characters ASCII 32 .. 126) - allows for 19x8 characters on the screen hello_world.bin prints out all glyphs for testing. Applies to current "master" (as of 9.4.2010/15:30 MESZ). Chris

6 11

update on layer 3 work
by Andreas.Eversberg 14 May '10

14 May '10

hi, i like to give a short update: currently i am testing the processes of selecting a cell and the network. the processes depend on the coverage, the sim card (network, inserted or not) and the mode (manual or automatic network selection). i hope i will finish this week. to configure mode and sim card and other parameters in the future, i use the VTY, you already know from the OpenBSC project. there you can get informations about the subscriber, the mobile station and the received cells (system informations). i will move all hacked parameters (test sim) to VTY config file. manual network selection mode requires reaction of the user, so it will also be added to the VTY. later the VTY can also command the "call" part to dial, answer and hangup a call. my idea: later these VTY command structure may be used for the phone's menu (up - down - enter - escape), if compiled appropiate. also: if layer 3 is running on the phone, the serial port could directly connect to the VTY, so the phone gets a console interface for debugging and faster configuration. currently the process (with sim card) ends while trying to do a location update. if the given channel is not supported, the program exits. to prevent this, just keep radio TX feature disable. the cell will be re-selected again and again (hopefully if the process works correct). sometimes, especially at the first run, the radio process stops. (no results for measurements, no sync to selected frequency.) also there is something i am wondering: calibration especially for the burst signal phase is measured and then stored on the eeprom by the manufacturer. do we use it? or do we need to do our own calibration? regards, andreas

2 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel