baseband-devel

baseband-devel@lists.osmocom.org

2022 discussions

public project with MTK baseband firmware project
by Harald Welte 10 May '10

10 May '10

Hi all! In case you're interested, there seems to be a public project on code.google.com that contains the build environment and baseband firmware sdk from mediatek: svn checkout http://mobile-phone-mtk-project.googlecode.com/svn mtk-project Please note that I don't know about the legality of this. However, it is distributed on a public server/service without any kind of authentication... 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)

7 13

Request for help with VCTCXO measurements
by Harald Welte 10 May '10

10 May '10

Hi all! Right now, one of our many issues in L1 is the frequency stability (or lack thereof). What we do right now is very primitive and is mostly based on guesswork, rather than measurements and good algorithms. In order to change this, we need some measurements to be done. As I am currently again travelling a lot, and my time for OsmocomBB is more limited now, I hope that somebody else will be able to take the measurements as described below. There is a big number of people in this project who now have a Racal 6103 (or similar) measurement device. Also, for those in Berlin, the CCC Berlin has one in its basement lab. What needs to be done: 1) Determine the relation between AFCDAC output and actual carrier frequency. All that is needed is some manual control over the AFCDAC value (e.g. based on keypad events) while the AFC is disabled. Then we continuously transmit bursts (content is unimportant) to the Racal 6103 and note the measured frequency error by the 6103 for every AFC value that we input. Those measurements should then be repeated for each supported band of the phone, preferrably each with a low-frequency channel, a medium frequency and a high-frequency channel. This means something like 10 different AFC values for 3 different channels of each of the 2 bands that the c123/c155 support. Basd on those measurements (preferrably do that series with 2-3 phones) we can construct a function that will tell us which AFCDAC value we should program if we want a given carrier frequency increase/decrease. 2) Determine the temperature related frequency drift and corresponding temperature ADC reading Especially when we transmit, the temperature in the RF section of the phone is assumed to change quite a bit. This means we need to measure the temperature in the oscillator (using the RITA-internal temperature sensor connected to one of the ADC channels of IOTA) and compare that with the frequency drift. In order to measure this, we first need a temperature-ADC driver. Once that exists, we can lock onto a BCCH, then make sure the AFC is disabled and the AFCDAC output value will be stable. Next, one can use e.g. a hairdryer or ice spray to change the temperature. While doing that, we can measure the difference in carrier frequency with the Racal 6103. The absolute temperature in centigrade/kelvin is not actually interesting to us all. All we want to know is: What is the 6103-measured frequency error at a given temperature-ADC-reading. Once again, the measurements should be done for high (1800) and low (900) band independently, just to be sure. Based on their relation we can also model a function, table or other approximation and include that in our AFC code. I think I'll be able to write the code even while I'm on the road - if somebody is able to do the measurements and post them to the mailing list. Thanks in advance, 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)

3 8

Osmoloader stored in Flash?
by Rust, Marco 04 May '10

04 May '10

Hello, I checkout the prom/loader AND prom/loader-crc part and merged it (perhaps I use git wrong way) When I run the loader with "osmcon -m c123xor" the loader starts but says "Failed to initialize flash". I tried to "romload" it with "-m romload" there only beacons but no valid response from phone. Sending beacon... Sending beacon... got 1 bytes from modem, data looks like: ff got 1 bytes from modem, data looks like: 00 got 1 bytes from modem, data looks like: ff Sending beacon... Sending beacon... Sending beacon... Sending beacon... 1. Why the flash initialization fails? 2. Is it (currently) possible to run programs (ex. L1test from flash)? I (think I)read all this rom/ram/bootloader stuff. ------------------------- Marco Rust FOKUS - Fraunhofer Institute for Open Communication Systems Kaiserin-Augusta-Allee 31, 10589 Berlin marco.rust(a)fokus.fraunhofer.de

4 6

I see cells
by Andreas.Eversberg 03 May '10

03 May '10

hi, tests with layer 3 pointed out a problem. when i select a cell, i get updates of system informations, paging requests and immediate assignments. after about half an hour, i get some corrupt frames. i don't know yet what is wrong. 1. is the communication between the layer 1 and layer 2 (over serial link) secure? 2. i must be sure that a message between layers always are: - never get lost (except unit-data or data when connection is aborted) - never are corrupt - received in the order they are sent 3. does layer 1 drop (bcch) frames, if they have biterrors? (as it should do) andreas

3 2

disable comitting of files
by Andreas.Eversberg 30 Apr '10

30 Apr '10

hi, i like to change some tracked files without committing them. when i do "git commit -a", every change is comitted. sometimes i like to play with layer1 code or even change Makefile.inc, but i don't want to reset my changes before committing. any idea how to create a list of omitted files? andreas

3 2

TODO list / Next project goals
by Harald Welte 29 Apr '10

29 Apr '10

Hi! I think we corrently have the following TODO list. GSM Layer 1: * implement transmit power control for transmit * implement SDCCH/8 on TS1-7 (Sylvain) * implement frequency hopping * proper split between synchronous and asynchronous part of L1 (Harald) * TCH/F support (Dieter, after L3 RR/MM/CC is working) * A5/1 and A5/2 encryption support GSM Layer 2: * implement a real layer2 that deserves the name (full LAPDm implementation) * properly encapsulate / abstract the L1 "MPH" primitives so L3 doesnt call L1 directly anymore GSM Layer 3: * test most of the code that Andreas has written (depends on L1 / L2) Misc: * SIM card driver + ISO7816 FS API * Battery charger driver * UI framework * minimal journalling flash file system * decide which RTOS kernel we want to use (Harald) * fully support a working firmware build for the openmoko gta01/gta02 GSM modem using calypso romloader For people who don't feel like they can take any of this work, there is some other work, regarding the mid-term port to our next target platform: * implement host utility for the medaitek MT622x romloader serial protocol * try to get a minimal hello world codebase to run on the MT622x * write hardware drivers for UART, PMU, I2C, SPI, ... of the MT622x 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)

5 4

Re: TODO list / Next project goals
by Dieter Spaar 29 Apr '10

29 Apr '10

Hello Harald, On Wed, 28 Apr 2010 20:26:07 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > GSM Layer 1: > * implement transmit power control for transmit > * implement SDCCH/8 on TS1-7 (Sylvain) > * implement frequency hopping > * proper split between synchronous and asynchronous part of L1 (Harald) > * TCH/F support (Dieter, after L3 RR/MM/CC is working) > * A5/1 and A5/2 encryption support I can take care of * implement frequency hopping * A5/1 and A5/2 encryption support in addition to * TCH/F support because this would fit together (just different setting on the GSM testset to do frequency hopping or encryption with a TCH). Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

AW: not tuning to another bcch
by Andreas.Eversberg 28 Apr '10

28 Apr '10

> This is a known problem, but despite working from morning through night I > really don't have any time to fix the various layer1 issues at the moment, > sorry. In fact, there are some fundamental changes/cleanups required, and > I've already literally spent days in coming up with an architecture that seems > to make sense to me :/ > I know it must be frustrating for you, but it seems our schedules didn't match > very well. hi harald, i am currently testing the process of cell selection. when i limit the number of cells down to 1, i can test some parts of the process. don't worry about frustrating me. i can wait until these issues are solved. until then, there is so much more for me todo: - system information parsing test - testing location update procedure - working on incomplete radio ressource process - maybe start working on some layer 4 application (lcr interface) regards, andreas

1 0

not tuning to another bcch
by Andreas.Eversberg 28 Apr '10

28 Apr '10

hi, while debugging my layer3 code and testing bcch_scan, i got the following problem: the fist 'tuning' message L1CTL_NEW_CCCH_REQ to layer 1 works, system informations are received. subsequently tuning to another channel does not give any rx data. any idea? andreas Mit freundlichen Grüßen, .-. /'v'\ (/ \) ------------------------------------------------------------------"-"- |_| i.A. Andreas Eversberg Network Operations / 2nd Level Data - KC Internet Versatel Nord GmbH Nordstr. 2 D-24937 Flensburg Fon: +49-461-9099749 | Fax: +49-461-909960749 andreas.eversberg@versatel.de@versatel.de | www.versatel.de Sitz der Gesellschaft: Flensburg, Registergericht: Flensburg, HRB 3395 FL Geschäftsführer: Dr. Hai Cheng, Dr. Max Padberg, Joachim Bellinghoven

2 1

AW: Layer 3 status
by Andreas.Eversberg 27 Apr '10

27 Apr '10

> - rslms_recvmsg() frees message if discriminator is not known, otherwhise it forward it to rslms_rx_rll(). > - rslms_rx_rll() forwards messages to rslms_rx_rll_*_req(), but does not free it when RLL message type is unknown. it seems that the message is freed by the receiving layer (or function), but i cannot understand why layer2_read() in main.c does it after calling l1ctl_recv.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel