baseband-devel

baseband-devel@lists.osmocom.org

1 participants
2024 discussions

Project hardware question
by Drasko DRASKOVIC 30 Jun '10

30 Jun '10

Hi, I have been looking for sometime at OsmocomBB project, but haven't tied it yet. I have seen that software supports a number of Compal phones : Supported Phone hardware Information specific to certain Calypso based phones that we support Designed + Manufactured by Compal, OEM by Motorola MotorolaC115/C117 (E87) MotorolaC123/C121/C118 (E88) -- our primary target MotorolaC140/C139 (E86) MotorolaC155 (E99) -- our secondary target MotorolaV171 (E68/E69) SonyEricssonJ100i So, I was wondering: 1) Which would be best to have to start with, as the most supported target ? 2) Where I can get this phone quickly and easily ? 3) What additional equipment is needed (how do you flash the software and how do you debug) ? 4) Is there some software simulator in which I could see what is happening and how the SW works without actual HW equipment ? Best regards, Drasko

2 1

RSL of Osmocom
by Andreas.Eversberg 30 Jun '10

30 Jun '10

hi, i like to do extensions to the RSLms layer of osmocom. before that i like to ask and discuss if this would be the correct way: instead directly of calling l1ctl_* functions of l1ctl.c, i would like to use RSL messages between layer 2 and layer 3. the lapdm.c would then convert these messages and call l1ctl_* functions. (maybe i could split up lapdm.c into lapdm.c and layer2.c. the selecting the handler for an RSL request could be made at layer2.c, as well as selecting the right handler for the frames received from layer1. only the lapdm part could be handled in lapdm.c. ) the RACH request could be sent using RSL_MT_CHAN_RQD, the confirm could be the same message type, but i prefer to invent a new one: 0x18, but using the same IE layout. also including RSL_IE_MS_POWER_PARAM with the RACH request, could tell the layer 1 about usage of power and TA (which is normally 0 for RACH request). the (UNIT) DATA request may also include RSL_IE_MS_POWER_PARAMS. if omitted, the stored value from the last message with RSL_IE_MS_POWER_PARAMS could used. the (UNIT) DATA indication and request of SACCH may include RSL_IE_L1_INFO IE to receive power and timing control as well as send the actual power and timing advance. i could handle these IE at layer 3 (radio ressource) and forward them to layer 1 (RSL_IE_MS_POWER_PARAM) depending on the supported radio power and on special VTY settings to mess with power and fake timing advance. regards, andreas

2 1

Constructors
by Harald Welte 29 Jun '10

29 Jun '10

Hi! As indicated in other mails, we now have support for gcc-style constructors in OsmocomBB. The way to use them is relatively easy: Simply put "__attribute__((constructor))" at the function that you want to be called during initialization. The way how this works is like this: * gcc and the linker create a table of function pointers to all the functions with that attribute * the code in compal_ramload_start.S takes care of calling lib/ctors.s:do_global_ctors() which iterates over the list and calls each constructor This concept is now used for things like prim_fbsb_init() in layer1, but I have also started to use it for board_init(). This means that board_init() no longer needs to be called from the main() function of each app. We can probably put more stuff into constructors, but we should also be careful as with gcc-4.0.2 we cannot yet indicate priorities and thus there is no explicit way to control the ordering in case of dependencies. 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)

3 3

OsmocomBB Layer1 progress
by Harald Welte 26 Jun '10

26 Jun '10

Hi all! JFYI: The AGC control in L1 is now active. At least it didn't make things worse for me. Maybe people who have had problems acquiring weak cells should give it a try again. I've also fixed some compile problems due to a missing header file, and there is now a L1CTL_DM_REL_REQ where Layer23 can explicitly release the dedicated mode and return to idle mode. Right now the 'mobile' program (specifically gsm322/gsm48_rr) issue another L1CTL_PM_REQ after a location update reject hap[pens, i.e. layer1 is still in dedicated mode but it gets some power measurements. This results in L1 trying to do Transmit in parallel with power measurements and it crashes at some point. I suggest to add the L1CTL_DM_REL_REQ into the state machine, I suppose it should avoid that problem. 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

Some L1 status updates
by Sylvain Munaut 24 Jun '10

24 Jun '10

Hi, The good news, is that hopping and ts[0:4] work just fine and were surprisingly easy to implement. The bugs I thought I had were in fact not related to these and just prior bugs that were never noticed before. (see my sylvain/testing branch). Only L1 is changed, so you'll need to tweak l23 (either the mobile app or layer23 for quick tests) if you want to try them out somehow. Current limitations: - SDCCH8 subchannel 4,5,6,7 won't work. For those, we need to TX and RX in the same frame ... which just isn't possible with the way the primitives work right now. (each assume to have the full frame for themselve). - TS >= 4 may not work When using TS>=4 we should also change the interrupt alignment so that the DSP still has time to do it's job. Switching 'forward' is easy, but when switching 'back', we need to be conscious that we need to skip 1 frame at the very least ... IMHO to solve both those issue, we need a better scheduler/primitives that possibly have some knowledge of the 'span' (in terms of qbit) of each operation. Because if we do a TX on TS=5 for instance, there is no way we can do a RX on TS=0 on the next frame, the tpu window overlap. - No ciphering. That should be trivial to add. Just setup the fn and the kc and set the flag ... the 'l1s.next_time' contains the godd time of the frame TX/RX frame during the primitive execution, so that's the FN to use. Once that's done, the few bits missing from mobile app could be added (and from a quick look, not much is missing ... just the l1ctl_* calls because they don't exists yet) and a full location update with auth and ciphering could be done. The need for a SIM interface grows quickly :) Some 'gotchas' you might encounter that are not fixed yet: - The L1 completion handler crashes. In target/firmware/layer1/prim_tx_nb.c , l1s.completion[L1_COMPL_TX_NB] is set in l1s_tx_test() but that's never called. So you need to comment out l1s_compl_sched(L1_COMPL_TX_NB) in the 'resp' handler temporarly until a proper fix. - Wireshark SDCCH8 subchannel decoding in IMMEDIATE ASSIGNEMENT is just plain wrong. (source code uses % 0x38 instead of & 0x38), need to send a patch for this - layer23 doesn't currently filter much the IMM.ASS it receives so you may end up on a channel that's not yours ... beware. Sylvain

2 3

AW: Some L1 status updates
by Andreas.Eversberg 24 Jun '10

24 Jun '10

> - layer23 doesn't currently filter much the IMM.ASS it receives so > you may end up on a channel that's not yours ... beware. hi sylvain, what do you mean with "much"? i filter the channel with the channel request number (includes random number) in the IMM.ASS message. maybe in the future we can filter the time slot where it was sent (RACH confirm) and compare it also. but this requires RACH confirm with GSM time where it was sent. andreas @harald: is there any time stamp in the RACH confirm? what format would it be? .... from the IMM.ASS parsing: /* 3.3.1.1.2: ignore assignment while idle */ if (rr->state != GSM48_RR_ST_CONN_PEND || !rr->wait_assign) { LOGP(DRR, LOGL_INFO, "Not for us, no request.\n"); return 0; } /* request ref */ if (gsm48_match_ra(ms, &ia->req_ref)) { /* channel description */ memcpy(&rr->cd_now, &cd, sizeof(rr->cd_now)); /* timing advance */ rr->cd_now.ta = ia->timing_advance; /* mobile allocation */ memcpy(&rr->cd_now.mob_alloc_lv, &ia->mob_alloc_len, ia->mob_alloc_len + 1); rr->wait_assign = 0; return gsm48_rr_dl_est(ms); } LOGP(DRR, LOGL_INFO, "Request, but not for us.\n");

3 2

AW: Some L1 status updates
by Andreas.Eversberg 23 Jun '10

23 Jun '10

> I was refering to "layer23" the quick & dirty test app if you want to > play with the layer1. oops. sorry, but anyway i need to improve the IMM.ASS. check against timestamp. i will test all the new features soon and also check the time stamps if they match.

1 0

l1test without hdlc (sercomm)
by Rust, Marco 22 Jun '10

22 Jun '10

Hello, I want to use the power measurements from the l1test in the phone. Therefore I modified the program so only the PM is done and additional some averaging and so on. Finally the information should be sent to an microcontroller over UART. There is the problem: I don't know how to use this HDLC sercomm stuff because I don't have time to understand AND implement it for my thesis in the µc-part. I need a quick dirty hack to deactivate this HDLC. I don't find it in code and tried some hours. I tried "uart_putchar_wait()" and hterm shows me that the bytes are sent with a lot other stuff. What is the easiest way working for me? Thanks a lot. Marco

2 2

[PATCH] l1ctl.c: add missing ntohs for band_arfcn
by Jan Luebbe 17 Jun '10

17 Jun '10

This fixes mangled ARFCN numbers in gsmtap. --- src/host/layer23/src/l1ctl.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/host/layer23/src/l1ctl.c b/src/host/layer23/src/l1ctl.c index 051b3d8..5e683d3 100644 --- a/src/host/layer23/src/l1ctl.c +++ b/src/host/layer23/src/l1ctl.c @@ -165,7 +165,7 @@ static int rx_ph_data_ind(struct osmocom_ms *ms, struct msgb *msg) /* send CCCH data via GSMTAP */ gsmtap_chan_type = chantype_rsl2gsmtap(chan_type, dl->link_id); - gsmtap_sendmsg(dl->band_arfcn, chan_ts, gsmtap_chan_type, chan_ss, + gsmtap_sendmsg(ntohs(dl->band_arfcn), chan_ts, gsmtap_chan_type, chan_ss, tm.fn, dl->rx_level-110, dl->snr, ccch->data, sizeof(ccch->data)); -- 1.7.1

2 1

Thank you
by Zaki Ud Din 17 Jun '10

17 Jun '10

Hello, I am just writing this email to thank everyone who helped me with all the trouble I had while Osmocom. Though I didn't succeed in my objective but it was just a part of my project that I started quite late and was always fighting against time to complete it. Thank you :), Zaki.

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel