baseband-devel April 2010

baseband-devel@lists.osmocom.org

25 participants
42 discussions

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

26 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

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

26 Apr '10

hi, 1) thanx for that info. i can see that you tried running it... 2) i have not checked it. i hope that msg->l3h points to l2 pseudo header. 3) before fixing that, i need to have an issue solved: two approaches to free a message, if it passes a layer border? a) the sending layer frees the message after calling the other layer. b) the receiving layer frees the message. i prefer the second approach, because the message can be queued by the receiving layer without duplicating it. but if i read lapdm.c, i cannot figure out what approach is ment to be used: - 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. this issue must be solved soon, i think. thanx for looking at it, andreas -----Ursprüngliche Nachricht----- Von: Sylvain Munaut [mailto:246tnt@gmail.com] Gesendet: Montag, 26. April 2010 15:22 An: Andreas.Eversberg Cc: baseband-devel(a)lists.osmocom.org Betreff: Re: Layer 3 status Hi, > i will start testing it tonight and hope to get results soon. Here's a few bug reports Sorry, there are no 'proper' fix or patches for them, I just worked around them with ugly hacks see if I could get up to LOCATION UPDATE REQUEST, then it was kinda late ... I hope just pointing them out will help you a bit anyway. 1) Typo in src/host/layer23/src/gsm322.c -> gsm322_a_sel_first_plmn /* if no PLMN in list */ - if (plmn_first) { + if (!plmn_first) { 2) BCCH message don't have the same header. See in src/host/layer23/src/gsm48_rr.c in gsm48_rr_unit_data_ind struct gsm48_hdr *gh = msgb_l3(msg); But in BCCH some message don't have this header and have a 'L2 pseudo length' field ... 3) You do a msgb_free on messages in , but the layer 1 will actually have freed those message already. See src/host/layer23/src/main.c in layer2_read(struct bsc_fd *fd) l1ctl_recv((struct osmocom_ms *) fd->data, msg); msgb_free(msg); // <====== Sylvain

1 0

Layer 3 status
by Andreas.Eversberg 26 Apr '10

26 Apr '10

hi, i like to give a short update about the current layer 3 development. everything compiles, but is not tested and debugged yet. it is divided into five processes: - radio ressource this process is partly complete. it implements functions to establish radio ressource connection. especially handover and release/abort is not implemented, but will follow soon. most things here depend on services of the radio part. as the radio part gets more and more functionality, the radio ressource can be more and more completed. - mobility management this process is complete. it also implements the location update process. - call control this process is complete. the MNCC interface of the call control is almost identical to the openbsc. therefore i would suggest to merge both "mncc.h" header files and put them into osmocore. currently there is a minimal application in mnccms.c which rejects any call. (any MS must at least do this.) later, a small telephone application could be used. - cell selection this process is complete. it does not do any measurements on the radio part for cell (re-)selection. what it does is taking the results and storing them in a structure. the structure is then used for selecting a cell. it also controls the frequency used by the radio part. - PLMN selection this process is complete. but the manual cell selection requires a user interface, which does not yet exist. it uses informations from cell selection process to select available networks. the term 'complete' refers only to basic call/data service. there is no VGCS, VBS, multislot, GPRS, SoSLA support. since there is no interface to the SIM card process (reading of data / storing data), there is just a comment in the source code whenever data has to be transferred from/to the SIM. also some special things, like NCC or cell priorization may be missing. i will start testing it tonight and hope to get results soon. regards, andreas

2 1

Re: Re: Off-by-one errors in Tx timing
by Dieter Spaar 26 Apr '10

26 Apr '10

Hello Sylvain, > Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes > > When you look deeper into the call, there is the PLL setup that is done > even earlier, to ensure that it's finished by that 'start' time. The earlier versions I refer to did no yet switch RX/TX for each burst, they used to switch after four burst were received/transmitted. In those versions only the ABB windows was used with the TPU, however we had the same situation because the code till enabling the TPU took longer than the "AT" value. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Re: Off-by-one errors in Tx timing
by Dieter Spaar 25 Apr '10

25 Apr '10

Hello Sylvain, On Sun, 25 Apr 2010 15:16:48 +0000, 246tnt(a)gmail.com wrote: > > * For RX it always worked for TS=0 because in l1s_rx_win_ctrl we put the > first command AT(DSP_SETUP_TIME - 100) ... which when you do the modulo > 5000 is somewhere around 4944. So when we start executing the TPU scenario > in the interrupt handler, that first AT command will force to wait almost > an entire frame and the rx window will be properly placed in the next frame. To be true, I don't know where the "- 100" in the recent versions come from. In earlier version the actual AT time was 54 (DSP_SETUP_TIME - TSP_DELAY - 6). This is about 50 us. However we had the same situation (actual processing happens in the next frame) because the time to execute the code after the interrupt occured till the TPU was enabled took a little bit more than those 50 us. Probably the code has changed in recent versions so that it tooks less than those 50 us and "- 100" is needed. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

Off-by-one errors in Tx timing
by Harald Welte 25 Apr '10

25 Apr '10

Hi all, as this has been a quite weird bug so far, and Sylvain now seems to have run into some related problems when trying to make a SDCCH8 on TS1 work, I'll elaborate a bit more on it. Before commit 0e9d250407f589cff312adc6c9e2c83f6af37de5, what happened was as follows: 1) The time between the TDMA interrupt happening and starting to execute l1_sync() and actually being able to configure the TPU window and tell the DSP what to do was too short for performing the scheduled work in the very same TDMA frame. 2) As a result, the actions that we thought were performed in the same TDMA were actually performed one TDMA later. Somehow we must have had another off-by-one error and thus the two errors compensated themselves in most cases, particularly for Rx 3) When trying to send, we hand a MAC BLOCK of 23 bytes to the DSP, after which the DSP has to do the FEC, Fire CRC, burst spreading, etc - before being able to generate the bits for the furst burst. Those bits then get sent over the TSP to the ABB (into its burst buffer), from where they are sent based on TPU signals. So what happened is that the data of the first burst was not in the burst buffer yet, and the TPU signals triggered sending the last burst of the previous MAC block, rather than the first burst of the current. This is why Dieter added the > tpu_enq_at(5000 - 10); /* TPU_CLOCK_RANGE - EPSILON_SYNC */ to l1s_tx_win_ctrl(), thereby delaying the TPU signal generation by one TDMA frame. At that time, the DSP has by long finished writing the new burst bits in to the ABB burst buffer, and we can transmit the correct burst data. I personally believe it would be better to simply move the TDMA interrupt a bit more ahead. Rather than occurring immediately before TS0, we could set SYNCHRO in a way that it occurs at a defined point in time still quite a bit into TS7. In this case we hopefully have enough time for the DSP to be able to transmit in TS0, making the timing sequence easier to understand. Hope that helps to explain... -- - 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 2

PWT and PWL relation
by emersonv6 22 Apr '10

22 Apr '10

Hi, I've playing for a while with the buzzer & PWT registers and I'm able to hear 'sound' according to the frequencies supported. The thing I can't not understand well is the relation between the PWT (pulse width tones) and the PWL (pulse width light), if exists: A) After loading some frequency into the PWT, set the volume and hear the it, if I change PWT to BU in the ASIC_CONF_REG, backlight intensity changes and sound stops. B) With LT output selected in the ASIC_CONF_REG instead of PWL, changes over the PWT registers produce nothing.

1 0

backlight reg?
by emersonv6 22 Apr '10

22 Apr '10

Hi, I was reading the bl_mode_pwl function at backlight.c and found that PWL_CTRL is being written at 0xfffe8002 (0xfffe8000 + 2) which doesn't map to any known reg. According to the second datasheet PWL_CTRL (Control Register (PWL_CTRL_REG) (Read / Write)) is located at 0xfffe8001. maybe i'm wrong? regards, emerson.

2 1

plabs prj
by emersonv6 22 Apr '10

22 Apr '10

Hi, plabs project seems to be removed from sf.net, did somebody mirror it or something? regards, emerson

2 1

How to grow and scale the project?
by Harald Welte 20 Apr '10

20 Apr '10

Hi! As you can see, there is not really that much progress throughout the last 2 weeks or so. Dieter and myself were the only two who actually looked at how to driver the DSP, TPU and RF hardware, write the drivers for it and the existing layer1 code. Now we're both busy with other (paid) work, and the project almost seems stuck. I would like to see this change. I'm quite sure there are some other folks on this list who would be interested in diving in those lower layer bits of the system. However, I also understand there is not all too much that can be done without running your own non-hopping BTS (as we don't do frequency hopping at the moment). So a working OpenBTS, OpenBSC setup or something like a CMD55 or Racal 6103 are a precondition. Nonetheless, a number of people on this list have access to those devices. I'd like to encourage some other people to also look at this and remove the dependence on Dieter and myself in that area. Furthermore, members of the IRC channel have certainly noticed the growing interest in a potential port to the Mediatek chipset based devicees. Mediatek is churning out more than 95 million chipsets every quarter, so there is plenty of phones around. The data sheets, reference schematics and other training materials can easily be found on a lot of chinese developer websites - as is the Mediatek SDK. However, the critical layer1 and DSP API part is only provided in object code, and the documentation does not document it. Still I believe it is feasible. So if you want to stay out of the GSM part, feel like the Calypso is too boring for you: Why not work on getting a minimal custom software image for the MT622x running, including bootloader support, keypad/touchscreen and graphics output? If that is done by the wider community, the so-called experts can focus on looking at the GSM side of things once they have time. Even on the Calypso there are many tasks that still need to be finished, including battery charging, power management, file system, SIM Card API, etc. If you know somebody who understands C development for microcontrollers and wants to help building the worlds first Free Software GSM baseband chipset software, please motivate them to join. We can really need every helping hand we get. Happy hacking, 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)

4 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel April 2010