June 2010 - baseband-devel - lists.osmocom.org

Receiving on TS=1 ?
by Sylvain Munaut 20 Jul '12

20 Jul '12

Hi, I've hacked something together to quickly test non-combined CCCH. However, I've hit a problem when trying to receive anything on another timeslot than 0. The TX side seems to work fine as the BTS can see my location update request and answers with a reject, but on the MS side, I never see the reject and wireshark only shows invalid incohrent data on the RX. The frames for SDCCH/8 show really nothing valid (looks like random bytes), things like 09 80 7f 47 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 09 00 47 d5 2d 06 1e 00 00 69 7c a0 91 3d 22 ff ab fe 6c 4f 56 4f 36 ... while the frames for the associated SAACH show at least something gsm-like : 03 03 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b but that's not quite a SI5/6 ... To RX/TX on TS=1, I just delayed the RX/TX window by 625 bits (4 * 156.25) when I'm in dedicated channel mode by chaning the 'start' in l1s_tx_win_ctrl / l1s_rx_win_ctrl Is there something else that should be done ? Cheers, Sylvain

2 5

Use OsmocomBB as OpenBTS / airprobe clock generator
by Harald Welte 15 Mar '12

15 Mar '12

Hi! Recently we've had the idea of using OsmocomBB with a simple firmware that synchronizes to an existing GSM networks FCCH and use the resulting 13MHz clock to drive the USRP for airprobe or OpenBTS. Ideally, we would even use the Calypso-internal PLL (for ARM or DSP) to multiply it up to the required 52 MHz. However, neither the Openmoko nor the Compal/Motorola phones expose any of the 3 clock output pads :( So the only choice is to use something along the lines of the http://focus.ti.com/docs/prod/folders/print/cdcvf25084.html as a quad clock multiplier and attach it to the CLK13OUT signal of the phone. The chip is available for 9 USD in single quantities at digikey, and possibly cheaper at other sources. Combined with a sub-20EUR phone it might be a very cheap but still accurate frequency source for OpenBTS - at least as long as there are any commercial gsm networks available. 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)

8 17

Re: Trouble building Osmocom
by Holger Freyther 26 Jan '11

26 Jan '11

On 06/08/2010 09:41 PM, Huseyin Turan wrote: > root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# ls -l arm-elf-gcc > -rwxrwxrwx 1 name1 name1 112344 2006-02-17 23:59 arm-elf-gcc > root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# ./arm-elf-gcc > bash: ./arm-elf-gcc: cannot execute binary file > root@name1-desktop:/home/name1/osmocom/gnuarm-4.0.2/bin# uname -a > Linux name1-desktop 2.6.28-19-generic #61-Ubuntu SMP Wed May 26 23:35:15 > UTC 2010 i686 GNU/Linux > please try b.) again (you miss the file part) and also please reply to the mailinglist.

6 10

Who would attend a developer room / meeting at FrOSCon ?
by Harald Welte 04 Aug '10

04 Aug '10

Hi! I've been offered a 'developer room' at FrOSCon 2010 (http://www.froscon.de/) which will be at FH Bonn-Rhein-Sieg (http://www.fh-brs.de/) in Sankt Augustin from August 21/22 this year. Before sending a response, I would like to inquire whom of you would actually have any intention of visiting this conference and spending time in the developer room to work on OpenBSC or OsmocomBB ? I think the idea is great to meet some of you guys [again], not only at the annual CCC congress in winter. But there is little point for me to go there if there is no interest from the wider project community. Please provide your feedback ASAP. -- - 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 4

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