baseband-devel April 2010

baseband-devel@lists.osmocom.org

25 participants
42 discussions

Fix building of layer23 against in-tree libosmocore
by Harald Welte 09 Apr '10

09 Apr '10

Hi all! As Andreas has pointed out to me in a phone call yesterday and steve-m mentioned on IRC: Building layer23 with the not-installed (make install) libosmocore from osmocom-bb resulted in link failures. I've now addressed those problems and the repo should be building just fine again. 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

merging prom/pending code (manifest)
by Harald Welte 08 Apr '10

08 Apr '10

Hi Prom! I've now merged (a rebased version of) your prom/pending, including the manifest part. Only one minor issue that I've noticed: 'make clean' does not remove the board/*/*.manifest.o files. Maybe you can fix that at some point. Also, I think it would be better to only export a 'struct manifest' that then has members for all the various parameters (so far only strings with versions, but there might be more stuff in the future). Thanks, 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: questions about layer 1 interface
by Dieter Spaar 08 Apr '10

08 Apr '10

Hello Harald, On Thu, 8 Apr 2010 05:18:15 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > Also, layer1 TX side still has a problem where it transmits the bursts > all off-by-one timeslot, i.e. only 3 out of 4 bursts of a message are > received correctly by the BTS, the other burst is sent at a different > (wrong!) point in time, disturbing some other phone on the same cell. With my fix from a while ago sending works as expected. In the meantime I extended my test code so that I could also verify the correct behaviour against a GSM test set when doing a Location Update. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

questions about layer 1 interface
by Andreas.Eversberg 08 Apr '10

08 Apr '10

hi, currently i am working on radio ressource layer and the sub processes for 1) network selection, 2) cell selection, and 3) location update trigger process. i have problems expecially with the cell selection task. since it requires measurements and detection of carriers (for some time depending on the slot configuration), it must work together with the layer 1 (radio part). here are some examples of messages what i think must exist between layer 1 and cell selection process: (the primitive names are just examples and do not conform to GSM specs.) L1CTL_DM_EST_REQ (which already exists) tune to a channel in dedicated mode (by given channel, frequency and later hopping sequence) L1CTL_IM_EST_REQ tune to a BCCH channel in idle mode (by given frequency) L1CTL_IM_EST_CNF confirm valid carrier signal. L1CTL_IM_INFO_IND info when reading of BCCH was enough for a cell selection (depends on the channel configuration), shall include measurement L1CTL_MEAS_IND periodic info of measurements from the selected channel. (required for cell reselection) take these only as examples, not as required messages. while reading GSM 05.08, this is what i think is required to do cell (re-)selection process or abort radio connection if fails (below minimum level). any help/ideas/suggestions? andreas

2 1

gsm48-andreas / issues.txt
by Harald Welte 07 Apr '10

07 Apr '10

Hi Andreas, some comments to your issues.txt: > How do we send MEASUREMENT RESULTS to RSL? (maybe RSL_MT_MEAS_RES) > what triggers the sending? Or do we just send it from time to time to > layer 1 where it is stored and sent when the time is right? (Then we > might get something like RSL_MT_MEAS_CNF, so we can send the next one, > if we have new measurements available, otherwhise the L1 will use the > old measurement results and resends them without confirming it.) measurement results are sent on the SACCH. The Layer1 has independent transmit queues for the main channel (SDCCH/TCH) and its associated SACCH. So the L23 code needs to send the respective packet to a chan_nr/link_id that indicates transmission over the SACCH. In the GSM TS, there is a primitive by which L1 can indicate that it needs the next L23 message for a given channel, which we don't implement (as we're tunnelling L1CTL through HDLC/serial, the answer would never be back before the next TDMA frame anyway). My suggestion would be: Have a fixed SACCH queue depth of 1 or 2 in L1CTL, and every time we actually dequeue the frame (i.e. send it to the DSP), send an indication of the current queue depth up to L23. We should do this for both the main and the ACCH queue so higher layers can implement some kind of flow control if they want. > I need some RACH primitives like: > - RACH request (tx_ph_rach_req already exists) including value and > offset of RACH slot from now. What exactly do you mean with 'value and offset of RACH slot from now'? As we're operating asynchronously "now" is not defined precisely. I think if you simply tell the L1 that you want to transmit at a specified GSM time (modulo 51), we can schedule it that way. L23 should understand the current CCCH/BCCH layout and determine which lsots are applicable for RACH burst transmission. They can then either say "please transmit at this full gsm time (uint32_t of the frame number)" or "please transmit in next multiframe at fn % 51 == X where X is something specified by L23" > - RACH confirm, the RACK has been sent (with timeslot where is was sent) that should be relatively easy to add, I'll add it during the next days. Meanwhile we can simply assume that it was sent at the timeslot as requested. > Since RACH request must be queued in layer 1 until it the right slot > is reached, I need to tell L1 to cancel it. Whenever I receive a > confirm, I schedule the next one until the maximum number has been > transmitted or until an IMMEDIATE ASSIGNMENT is received on CCCH. I think we can ignore that for now. In the worst case, we send one more RACH request than needed. I know this is dangerous if done by many phones on real networks, but for our current goal of "getting something working in our own gsm test network" this is the kind of shortcut we can take. I know your development style is very different. You seem to be trying to implement something thats fully compliant with the spec. I usually try to take a more incremental/iterative approach. Make something work first, and then iteratively improve/complete it. I hope you can live with the fact that at least for now, L1 doesn't have this support. If you want, we can already define the L1CTL message for it but simply ignore it on L1 until its implemented. > RACH request on RSL: > Does it make sense to put RACH request to the set of RSLms primitives? > (i.e. RSL_MT_CHAN_REQ, not RQD!, RSL_MT_CHAN_CNF, RSL_MT_CHAN_CAN) > What do you say? I think we should mark them explicitly as RSLms_MT_* to make it obvious that it is non-standard RSL. Otherwise, I agree. "CAN" for "CANCEL" is probably causing misunderstanding, lets just write the full word. 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 1

Support for the Calypso romloader in osmocon
by Steve Markgraf 06 Apr '10

06 Apr '10

Hi all, I've added support for the Calypso "non-secure" romloader in my branch steve-m/osmocon. This means we now can execute our code on devices like the Motorola W220, the BenQ A38 (which I've used for development), and the OpenMoko devices (can anyone try to cross-compile osmocon and see if it works?). For more information see in the wiki: http://bb.osmocom.org/trac/wiki/CalypsoRomloader I also added a new model switch for the C140 (-m c140), which automatically adds the "1003" string in the uploaded binary. This is meant for use with proms loader, so now you can upload loader.ramload.bin on the C139/C140 and J100i, and load the application itself with osmoload. Regards, Steve

2 1

Re: Developer Meeting in Berlin / 2010-04-10
by Samuel Omlin 06 Apr '10

06 Apr '10

Hi Harald, That's a bright idea for all the developers behind the project as well as those observers around the project to make a brainstorm with the development and evolution of the project. It's a little pity, however, for those people not going to participate directly in the Developer Meeting at CCC near Berlin. If setting up a "green pathway" connecting to the live meeting on the internet, so the people strongly wanna share their ideas with others will be able to join into the Developer Meeting simultaneously. If there has difficulty in doing such things, maybe recording and uploading the live video of the meeting into the public wiki of the project is another way to share the content and fun of the meeting together with other people all around the world. Thanks. Best Regards, Samuel On Mon, Apr 5, 2010 at 6:00 PM, <baseband-devel-request(a)lists.osmocom.org>wrote: > Send baseband-devel mailing list submissions to > baseband-devel(a)lists.osmocom.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.osmocom.org/mailman/listinfo/baseband-devel > or, via email, send a message with subject or body 'help' to > baseband-devel-request(a)lists.osmocom.org > > You can reach the person managing the list at > baseband-devel-owner(a)lists.osmocom.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of baseband-devel digest..." > > Today's Topics: > > 1. Developer Meeting in Berlin / 2010-04-10 (Harald Welte) > 2. Re: noisy cable? (Nathan Fain) > > > ---------- Forwarded message ---------- > From: Harald Welte <laforge(a)gnumonks.org> > To: baseband-devel(a)lists.osmocom.org > Date: Mon, 5 Apr 2010 09:24:45 +0800 > Subject: Developer Meeting in Berlin / 2010-04-10 > Hi all! > > Since I'm returning from holidays in two days, I think it's a good idea > (for those who are in/around Berlin) to meet again at CCC Berlin. > > This is mainly for me to get an idea where we are (compared to before my > holidas) and how we proceed. Especially the loader seems to have made > progress, as far as I can tell from casual reading of the commitlog. > > I'm also curious to see what's happening on the battery charger, sim > card reader (and other) parts of the system. > > I'd say we'll meet from 7pm on at the CCC Berlin. Anyone interested in > joining, feel free to join! > > Cheers, > 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) > > > > > ---------- Forwarded message ---------- > From: Nathan Fain <nat(a)fains.com> > To: baseband-devel(a)lists.osmocom.org > Date: Sun, 04 Apr 2010 22:17:38 -0700 > Subject: Re: noisy cable? > fyi, using the /dev/cu.** variant solved my problem of osmocon being > unable to write CMD1 to the port. At least, it worked with an FTDI > cable I built. I imagine it will solve the issue with the prolific > cable as well (will try later). > > > > On 29/03/2010 03:39, willem wrote: > > i managed to get hello_world working on my c121, connected through a > > pl2303 usb/serial cable to my macbookpro. > > > > but found that the connection is extremely noisy. > > often the movement of me putting down the phone on the table is enough > > to break the upload. > > is that a common problem with these headphone/serial cable plugs? > > > > > > for the serial device i can use /dev/cu.PL2303-0000201A > > or /dev/tty.PL2303-0000201A > > > > but when using the '/dev/tty...' variant, i have to add this to > osmocon.c > > > > diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c > > index f934dd7..b361eb1 100644 > > --- a/src/host/osmocon/osmocon.c > > +++ b/src/host/osmocon/osmocon.c > > @@ -128,6 +128,9 @@ static int serial_init(const char *serial_dev) > > /* hardware flow control off */ > > options.c_cflag &= ~CRTSCTS; > > > > + /* ignore modem status lines */ > > + options.c_cflag |= CLOCAL; > > + > > /* software flow control off */ > > options.c_iflag &= ~(IXON | IXOFF | IXANY); > > > > ============================= > > > > willem > > > > > > > > > > > > > _______________________________________________ > baseband-devel mailing list > baseband-devel(a)lists.osmocom.org > https://lists.osmocom.org/mailman/listinfo/baseband-devel > >

2 2

AW: Developer Meeting in Berlin / 2010-04-10
by Andreas.Eversberg 06 Apr '10

06 Apr '10

hi harald, i would like to participate (and others maybe too). what if we have somethink like a conference for all the people not in berlin? in our company we do it this way: - a conference number is dialed by all members. - a phone with hands free option can be used on one place where multiple members are. - netmeeting is used for presentation. this can also be via VNC remote desktop. is it possible for you in berlin to establish a VNC server with multiple access, or at least something like a "screen" command? my PRI test machine in my company can be used as conference server for up to 30 parties. it has a german dial-up number. regrads, andreas -----Ursprüngliche Nachricht----- Von: baseband-devel-bounces(a)lists.osmocom.org [mailto:baseband-devel-bounces@lists.osmocom.org] Im Auftrag von Harald Welte Gesendet: Montag, 5. April 2010 03:25 An: baseband-devel(a)lists.osmocom.org Betreff: Developer Meeting in Berlin / 2010-04-10 Hi all! Since I'm returning from holidays in two days, I think it's a good idea (for those who are in/around Berlin) to meet again at CCC Berlin. This is mainly for me to get an idea where we are (compared to before my holidas) and how we proceed. Especially the loader seems to have made progress, as far as I can tell from casual reading of the commitlog. I'm also curious to see what's happening on the battery charger, sim card reader (and other) parts of the system. I'd say we'll meet from 7pm on at the CCC Berlin. Anyone interested in joining, feel free to join! Cheers, 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)

2 1

update on layer 3 process
by Andreas.Eversberg 05 Apr '10

05 Apr '10

hi, the current state of coding can be seen in the src/host/gsm48-andreas/README file of GIT. as noted there, the process of mobility management and call control is completed. this does not mean that it is compiling and working. als debugging has to be completed. the next step would be to follow the compiler errors step by step until all missing and wrong symbols are found and fixed. i will do that later. also the radio ressource is at a point where i like to start integrating it into the layer23 application. today i checked out how the system informations are received and how to send a random access burst. please check out the issues about that at src/host/gsm48-andreas/issues.txt in the GIT. i must note that layer3.c and rslms.c is not needed in my case, since it is part of gsm48_rr.c in order to integrate it, i would like to open a new branch, since there are many other existing files to be expanded. (new structures to header files... see extra.c and extra.h) there must also be a way to get all the changes in the master branch merged to the new branch, so i can react on changes of master branch. i am not that familiar with git, so is there any advice except cherry-picking all the time? or maybe there is a better way of doing that? andreas

1 0

noisy cable?
by willem 05 Apr '10

05 Apr '10

i managed to get hello_world working on my c121, connected through a pl2303 usb/serial cable to my macbookpro. but found that the connection is extremely noisy. often the movement of me putting down the phone on the table is enough to break the upload. is that a common problem with these headphone/serial cable plugs? for the serial device i can use /dev/cu.PL2303-0000201A or /dev/tty.PL2303-0000201A but when using the '/dev/tty...' variant, i have to add this to osmocon.c diff --git a/src/host/osmocon/osmocon.c b/src/host/osmocon/osmocon.c index f934dd7..b361eb1 100644 --- a/src/host/osmocon/osmocon.c +++ b/src/host/osmocon/osmocon.c @@ -128,6 +128,9 @@ static int serial_init(const char *serial_dev) /* hardware flow control off */ options.c_cflag &= ~CRTSCTS; + /* ignore modem status lines */ + options.c_cflag |= CLOCAL; + /* software flow control off */ options.c_iflag &= ~(IXON | IXOFF | IXANY); ============================= willem

4 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel April 2010