From altaf329 at gmail.com Fri Jul 20 13:38:59 2012 From: altaf329 at gmail.com (Altaf) Date: Fri, 20 Jul 2012 06:38:59 -0700 (PDT) Subject: Receiving on TS=1 ? In-Reply-To: References: Message-ID: <1342791539055-4025204.post@n3.nabble.com> Hello Sylvain I am using the burst_ind branch and have some doubts. I am using a test network, and it has no encryption. Usually the n/w has a low load and the channel structure followed during the assignment is SDCCH/4 + SACCH/C4 or CBCH(SDCCH/4). and timeslot 0 . The ccch_scan is able to capture the SMS sent on timeslot 0 and also only one of the subchannel as per the above assignment. Just for testing, When I use two phones and send an SMS from both of them simultaneously both are assigned timeslot 0 and different subchannels. CCCH_scan could capture only one SMS. meaning that it could only get one subchannel. Am I right about ccch_scan or does it have the capability to get a complete timeslot. ? Thank you Altaf -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Receiving-on-TS-1-tp739307p4025204.html Sent from the baseband-devel mailing list archive at Nabble.com. From 246tnt at gmail.com Fri Jul 20 14:03:16 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 20 Jul 2012 16:03:16 +0200 Subject: Receiving on TS=1 ? In-Reply-To: <1342791539055-4025204.post@n3.nabble.com> References: <1342791539055-4025204.post@n3.nabble.com> Message-ID: DO NOT just reply to a 2 year old thread with a question that has nothing to do with the original subject without even bothering to change it ... Learn to use a mailing list properly ... if you don't have the time to do that, well then I don't have the time to answer your question either ... Cheers, Sylvain From altaf329 at gmail.com Fri Jul 20 14:12:19 2012 From: altaf329 at gmail.com (Altaf) Date: Fri, 20 Jul 2012 07:12:19 -0700 (PDT) Subject: Receiving on TS=1 ? In-Reply-To: References: <1342791539055-4025204.post@n3.nabble.com> Message-ID: <1342793539352-4025207.post@n3.nabble.com> I apologize about this. -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Receiving-on-TS-1-tp739307p4025207.html Sent from the baseband-devel mailing list archive at Nabble.com. From avwiseav at gmail.com Wed Jul 11 02:37:09 2012 From: avwiseav at gmail.com (bob) Date: Tue, 10 Jul 2012 19:37:09 -0700 (PDT) Subject: burst_ind and TCH In-Reply-To: References: <0022158df35bf87df5049e89e0c2@google.com> Message-ID: <1341974229186-4025141.post@n3.nabble.com> Hi, mad I met the same problem as you, are you settle the problem and capute the TCH correctly now? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/burst-ind-and-TCH-tp2683277p4025141.html Sent from the baseband-devel mailing list archive at Nabble.com. From akkordeonmodricker at t-online.de Tue Jul 31 07:43:02 2012 From: akkordeonmodricker at t-online.de (stephan Modricker) Date: Tue, 31 Jul 2012 09:43:02 +0200 Subject: cp2102 (betemcu, B75937) In-Reply-To: References: Message-ID: <50178C86.6040305@t-online.de> Hi I am a user of a betemcu usbasp ispprogrammer. I can not start the thing. Do you know somebody who could help, please? Thanks ! Best Regards Stephan From mail at thomasbertani.it Sun Jul 22 11:56:09 2012 From: mail at thomasbertani.it (Thomas Bertani) Date: Sun, 22 Jul 2012 13:56:09 +0200 Subject: Sagem OT-290 trace phone / GSMTAP integration Message-ID: Hi list, I'm an information engineering student interested in working on embedded systems and tlc (especially I would like to get deep into firmware coding and dsp). In the last years I have been an active member of the italian openmoko community so I'm familiar with gta0X phones (I owned a gta02, now I have only a gta01). Two years ago I've worked at the Trento's research center on the n900 while today I'm working at a tlc company in Padua. Even if it's not what I'm working on at the moment, I'd like to spend some of my time by working on the GSMTAP integration of the Sagem OT-290. Is there any news about that? Since the last message on this thread was posted more than 2 months ago I wanted to know whether anyone was already working on it. Thanks, Thomas Bertani From mail at thomasbertani.it Sun Jul 22 12:44:50 2012 From: mail at thomasbertani.it (Thomas Bertani) Date: Sun, 22 Jul 2012 14:44:50 +0200 Subject: Sagem OT-290 trace phone / GSMTAP integration In-Reply-To: References: Message-ID: On 22 July 2012 14:26, Tyson Key wrote: > Hi Thomas, > > Although myself and a few others (Denis?) have tentatively volunteered to > work on it, no-one has actually requested (or received) the hardware itself > yet, as far as I know. If I remember correctly, two phones were available - > so it might be possible to share the workload, if arrangements can be made > regarding logistics. > Hi, well I can start to work on it immediately, however I'm not sure whether one or two phones were actually available, so if it's only one, it won't be possible to share the workload. > If you're interested, then I'd suggest asking Harald for a copy of the > protocol specification to read through, to determine its feasibility in > order to figure out how long you think it would take. I've already received it, it doesn't seem an excessively long work but at the moment it would be difficult to do a precise estimation. > I hope that helps, > > Tyson. Thank you for the update, Thomas From GNUtoo at no-log.org Sun Jul 22 20:16:40 2012 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Sun, 22 Jul 2012 22:16:40 +0200 Subject: Sagem OT-290 trace phone / GSMTAP integration In-Reply-To: References: Message-ID: <1342988200.4810.8.camel@gnutoo-laptop> On Sun, 2012-07-22 at 13:56 +0200, Thomas Bertani wrote: > Hi list, Hi, > I'm an information engineering student interested in working on > embedded systems and tlc (especially I would like to get deep into > firmware coding and dsp). Maybe you would also be interested in helping us with the nuttx port on osmocom-bb compatible phones? (the goal is to get an usable phone that would work without the help of a computer, but recently it seem to progress very slowly...). > Even if it's not what I'm working on at the moment, I'd like to spend > some of my time by working on the GSMTAP integration of the Sagem > OT-290. ok. > Is there any news about that? Since the last message on this thread > was posted more than 2 months ago I wanted to know whether anyone was > already working on it. Since There was someone else(Tyson Key) than me willing to do the work, I declined in favor of the other person(because I'm rather busy and he really wanted to do it). But it seem that he didn't get the phone at the end... So I'll decline again, specially if you start working on it now... Denis. From mail at thomasbertani.it Mon Jul 23 06:05:46 2012 From: mail at thomasbertani.it (Thomas Bertani) Date: Mon, 23 Jul 2012 08:05:46 +0200 Subject: Sagem OT-290 trace phone / GSMTAP integration In-Reply-To: <1342988200.4810.8.camel@gnutoo-laptop> References: <1342988200.4810.8.camel@gnutoo-laptop> Message-ID: On 22 July 2012 22:16, Denis 'GNUtoo' Carikli wrote: > On Sun, 2012-07-22 at 13:56 +0200, Thomas Bertani wrote: > Maybe you would also be interested in helping us with the nuttx port on > osmocom-bb compatible phones? (the goal is to get an usable phone that > would work without the help of a computer, but recently it seem to > progress very slowly...). Yes, I am interested in contributing to the nuttx port too, but at the moment I'd like to start by working on this sagem-gsmtap project. > Since There was someone else(Tyson Key) than me willing to do the work, > I declined in favor of the other person(because I'm rather busy and he > really wanted to do it). > But it seem that he didn't get the phone at the end... > So I'll decline again, specially if you start working on it now... Ok, so I can start to work on it as soon as I get the needed hardware. Regards, Thomas Bertani From altaf329 at gmail.com Thu Jul 12 17:10:19 2012 From: altaf329 at gmail.com (Altaf) Date: Thu, 12 Jul 2012 10:10:19 -0700 (PDT) Subject: Osmocom-bb Making a call In-Reply-To: <1340962555365-4025103.post@n3.nabble.com> References: <1338309066299-4021037.post@n3.nabble.com> <1339068139245-4025047.post@n3.nabble.com> <1339159362602-4025051.post@n3.nabble.com> <4FD1F807.6090302@eversberg.eu> <1339404034989-4025054.post@n3.nabble.com> <1339502525325-4025058.post@n3.nabble.com> <1340962555365-4025103.post@n3.nabble.com> Message-ID: <1342113019716-4025172.post@n3.nabble.com> Hello. What does it mean by starting osmocomBB in an external socket mode. In the above post I had a problem with linking OS_BB with LCR. I start OS_BB with the usual command ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/loader.compalram.bin and on starting LCR it says 000000 ERROR (in mncc_socket_retry_cb() line 1101): Could not connect to MNCC socket /tmp/ms_mncc_1 /tmp/osmocom_l2, retrying in 5 seconds I read in one of openBSC mailing lists that starting osmo_nitb with -m is needed to connect it to LCR. And in the command above -m is already there. Is it the same.? How would the command be then to launch the OS_BB firmware so as to connect it to OS_BB. Kindly give me some hint.. regards Altaf -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Osmocom-bb-Making-a-call-tp3997264p4025172.html Sent from the baseband-devel mailing list archive at Nabble.com. From rootbit at yahoo.com Mon Jul 2 14:22:21 2012 From: rootbit at yahoo.com (Gerard) Date: Mon, 2 Jul 2012 14:22:21 +0000 (UTC) Subject: the airprobe port to BB References: <1339499792233-4025056.post@n3.nabble.com> Message-ID: Could you post your patches ? Thanks a lot. From lonelysurfer at web.de Thu Jul 5 04:37:55 2012 From: lonelysurfer at web.de (lonelysurfer) Date: Wed, 4 Jul 2012 21:37:55 -0700 (PDT) Subject: the airprobe port to BB In-Reply-To: References: <1339499792233-4025056.post@n3.nabble.com> Message-ID: <1341463075819-4025114.post@n3.nabble.com> I can't make a patch, cause I used my own tool to generate the input. -- View this message in context: http://baseband-devel.722152.n3.nabble.com/the-airprobe-port-to-BB-tp4024444p4025114.html Sent from the baseband-devel mailing list archive at Nabble.com. From laforge at gnumonks.org Thu Jul 12 07:03:39 2012 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 12 Jul 2012 09:03:39 +0200 Subject: my patch for decode using burst_id In-Reply-To: <1340019535300-4025078.post@n3.nabble.com> References: <20120618090708.GN28821@prithivi.gnumonks.org> <1340019535300-4025078.post@n3.nabble.com> Message-ID: <20120712070339.GK2490@prithivi.gnumonks.org> Dear Bob, On Mon, Jun 18, 2012 at 04:38:55AM -0700, bob wrote: > I have done it, This my pacth for burst_id > but it can`t work well for TCH decode! > http://baseband-devel.722152.n3.nabble.com/file/n4025078/app_ccch_scan.patch > app_ccch_scan.patch you still hve not sent the actual patch to this mailing list. I would appreciate if you could follow common procedures / habits of FOSS projects and send your patches as unified diff to the mailing list for review / comments. Linking code published on a website that is not even online for one month is very inefficient. Now people can still read your mails in the archvie but not your patch. What a waste! Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From akibsayyed at gmail.com Sun Jul 1 17:03:35 2012 From: akibsayyed at gmail.com (Akib Sayyed) Date: Sun, 1 Jul 2012 22:33:35 +0530 Subject: little confusion while studying l1l2 interface via sercomm Message-ID: in layer23 apps we open local unix socket in layer23 app and one in osmocon another socket to communicate in between. now in layer23 we just send (write) or receive (read) msg. but we handle actual communication with phone is handled in osmocon. now flow of functions is main ->register_tool_server->tool_accept->un_tool_read->hdlc_send_to_phone->sercomm_sendmsg then sercomm handles all transmission in details then layer1 accept all data via so i wanted to ask that how does rssi firmware is sending data directly to l1 -l2 and i would also like to ask what is actual protocol used in communication between l1 and l2 -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From altaf329 at gmail.com Tue Jul 3 11:38:05 2012 From: altaf329 at gmail.com (Altaf) Date: Tue, 3 Jul 2012 04:38:05 -0700 (PDT) Subject: little confusion while studying l1l2 interface via sercomm In-Reply-To: References: Message-ID: <1341315485402-4025110.post@n3.nabble.com> Hai. HDLC is the protocol used between L1 and L2 regards, Altaf -- View this message in context: http://baseband-devel.722152.n3.nabble.com/little-confusion-while-studying-l1l2-interface-via-sercomm-tp4025106p4025110.html Sent from the baseband-devel mailing list archive at Nabble.com. From gabriele.rago at email.it Mon Jul 2 21:02:31 2012 From: gabriele.rago at email.it (Gabriele.rago) Date: Mon, 2 Jul 2012 23:02:31 +0200 Subject: help on sim.c Message-ID: <6454628f81036fb68478bb6bd8978c40@2.226.168.72> Hello all, I am using osmocomm (branch sylvain) on a motorola C140. I have uncommented the line "#define DEBUG" on src/target/firmware/calypso/sim.c and recompiled. I have connected an interface between my PC and phone sim slot ( a pl2303 usb module, with a diode between TXD and RXD and a 22K resistor between +5V and RXD). Now I have opened the serial port on my PC with these settings: baud rate = 9600 databits = 8 parity = even stopbits = 2 and I am sending the byte "3B" to the phone, but I see in osmocon console: "SIM-ISR:  Waiting for read (9B)..." (id est the phone seems like to receive "9B" instead of "3B"), where I am wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dario.lombardo at libero.it Tue Jul 3 11:35:56 2012 From: dario.lombardo at libero.it (Dario Lombardo) Date: Tue, 3 Jul 2012 13:35:56 +0200 Subject: Clock from phone Message-ID: In some past post of the ML, I've read that someone was trying to get the GSM 10MHz clock reference from the motorola phones. This aimed at feeding usrp with a stable reference, if I'm not wrong. Anything new this side? This would be extremely useful if GPS signal can't be got but GSM cell can. Dario. From 246tnt at gmail.com Tue Jul 3 11:44:01 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 3 Jul 2012 13:44:01 +0200 Subject: Clock from phone In-Reply-To: References: Message-ID: > In some past post of the ML, I've read that someone was trying to get > the GSM 10MHz clock reference from the motorola phones. > This aimed at feeding usrp with a stable reference, if I'm not wrong. > Anything new this side? This would be extremely useful if GPS signal > can't be got but GSM cell can. 1) It's not 10 MHz but 26 MHz 2) Yes it works, but you can't feed the USRP directly, you need to multiply it by 2 (using a PLL chip) to get 52 MHz for the USRP. Cheers, Sylvain From dario.lombardo at libero.it Tue Jul 3 13:08:02 2012 From: dario.lombardo at libero.it (Dario Lombardo) Date: Tue, 3 Jul 2012 15:08:02 +0200 Subject: Clock from phone In-Reply-To: References: Message-ID: On Tue, Jul 3, 2012 at 1:44 PM, Sylvain Munaut <246tnt at gmail.com> wrote: >> In some past post of the ML, I've read that someone was trying to get >> the GSM 10MHz clock reference from the motorola phones. >> This aimed at feeding usrp with a stable reference, if I'm not wrong. >> Anything new this side? This would be extremely useful if GPS signal >> can't be got but GSM cell can. > > 1) It's not 10 MHz but 26 MHz Mmm... but the front panel of usrp is fed by 10 MHz/1pps... isn't it? > 2) Yes it works, but you can't feed the USRP directly, you need to > multiply it by 2 (using a PLL chip) to get 52 MHz for the USRP. Can you provide some link to read something about it? Don't you think that this way could be much more preferrable than the GPS way, if USRP is under GSM coverage? I mean: the clock from GSM is next to us... why just don't use it? Probably there's something I'm missing, since this approach is much less used than GPS clocking... From alexander.huemer at xx.vu Tue Jul 3 13:27:33 2012 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Tue, 3 Jul 2012 15:27:33 +0200 Subject: Clock from phone In-Reply-To: References: Message-ID: <20120703132733.GD21508@de.xx.vu> On Tue, Jul 03, 2012 at 03:08:02PM +0200, Dario Lombardo wrote: > On Tue, Jul 3, 2012 at 1:44 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > >> In some past post of the ML, I've read that someone was trying to get > >> the GSM 10MHz clock reference from the motorola phones. > >> This aimed at feeding usrp with a stable reference, if I'm not wrong. > >> Anything new this side? This would be extremely useful if GPS signal > >> can't be got but GSM cell can. > > > > 1) It's not 10 MHz but 26 MHz > > Mmm... but the front panel of usrp is fed by 10 MHz/1pps... isn't it? > There are different revisions of the USRP. Sylvain is talking about the USRP1, you of a later rev. The USRP1 has an (unpopulated) direct clock input. The other USRP revisions have a reference clock input, which is something different. > > 2) Yes it works, but you can't feed the USRP directly, you need to > > multiply it by 2 (using a PLL chip) to get 52 MHz for the USRP. > > Can you provide some link to read something about it? > See [1,2,3] > Don't you think that this way could be much more preferrable than the > GPS way, if USRP is under GSM coverage? I mean: the clock from GSM is > next to us... why just don't use it? Probably there's something I'm > missing, since this approach is much less used than GPS clocking... > There are many ways to provide a stable reference clock. A OCXO (e.g. [4]), a cheap rubidium standard, the clock tamer[5], ... Every option has up and downsides. Kind regards, -Alexander Huemer [1] http://lists.osmocom.org/pipermail/baseband-devel/2010-April/000322.html [2] http://bb.osmocom.org/trac/wiki/PirelliDPL10#Phoneasclockgenerator [3] http://sourceforge.net/mailarchive/message.php?msg_id=24642256 [4] http://shop.sysmocom.de/products/ohm4-ocxo [5] https://code.google.com/p/clock-tamer/ From dario.lombardo.ml at gmail.com Tue Jul 3 16:18:20 2012 From: dario.lombardo.ml at gmail.com (Dario Lombardo) Date: Tue, 3 Jul 2012 18:18:20 +0200 Subject: Clock from phone In-Reply-To: References: <20120703132733.GD21508@de.xx.vu> Message-ID: On Tue, Jul 3, 2012 at 3:27 PM, Alexander Huemer wrote: > On Tue, Jul 03, 2012 at 03:08:02PM +0200, Dario Lombardo wrote: >> On Tue, Jul 3, 2012 at 1:44 PM, Sylvain Munaut <246tnt at gmail.com> wrote: >> >> In some past post of the ML, I've read that someone was trying to get >> >> the GSM 10MHz clock reference from the motorola phones. >> >> This aimed at feeding usrp with a stable reference, if I'm not wrong. >> >> Anything new this side? This would be extremely useful if GPS signal >> >> can't be got but GSM cell can. >> > >> > 1) It's not 10 MHz but 26 MHz >> >> Mmm... but the front panel of usrp is fed by 10 MHz/1pps... isn't it? >> > There are different revisions of the USRP. Sylvain is talking about the > USRP1, you of a later rev. > The USRP1 has an (unpopulated) direct clock input. > The other USRP revisions have a reference clock input, which is > something different. > You are definitly right. I was taling about N210, which can be fed by reference clock input. >> > 2) Yes it works, but you can't feed the USRP directly, you need to >> > multiply it by 2 (using a PLL chip) to get 52 MHz for the USRP. >> >> Can you provide some link to read something about it? >> > See [1,2,3] >> Don't you think that this way could be much more preferrable than the >> GPS way, if USRP is under GSM coverage? I mean: the clock from GSM is >> next to us... why just don't use it? Probably there's something I'm >> missing, since this approach is much less used than GPS clocking... >> > > There are many ways to provide a stable reference clock. A OCXO (e.g. > [4]), a cheap rubidium standard, the clock tamer[5], ... > Every option has up and downsides. > Just the "pirelli" way uses clock from existing GSM network. As said before I think that "reusing" the clock from network could be very useful, but I don't know if it is more difficult than generate the signal itself. Is that possible using motorola phones? Did anyone investigate that possibility? From avwiseav at gmail.com Fri Jul 6 09:30:49 2012 From: avwiseav at gmail.com (bob wisebob) Date: Fri, 6 Jul 2012 17:30:49 +0800 Subject: TCH AMR codec in GSM Message-ID: Hi List! I am studying the AMR codec in GSM.but I met some problem. I use burst_id to capture TCH in my test network,and in my programmm, I use the firsrt 8 bits of a TCH block to decide whether it is a tch or not and also get the codec mode of a AFS,and than other operations,but it is not to work , I am struggled to this, any one can help me? this is my code: static void process_tch_amr(struct osmocom_ms *ms,struct l1ctl_burst_ind *bi) { int16_t rx_dbm; uint16_t arfcn; uint32_t fn,B; uint8_t cbits, tn, lch_idx; int ul, bid, i, k, length; sbit_t *bursts, mC[456]; ubit_t steal_bit[2], bt[114],convu[260],convd[260],EFRBits[244],EFRAMR[8 + 244]; pbit_t voice[33]; unsigned char mode; arfcn = ntohs(bi->band_arfcn); rx_dbm = rxlev2dbm(bi->rx_level); fn = ntohl(bi->frame_nr); ul = !!(arfcn & ARFCN_UPLINK); cbits = bi->chan_nr >> 3; tn = bi->chan_nr & 7; B = -1; if((fn%13)%4 == 0) flag= 1; if(!flag) return; B = count_tch % 8; if (B == -1) return; if (B == 0){ for(i=0; i<4; i++){ memset(app_state.mI[i], 0x00, 114); } }else if(B == 4){ for(i=4; i<8; i++){ memset(app_state.mI[i], 0x00, 114); } } /* Unpack (ignore hu/hl) */ osmo_pbit2ubit_ext(bt, 0, bi->bits, 0, 57, 0); osmo_pbit2ubit_ext(bt, 57, bi->bits, 57, 57, 0); /* Convert to softbits */ for (i=0; i<114; i++) app_state.mI[B][i] = bt[i] ? - (bi->snr >> 1) : (bi->snr >> 1); count_tch++; // Deinterleaves i[] to c[] if((B % 4 ==3)&&(count_tch >= 7)){ if(B == 3) { tch_deinterleave(mC, 4); }else{ tch_deinterleave(mC, 0); } //abstract the codec mode for(i = 0;i<8;i++) { //printf("%x ",mC[i]); if(mC[i] < 0) mode = ( mode | (1 << i)); else mode = ( mode & (~(1 << i))); } //printf("mode %x\n",mode); switch(mode){ case CODEC_MODE_1: printf("codec 1\n"); i = find_speech_mode(app_state.amr_arg.amr_acs, 1); break; case CODEC_MODE_2: printf("codec 2\n"); i = find_speech_mode(app_state.amr_arg.amr_acs, 2); break; case CODEC_MODE_3: printf("codec 3\n"); i = find_speech_mode(app_state.amr_arg.amr_acs, 3); break; case CODEC_MODE_4: printf("codec 4\n"); i = find_speech_mode(app_state.amr_arg.amr_acs, 4); break; default: { //printf("unkown codec\n"); return; } } memset(voice,0,32); switch( 1 << i ){ case gsm690_4_75: printf("codec gsm690_4_75\n"); osmo_conv_decode(&conv_tch_afs_4_75, &mC[8], convu); memcpy(convd,convu,39); memcpy(convd,&convu[45],56); tch_map(gsm690_4_75_bitorder, gsm690_4_75_len, EFRAMR + 8,convd); fillField(EFRAMR, 0, 0x04, 8); length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_4_75_len, 1); break; case gsm690_5_15: printf("codec gsm690_5_15\n"); osmo_conv_decode(&conv_tch_afs_5_15, &mC[8], convu); memcpy(convd,convu,49); memcpy(convd,&convu[55],54); tch_map(gsm690_5_15_bitorder, gsm690_5_15_len, EFRAMR + 8,convd); fillField(EFRAMR, 0, 0x0c, 8); length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_5_15_len, 1); break; case gsm690_5_90: printf("codec gsm690_5_90\n"); osmo_conv_decode(&conv_tch_afs_5_9, &mC[8], convu); memcpy(convd,convu,55); memcpy(convd,&convu[61],63); tch_map(gsm690_5_9_bitorder, gsm690_5_90_len, EFRAMR + 8,convd); fillField(EFRAMR, 0, 0x14, 8); length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_5_90_len, 1); break; case gsm690_6_70: printf("codec gsm690_6_70\n"); osmo_conv_decode(&conv_tch_afs_6_7, &mC[8], convu); memcpy(convd,convu,55); memcpy(convd,&convu[61],79); tch_map(gsm690_6_7_bitorder, gsm690_6_70_len, EFRAMR + 8,convd); fillField(EFRAMR, 0, 0x1c, 8); length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_6_70_len, 1); break; case gsm690_7_40: printf("codec gsm690_7_40\n"); osmo_conv_decode(&conv_tch_afs_7_4, &mC[8], convu); memcpy(convd,convu,61); memcpy(convd,&convu[67],87); tch_map(gsm690_7_4_bitorder, gsm690_7_40_len, EFRAMR + 8,convd); fillField(EFRAMR, 0, 0x24, 8); length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_7_40_len, 1); break; case gsm690_7_95: printf("codec gsm690_7_95\n"); osmo_conv_decode(&conv_tch_afs_7_95, &mC[8], convu); memcpy(convd,convu,75); memcpy(convd,&convu[81],84); tch_map(gsm690_7_95_bitorder, gsm690_7_95_len, EFRAMR + 8,convd); fillField(EFRAMR, 0, 0x2c, 8); length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_7_95_len, 1); break; case gsm690_10_2: printf("codec gsm690_10_2\n"); osmo_conv_decode(&conv_tch_afs_10_2, &mC[8], convu); memcpy(convd,convu,65); memcpy(convd,&convu[71],139); tch_map(gsm690_10_2_bitorder, gsm690_10_2_len, EFRAMR + 8,convd); fillField(EFRAMR, 0, 0x34, 8); length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_10_2_len, 1); break; case gsm690_12_2: printf("codec gsm690_12_2\n"); osmo_conv_decode(&conv_tch_afs_12_2, &mC[8], convu); memcpy(convd,convu,81); memcpy(convd,&convu[87],163); tch_map(gsm690_12_2_bitorder, gsm690_12_2_len, EFRAMR + 8,convd); fillField(EFRAMR, 0, 0x3c, 8); length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_12_2_len, 1); break; default: { printf("unkown gsm690 codec\n"); return; } } printf("length is %d\n",length); printf("voice[0] is %x\n",voice[0]); fwrite(voice, 1, length, d_speech_file); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From ml at mail.tsaitgaist.info Sat Jul 7 09:15:05 2012 From: ml at mail.tsaitgaist.info (Kevin Redon) Date: Sat, 07 Jul 2012 11:15:05 +0200 Subject: Pirelli DP-L10 keypad Message-ID: <1341651227-sup-8954@dennou> Hi, I changed the keypad bit mask so to match for the Pirelli DP-L10 (patch attached). some remarks: - the additional volume up/down and camera buttons press are detected by keypad_poll(), but not visible in KBR_LATCH_REG - the power button press is not detected by keypad_poll() (or ignored by "with_interrupts && !polling") - the keypad.h file is in target/firmware/include/, but it's board dependent. is there a clean way to handle that? thanks, kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: keypad.h.diff Type: application/octet-stream Size: 1284 bytes Desc: not available URL: From Steve.Markgraf at student.hs-rm.de Sat Jul 7 10:57:32 2012 From: Steve.Markgraf at student.hs-rm.de (Steve Markgraf) Date: Sat, 07 Jul 2012 12:57:32 +0200 Subject: Pirelli DP-L10 keypad In-Reply-To: <4FF81131.9000100@steve-m.de> References: <1341651227-sup-8954@dennou> <4FF81131.9000100@steve-m.de> Message-ID: <517bb7b5648f6f4fb711fbfb083794b2@mail.student.hs-rm.de> Hi Kevin, On 07.07.2012 11:15, Kevin Redon wrote: > - the additional volume up/down and camera buttons press are detected > by keypad_poll(), but not visible in KBR_LATCH_REG Yes, for that you need to increase the number of rows/columns that are scanned (can exactly remember which one). The Compal phones don't use all of them. > - the power button press is not detected by keypad_poll() (or ignored > by > "with_interrupts && !polling") As it seems the power button is not connected to the keyboard scan matrix. You get an interrupt from Iota though when the button is pressed, see [2]. That code was removed again from master. > - the keypad.h file is in target/firmware/include/, but it's board > dependent. is there a clean way to handle that? Did you check out the steve-m/pirelli branch [2]? It already contains the modified keypad header. Those changes should definitely be cleaned up and put into master, especially make the UARTs runtime configurable to have them swapped for the DP-L10. Regards, Steve [1] http://cgit.osmocom.org/cgit/osmocom-bb/commit/?id=4f0825a352af5499beee068dedbd5e9cf5674262 [2] http://cgit.osmocom.org/cgit/osmocom-bb/commit/?h=steve-m/pirelli From krazy.okmo at gmail.com Sun Jul 8 02:02:56 2012 From: krazy.okmo at gmail.com (Ryan Hayes) Date: Sat, 7 Jul 2012 19:02:56 -0700 Subject: GSM Paging Request Message-ID: Hi, I am confused about the paging request when monitoring channel bursts, is the return downlink say from TMSI only reviewed by the BTS or is it accessible from the layer23 forwarding wireshark? more mods needed in development kit? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From akibsayyed at gmail.com Sun Jul 8 07:37:17 2012 From: akibsayyed at gmail.com (Akib Sayyed) Date: Sun, 8 Jul 2012 13:07:17 +0530 Subject: replacing sercomm tranfer with direct function Message-ID: l1_queue_for_l2(struct msgb *msg) will queue data from layer1 for layer2 and will send via serial to host now if i directly replace all layer2_read content and pass msg to l1ctlrecv will it work on target host == host pc target == phone any suggestion on this and l1a_l23_rx this will receive data from l23 from host is it correct Note: I am trying to implement l2l3 on phone it self -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From avwiseav at gmail.com Mon Jul 9 03:00:50 2012 From: avwiseav at gmail.com (bob wisebob) Date: Mon, 9 Jul 2012 11:00:50 +0800 Subject: the layer1 FN count Message-ID: Hi, List: I am puzzled about the variation of gsmtime when the channel iump to sdcch or tch, how does the gsmtime change? I am decode the tch in the burst_id, but I think I can`t capture the TCH frame correctly?anyone who is familiar with it can help me? -------------- next part -------------- An HTML attachment was scrubbed... URL: From avwiseav at gmail.com Mon Jul 9 08:28:03 2012 From: avwiseav at gmail.com (bob) Date: Mon, 9 Jul 2012 01:28:03 -0700 (PDT) Subject: the layer1 FN count In-Reply-To: References: Message-ID: <1341822483050-4025121.post@n3.nabble.com> the flow is the TCH steal bit in a test network;in the burst_id branch, I do as following: osmo_pbit2ubit_ext(steal_bit, 0 , bi->bits, 114 , 2 , 0); printf("steal_bit %x , %x\n",steal_bit[0],steal_bit[1]); is that right?the result is below,: SACCH fn = 452204 fn_report = 90 steal_bit 1 , 0 steal_bit 0 , 0 steal_bit 1 , 1 steal_bit 0 , 0 steal_bit 0 , 1 steal_bit 1 , 1 steal_bit 1 , 0 steal_bit 1 , 1 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 1 , 0 steal_bit 0 , 0 steal_bit 1 , 0 steal_bit 0 , 0 steal_bit 1 , 0 steal_bit 1 , 1 steal_bit 0 , 0 steal_bit 1 , 1 steal_bit 1 , 0 steal_bit 0 , 0 steal_bit 1 , 0 steal_bit 0 , 0 SACCH fn = 452230 fn_report = 12 steal_bit 0 , 1 steal_bit 1 , 1 steal_bit 0 , 1 steal_bit 1 , 1 steal_bit 0 , 1 steal_bit 0 , 0 steal_bit 1 , 1 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 1 steal_bit 0 , 1 steal_bit 0 , 1 steal_bit 1 , 0 steal_bit 0 , 0 steal_bit 0 , 1 steal_bit 1 , 1 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 1 steal_bit 1 , 0 steal_bit 1 , 0 steal_bit 0 , 0 SACCH fn = 452256 fn_report = 38 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 1 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 1 , 0 steal_bit 1 , 1 steal_bit 0 , 0 steal_bit 1 , 1 steal_bit 1 , 0 steal_bit 1 , 0 steal_bit 0 , 1 steal_bit 1 , 0 steal_bit 0 , 1 steal_bit 1 , 1 steal_bit 1 , 0 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 1 steal_bit 0 , 0 steal_bit 0 , 1 steal_bit 1 , 0 SACCH fn = 452282 fn_report = 64 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 1 , 1 steal_bit 1 , 0 steal_bit 0 , 0 steal_bit 1 , 0 steal_bit 0 , 1 steal_bit 0 , 0 steal_bit 0 , 1 steal_bit 1 , 1 steal_bit 0 , 0 steal_bit 1 , 0 steal_bit 0 , 1 steal_bit 0 , 0 steal_bit 1 , 0 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 1 , 0 steal_bit 0 , 1 SACCH fn = 452308 fn_report = 90 steal_bit 0 , 1 steal_bit 1 , 1 steal_bit 1 , 0 steal_bit 0 , 1 steal_bit 1 , 0 steal_bit 0 , 0 steal_bit 0 , 1 steal_bit 1 , 1 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 1 , 1 steal_bit 0 , 0 steal_bit 1 , 0 steal_bit 1 , 1 steal_bit 0 , 1 steal_bit 1 , 1 steal_bit 1 , 0 steal_bit 1 , 1 steal_bit 1 , 1 steal_bit 0 , 0 steal_bit 0 , 1 steal_bit 0 , 0 SACCH fn = 452334 fn_report = 12 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 1 , 1 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 1 steal_bit 1 , 0 steal_bit 0 , 1 steal_bit 0 , 1 steal_bit 0 , 1 steal_bit 1 , 1 steal_bit 0 , 1 steal_bit 1 , 0 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 1 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 1 steal_bit 0 , 0 steal_bit 0 , 0 SACCH fn = 452360 fn_report = 38 steal_bit 0 , 1 steal_bit 1 , 1 steal_bit 1 , 0 steal_bit 0 , 0 steal_bit 1 , 0 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 1 steal_bit 1 , 1 steal_bit 1 , 0 steal_bit 0 , 0 steal_bit 0 , 1 steal_bit 1 , 1 steal_bit 1 , 0 steal_bit 0 , 0 steal_bit 1 , 1 steal_bit 0 , 1 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 1 , 0 steal_bit 0 , 0 steal_bit 1 , 1 steal_bit 0 , 0 steal_bit 1 , 0 SACCH fn = 452386 fn_report = 64 steal_bit 0 , 0 steal_bit 0 , 0 steal_bit 0 , 0 but I think it is not correct,because A FACCH/F frame of 456 coded bits is mapped on 8 consecutive bursts as specified for the TCH/FS, the even numbered bits in the first 4 bursts and the odd numbered bits of the last 4 bursts are stolen. so I think what is right is : steal_bit 1, 0 steal_bit 1 , 0 steal_bit 1 , 0 steal_bit 1 , 0 steal_bit 0 , 1 steal_bit 0 , 1 steal_bit 0 , 1 steal_bit 0 , 1 steal_bit 1 , 0 steal_bit 1 , 0 steal_bit 1 , 0 steal_bit 1 , 0 I am puzzled, what is the right answer? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/the-layer1-FN-count-tp4025120p4025121.html Sent from the baseband-devel mailing list archive at Nabble.com. From 246tnt at gmail.com Mon Jul 9 08:59:30 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 9 Jul 2012 10:59:30 +0200 Subject: the layer1 FN count In-Reply-To: <1341822483050-4025121.post@n3.nabble.com> References: <1341822483050-4025121.post@n3.nabble.com> Message-ID: On Mon, Jul 9, 2012 at 10:28 AM, bob wrote: > the flow is the TCH steal bit in a test network;in the burst_id branch, I do > as following: > > osmo_pbit2ubit_ext(steal_bit, 0 , bi->bits, 114 , 2 , 0); > printf("steal_bit %x , %x\n",steal_bit[0],steal_bit[1]); > > is that right?the result is below,: Yup should work, I use : hl = bi->bits[14] & 0x10; hu = bi->bits[14] & 0x20; but it should lead to the same result. > steal_bit 1 , 0 > steal_bit 0 , 0 > .... This just look like noise. As you say you should have runs of 4. You must have a problem somewhere ... Cheers, Sylvain From osmocom at ngolde.de Mon Jul 9 15:32:17 2012 From: osmocom at ngolde.de (Nico Golde) Date: Mon, 9 Jul 2012 17:32:17 +0200 Subject: [PATCH] firmware/rssi: attempt to resync on sync errors Message-ID: <20120709153217.GA23627@nybble.binarybase.org> --- src/target/firmware/apps/rssi/main.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/src/target/firmware/apps/rssi/main.c b/src/target/firmware/apps/rssi/main.c index b2cafae..8907cce 100644 --- a/src/target/firmware/apps/rssi/main.c +++ b/src/target/firmware/apps/rssi/main.c @@ -763,6 +763,7 @@ static int inc_dec_spectrum(int inc) static void enter_sync(void); static void exit_sync(void); +static void retry_sync(void); static void enter_rach(void); static void exit_rach(void); @@ -987,6 +988,13 @@ static void handle_pm(void) /* sync / SI */ +static void retry_sync(void) +{ + exit_sync(); + toggle_dcs_pcs(); + enter_sync(); +} + static void enter_sync(void) { struct msgb *msg = l1ctl_msgb_alloc(L1CTL_FBSB_REQ); @@ -1414,8 +1422,10 @@ static void l1a_l23_tx(struct msgb *msg) sb = (struct l1ctl_fbsb_conf *) dl->payload; if (sb->result == 0) sync_result = "ok"; - else + else { sync_result = "error"; + retry_sync(); + } bsic = sb->bsic; break; case L1CTL_DATA_IND: -- 1.7.10 From andreas at eversberg.eu Mon Jul 9 19:27:00 2012 From: andreas at eversberg.eu (Andreas Eversberg) Date: Mon, 09 Jul 2012 21:27:00 +0200 Subject: [PATCH] firmware/rssi: attempt to resync on sync errors In-Reply-To: <4FFB3038.60008@eversberg.eu> References: <20120709153217.GA23627@nybble.binarybase.org> <4FFB3038.60008@eversberg.eu> Message-ID: <4FFB3084.6040701@eversberg.eu> Nico Golde wrote: > +static void retry_sync(void) > +{ > + exit_sync(); > + toggle_dcs_pcs(); > + enter_sync(); > +} > + hi nico, i see 2 problems: why do you toggle dcs/pcs? if you select dcs (default), but like to sync to pcs, just push the function key, then sync. if no sync is possible at all, your patch ends up in an endless loop. (or am i wrong?) regards, andreas From osmocom at ngolde.de Tue Jul 10 10:03:26 2012 From: osmocom at ngolde.de (Nico Golde) Date: Tue, 10 Jul 2012 12:03:26 +0200 Subject: [PATCH] firmware/rssi: attempt to resync on sync errors In-Reply-To: <4FFB3084.6040701@eversberg.eu> References: <20120709153217.GA23627@nybble.binarybase.org> <4FFB3038.60008@eversberg.eu> <4FFB3084.6040701@eversberg.eu> Message-ID: <20120710100325.GA10475@nybble.binarybase.org> Hi, * Andreas Eversberg [2012-07-10 11:59]: > Nico Golde wrote: > >+static void retry_sync(void) > >+{ > >+ exit_sync(); > >+ toggle_dcs_pcs(); > >+ enter_sync(); > >+} > >+ > > i see 2 problems: > why do you toggle dcs/pcs? if you select dcs (default), but like to > sync to pcs, just push the function key, then sync. To be honest, for a very pragmatic reason. I never successfully resynced without toggling the pcs if I just call enter_sync() in a loop. > if no sync is possible at all, your patch ends up in an endless loop. > (or am i wrong?) Yes but the key handler to leave the loop is still working. Maybe it would be a better solution to set a timer and a retry attempt counter and stop this after n attempts. For me this endless loop was sufficient for now. Cheers Nico From tarik.benaddi at gmail.com Mon Jul 9 15:40:42 2012 From: tarik.benaddi at gmail.com (tarik benaddi) Date: Mon, 9 Jul 2012 17:40:42 +0200 Subject: Which (phone, cable) should I choose? Message-ID: Hi all, I want to join the adventure. First, I need to make my hardware. I saw on the project website that different mobiles are compatible with osmocombb ( http://bit.ly/MaSR5T). Which one do you advice and where can I buy it? Thanks :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stuge.se Mon Jul 9 15:50:03 2012 From: peter at stuge.se (Peter Stuge) Date: Mon, 9 Jul 2012 17:50:03 +0200 Subject: Which (phone, cable) should I choose? In-Reply-To: References: Message-ID: <20120709155003.6754.qmail@stuge.se> tarik benaddi wrote: > where can I buy it? These links are in the wiki: http://shop.sysmocom.de/products/motorola-c1xx http://shop.sysmocom.de/products/cp2102-25 //Peter From tarik.benaddi at gmail.com Mon Jul 9 19:21:49 2012 From: tarik.benaddi at gmail.com (tarik benaddi) Date: Mon, 9 Jul 2012 21:21:49 +0200 Subject: Which (phone, cable) should I choose? In-Reply-To: <20120709155003.6754.qmail@stuge.se> References: <20120709155003.6754.qmail@stuge.se> Message-ID: Thank you for your answer. The cable is described as a Motorola T191 cable, while the phone is C1xx series...Are they compatible despite given description? Tarik On Mon, Jul 9, 2012 at 5:50 PM, Peter Stuge wrote: > tarik benaddi wrote: > > where can I buy it? > > These links are in the wiki: > > http://shop.sysmocom.de/products/motorola-c1xx > http://shop.sysmocom.de/products/cp2102-25 > > > //Peter > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.huemer at xx.vu Mon Jul 9 21:41:16 2012 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Mon, 9 Jul 2012 23:41:16 +0200 Subject: Which (phone, cable) should I choose? In-Reply-To: References: <20120709155003.6754.qmail@stuge.se> Message-ID: <20120709214114.GC13928@de.xx.vu> On Mon, Jul 09, 2012 at 09:21:49PM +0200, tarik benaddi wrote: > The cable is described as a Motorola T191 cable, while the phone is C1xx > series...Are they compatible despite given description? yes From avwiseav at gmail.com Tue Jul 10 09:16:55 2012 From: avwiseav at gmail.com (bob) Date: Tue, 10 Jul 2012 02:16:55 -0700 (PDT) Subject: the amr codec test result Message-ID: <1341911815051-4025129.post@n3.nabble.com> Hi List! I test the AMR codec in my GSM network, and it is so strange, the code mode is jump between codec gsm690_12_2 and codec gsm690_4_75, why? codec gsm690_4_75 length is 13 voice[0] is 20 codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 4 codec gsm690_12_2 length is 32 voice[0] is 3c SACCH fn = 1682888 fn_report = 90 codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 4 codec gsm690_12_2 length is 32 voice[0] is 3c codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 4 codec gsm690_12_2 length is 32 voice[0] is 3c SACCH fn = 1682914 fn_report = 12 codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 4 codec gsm690_12_2 length is 32 voice[0] is 3c codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 4 codec gsm690_12_2 length is 32 voice[0] is 3c SACCH fn = 1682940 fn_report = 38 codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 4 codec gsm690_12_2 length is 32 voice[0] is 3c codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 4 codec gsm690_12_2 length is 32 voice[0] is 3c SACCH fn = 1682966 fn_report = 64 codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 4 codec gsm690_12_2 length is 32 voice[0] is 3c codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 4 codec gsm690_12_2 length is 32 voice[0] is 3c SACCH fn = 1682992 fn_report = 90 codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 4 codec gsm690_12_2 length is 32 voice[0] is 3c codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 4 codec gsm690_12_2 length is 32 voice[0] is 3c SACCH fn = 1683018 fn_report = 12 codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 4 codec gsm690_12_2 length is 32 voice[0] is 3c codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 4 codec gsm690_12_2 length is 32 voice[0] is 3c SACCH fn = 1683044 fn_report = 38 codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 4 codec gsm690_12_2 length is 32 voice[0] is 3c codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 1 codec gsm690_4_75 length is 13 voice[0] is 20 codec 4 codec gsm690_12_2 length is 32 voice[0] is 3c SACCH fn = 1683070 fn_report = 64 codec 1 codec gsm690_4_75 length is 13 -- View this message in context: http://baseband-devel.722152.n3.nabble.com/the-amr-codec-test-result-tp4025129.html Sent from the baseband-devel mailing list archive at Nabble.com. From martix.cz at gmail.com Tue Jul 10 11:14:21 2012 From: martix.cz at gmail.com (Martix) Date: Tue, 10 Jul 2012 13:14:21 +0200 Subject: Open GSM firmware - OsmocomBB supports Neo FreeRunner Message-ID: <4FFC0E8D.7090700@gmail.com> Hi! There is some GTA02 support in OsmocomBB project. You can flash open source firmware for TI Calypso GSM modem. http://bb.osmocom.org/trac/wiki/OpenMoko Did anybody tried this firmware on his Neo FreeRunner? What's your experience? Is it usable with SHR or Qt Moko like old proprietary firmware? Calls, SMS, GPRS, SIM load/store (contacts, SMSs) works? How many successfully flashed devices are here? And how many bricks? ;-) I know about OsmocomBB from beginning, but Openmoko smartphones support wasn't priority for them. I'm glad to see some progress on GTA02. Did leaked documentation and proprietary firmware source codes helped OsmocomBB? http://lists.openmoko.org/pipermail/community/2011-November/065731.html Best Regards, Martix From alexander.huemer at xx.vu Tue Jul 10 11:35:32 2012 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Tue, 10 Jul 2012 13:35:32 +0200 Subject: Open GSM firmware - OsmocomBB supports Neo FreeRunner In-Reply-To: <4FFC0E8D.7090700@gmail.com> References: <4FFC0E8D.7090700@gmail.com> Message-ID: <20120710113531.GA1263@de.xx.vu> Hi Martix, On Tue, Jul 10, 2012 at 01:14:21PM +0200, Martix wrote: > Hi! > > There is some GTA02 support in OsmocomBB project. You can flash open > source firmware for TI Calypso GSM modem. > http://bb.osmocom.org/trac/wiki/OpenMoko > > Did anybody tried this firmware on his Neo FreeRunner? What's your > experience? Is it usable with SHR or Qt Moko like old proprietary > firmware? Calls, SMS, GPRS, SIM load/store (contacts, SMSs) works? > How many successfully flashed devices are here? And how many bricks? > ;-) > AFAIK osmocom-bb works on the OpenMoko phones, but most likely not in the way you expect. There is so far no AT-command interface, which means you cannot use OpenMoko dialing-apps, etc. You have to use the normal osmocom-bb telnet interface to interact with it. > > [...] > Kind regards, -Alexander Huemer From khorben at defora.org Tue Jul 10 11:50:54 2012 From: khorben at defora.org (Pierre Pronchery) Date: Tue, 10 Jul 2012 13:50:54 +0200 Subject: Open GSM firmware - OsmocomBB supports Neo FreeRunner In-Reply-To: <4FFC0E8D.7090700@gmail.com> References: <4FFC0E8D.7090700@gmail.com> Message-ID: <4FFC171E.4030009@defora.org> Hi, On 10/07/2012 13:14, Martix wrote: > > There is some GTA02 support in OsmocomBB project. You can flash open > source firmware for TI Calypso GSM modem. > http://bb.osmocom.org/trac/wiki/OpenMoko > > Did anybody tried this firmware on his Neo FreeRunner? What's your > experience? Is it usable with SHR or Qt Moko like old proprietary > firmware? Calls, SMS, GPRS, SIM load/store (contacts, SMSs) works? How > many successfully flashed devices are here? And how many bricks? ;-) I think there's already been a thread recently about this; please check the archives. > I know about OsmocomBB from beginning, but Openmoko smartphones support > wasn't priority for them. I'm glad to see some progress on GTA02. It's neither SHR or QtMoko, but I have begun to write some code to integrate OsmocomBB with my own telephony implementation (called "DeforaOS Phone") for the Openmoko Freerunner. It is very, very early work and therefore far from being functional yet, but for the record, you can find it here: http://www.defora.org/os/project/browse/3343?file=/src/modems/osmocom.c,v&revision=1.2 Previous versions of the DeforaOS environment are already packaged for the hackable:1 distribution, and released within the "dse" series. For more information on how to install and test this: http://trac.hackable1.org/trac/wiki/DeforaOSSmartphone http://trac.hackable1.org/trac/wiki/AvailableVersions/dse2 http://www.defora.org/os/wiki/3438/DeforaOS-Smartphone HTH, -- khorben From GNUtoo at no-log.org Tue Jul 10 14:43:29 2012 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Tue, 10 Jul 2012 16:43:29 +0200 Subject: Open GSM firmware - OsmocomBB supports Neo FreeRunner In-Reply-To: <4FFC0E8D.7090700@gmail.com> References: <4FFC0E8D.7090700@gmail.com> Message-ID: <1341931409.3093.18.camel@gnutoo-desktop> On Tue, 2012-07-10 at 13:14 +0200, Martix wrote: > Hi! > > There is some GTA02 support in OsmocomBB project. You can flash open > source firmware for TI Calypso GSM modem. > http://bb.osmocom.org/trac/wiki/OpenMoko 1) no need to flash it, just load it. 2) flashing doesn't work currently with the calypso of the openmoko because its flash is not detected. > > Did anybody tried this firmware on his Neo FreeRunner? What's your > experience? Is it usable with SHR or Qt Moko like old proprietary > firmware? Calls, SMS, GPRS, SIM load/store (contacts, SMSs) works? How > many successfully flashed devices are here? And how many bricks? ;-) Calls, SMS, SIM should work....trough the telnet interface... I'm not sure about the GPRS... Adding support for osmocombb in FSO is doable, however the big problem is that the layer 2 and layer 3 of GSM are actually not running on the calypso but on another CPU(for instance the CPU of a laptop/desktop, or it could run on the CPU running SHR as well, it only requires to cross-compile applications such as mobile etc..., it's easy to do). Why is running the layer 2 and 3 on the calypso CPU important? Simply because you may want to permit the CPU running SHR to suspend and to resume when you have a call or an SMS: with the proprietary firmware(which runs layer 1,2,3 on the calypso) it works that way: I don't know the exact details but I guess there is an interrupt line between the modem(calypso) and the CPU. If the CPU running SHR is suspended and that there is a call, the calypso, which is not suspended will trigger the wakeup of the CPU running SHR, the CPU will then wakeup and display that there is a call,ring and vibrate. I'm not a GSM protocol specialist yet, but I guess that if you're only running layer1 on the calypso you have no way to determine if there is an incoming call. The CPU that can do that is the one running SHR, and the layer 2 and 3, however if that CPU is suspended it can't know that there is a call. A workaround suggested long time ago by someone on IRC would be to wake up the CPU often and check if there is a call, however that may not be doable because suspend/resume may take quite some time, and the wakeup would eat more power etc... There are 2 ways to solve the problem correctly: 1) help with the port of the GSM applications on top of nuttx: While the gta02 is supported in nuttx,we were currently focussing on the c155 with its drivers(such as display,spi,uwire,poweroff etc...) 2) port the layer 2 and 3 to the calypso without the help of nuttx. Denis. From khorben at defora.org Tue Jul 10 20:58:34 2012 From: khorben at defora.org (Pierre Pronchery) Date: Tue, 10 Jul 2012 22:58:34 +0200 Subject: Open GSM firmware - OsmocomBB supports Neo FreeRunner In-Reply-To: <1341931409.3093.18.camel@gnutoo-desktop> References: <4FFC0E8D.7090700@gmail.com> <1341931409.3093.18.camel@gnutoo-desktop> Message-ID: <4FFC977A.9040508@defora.org> Hi, On 10/07/2012 16:43, Denis 'GNUtoo' Carikli wrote: > On Tue, 2012-07-10 at 13:14 +0200, Martix wrote: >> >> There is some GTA02 support in OsmocomBB project. You can flash open >> source firmware for TI Calypso GSM modem. [...] > > There are 2 ways to solve the problem correctly: > 1) help with the port of the GSM applications on top of nuttx: > While the gta02 is supported in nuttx,we were currently focussing on the > c155 with its drivers(such as display,spi,uwire,poweroff etc...) > 2) port the layer 2 and 3 to the calypso without the help of nuttx. I don't think nuttx is the only solution for the application processor on the Openmoko: it should be fine to run Linux (or *BSD...) there. In any case, I see another problem, which once implemented would help integration a whole lot: a developer-friendly way to interact with OsmocomBB aside of the Telnet interface. Easier said than done I know, but I'll welcome anyone who beats me to it :) Cheers, -- khorben From laforge at gnumonks.org Tue Jul 10 17:00:19 2012 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 10 Jul 2012 19:00:19 +0200 Subject: Custom calypso board Message-ID: <20120710170019.GC30822@prithivi.gnumonks.org> Hi all! There are some signs that the supply of Motola C1xx phones is not endless, after all. As such, sysmocom has decided to manufacture some custom boards with the typical TI Calypso/Iota/Rita design. The RF PA will be RFMD RF3166, and the combined NOR + SRAM will be a Samsung K5A3281. All parts are still available from the surplus market. Schematics will be published in PDF form only, Gerber/PCB files will not be released (so basically the same like the OsmoSDR situation). All software used is already available as OsmocomBB under a *GPL license. Any help and input from the community will of course be appreciated. The design will be more or less a standard tri-band calypso phone design (900/1800/1900), with possibly a placement option for having 850/1800/1900. We'll be targetting a modem as opposed to a phone design, so no built-in keypad / display / battery, but external connections. At one edge there should be a PCB edge connector, possibly with mechanical form-factor of PCIe (sinc they're cheap). This connector should allow the module to be plugged into a back-plane with a number of other modems. I've crated an initial Wiki page about the possible / intended modifications from a classic phoned design at http://bb.osmocom.org/trac/wiki/Custom_Calypso_Board : * expose JTAG * board-edge connector for plugging many boards into one backplane * external clock input / buffered clock output * RF connector standard u.fl or SMA or optionally separate Rx/Tx? * I2C/SPI and both UARTs available on headers * on-board EEPROM for storing persistent data, even beyond NOR flashing * SIM card slot, SIM interface also present on header * additional / unused TPU ports * header for TSP / TPU and all data/control interfaces between iota/rita/calypso * RTC crystal and footprint for lithium backup battery * version of the board with uplink / downlink filters switched Feel free to discuss other extensions/modifications you may have in mind. Please note that fundamentally we are still heading for a calypso based design, so this will not be a board that just contains the Iota/Rita and some FPGA or general purpose DSP, as some people have proposed in the past. However, it may be possible to have connector footprints for the TSP / BSP interfaces and make some boarde that don't contain the calypso/ram/nor parts. Pricing will definitely not be anywhere near to the price of current phones. You cannot even source all the components for the price of those refurbished phones, let alone the fairly complex 6-layer PCB. Also, the quantities will be low, we may be manufacturing something like 100 units a batch only. This is a low-effort / side project, so I'm conservative with any estimates and would say that we're happy to have boards shipping by the end of this year. Regards, Harald (waiting for the e-mail flood) -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From peter at stuge.se Tue Jul 10 22:11:59 2012 From: peter at stuge.se (Peter Stuge) Date: Wed, 11 Jul 2012 00:11:59 +0200 Subject: Custom calypso board In-Reply-To: <20120710170019.GC30822@prithivi.gnumonks.org> References: <20120710170019.GC30822@prithivi.gnumonks.org> Message-ID: <20120710221159.21949.qmail@stuge.se> Harald Welte wrote: > I've crated an initial Wiki page about the possible / intended > modifications from a classic phoned design at > http://bb.osmocom.org/trac/wiki/Custom_Calypso_Board : > > * board-edge connector for plugging many boards into one backplane .. > Feel free to discuss other extensions/modifications you may have in > mind. How about USB to the backplane if 12Mbps is enough throughput? The contacts are specified on the MiniPCI-E edge connector. Could also try some trick with the SIM signals for when using real SIM. //Peter From laforge at gnumonks.org Tue Jul 10 22:35:17 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 11 Jul 2012 00:35:17 +0200 Subject: Custom calypso board In-Reply-To: <20120710221159.21949.qmail@stuge.se> References: <20120710170019.GC30822@prithivi.gnumonks.org> <20120710221159.21949.qmail@stuge.se> Message-ID: <20120710223517.GJ30822@prithivi.gnumonks.org> Hi Peter, On Wed, Jul 11, 2012 at 12:11:59AM +0200, Peter Stuge wrote: > How about USB to the backplane if 12Mbps is enough throughput? That might be an option, but it would require a cascade of USB hubs on the backplane, and it would prevent the boards from talking to each other in a peer-to-peer kind of fashion. Also, as the Calypso itself doesnt' have USB, we'd need some kind of external USB device controller hooked up to the calyposo UART / SPI or even data/address bus. Something like multi-master SPI would at leaset from a hardware point of view support that. Also, in addition to whatever bus we may choose, we should always have some timing signals, so we can e.g. trigger events on board "B" by the TPU on board "A". Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.huemer at xx.vu Wed Jul 11 08:22:34 2012 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Wed, 11 Jul 2012 10:22:34 +0200 Subject: Custom calypso board In-Reply-To: <20120710223517.GJ30822@prithivi.gnumonks.org> References: <20120710170019.GC30822@prithivi.gnumonks.org> <20120710221159.21949.qmail@stuge.se> <20120710223517.GJ30822@prithivi.gnumonks.org> Message-ID: <20120711082234.GB1263@de.xx.vu> On Wed, Jul 11, 2012 at 12:35:17AM +0200, Harald Welte wrote: > On Wed, Jul 11, 2012 at 12:11:59AM +0200, Peter Stuge wrote: > > > How about USB to the backplane if 12Mbps is enough throughput? > > [...] > > Something like multi-master SPI would at leaset from a hardware point of > view support that. > multi-master smells very much like CAN. Just saying. From kesmtp at freenet.de Wed Jul 11 08:41:56 2012 From: kesmtp at freenet.de (Mathias K.) Date: Wed, 11 Jul 2012 10:41:56 +0200 Subject: Custom calypso board In-Reply-To: <20120711082234.GB1263@de.xx.vu> References: <20120710170019.GC30822@prithivi.gnumonks.org> <20120710221159.21949.qmail@stuge.se> <20120710223517.GJ30822@prithivi.gnumonks.org> <20120711082234.GB1263@de.xx.vu> Message-ID: <4FFD3C54.4040206@freenet.de> On 11.07.2012 10:22, Alexander Huemer wrote: > On Wed, Jul 11, 2012 at 12:35:17AM +0200, Harald Welte wrote: >> On Wed, Jul 11, 2012 at 12:11:59AM +0200, Peter Stuge wrote: >> >>> How about USB to the backplane if 12Mbps is enough throughput? >> >> [...] >> >> Something like multi-master SPI would at leaset from a hardware point of >> view support that. >> > multi-master smells very much like CAN. Just saying. > CAN has a maximum theoretical data-rate of 1MBit/s. For the calypso cpu we need a external CAN interface and the CAN transceiver. If we really want to use CAN for backplane communication i would use, as example, a LPC11C24FBD48 with a integrated CAN transceiver as "backplane" co-processor. From paul at kristianpaul.org Wed Jul 11 01:57:43 2012 From: paul at kristianpaul.org (Cristian Paul =?iso-8859-1?Q?Pe=F1aranda?= Rojas) Date: Tue, 10 Jul 2012 20:57:43 -0500 Subject: Custom calypso board In-Reply-To: <20120710170019.GC30822@prithivi.gnumonks.org> References: <20120710170019.GC30822@prithivi.gnumonks.org> Message-ID: <20120711015743.GD16954@micro> > Schematics will be published in PDF form only, Gerber/PCB files will not > be released (so basically the same like the OsmoSDR situation). Is it due some restricted format from layout software or third party contract clause? As you mentioned there will not be LCM/Keypad or similar, useful for a theoretically Open Hardware Phone, so by limiting access to layout/gerber stops a bit the chance one some day can free it and make a derivate work. Hope not annoying with this question, but I would like to understand better the situation, so may be we can learn from it to. Cheers anyway for making this happen ! Cristian Paul From laforge at gnumonks.org Wed Jul 11 07:41:04 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 11 Jul 2012 09:41:04 +0200 Subject: Custom calypso board In-Reply-To: <20120711015743.GD16954@micro> References: <20120710170019.GC30822@prithivi.gnumonks.org> <20120711015743.GD16954@micro> Message-ID: <20120711074104.GF2490@prithivi.gnumonks.org> Hi Cristian Paul, On Tue, Jul 10, 2012 at 08:57:43PM -0500, Cristian Paul Pe?aranda Rojas wrote: > > Schematics will be published in PDF form only, Gerber/PCB files will not > > be released (so basically the same like the OsmoSDR situation). > > Is it due some restricted format from layout software or third party > contract clause? Actually, both is true and there's little flexibility on that side :/ > As you mentioned there will not be LCM/Keypad or similar, useful for > a theoretically Open Hardware Phone, so by limiting access to > layout/gerber stops a bit the chance one some day can free it and make a > derivate work. Well, I'd say there will be plenty of connectors. The LCD (even on the compal/motorola phones) is just attached to I2C (plus the backlight pwm). And the keypad is just the matrix. We _may_ actually be able to put the circular "button" footprint for something like the C123 keypad on the back side of the PCB, as so far this is "only" a ground plane. Depends a bit on the effort, and where/how somebody could source those thin membrane keyboards. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From kesmtp at freenet.de Wed Jul 11 05:55:45 2012 From: kesmtp at freenet.de (Mathias K.) Date: Wed, 11 Jul 2012 07:55:45 +0200 Subject: Custom calypso board In-Reply-To: <20120710170019.GC30822@prithivi.gnumonks.org> References: <20120710170019.GC30822@prithivi.gnumonks.org> Message-ID: <4FFD1561.3080905@freenet.de> Hello, just my comments: Whats your planed form factor of the board? Do you have choose the concrete calypso cpu already? On 10.07.2012 19:00, Harald Welte wrote: > * expose JTAG 1.27mm 10 pol Pin-Header on the opposite side of the board edge connector, this make it possible to debug the board in a backplane > * board-edge connector for plugging many boards into one backplane I would suggest the ERNI SMC. There are also a cable assembly available. http://www.erni.com/fileadmin/medien/downloadcenter/smc/ERNI-SMC-e.pdf > * I2C/SPI and both UARTs available on headers > * on-board EEPROM for storing persistent data, even beyond NOR flashing There are different types available: 64KBIT: SOT23-5 - MICROCHIP - 24AA64T-I/OT 512KBIT: 8TSSOP - MICROCHIP - 24AA512-I/ST ... It is a question of how much memory we need. > * SIM card slot, SIM interface also present on header > * additional / unused TPU ports > * header for TSP / TPU and all data/control interfaces between iota/rita/calypso > * RTC crystal and footprint for lithium backup battery > * version of the board with uplink / downlink filters switched Regards, Mathias From alexander.huemer at xx.vu Wed Jul 11 08:25:26 2012 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Wed, 11 Jul 2012 10:25:26 +0200 Subject: Custom calypso board In-Reply-To: <4FFD1561.3080905@freenet.de> References: <20120710170019.GC30822@prithivi.gnumonks.org> <4FFD1561.3080905@freenet.de> Message-ID: <20120711082526.GC1263@de.xx.vu> On Wed, Jul 11, 2012 at 07:55:45AM +0200, Mathias K. wrote: > > > * board-edge connector for plugging many boards into one backplane > > I would suggest the ERNI SMC. There are also a cable assembly available. > > http://www.erni.com/fileadmin/medien/downloadcenter/smc/ERNI-SMC-e.pdf > My first thought for such kind of project was Compact PCI, but that maybe that blows the planned costs. From laforge at gnumonks.org Wed Jul 11 08:26:10 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 11 Jul 2012 10:26:10 +0200 Subject: Custom calypso board In-Reply-To: <4FFD1561.3080905@freenet.de> References: <20120710170019.GC30822@prithivi.gnumonks.org> <4FFD1561.3080905@freenet.de> Message-ID: <20120711082610.GG2490@prithivi.gnumonks.org> Hi Matthias, On Wed, Jul 11, 2012 at 07:55:45AM +0200, Mathias K. wrote: > Whats your planed form factor of the board? the core modem design is 40 x 29.8mm in size, but that of course excludes things like the sim card reader, or any other new components we may add. After some first checking, that size would actually even fit nicely within the mechanical form factor of the C1xx boards, as they have at least something like 36 x 70 mm mechanical form-factor. Now if thre was an _easy_ way to make one circuit board that would both fit into the C1xx case _and_ also have a board edge connector for use in a back-plane, I would consider doing that. However, I think that's quite hard. The modem is likely smaller than the phone PCB, and there would be a lot of constraints where to have connectors for battery/sim/speaker/mic/vibrator, etc. my first idea is to have a 'break away' backplane connector that one would simply break off to mount it in a phone case. But then, if it is intended to be broken (e.g. by perforating with a series of holes), the PCB might break when it is plugged into the backplane and somebody pushes it sidewise. > Do you have choose the concrete calypso cpu already? Sure, the D751992AZHH. It seems to be widely available and known. Contrary to the C1xx designs, it is not a "Calypso Lite", i.e. it has 512kByte internal SRAM and not just 256. > > * expose JTAG > > 1.27mm 10 pol Pin-Header on the opposite side of the board edge > connector, this make it possible to debug the board in a backplane yes, good point. However, on that side there is likely the RF transceiver and the antenna connections :( You probably don't want the transmitter near the jtag cable... > > * board-edge connector for plugging many boards into one backplane > > I would suggest the ERNI SMC. There are also a cable assembly available. > http://www.erni.com/fileadmin/medien/downloadcenter/smc/ERNI-SMC-e.pdf undoubful great connectors, but I really wanted to keep it low cost, thus the proposalf of using PCIe connectors on the backplane. Needs no connector on the board itself, just a bit of board footprint. > > * on-board EEPROM for storing persistent data, even beyond NOR flashing > There are different types available: > > 64KBIT: SOT23-5 - MICROCHIP - 24AA64T-I/OT > 512KBIT: 8TSSOP - MICROCHIP - 24AA512-I/ST > > It is a question of how much memory we need. thanks, I'm not quite clear on that myself yet. I just thought it makes sense to be able to fully erase the NOR flash without impacting hard to recover data such as calibration. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From kesmtp at freenet.de Wed Jul 11 09:39:21 2012 From: kesmtp at freenet.de (Mathias K.) Date: Wed, 11 Jul 2012 11:39:21 +0200 Subject: Custom calypso board In-Reply-To: <20120711082610.GG2490@prithivi.gnumonks.org> References: <20120710170019.GC30822@prithivi.gnumonks.org> <4FFD1561.3080905@freenet.de> <20120711082610.GG2490@prithivi.gnumonks.org> Message-ID: <4FFD49C9.6000405@freenet.de> On 11.07.2012 10:26, Harald Welte wrote: > the core modem design is 40 x 29.8mm in size, but that of course > excludes things like the sim card reader, or any other new components we > may add. So it looks like the MiniPCI Express Card on this picture http://en.wikipedia.org/wiki/File:MiniPCI_and_MiniPCI_Express_cards.jpg ? > After some first checking, that size would actually even fit nicely > within the mechanical form factor of the C1xx boards, as they have at > least something like 36 x 70 mm mechanical form-factor. The question is, if you want to build a modem or re-engineer a phone for cases that: > There are some signs that the supply of Motola C1xx phones is not > endless, after all. And this include the cases as well. > Now if thre was an _easy_ way to make one circuit board that would both > fit into the C1xx case _and_ also have a board edge connector for use in > a back-plane, I would consider doing that. Make it simple. > my first idea is to have a 'break away' backplane connector that one > would simply break off to mount it in a phone case. But then, if it is > intended to be broken (e.g. by perforating with a series of holes), the > PCB might break when it is plugged into the backplane and somebody > pushes it sidewise. The 'break away' connectors came from manufacturing and they are not made to use it on "harsh" environments. >>> * expose JTAG >> >> 1.27mm 10 pol Pin-Header on the opposite side of the board edge >> connector, this make it possible to debug the board in a backplane > > yes, good point. However, on that side there is likely the RF > transceiver and the antenna connections :( You probably don't want the > transmitter near the jtag cable... For development that's fine i think. But this is related to the planed backplane connector. > >>> * board-edge connector for plugging many boards into one backplane >> >> I would suggest the ERNI SMC. There are also a cable assembly available. >> http://www.erni.com/fileadmin/medien/downloadcenter/smc/ERNI-SMC-e.pdf > > undoubful great connectors, but I really wanted to keep it low cost, > thus the proposalf of using PCIe connectors on the backplane. Needs no > connector on the board itself, just a bit of board footprint. Yes but that's only simple on one site and the board price increase because the extra milling ways but maybe for a 6 plane pcb it's not that much. I think the initial hurdle to get it run on the table is really high with this kind of connector. How a developer or backplane board should looks like and whats the estimated price relative to the modem price? Regards, Mathias From laforge at gnumonks.org Wed Jul 11 10:21:47 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 11 Jul 2012 12:21:47 +0200 Subject: Custom calypso board In-Reply-To: <4FFD49C9.6000405@freenet.de> References: <20120710170019.GC30822@prithivi.gnumonks.org> <4FFD1561.3080905@freenet.de> <20120711082610.GG2490@prithivi.gnumonks.org> <4FFD49C9.6000405@freenet.de> Message-ID: <20120711102147.GO2490@prithivi.gnumonks.org> Hi Mathias, On Wed, Jul 11, 2012 at 11:39:21AM +0200, Mathias K. wrote: > On 11.07.2012 10:26, Harald Welte wrote: > >the core modem design is 40 x 29.8mm in size, but that of course > >excludes things like the sim card reader, or any other new components we > >may add. > > So it looks like the MiniPCI Express Card on this picture http://en.wikipedia.org/wiki/File:MiniPCI_and_MiniPCI_Express_cards.jpg > ? I was thinking of a full-size PCIe connector like in desktop PC use. This allows the modems to be 90degree angle from the main board. The miniPCIe or miniPCI connectors require the modem to be flat on top of the base board, reducing the density and increasing PCB size of that backplane. > > There are some signs that the supply of Motola C1xx phones is not > > endless, after all. > > And this include the cases as well. no, not neccessarily. the cases are still being manufactured for spare part / re-work. > >undoubful great connectors, but I really wanted to keep it low cost, > >thus the proposalf of using PCIe connectors on the backplane. Needs no > >connector on the board itself, just a bit of board footprint. > > Yes but that's only simple on one site and the board price increase > because the extra milling ways but maybe for a 6 plane pcb it's not > that much. I think the 6-layer PCB will be espensive anyway, the milling of the connector is probably not a big impact, as you indicated. > I think the initial hurdle to get it run on the table is really high > with this kind of connector. Well, we can always make a simple PCIe break-out board that you can plug the modem into. That break-out could then provide you with a 2.54mm pitch standard header. Would that work? > How a developer or backplane board should looks like and whats the > estimated price relative to the modem price? There's no thought about that so far, first we want to get the modem done... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From kesmtp at freenet.de Wed Jul 11 11:38:29 2012 From: kesmtp at freenet.de (Mathias K.) Date: Wed, 11 Jul 2012 13:38:29 +0200 Subject: Custom calypso board In-Reply-To: <20120711102147.GO2490@prithivi.gnumonks.org> References: <20120710170019.GC30822@prithivi.gnumonks.org> <4FFD1561.3080905@freenet.de> <20120711082610.GG2490@prithivi.gnumonks.org> <4FFD49C9.6000405@freenet.de> <20120711102147.GO2490@prithivi.gnumonks.org> Message-ID: <4FFD65B5.7020707@freenet.de> On 11.07.2012 12:21, Harald Welte wrote: > On Wed, Jul 11, 2012 at 11:39:21AM +0200, Mathias K. wrote: >> On 11.07.2012 10:26, Harald Welte wrote: >>> the core modem design is 40 x 29.8mm in size, but that of course >>> excludes things like the sim card reader, or any other new components we >>> may add. >> >> So it looks like the MiniPCI Express Card on this picture http://en.wikipedia.org/wiki/File:MiniPCI_and_MiniPCI_Express_cards.jpg >> ? > > I was thinking of a full-size PCIe connector like in desktop PC use. > This allows the modems to be 90degree angle from the main board. The > miniPCIe or miniPCI connectors require the modem to be flat on top of > the base board, reducing the density and increasing PCB size of that > backplane. Do you mean the x16 with full-size PCIe? Size/Pins: PCI Express ?1 - 25mm - 36 pins PCI Express ?4 - 39mm - 64 pins PCI Express ?8 - 56mm - 98 pins PCI Express ?16 - 89mm - 164 pins http://en.wikipedia.org/wiki/File:PCIExpress.jpg Do you have done some pinout done? The x16 (full size) is a really huge as connector. >> I think the initial hurdle to get it run on the table is really high >> with this kind of connector. > > Well, we can always make a simple PCIe break-out board that you can plug > the modem into. That break-out could then provide you with a 2.54mm > pitch standard header. Would that work? Sounds good. Regards, Mathias From laforge at gnumonks.org Wed Jul 11 12:51:33 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 11 Jul 2012 14:51:33 +0200 Subject: Custom calypso board In-Reply-To: <4FFD65B5.7020707@freenet.de> References: <20120710170019.GC30822@prithivi.gnumonks.org> <4FFD1561.3080905@freenet.de> <20120711082610.GG2490@prithivi.gnumonks.org> <4FFD49C9.6000405@freenet.de> <20120711102147.GO2490@prithivi.gnumonks.org> <4FFD65B5.7020707@freenet.de> Message-ID: <20120711125133.GV2490@prithivi.gnumonks.org> Hi Mathias, On Wed, Jul 11, 2012 at 01:38:29PM +0200, Mathias K. wrote: > Do you mean the x16 with full-size PCIe? I was thinking of x1 or x4. I already have done some other board with x1 PCIe, so the footprint is already present. However, now that I think of it, PCIe requires PCB thickness to be different (1.5mm) from what we are hading for (more like .8 or 1mm). So I guess I'll scrap that idea. > Do you have done some pinout done? no, not yet. Things will move slow, we're in early planning phase now... Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From kesmtp at freenet.de Wed Jul 11 20:00:10 2012 From: kesmtp at freenet.de (Mathias K.) Date: Wed, 11 Jul 2012 22:00:10 +0200 Subject: Custom calypso board In-Reply-To: <20120711125133.GV2490@prithivi.gnumonks.org> References: <20120710170019.GC30822@prithivi.gnumonks.org> <4FFD1561.3080905@freenet.de> <20120711082610.GG2490@prithivi.gnumonks.org> <4FFD49C9.6000405@freenet.de> <20120711102147.GO2490@prithivi.gnumonks.org> <4FFD65B5.7020707@freenet.de> <20120711125133.GV2490@prithivi.gnumonks.org> Message-ID: <4FFDDB4A.9050706@freenet.de> On 11.07.2012 14:51, Harald Welte wrote: > On Wed, Jul 11, 2012 at 01:38:29PM +0200, Mathias K. wrote: > >> Do you mean the x16 with full-size PCIe? > > I was thinking of x1 or x4. I already have done some other board with > x1 PCIe, so the footprint is already present. > > However, now that I think of it, PCIe requires PCB thickness to be > different (1.5mm) from what we are hading for (more like .8 or 1mm). Your plan to use a 1.00mm thickness instead of the default 1.55mm increase the price by around 50% on, as example, WEdirekt. Why you need this thickness? Most time this is really useless and only increase the board costs. You should also think about bending, bga and small thickness. Regards, Mathias From laforge at gnumonks.org Wed Jul 11 23:03:32 2012 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 12 Jul 2012 01:03:32 +0200 Subject: Custom calypso board In-Reply-To: <4FFDDB4A.9050706@freenet.de> References: <20120710170019.GC30822@prithivi.gnumonks.org> <4FFD1561.3080905@freenet.de> <20120711082610.GG2490@prithivi.gnumonks.org> <4FFD49C9.6000405@freenet.de> <20120711102147.GO2490@prithivi.gnumonks.org> <4FFD65B5.7020707@freenet.de> <20120711125133.GV2490@prithivi.gnumonks.org> <4FFDDB4A.9050706@freenet.de> Message-ID: <20120711230332.GF2490@prithivi.gnumonks.org> Hi Mathias, On Wed, Jul 11, 2012 at 10:00:10PM +0200, Mathias K. wrote: > Your plan to use a 1.00mm thickness instead of the default 1.55mm > increase the price by around 50% on, as example, WEdirekt. Why you > need this thickness? Most time this is really useless and only > increase the board costs. You should also think about bending, bga > and small thickness. I want to use a known 6 layer PCB stacking of materials / thickness that we know works with the Calypso/Iota/Rita. Particularly on the RF side, I don't want to spend time re-calculating all the impedance matched / controlled parts. That's the part that is hard to measure if we get it wrong. So just do the safe thing and stay with the "known working" case. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From roh at hyte.de Wed Jul 11 23:06:34 2012 From: roh at hyte.de (Joachim Steiger) Date: Thu, 12 Jul 2012 01:06:34 +0200 Subject: Custom calypso board In-Reply-To: <20120711125133.GV2490@prithivi.gnumonks.org> References: <20120710170019.GC30822@prithivi.gnumonks.org> <4FFD1561.3080905@freenet.de> <20120711082610.GG2490@prithivi.gnumonks.org> <4FFD49C9.6000405@freenet.de> <20120711102147.GO2490@prithivi.gnumonks.org> <4FFD65B5.7020707@freenet.de> <20120711125133.GV2490@prithivi.gnumonks.org> Message-ID: <4FFE06FA.7020308@hyte.de> Harald Welte wrote: [...] > However, now that I think of it, PCIe requires PCB thickness to be > different (1.5mm) from what we are hading for (more like .8 or 1mm). > > So I guess I'll scrap that idea. what about making it 2 pcb? one 'gsm module' with 'plated half holes'* and or board to board conn. one 'carrier board' which then has the right thickness for the pcie-con. that way the sandwhich is mechanical stable and the rf performance shouldnt be tampered with and can even serve as additional shielding if needed (e.g. make side opposite to the modem gnd flat). this makes the modules as small as possible for integration into different kinds of carriers or even a full phone. what do you think? [*] http://www.multi-circuit-boards.eu/en/pcb-design-aid/design-parameters/plated-half-holes.html -- roh From sebastien at lorquet.fr Thu Jul 12 01:29:14 2012 From: sebastien at lorquet.fr (=?ISO-8859-1?Q?S=E9bastien_Lorquet?=) Date: Thu, 12 Jul 2012 03:29:14 +0200 Subject: Custom calypso board In-Reply-To: <4FFE06FA.7020308@hyte.de> References: <20120710170019.GC30822@prithivi.gnumonks.org> <4FFD1561.3080905@freenet.de> <20120711082610.GG2490@prithivi.gnumonks.org> <4FFD49C9.6000405@freenet.de> <20120711102147.GO2490@prithivi.gnumonks.org> <4FFD65B5.7020707@freenet.de> <20120711125133.GV2490@prithivi.gnumonks.org> <4FFE06FA.7020308@hyte.de> Message-ID: <4FFE286A.6020601@lorquet.fr> Le 12/07/2012 01:06, Joachim Steiger a ?crit : > Harald Welte wrote: > [...] >> However, now that I think of it, PCIe requires PCB thickness to be >> different (1.5mm) from what we are hading for (more like .8 or 1mm). >> >> So I guess I'll scrap that idea. > what about making it 2 pcb? > > one 'gsm module' with 'plated half holes'* and or board to board conn. > one 'carrier board' which then has the right thickness for the pcie-con. > > that way the sandwhich is mechanical stable and the rf performance > shouldnt be tampered with and can even serve as additional shielding if > needed (e.g. make side opposite to the modem gnd flat). > > this makes the modules as small as possible for integration into > different kinds of carriers or even a full phone. > > what do you think? > > > [*] > http://www.multi-circuit-boards.eu/en/pcb-design-aid/design-parameters/plated-half-holes.html > > -- > > roh > I was about to suggest the same thing. A very small 6-layer board with minimal/critical functionnality (not even the sim) and then let people integrate that into simpler PCBs. The RF can get out of the "critical" board via an UFL socket. In the past, wavecom (now sierra wireless) had this idea. They developed a modem core on a small PCB, using bga on the backside instead of plated half holes. The packaging was made with a metallic shielding box. Sebastien From kesmtp at freenet.de Thu Jul 12 21:08:56 2012 From: kesmtp at freenet.de (Mathias K.) Date: Thu, 12 Jul 2012 23:08:56 +0200 Subject: Custom calypso board In-Reply-To: <4FFE286A.6020601@lorquet.fr> References: <20120710170019.GC30822@prithivi.gnumonks.org> <4FFD1561.3080905@freenet.de> <20120711082610.GG2490@prithivi.gnumonks.org> <4FFD49C9.6000405@freenet.de> <20120711102147.GO2490@prithivi.gnumonks.org> <4FFD65B5.7020707@freenet.de> <20120711125133.GV2490@prithivi.gnumonks.org> <4FFE06FA.7020308@hyte.de> <4FFE286A.6020601@lorquet.fr> Message-ID: <4FFF3CE8.5050304@freenet.de> On 12.07.2012 03:29, S?bastien Lorquet wrote: > Le 12/07/2012 01:06, Joachim Steiger a ?crit : >> Harald Welte wrote: >> [...] >>> However, now that I think of it, PCIe requires PCB thickness to be >>> different (1.5mm) from what we are hading for (more like .8 or 1mm). >>> >>> So I guess I'll scrap that idea. >> what about making it 2 pcb? >> >> one 'gsm module' with 'plated half holes'* and or board to board conn. >> one 'carrier board' which then has the right thickness for the pcie-con. >> >> that way the sandwhich is mechanical stable and the rf performance >> shouldnt be tampered with and can even serve as additional shielding if >> needed (e.g. make side opposite to the modem gnd flat). >> >> this makes the modules as small as possible for integration into >> different kinds of carriers or even a full phone. >> >> what do you think? > > I was about to suggest the same thing. > A very small 6-layer board with minimal/critical functionnality (not even the sim) and then let > people integrate that into simpler PCBs. > The RF can get out of the "critical" board via an UFL socket. > > In the past, wavecom (now sierra wireless) had this idea. They developed a modem core on a small > PCB, using bga on the backside instead of plated half holes. The packaging was made with a metallic > shielding box. There are more other companies that go this way (look at bt or zigbee) and you can use this tiny boards with every cpu of your choice because the simple interface. I don't think this happens with this kind of special hardware. I really don't know if it make sense to use a separate rf-board and a main-board. Is there any chance to use this rf-board with another platform (fpga,dsp ...) then this would make sense and also decrease the price of this platform. Regards, Mathias From laforge at gnumonks.org Fri Jul 13 17:28:44 2012 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 13 Jul 2012 19:28:44 +0200 Subject: Custom calypso board In-Reply-To: <4FFE06FA.7020308@hyte.de> References: <20120710170019.GC30822@prithivi.gnumonks.org> <4FFD1561.3080905@freenet.de> <20120711082610.GG2490@prithivi.gnumonks.org> <4FFD49C9.6000405@freenet.de> <20120711102147.GO2490@prithivi.gnumonks.org> <4FFD65B5.7020707@freenet.de> <20120711125133.GV2490@prithivi.gnumonks.org> <4FFE06FA.7020308@hyte.de> Message-ID: <20120713172844.GQ20424@prithivi.gnumonks.org> Hi roh, On Thu, Jul 12, 2012 at 01:06:34AM +0200, Joachim Steiger wrote: > what about making it 2 pcb? > > one 'gsm module' with 'plated half holes'* and or board to board conn. > one 'carrier board' which then has the right thickness for the pcie-con. It increases the cost quite a bit, and you will end up wasting a lot of PCB space on the carrier board. Sure, I can understand where you're coming from, but I'm not so sure if I'm convinced that it's the way to go... Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sun Jul 15 21:51:22 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 15 Jul 2012 23:51:22 +0200 Subject: Custom calypso board In-Reply-To: <20120710170019.GC30822@prithivi.gnumonks.org> References: <20120710170019.GC30822@prithivi.gnumonks.org> Message-ID: <20120715215122.GH16134@prithivi.gnumonks.org> Hi again, there have been some comments and feedback to my original posting, but I was actually naively hoping for a bit more input. Particularly the "modifications" parts lile: > * external clock input / buffered clock output Any ideas how this should be implemented? Adding the buffered output is relatively simple, and it can always be present whether it is used or not. More interesting is the clock source, where I would like to see a switchable clock source between: * regular inetrnal VCTCXO * external clock input (U.FL) The external input could be sourced from one of our OCXO boards for higher stability. Or you can of course source the clock input of one board using the buffered output of another. Does anyone have a good idea how to implement the actual switch? I think it would be best to have it software-switchable from a GPIO... > * RF connector standard u.fl or SMA or optionally separate Rx/Tx? Here also we have the question of how to choose between the options. If nobody comes up with a better idea, I would probably simply have a placement option along the lines of a capacitor that can be soldered either in the direction of the antenna switch (for duplex) or into the direction of separate u.fl sockets for rx and tx. In fact,t we can e.g. route Rx always via the switch and do that procedure only for Tx. > * additional / unused TPU ports One of my ideas here was to be able to issue a TPU event from one board and use it to trigger something on another board. The question is how exactly the second half would be implemented. We could connect it to an interrupt input (like sim card detect which even is a FIQ on the ARM). But would that really help? Unfortunately the TPU has no triggers for external events (which would be 100% synchronous). If you have inputs to any of these topics, or have some other ideas of what could or should be done, feel free to discuss them here! Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From kesmtp at freenet.de Mon Jul 16 20:11:50 2012 From: kesmtp at freenet.de (Mathias K.) Date: Mon, 16 Jul 2012 22:11:50 +0200 Subject: Custom calypso board In-Reply-To: <20120715215122.GH16134@prithivi.gnumonks.org> References: <20120710170019.GC30822@prithivi.gnumonks.org> <20120715215122.GH16134@prithivi.gnumonks.org> Message-ID: <50047586.7030003@freenet.de> Hello, On 15.07.2012 23:51, Harald Welte wrote: > The external input could be sourced from one of our OCXO boards for > higher stability. Or you can of course source the clock input of one > board using the buffered output of another. > > Does anyone have a good idea how to implement the actual switch? I > think it would be best to have it software-switchable from a GPIO... > http://www.micrel.com/page.do?page=product-info/multiplexers.jsp Regards, Mathias From vogelchr at vogel.cx Tue Jul 17 12:54:14 2012 From: vogelchr at vogel.cx (Christian Vogel) Date: Tue, 17 Jul 2012 14:54:14 +0200 Subject: Custom calypso board In-Reply-To: <50047586.7030003@freenet.de> <20120715215122.GH16134@prithivi.gnumonks.org> Message-ID: <20120717125412.GA31986@vogel.cx> Hi all, On Sun, Jul 15, 2012 at 11:51:22PM +0200, Harald Welte wrote: > More interesting is the clock source, where I would like to see a > switchable clock source between: > * regular inetrnal VCTCXO > * external clock input (U.FL) on the compal phones, a stand-alone oscillator (with control input) is used, so I think you'll want to copy that. There are tiny single gate multiplexers (e.g. 74LVC1G157) where NXP specifies a propagation delay of 13ns max (125?C temperature, 1.65V supply), so it should certainly work at 26Mhz (RITA's input wouldn't need the full voltage swing anyway). > Does anyone have a good idea how to implement the actual switch? I > think it would be best to have it software-switchable from a GPIO... Switching the clock will produce a glitch, but we should be able to run the ARM core from the 32kHz clock crystal during that period, I think (but will have to check) would we really want to toggle between the two inputs? Do we want to autodetect a valid ext. refclock? On Mon, Jul 16, 2012 at 10:11:50PM +0200, Mathias K. wrote: > http://www.micrel.com/page.do?page=product-info/multiplexers.jsp The micrel parts are really impressive, but much too fast for our purpose (>2GHz). Chris From laforge at gnumonks.org Tue Jul 10 23:44:41 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 11 Jul 2012 01:44:41 +0200 Subject: TODAY: Jul 11, 8pm / Osmocom meeting in Berlin Message-ID: <20120710234441.GD2490@prithivi.gnumonks.org> Hi all! This is the announcement for the next Osmocom Berlin meeting. Jul 11, 8pm @ CCC Berlin, Marienstr. 11, 10113 Berlin There is no formal presentation scheduled for this meeting. However, updates will be provided on various current developments, such as * Progress in development of GPRS PCU * Status of Osmocom UMA/GAN controller development * Planning phase of custom calypso board * OsmoSDR roadmap If you are interested to show up, feel free to do so. There is no registration required. The meeting is free as in "free beer", despite no actual free beer being around. Updates and the blog post can be found here: http://openbsc.osmocom.org/trac/blog/osmug-20120711 Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From avwiseav at gmail.com Wed Jul 11 09:11:46 2012 From: avwiseav at gmail.com (bob wisebob) Date: Wed, 11 Jul 2012 17:11:46 +0800 Subject: A TCH sniffer demo Message-ID: Hi,List who can can me a TCH sniffer demo like the app_ccch_scan.c in the burst_id? I am try to do it but not work well ! Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From 775725965 at qq.com Wed Jul 11 13:37:03 2012 From: 775725965 at qq.com (=?gb18030?B?wvPM78rYzfvV3w==?=) Date: Wed, 11 Jul 2012 21:37:03 +0800 Subject: moto C118 who can give me a the phone UART connects PC USb PL2303 Message-ID: On the C123 the following pads are usable TP27 -- DLPWR (download power on), connects to Iota:RPWON TP14 -- RxD Modem TP13 -- TxD Modem TP9 -- CTS Modem TP39 -- GND can you give me a picture thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Jul 12 07:10:32 2012 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 12 Jul 2012 09:10:32 +0200 Subject: moto C118 who can give me a the phone UART connects PC USb PL2303 In-Reply-To: References: Message-ID: <20120712071032.GM2490@prithivi.gnumonks.org> Hi! I would appreciate if you could quickly introduce to us _what_ you are exactly trying to do. On Wed, Jul 11, 2012 at 09:37:03PM +0800, ????? wrote: > On the C123 the following pads are usable > > [...] > can you give me a picture thanks if you rotate the picture at http://bb.osmocom.org/trac/attachment/wiki/MotorolaC123/c123_pcb.jpg by 90 degrees clock-wise (Antenna on the top, buzzer at the bottom), you can see the test pads as illustrated here: http://bb.osmocom.org/trac/raw-attachment/wiki/MotorolaC123/compal_testpads.png Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From Marco_Schwan at arcor.de Wed Jul 11 17:54:44 2012 From: Marco_Schwan at arcor.de (Marco Schwan) Date: Wed, 11 Jul 2012 19:54:44 +0200 Subject: [PATCH] change the keypad layout and the uart port number for the Pirelli DP-L10 Message-ID: Hi, I have make a patch for the Pirelli DP-L10 created. You can enable and disable the patch in the makefile (src/target/firmware/Makefile). The Keypad layout is tested with rssi.bin app. Only the power button is not available. regards Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: pirelli_dpl10-keypad&uart.patch Type: text/x-patch Size: 3790 bytes Desc: not available URL: From 246tnt at gmail.com Wed Jul 18 08:29:37 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Wed, 18 Jul 2012 10:29:37 +0200 Subject: [PATCH] change the keypad layout and the uart port number for the Pirelli DP-L10 In-Reply-To: References: Message-ID: > I have make a patch for the Pirelli DP-L10 created. You can enable and > disable the patch in the makefile (src/target/firmware/Makefile). > The Keypad layout is tested with rssi.bin app. Only the power button > is not available. To be merge-able the patch would need to select at run time so that all built binaries built are functional at once. Right now this only creates a different set of wrong binaries ... Cheers, Sylvain From laforge at gnumonks.org Wed Jul 11 23:52:58 2012 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 12 Jul 2012 01:52:58 +0200 Subject: T-Mobile SIM card trouble / OsmocomBB Message-ID: <20120711235258.GI2490@prithivi.gnumonks.org> Hi Tobias! Regarding the problem with your current German T-Mobile SIM and OsmocomBB: The 0x60 that was received at startup is actually a "waiting time extension" byte. A quick read through the calypso SIM driver by dexter reveals that procedure byte handling is not implemented completely (only in the special case of RUN GSM ALGO). So basically what happens is that the card sends 0x60 to let the reader know that it is alive, but that it needs some more time to respond. The next byte 0x9f was then the first half of the status word. However, due to the incomplete SIM driver, the code thinks 0x60 0x9F is the status word, which of course is unknown. I'm not able to look into fixing this myself right now, but maybe somebody on the list has an interest in looking into the bug. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From avwiseav at gmail.com Thu Jul 12 03:28:06 2012 From: avwiseav at gmail.com (bob wisebob) Date: Thu, 12 Jul 2012 11:28:06 +0800 Subject: the sign of a voice frame in the AMR codec Message-ID: Hi,List. I am studying the TCH AMR codec; I using the first 8 bits of any TCH frame block to decide whether it is a speech frame or a signal; Although it will contain some non-speech frame; but I think it can capture all the speech frame and the captured file can be decoded correctly. is that right? -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Jul 12 07:07:56 2012 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 12 Jul 2012 09:07:56 +0200 Subject: the sign of a voice frame in the AMR codec In-Reply-To: References: Message-ID: <20120712070756.GL2490@prithivi.gnumonks.org> Hi Bob, maybe it would be a good idea if you could introduce yourself, who you are, what you are working on, and in which context you are doing this. You post a number of questions here, and expect people to help you. Unless we know if you are working on something useful, and will actually contribute that back to the community, why should somebody help you with those issues? Also, your mails are often _very_ short and don't give a lot of context. I don't want to scare you away, but just give you an explanation why your mails get so little feedback on this list. It's actually up to you to do something to change that. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From lonelysurfer at web.de Thu Jul 12 11:28:51 2012 From: lonelysurfer at web.de (lonelysurfer) Date: Thu, 12 Jul 2012 04:28:51 -0700 (PDT) Subject: the sign of a voice frame in the AMR codec In-Reply-To: References: Message-ID: <1342092531881-4025167.post@n3.nabble.com> Hi Bob, I tried efr and fr in airprobe and your decoder but also without success. My filter for non voice frames is : /* Unpack (ignore hu/hl) */ osmo_pbit2ubit_ext(bt, 0, bi->bits, 0, 57, 0); osmo_pbit2ubit_ext(bt, 57, bi->bits, 57, 57, 0); /* save stealing flags */ bt[114] = !!(bi->bits[14] & 0x10); // hl bt[115] = !!(bi->bits[14] & 0x20); // hu if (bt[114] || bt[115]) { // printf("might be FACCH %x , %x\n", bt[114], bt[115]); return; } You using the first 8 bits for indicating? Can you explain this? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/the-sign-of-a-voice-frame-in-the-AMR-codec-tp4025161p4025167.html Sent from the baseband-devel mailing list archive at Nabble.com. From avwiseav at gmail.com Fri Jul 13 00:25:52 2012 From: avwiseav at gmail.com (bob) Date: Thu, 12 Jul 2012 17:25:52 -0700 (PDT) Subject: the sign of a voice frame in the AMR codec In-Reply-To: <1342092531881-4025167.post@n3.nabble.com> References: <1342092531881-4025167.post@n3.nabble.com> Message-ID: <1342139152650-4025174.post@n3.nabble.com> Hi firstly, you must Determine how your network code?whether it is EFR or AMR, it is Very different. secondly, I correct myself, the 8 indication is not fully true, it depend many things, I read the GSM0509, found this, I hope it can be use to you : 3.2.1 Frequent inband signalling for AMR codec mode adaptation 3.2.1.1 General aspects The codec mode information, which has to be transmitted on each link, consists of Codec Mode Indications and Codec Mode Commands in the downlink, respectively Codec Mode Indications and Codec Mode Requests in the uplink. Codec Mode Indications inform the receiver about the currently applied codec mode. Codec Mode Commands inform the other end about the codec mode to be applied on the other link. Codec Mode Requests inform the other end about the preferred codec mode on the other link. Codec mode information is transmitted inband in the speech traffic channel, using a part of its transmission capacity. The coding of codec modes in the inband signalling is given in subclause 3.4.1. Channel coding of codec mode information is specified in GSM 05.03 [4] for all frame types. Codec modes are constrained to change only every second speech frame. Codec Mode Commands/Requests and Codec Mode Indications are sub-sampled such that they occur only every second frame. Codec Mode Indications and Codec Mode Commands/Requests shall be transmitted alternating within consecutive speech frames. Both, Codec Mode Indication and Codec Mode Command/Request, shall be transmitted together within every RATSCCH frame. 3.2.1.3 Transmitter/Receiver Synchronisation The alternating transmission of the codec mode information requires synchronisation of transmitting and receiving ends, such that Codec Mode Indications and Codec Mode Commands/Requests are decoded in correct order. To ensure proper synchronisation, the codec mode information shall be transmitted aligned to the 26?multiframe structure of the GSM system. For TCH/AFS, the default transmission phase shall be such that Codec Mode Indications are sent with speech frames having their first burst sent on TDMA frames 0, 8, 17 (modulo 26) in the uplink and TDMA frames 4, 13, 21 (modulo 26) in the downlink as defined in GSM 05.02 [3]. For TCH/AHS, the default transmission phase shall be such that Mode Indications are sent with speech frames having their first burst sent on TDMA frames 0, 8, 17 (modulo 26) or 1, 9, 18 (modulo 26) depending on the subchannel in the uplink and TDMA frames 4, 13, 21 (modulo 26) or 5, 14, 22 (modulo 26) depending on the subchannel, in the downlink, as defined in GSM 05.02 [3]. This default phase of the Codec Mode Indication in downlink direction is called "odd", the alternative phase, one speech frame shifted, is called "even". The phase in uplink is always the same and is never changed. At call set-up, after every successful handover and after a channel mode modify with consistent Multirate IE, the default phase (odd) shall be used in downlink direction. During a call, the phase of Codec Mode Indication may be changed in downlink by using a RATSCCH message. In case of handover failure and fall back to the BTS before the handover attempt, the phase before the handover attempt shall be used again (except if a RATSCCH procedure is pending, see section 3.2.2.2 bullet 6). -- View this message in context: http://baseband-devel.722152.n3.nabble.com/the-sign-of-a-voice-frame-in-the-AMR-codec-tp4025161p4025174.html Sent from the baseband-devel mailing list archive at Nabble.com. From chris.pcguy.inci at gmail.com Thu Jul 12 07:26:19 2012 From: chris.pcguy.inci at gmail.com (Christian Inci) Date: Thu, 12 Jul 2012 09:26:19 +0200 Subject: [PATCH] Fix build Message-ID: <4FFE7C1B.9040903@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Remember to change the header too. ;-) Signed-off-by: Christian Inci - --- src/logging.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP/nwYAAoJEC7OUg5VIFIF+zYP/i9itRon3ovv4Li2xqgIe6ZD DYmfG2m5iZiY6kvGR1q387gE/aQdyiOfO/tbmy+pwGJgP+H3Dvhy6cH4GGMxN+p1 OA84bLWGnpJ3+GJ1W9ippKgKxih5QHvR/+9gy4/z5Yxdtec4+jlTQyn/eD54Z95N HAcqJUBV0FSZeSdWDaEZUnLdnbtoBOBnW/3BHwUCgtXrzVpOumb4IM6AvbynmWiH F6q0pQgAYY4AdcbKlU1DzGxv1ge4FhjFOa06frAMiAN1oXy5iobdMq9+Yi/+EHmw NYsKMZJ4PAucuZZ0yspW+RvnBXhA8TZGBq6bjRmEvj1dMVHMIwmkeHS7VVpUDBgj GL6RiYAJz/2BZGh4k16HOi5BQdDYIKBFrPN5lMSJuj7et1PI2OxArywnP8OJ/Ff5 Ia4Jzx0lSjElVZtLGba9ujAXRQ+sAO5WcoAyFOnxuu1KxlBFY57s1Tep0J3mnmAD IMrPA7qxQbyiTVqR+pa7+e18MJf92rrhfsdBnW0oiATaYNrVY5eZ6mba2LHk5rRa P68McxYYGY6uf236DsE1fEji7UNNAmdhZaFMjcMFbw5cJK/Dmucf5EYcUHP9HIWs kqM4ehdr65TYvYJSeqcDr7wmOlr2QJih9T+NxxLiWE6VFvvTdh1cu9+wCJmkQBRC ZaqipE43nZxJ8CwRsZtu =3eYr -----END PGP SIGNATURE----- From chris.pcguy.inci at gmail.com Thu Jul 12 07:21:17 2012 From: chris.pcguy.inci at gmail.com (Christian Inci) Date: Thu, 12 Jul 2012 09:21:17 +0200 Subject: [PATCH] Fix build Message-ID: Remember to change the header too. ;-) Signed-off-by: Christian Inci --- src/logging.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/logging.c b/src/logging.c index 8dfc31e..b92a54c 100644 --- a/src/logging.c +++ b/src/logging.c @@ -314,7 +314,7 @@ void osmo_vlogp(int subsys, int level, char *file, int line, } } -void logp(int subsys, char *file, int line, int cont, +void logp(int subsys, const char *file, int line, int cont, const char *format, ...) { va_list ap; @@ -324,7 +324,7 @@ void logp(int subsys, char *file, int line, int cont, va_end(ap); } -void logp2(int subsys, unsigned int level, char *file, int line, int cont, const char *format, ...) +void logp2(int subsys, unsigned int level, const char *file, int line, int cont, const char *format, ...) { va_list ap; -- 1.7.8.6 --------------050502050900090804030106 Content-Type: application/pgp-signature; name="0001-Fix-build.patch.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0001-Fix-build.patch.sig" iQIcBAABAgAGBQJP/nwYAAoJEC7OUg5VIFIFwBUQAK4CHbDqHOd+ljCt/g/KHakum5u+/7oG htAlPb8NBvxQp4ao3Ui7QRHwn1HVw+X7l6sr8Aa0A03lljvm92emoeoGo+sFLosMR9sCBo/x gnGxZVAmkHsF+DM65r7C7XC07KcqH+dlDtUxlkAWBRf3ODl0sdTUiXY7qnz2tybvd5BB+M0k 1MtsA/zg+0bSFpspBZHcOSDJRn1kRP3/0RflWHH6rEjhvpIA7c5WFj6mPoS5btGfcOGUNOXj stLiusgQgzdOjHXsFpI5Of5BnGHAWooW0oEyuPpRi+c+FhFllD7EMaFrnBnkDugS92cpy3r7 6G+ByfQ6YMikyZErkc5KG9HLPqsNavMTz1AhU9w9vH22C8YWEyIQ6M0JZApiQVwHbezrwWFu qHU5ldv9ezPQ3VLzofldxvJx5ysheA65rpSaaI0EGH9/zw5/7zmpO56gJbWbYIFezOLmyEcI A4vB3ibuiFVJhEeEad221cAXv2QRLusNzhrhEHmCyRPBKjyzBFlarplspbOq2XB4pKa1mph0 oc4T5QWuvBjKznbhdSnFN99ON6UksYjQb9zBdlmkEhm+RjjwUuG9W3hleu2qhPbzlXtImGC5 nm2eT/IX+HcVaDFa9CFbqd2u4mXEi3LAl7MdHhhJTJsy/1DbLPTjS/0JvjOEeEY/93CEQvP2 SuSV --------------050502050900090804030106-- From 246tnt at gmail.com Thu Jul 12 07:37:09 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 12 Jul 2012 09:37:09 +0200 Subject: [PATCH] Fix build In-Reply-To: <4FFE7C1B.9040903@gmail.com> References: <4FFE7C1B.9040903@gmail.com> Message-ID: > Remember to change the header too. ;-) ??? Why not submit a patch that's complete directly ? Also, you add the 'const' but those two functions will end up calling osmo_vlogp which doesn't have a 'const' for the file argument. Cheers, Sylvain From dario.lombardo.ml at gmail.com Thu Jul 12 13:41:52 2012 From: dario.lombardo.ml at gmail.com (Dario Lombardo) Date: Thu, 12 Jul 2012 15:41:52 +0200 Subject: GSM clock and phones Message-ID: Hello everybody When launching a local BTS (like with openbts on usrp or similar), one needs to feed the BTS with a precise clock or a reference clock, depending on the hardware. This step is needed because phones need a precise clock from the BTS, otherwise they don't camp. Is that correct? If yes, my question is: how can a phone determine that the clock given by the network is precise enough? I'm a bit confused: how can the phone say that's not good, if it doesn't have a precise clock itself? I tried to search something on google but results got are completely out of scope. Can someone share some link? Thanks to all Dario. From 246tnt at gmail.com Thu Jul 12 14:01:46 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 12 Jul 2012 16:01:46 +0200 Subject: GSM clock and phones In-Reply-To: References: Message-ID: Hi, > When launching a local BTS (like with openbts on usrp or similar), one > needs to feed the BTS with a precise clock or a reference clock, > depending on the hardware. This step is needed because phones need a > precise clock from the BTS, otherwise they don't camp. Is that > correct? Yes it needs a precise clock to work reliably. But it's not that the phone will "reject" the BTS, it just won't find it at all ... > If yes, my question is: how can a phone determine that the clock given > by the network is precise enough? I'm a bit confused: how can the > phone say that's not good, if it doesn't have a precise clock itself? The phone doesn't have a precise clock, it has a pretty crappy cheap one often, let's say about 20 ppm. But once it find a GSM base station, it can tune its clock (because it's a VCXO Voltage Controlle Xtal Oscillator) and align it to match the one of the network. Now there are two distinct case that happens: 1) First phone power on / First sync When you first turn on your phone it will try to find a BTS. It will often try the last ARFCN that was used (it's written on the SIM). During this initial acquisition, the phone uses a large frequency error window like ~ 20 kHz for the calypso IIRC because it knows that its own clock is currently pretty bad. 2) Funrther sync / scan Once the phone has locked to at least one BTS, it has aligned its clocked to it and so it knows that its own clock became fairely good and from that point on, it will use a smaller frequency error window ( like ~ 2 kHz ) this will make the scan faster and avoid false positives. So as you see it's possible that a bad BTS clock would still be found by accident if its clock happens to deviate in the same direction as the phone xtal and if it's found during the initial scan. And this can also lead to situation where the phone only sees either the official networks _or_ the "custom" network but not both depending on which it found first ... Cheers, Sylvain From laforge at gnumonks.org Thu Jul 12 14:08:54 2012 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 12 Jul 2012 16:08:54 +0200 Subject: GSM clock and phones In-Reply-To: References: Message-ID: <20120712140854.GH2490@prithivi.gnumonks.org> On Thu, Jul 12, 2012 at 03:41:52PM +0200, Dario Lombardo wrote: > If yes, my question is: how can a phone determine that the clock given > by the network is precise enough? I'm a bit confused: how can the > phone say that's not good, if it doesn't have a precise clock itself? The phone will trim it's oscillator against the first network it is trying to register. So it is not absolute accuracy that you need, but relative accuracy. If the first cell the phone registers to is wrong, then it will only find other cells with an equally wrong clock. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From dario.lombardo.ml at gmail.com Thu Jul 12 15:27:03 2012 From: dario.lombardo.ml at gmail.com (Dario Lombardo) Date: Thu, 12 Jul 2012 17:27:03 +0200 Subject: GSM clock and phones In-Reply-To: <20120712140854.GH2490@prithivi.gnumonks.org> References: <20120712140854.GH2490@prithivi.gnumonks.org> Message-ID: Ok, I understand. That means that if I have a bts with clock source that has an offset of around 200 Hz from 10MHz of field BTS (like usrp N120 with its bundled OCXO), I CAN camp to that, and I have more chances to do so if I start from a switched off phone? Thanks Dario. From 775725965 at qq.com Fri Jul 13 02:53:52 2012 From: 775725965 at qq.com (=?gb18030?B?wvPM78rYzfvV3w==?=) Date: Fri, 13 Jul 2012 10:53:52 +0800 Subject: MOTO C 118 TP27 -- DLPWR (download power on), connects to Iota:RPWON Message-ID: TP27 -- DLPWR (download power on), connects to Iota:RPWON connects to ???????????????????????????????????? TP27 is must connects ????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 111212.JPG Type: application/octet-stream Size: 22811 bytes Desc: not available URL: From g3260 at lucre.fceia.unr.edu.ar Fri Jul 13 03:44:18 2012 From: g3260 at lucre.fceia.unr.edu.ar (=?ISO-8859-1?Q?G=A2mez_Nahuel_Lucas?=) Date: Fri, 13 Jul 2012 00:44:18 -0300 (ART) Subject: Sony Ericsson J100a (GSM-850 / GSM-1900), i can't configure Radio. Message-ID: Hey. I am new to the mailing list. I have a Sony Ericsson J100a phone (GSM-850 / GSM-1900)The problem is that I can not make calls and send SMS. I think the problem I have is with the configuration of the stage of Radio the phone, it seems that the SIM card is properly read. I leave it attached the console output of osmocom. OsmocomBB# show subscriber Mobile Subscriber of MS '1': IMSI: 72231001******* ICCID: 8954310111********* Service Provider Name: Claro AR SMS Service Center Address: +543200000001 Status: U1_UPDATED IMSI detached TSMI 0x65945b7c LAI: MCC 722 MNC 310 LAC 0x0c29 (Argentina, CTI PCS S.A) Key: sequence 1 ec 94 74 df fa 7c 69 fb Registered PLMN: MCC 722 MNC 310 (Argentina, CTI PCS S.A) Access barred cells: no Access classes: C1 List of forbidden PLMNs: MCC |MNC |cause -------+-------+------- 722 |34 |#255 (Argentina, 34) 722 |07 |#255 (Argentina, 07) 155 |0xff4 |#255 (155, 0xff4) OsmocomBB# OsmocomBB# show ms MS '1' is up, service is limited IMEI: 010848********* IMEISV: 010848********** IMEI generation: fixed automatic network selection state: A1 trying RPLMN MCC=722 MNC=310 (Argentina, CTI PCS S.A) cell selection state: C1 normal cell selection radio ressource layer state: idle mobility management layer state: MM idle, PLMN search OsmocomBB# Are missing information, please let me know to attach. Thank you very much. From sales at handheld-linux.com Fri Jul 13 17:30:15 2012 From: sales at handheld-linux.com (Dr. H. Nikolaus Schaller) Date: Fri, 13 Jul 2012 19:30:15 +0200 Subject: Spare / used Openmoko GTA02 motherboards Message-ID: <6219626D-AA67-4DAA-AC86-0257AF5AE779@handheld-linux.com> Hi, maybe someone here has a use for the motherboards we have removed to upgrade Openmoko Freerunners with a GTA04 board because they carry a Calypso modem. http://www.handheld-linux.com/wiki.php?page=Neo%20Freerunner%3AMotherboard If you don't agree on the price, please use the "wishlist" function to make your proposal. There are currently approx. 20-30 such boards. Nikolaus From krazy.okmo at gmail.com Sat Jul 14 00:33:52 2012 From: krazy.okmo at gmail.com (Ryan Hayes) Date: Fri, 13 Jul 2012 17:33:52 -0700 Subject: Baseband Architecture Question Message-ID: Hello all, I working with osmcombb phone, is there a current list of services needing to be developed for uplink/downlink services or am I assuming the entire architecture is based on a encryption set in GSM network? It would be great to get going on possible direction of either studying the architecture base as messaging service or UART programming side. thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From krazy.okmo at gmail.com Sat Jul 14 00:49:11 2012 From: krazy.okmo at gmail.com (Ryan Hayes) Date: Fri, 13 Jul 2012 17:49:11 -0700 Subject: Logical Channels in firmware Message-ID: Here is a good link on Logical Channels, I am assuming the firmware is capable of decoding some point of entry into network MU. http://gsmfordummies.com/tdma/logical.shtml is there a tutorial in applying patches in both osmocombb mobile or layer23? Is using it as a BTS a key to accessing these RF channels without seeing the normal ARFCN dumps? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From leonardo.nve at gmail.com Sat Jul 14 01:43:48 2012 From: leonardo.nve at gmail.com (Leonardo Nve) Date: Sat, 14 Jul 2012 03:43:48 +0200 Subject: TCH/H with BB Message-ID: <6B5101B9-EF80-4E3D-957D-1467DF7F8465@gmail.com> Hi everyone. I tried to use TCH/H with osmocom-bb (Testing branch) with this configuration on mobile.cfg: ...... ...... codec full-speed codec half-speed prefer ...... ...... no full-speech-v1 no full-speech-v2 half-speech-v1 ...... ...... Trying it over our network (openbsc only with TCH/H timeslots and hr default codecs ) we saw that handsets are still trying TCH/F, is TCH/H supported by bb??? Openbsc log: Fri Jul 13 20:48:28 2012 <0004> abis_rsl.c:621 (bts=0,trx=0,ts=2,ss=0) RF Channel Release CMD due error 1 Fri Jul 13 20:48:28 2012 <0004> abis_rsl.c:658 (bts=0,trx=0,ts=2,ss=0) RF CHANNEL RELEASE ACK Fri Jul 13 20:48:30 2012 <0004> abis_rsl.c:594 (bts=0,trx=0,ts=0,ss=0) is back in operation. Fri Jul 13 20:48:30 2012 <0004> abis_rsl.c:1281 BTS 0 CHAN RQD: no resources for TCH/F 0xdf Fri Jul 13 20:48:30 2012 <0019> ipaccess.c:426 Bad signalling message,sign_link returned error: 0c 13 01 88 13 df 03 31 11 0c Fri Jul 13 20:48:30 2012 <0004> abis_rsl.c:594 (bts=0,trx=0,ts=2,ss=0) is back in operation. Fri Jul 13 20:48:39 2012 <0004> abis_rsl.c:1281 BTS 0 CHAN RQD: no resources for TCH/F 0xdf Fri Jul 13 20:48:39 2012 <0019> ipaccess.c:426 Bad signalling message,sign_link returned error: 0c 13 01 88 13 df 09 f5 11 0c Fri Jul 13 20:48:51 2012 <0004> abis_rsl.c:1281 BTS 0 CHAN RQD: no resources for TCH/F 0xdf Fri Jul 13 20:48:51 2012 <0019> ipaccess.c:426 Bad signalling message,sign_link returned error: 0c 13 01 88 13 df 1c 31 11 0c From 246tnt at gmail.com Sat Jul 14 06:05:48 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 14 Jul 2012 08:05:48 +0200 Subject: TCH/H with BB In-Reply-To: <6B5101B9-EF80-4E3D-957D-1467DF7F8465@gmail.com> References: <6B5101B9-EF80-4E3D-957D-1467DF7F8465@gmail.com> Message-ID: > Trying it over our network (openbsc only with TCH/H timeslots and hr default codecs ) we saw that handsets are still trying TCH/F, is TCH/H supported by bb??? Yes, I've tested that with a MS tester a while ago. Make sure you also have: channel-capability sdcch+tchf+tchh in the config. It is _not_ supported by the nanoBTS though. Cheers, Sylvain From laforge at gnumonks.org Sat Jul 14 09:47:23 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 14 Jul 2012 11:47:23 +0200 Subject: TCH/H with BB In-Reply-To: References: <6B5101B9-EF80-4E3D-957D-1467DF7F8465@gmail.com> Message-ID: <20120714094723.GD21870@prithivi.gnumonks.org> On Sat, Jul 14, 2012 at 08:05:48AM +0200, Sylvain Munaut wrote: > It is _not_ supported by the nanoBTS though. to be more speicific: HR codec is not supported by it. AMR-HR (on TCH/H) is. But the latter is not supported by OsmocomBB (until somebody figures out the DSP patches from the TSM30 or original firmware and how to use them... Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 775725965 at qq.com Tue Jul 17 06:19:35 2012 From: 775725965 at qq.com (=?gb18030?B?wvPM78rYzfvV3w==?=) Date: Tue, 17 Jul 2012 14:19:35 +0800 Subject: how to make T191 Brush line Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Jul 17 07:53:15 2012 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 17 Jul 2012 09:53:15 +0200 Subject: your behaviour on this list (Re: how to make T191 Brush line) In-Reply-To: References: Message-ID: <20120717075315.GA3742@prithivi.gnumonks.org> Dear poster of this message, please do not post messages without an actual message body / text to this mailing list. It is considered rude if you ask other people for (free!) help, but don't even manage to write one paragraph about what you actually want to do. Even your previous postings usually only contained a one line text. No greeting, no signature, no explanation. This is not an instant messenger, but a mailing list! If you continue like this, I will remove you from this list. Thanks for your understanding. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From osmocarpenter at gmail.com Tue Jul 17 11:04:16 2012 From: osmocarpenter at gmail.com (George Carpenter) Date: Tue, 17 Jul 2012 14:04:16 +0300 Subject: OsmocomBB Wiki update/upgrade Message-ID: Hello. This is my first message to the mailing list and I would like to introduce myself. My name is George Tsnikosmaoglou (OsmoCarpenteR) and I live in Greece. I am watching this project for some years now, but due to heavy work load, unfortunately I cannot dedicate a lot of time to contribute to this project. I must give my congratulations to the people that have dedicated their time and show their passion and intelligence through this project. Even though I am watching this project for a lot of time, I consider myself a newbie, but I want to actively participate to the project and contribute to this effort as much as I can. I am already trying to inform as many people as possible, but as you know, you need a lot of effort to explain and convince one person at a time to devote some time to this project. I have met a lot of people that have either technical, or theoretical or both knowledge about GSM and general electronics. These people come with a high educational background, but due to the current working environment, they do not have time to spare to a free Software Open Source GSM Baseband software implementation as OsmocomBB is. The bottom line is that they are interested, but they stop after a while because the first steps are always difficult. So here are my proposals. It would be nice to have a complete and easy to read wiki. I know that this project is created and maintained by people who have devoted a lot of time to this project, but the current status of wiki does not allow a newbie to gather all the information that are needed to start easy and get in the project as fast as possible. I remember my first attempts to load the firmware to the mobile phone and I remember this was somewhat difficult. Thanks to some help from the IRC people that hang out and some manuals that float on the net (see srlabs gsmmap and gprs sniffing tutorial), I managed to get started. And never underestimate the frustration and the temper when you keep trying and trying to load your first firmware, or the excitement and awe when you see these sweet words (OsmocomBB) on the screen of the mobile phone. Personally, when I finally managed to load and run my first application (ccch_scan), something was created in my mind that this project really stands for something innovative and genius. But for most of my friends, this did not happen. Many of them stopped because they found this whole procedure frustrating and nerve breaking, so they either stopped or they left this aside. Also I see that although I am trying to devote sometime, there are always some expected problems. These problems are usually solved if you read the mailing list or ask help from IRC, but in many cases this takes a lot of effort and after some hours and painkillers, you cannot figure out how to solve a problem. Just to mention the latest FULL LRAM compile problem that exists since the start of the year. Yesterday I was trying all day to find a solution, but there were a lot of candidate solutions and patches, but none was solving the actual problem. This would have saved me a lot of time if this was mentioned in the wiki and if someone had devoted some time to print 2 lines of comment or directions on how to solve or explain to many people that it is not solved. Because I see that no one from the persons that have real skills and knowledge of this project spares some time to update and evolve the OsmocomBB wiki, I propose to create some ?booty?, so we get a proper wiki for this project and the person or persons that will create this will be ?rewarded? for their time and effort. I know that knowledge has no price, but I propose to create a ?booty? bank with either money or/and services or/and equipment. Anything that any individual can contribute. I think this will boost the quality of this project and will be something interesting for some newbie to get involved. Some things that I found that this project needs is a newbie/getting started wiki. Detailed and with information and explanation as you were talking to a 5 year old child. This should include detailed information on what equipment and first things to do before you even start your first attempt to load any code to the phone and then how to load the first firmware and load the first application. I really liked the srlabs instructions about gprs and gsmmap. It was a good way to start and it was a step by step manual and easy to understand. A full list of existing applications. This will include detailed explanation of each application and it?s capabilities. Also how to load them, all the application parameters and what you can do with them. A hints/tips list. This will be some useful information about the OsmocomBB project. What to do and not to do. For example if the loader shows always the FMTOOL message and what o do in similar situations. To take extra caution to the physical contact of the cable, etc. Issues that are encountered and are standard to the project. A current issues/proposed solutions to current problems. I cannot find a more proper example as the current FULL LRAM compile problem that we currently have. There can be a small description of the problem and candidate solutions till the problem is fully solved. This will spare a lot of time to persons that encounter problems and save a lot of traffic in the IRC and mailing list. It will also be a database of knowledge for genius solutions or efforts to solve an issue. A todo list. This refers to the masters of this project. That is because they usually show the direction of the project. They who have deep knowledge of this project can show where this project is heading for. So a todo list to get there will be nice. You never know, even a newbie may solve an issue that is it totally new to the project, just to evolve the whole project. Right now I do not find any reference or it is very difficult to know (even the masters of OsmocomBB) where this project is heading to. A full GSM documentation. This will include detailed documents and references on each and every aspect of GSM technology. I am talking for an encyclopedia of everything that is referred in GSM technology. I think this is very important to have all the information that is needed all in one place and updated on any occasion. This is very important for someone who really want to get involved in the project. This can also include 3G and future communication technologies. I am talking for the bible of communications. Of course one step at a time. I know that all the information that we need is out there on the net, but all the information gathered in one place and shorted by an expert would be the ultimate tool. Of course everything that I mentioned does not have any meaning or purpose if the wiki is not updated frequently. Sorry for the big message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alvin.schurman at gmail.com Tue Jul 17 12:17:52 2012 From: alvin.schurman at gmail.com (Alvin Schurman) Date: Tue, 17 Jul 2012 08:17:52 -0400 Subject: OsmocomBB Wiki update/upgrade In-Reply-To: References: Message-ID: Speaking as another interested observer, I wholeheartedly agree with what you wrote. I have been reading this list for years and actually own some of the equipment but I've never loaded the phones or become involved because the barrier to entry is a little high. It's a pain to search the list for info and I don't want to be seen asking what might appear to be stupid questions to the list. George, you might not want to hear this, but I think you would be a great person to document what you've done. You have good communication skills and the experience of loading a phone and entering into the project is fresh in your mind. Do yoiu have any notes from your experience that the gurus could add to the current wiki or use to construct a new one? If someone else is willing to start some newbee documentation, I would gladly add to the info by documenting my own entrance into the project. I'm sure other lurkers here would feel the same. Respectfully, Alvin On Tue, Jul 17, 2012 at 7:04 AM, George Carpenter wrote: > Hello. This is my first message to the mailing list and I would like to > introduce myself. > > My name is George Tsnikosmaoglou (OsmoCarpenteR) and I live in Greece. I > am watching this project for some years now, but due to heavy work load, > unfortunately I cannot dedicate a lot of time to contribute to this > project. I must give my congratulations to the people that have dedicated > their time and show their passion and intelligence through this project. > > Even though I am watching this project for a lot of time, I consider > myself a newbie, but I want to actively participate to the project and > contribute to this effort as much as I can. > > I am already trying to inform as many people as possible, but as you know, > you need a lot of effort to explain and convince one person at a time to > devote some time to this project. I have met a lot of people that have > either technical, or theoretical or both knowledge about GSM and general > electronics. These people come with a high educational background, but due > to the current working environment, they do not have time to spare to a > free Software Open Source GSM Baseband software implementation as > OsmocomBB is. The bottom line is that they are interested, but they stop > after a while because the first steps are always difficult. So here are my > proposals. > > It would be nice to have a complete and easy to read wiki. I know that > this project is created and maintained by people who have devoted a lot of > time to this project, but the current status of wiki does not allow a > newbie to gather all the information that are needed to start easy and get > in the project as fast as possible. I remember my first attempts to load > the firmware to the mobile phone and I remember this was somewhat > difficult. Thanks to some help from the IRC people that hang out and some > manuals that float on the net (see srlabs gsmmap and gprs sniffing > tutorial), I managed to get started. And never underestimate the > frustration and the temper when you keep trying and trying to load your > first firmware, or the excitement and awe when you see these sweet words > (OsmocomBB) on the screen of the mobile phone. Personally, when I finally > managed to load and run my first application (ccch_scan), something was > created in my mind that this project really stands for something innovative > and genius. But for most of my friends, this did not happen. Many of them > stopped because they found this whole procedure frustrating and nerve > breaking, so they either stopped or they left this aside. > > Also I see that although I am trying to devote sometime, there are always > some expected problems. These problems are usually solved if you read the > mailing list or ask help from IRC, but in many cases this takes a lot of > effort and after some hours and painkillers, you cannot figure out how > to solve a problem. Just to mention the latest FULL LRAM compile problem > that exists since the start of the year. Yesterday I was trying all day to > find a solution, but there were a lot of candidate solutions and patches, > but none was solving the actual problem. This would have saved me a lot of > time if this was mentioned in the wiki and if someone had devoted some time > to print 2 lines of comment or directions on how to solve or explain to > many people that it is not solved. > > Because I see that no one from the persons that have real skills and > knowledge of this project spares some time to update and evolve the > OsmocomBB wiki, I propose to create some ?booty?, so we get a proper wiki > for this project and the person or persons that will create this will be > ?rewarded? for their time and effort. I know that knowledge has no price, > but I propose to create a ?booty? bank with either money or/and services > or/and equipment. Anything that any individual can contribute. > > I think this will boost the quality of this project and will be something > interesting for some newbie to get involved. > > Some things that I found that this project needs is a newbie/getting > started wiki. Detailed and with information and explanation as you were > talking to a 5 year old child. This should include detailed information on > what equipment and first things to do before you even start your first > attempt to load any code to the phone and then how to load the first > firmware and load the first application. I really liked the srlabs > instructions about gprs and gsmmap. It was a good way to start and it was a > step by step manual and easy to understand. > > A full list of existing applications. This will include detailed > explanation of each application and it?s capabilities. Also how to load > them, all the application parameters and what you can do with them. > > A hints/tips list. This will be some useful information about the > OsmocomBB project. What to do and not to do. For example if the loader > shows always the FMTOOL message and what o do in similar situations. To > take extra caution to the physical contact of the cable, etc. Issues that > are encountered and are standard to the project. > > A current issues/proposed solutions to current problems. I cannot find a > more proper example as the current FULL LRAM compile problem that we > currently have. There can be a small description of the problem and > candidate solutions till the problem is fully solved. This will spare a lot > of time to persons that encounter problems and save a lot of traffic in the > IRC and mailing list. It will also be a database of knowledge for genius > solutions or efforts to solve an issue. > > A todo list. This refers to the masters of this project. That is because > they usually show the direction of the project. They who have deep > knowledge of this project can show where this project is heading for. So a > todo list to get there will be nice. You never know, even a newbie may > solve an issue that is it totally new to the project, just to evolve the > whole project. Right now I do not find any reference or it is very > difficult to know (even the masters of OsmocomBB) where this project is > heading to. > > A full GSM documentation. This will include detailed documents and > references on each and every aspect of GSM technology. I am talking for an > encyclopedia of everything that is referred in GSM technology. I think > this is very important to have all the information that is needed all in > one place and updated on any occasion. This is very important for someone > who really want to get involved in the project. This can also include 3G > and future communication technologies. I am talking for the bible of > communications. Of course one step at a time. I know that all the > information that we need is out there on the net, but all the information > gathered in one place and shorted by an expert would be the ultimate tool. > > Of course everything that I mentioned does not have any meaning or purpose > if the wiki is not updated frequently. > > Sorry for the big message. > > Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.huemer at xx.vu Tue Jul 17 13:10:15 2012 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Tue, 17 Jul 2012 15:10:15 +0200 Subject: OsmocomBB Wiki update/upgrade In-Reply-To: References: Message-ID: <20120717131014.GC10125@de.xx.vu> Hi George, On Tue, Jul 17, 2012 at 02:04:16PM +0300, George Carpenter wrote: > [...] > > Also I see that although I am trying to devote sometime, there are always > some expected problems. These problems are usually solved if you read the > mailing list or ask help from IRC, but in many cases this takes a lot of > effort and after some hours and painkillers, you cannot figure out how to > solve a problem. Maybe that's a question of tools. There are no public IRC logs of the #osmocom channel that I know of. I don't know whether publishing logs would comply with the freenode TOS and if the project leader would agree with that, it could be discussed though. Since the mailing list is mailman driven there are archives which can be downloaded and tools so you can convert these archives in mbox/maildir format and therefor search them with e.g. notmuchmail. > Just to mention the latest FULL LRAM compile problem that > exists since the start of the year. Yesterday I was trying all day to find > a solution, but there were a lot of candidate solutions and patches, but > none was solving the actual problem. This would have saved me a lot of time > if this was mentioned in the wiki and if someone had devoted some time to > print 2 lines of comment or directions on how to solve or explain to many > people that it is not solved. > In my opinion it is quite obvious what to do: update the wiki. Everybody can get an account. > Because I see that no one from the persons that have real skills and > knowledge of this project spares some time to update and evolve the > OsmocomBB wiki, I think the quality of the *.osmocom.org wikis is very high. >I propose to create some ?booty?, so we get a proper wiki > for this project and the person or persons that will create this will be > ?rewarded? for their time and effort. I know that knowledge has no price, > but I propose to create a ?booty? bank with either money or/and services > or/and equipment. Anything that any individual can contribute. Where would this money/services/equipment come from? > I think this will boost the quality of this project and will be something > interesting for some newbie to get involved. Again, if you find something out, why not just add it to the wiki? > Some things that I found that this project needs is a newbie/getting > started wiki. Detailed and with information and explanation as you were > talking to a 5 year old child. This should include detailed information on > what equipment and first things to do before you even start your first > attempt to load any code to the phone and then how to load the first > firmware and load the first application. I really liked the srlabs > instructions about gprs and gsmmap. It was a good way to start and it was a > step by step manual and easy to understand. To me there is no compelling reason to split the existing wiki. If the documented steps to get started are not verbose enough, this can be improved. Fragmentation isn't very likely to improve the overall documentation quality. > A full list of existing applications. This will include detailed > explanation of each application and it?s capabilities. Also how to load > them, all the application parameters and what you can do with them. I am not aware of an 'application' that is not documented in the wiki. If that's the case, start a new wiki page! A stub is better than nothing, questions can be asked on IRC... > A hints/tips list. This will be some useful information about the OsmocomBB > project. What to do and not to do. For example if the loader shows always > the FMTOOL message and what o do in similar situations. To take extra > caution to the physical contact of the cable, etc. Issues that are > encountered and are standard to the project. You just created some documentation. All that is left is to add it to the already existing wiki. > [...] > > A todo list. This refers to the masters of this project. That is because > they usually show the direction of the project. They who have deep > knowledge of this project can show where this project is heading for. So a > todo list to get there will be nice. You never know, even a newbie may > solve an issue that is it totally new to the project, just to evolve the > whole project. Right now I do not find any reference or it is very > difficult to know (even the masters of OsmocomBB) where this project is > heading to. This was discussed before. Not only at osmocom.org, but also at the LKML and other places. The consensus was always that people who understand the codebase also see what is left to do. a TODO list has not much value without knowledge and the skill level to implement missing features. > A full GSM documentation. This will include detailed documents and > references on each and every aspect of GSM technology. I am talking for an > encyclopedia of everything that is referred in GSM technology. I think > this is very important to have all the information that is needed all in > one place and updated on any occasion. This is very important for someone > who really want to get involved in the project. This can also include 3G > and future communication technologies. I am talking for the bible of > communications. Of course one step at a time. I know that all the > information that we need is out there on the net, but all the information > gathered in one place and shorted by an expert would be the ultimate tool. I agree that this would be useful. There are some places on the internet like gsmfordummies that try to do that, but there is undoubted room for improvement. To do something like that would mean a massive lot of work. Who should do that? > [...] Kind regards, -Alexander Huemer From Max.Suraev at fairwaves.ru Wed Jul 18 16:50:24 2012 From: Max.Suraev at fairwaves.ru (=?UTF-8?B?4piO?=) Date: Thu, 19 Jul 2012 00:50:24 +0800 Subject: milenage usage Message-ID: <5006E950.9020309@fairwaves.ru> Hello. I've noticed that unlike a5.h and comp128.h (include/osmocom/gsm), milenage.h is located in "src/gsm/milenage/" and thus is not included into .deb packages. What are the reasons for that and how milenage should be used properly? -- best regards, Max, http://fairwaves.ru From laforge at gnumonks.org Wed Jul 18 17:33:33 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 18 Jul 2012 19:33:33 +0200 Subject: milenage usage In-Reply-To: <5006E950.9020309@fairwaves.ru> References: <5006E950.9020309@fairwaves.ru> Message-ID: <20120718173333.GE1459@prithivi.gnumonks.org> Hi Max, On Thu, Jul 19, 2012 at 12:50:24AM +0800, ? wrote: > I've noticed that unlike a5.h and comp128.h (include/osmocom/gsm), milenage.h is > located in "src/gsm/milenage/" and thus is not included into .deb packages. the debian packages are not really maintained, we're happy if you want to improve their status. > What are the reasons for that and how milenage should be used properly? neither comp128v1 nor milenage should be used directly. Thei idea is that an application shouldn't care or know about the detailed algorithms. It should all be handled by the library in a generic way. They should be used via the generic osmo_auth api. both the comp128v1 and the milenage plugin are registering themselves via osmo_auth_register(). From laforge at gnumonks.org Wed Jul 18 17:48:50 2012 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 18 Jul 2012 19:48:50 +0200 Subject: milenage usage In-Reply-To: <5006E950.9020309@fairwaves.ru> References: <5006E950.9020309@fairwaves.ru> Message-ID: <20120718174850.GF1459@prithivi.gnumonks.org> Hi Max, I have not added doxygen documentation to the authentication code, see git commit 007a71e3329aa76bb92701c9eb10743c68c93af9 -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From martinhaug at smart-mail.de Wed Jul 18 18:00:20 2012 From: martinhaug at smart-mail.de (Martin Haug) Date: Wed, 18 Jul 2012 20:00:20 +0200 Subject: Is OsmocomBB save for use in Live Networks? Message-ID: <5006F9B4.80403@smart-mail.de> Hello, I am using a mobile phone with OsmocomBB on it, but with transmission disabled, because I dont have a private GSM-Network. Do you think it is save to turn tramission on or is Osmocom not reliable enough? greetz Martin Haug _________________________________________________________________ Free-Mail Postfach (bis zu 10 GB E-Mail-Speicher) SMS, MMS, Fax und vieles mehr - http://www.smart-mail.de From case at SDF.ORG Thu Jul 19 05:43:08 2012 From: case at SDF.ORG (John Case) Date: Thu, 19 Jul 2012 05:43:08 +0000 (UTC) Subject: Tooling up for osmocom, gnuradio, and android ... suggestions ? Message-ID: I am a mac and NetBSD user and have not run any linux systems for many years. I have never used Debian/Ubuntu/etc. Now I would like to begin doing work with osmocom, GNU radio, SDRs and some android development. I knw it's a religious question, but since I am starting with a completely blank slate, what would be the simplest, most painless distro to set up a development and build environment (cross compiling for arm, building osmocom, gnu radio, and running android development tools and SDKs) ? I assume the answer must be either Debian or Ubuntu, but really have no idea ... comments ? I think the nicest thing would be a distro that *already* had a full complement of the GNU devel/conf/build tools that all the examples in the wiki rely on ... so I wouldn;t have to worry about getting that environment up from scratch ... Thanks. From alexander.huemer at xx.vu Thu Jul 19 07:04:47 2012 From: alexander.huemer at xx.vu (Alexander Huemer) Date: Thu, 19 Jul 2012 09:04:47 +0200 Subject: Tooling up for osmocom, gnuradio, and android ... suggestions ? In-Reply-To: References: Message-ID: <20120719070447.GA24372@de.xx.vu> Hi John, On Thu, Jul 19, 2012 at 05:43:08AM +0000, John Case wrote: > > I am a mac and NetBSD user and have not run any linux systems for > many years. I have never used Debian/Ubuntu/etc. Now that's an interesting combination! ;) > > Now I would like to begin doing work with osmocom, GNU radio, SDRs > and some android development. > > I knw it's a religious question, but since I am starting with a > completely blank slate, what would be the simplest, most painless > distro to set up a development and build environment (cross > compiling for arm, building osmocom, gnu radio, and running android > development tools and SDKs) ? > > I assume the answer must be either Debian or Ubuntu, but really have > no idea ... comments ? Most developers use Debian, it works as expected. IIRC somebody in the past tried to package something from *.osmocom.org for netbsd. Search the ML archive. At least libosmocore compiles on freebsd[1]. Did you try to compile osmocombb on netbsd? I'd be interested in the results. > > [...] > Kind regards, -Alexander Huemer [1] http://jenkins.osmocom.org/jenkins/job/libosmocore/label=FreeBSD_amd64/ From khorben at defora.org Thu Jul 19 11:52:10 2012 From: khorben at defora.org (Pierre Pronchery) Date: Thu, 19 Jul 2012 13:52:10 +0200 Subject: Tooling up for osmocom, gnuradio, and android ... suggestions ? In-Reply-To: <20120719070447.GA24372@de.xx.vu> References: <20120719070447.GA24372@de.xx.vu> Message-ID: <5007F4EA.2090603@defora.org> Hi Alexander, John, list, On 19/07/2012 09:04, Alexander Huemer wrote: > > On Thu, Jul 19, 2012 at 05:43:08AM +0000, John Case wrote: >> >> I am a mac and NetBSD user and have not run any linux systems for >> many years. I have never used Debian/Ubuntu/etc. > Now that's an interesting combination! ;) Rock on! >> Now I would like to begin doing work with osmocom, GNU radio, SDRs >> and some android development. >> >> I knw it's a religious question, but since I am starting with a >> completely blank slate, what would be the simplest, most painless >> distro to set up a development and build environment (cross >> compiling for arm, building osmocom, gnu radio, and running android >> development tools and SDKs) ? I have managed to build Osmocom at some point on NetBSD; see: https://github.com/khorben/osmocom-bb It didn't fully work as-is from my tests, but it should be possible to make it work. I used a cross-compilation toolchain built through NetBSD's build.sh (evbarm). >> I assume the answer must be either Debian or Ubuntu, but really have >> no idea ... comments ? > Most developers use Debian, it works as expected. > IIRC somebody in the past tried to package something from *.osmocom.org > for netbsd. Search the ML archive. It's in pkgsrc-wip, wip/libosmocore. I did it in August 2011, I think it's way out of date now. > At least libosmocore compiles on freebsd[1]. > Did you try to compile osmocombb on netbsd? I'd be interested in the > results. *tadaaa* (no idea about the current code though) HTH, -- khorben From laforge at gnumonks.org Sat Jul 21 09:04:57 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 21 Jul 2012 11:04:57 +0200 Subject: Tooling up for osmocom, gnuradio, and android ... suggestions ? In-Reply-To: <5007F4EA.2090603@defora.org> References: <20120719070447.GA24372@de.xx.vu> <5007F4EA.2090603@defora.org> Message-ID: <20120721090457.GG22222@prithivi.gnumonks.org> Hi khorben and others, On Thu, Jul 19, 2012 at 01:52:10PM +0200, Pierre Pronchery wrote: > I have managed to build Osmocom at some point on NetBSD; see: > https://github.com/khorben/osmocom-bb we're happy to merge any patches you may have. I don't really think there are large show-stoppers in the libosmocore/openbsc/osmocom-bb code from making it work on NetBSD or other flavors of *NIX-like operating systems. It basically needs somebody who uses those systems to more or less regularly build the code and send patches for any problems. It's not that we are a Linux-only club. It's really just that nobody contributes patches... -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From peter at stuge.se Thu Jul 19 15:34:21 2012 From: peter at stuge.se (Peter Stuge) Date: Thu, 19 Jul 2012 17:34:21 +0200 Subject: Tooling up for osmocom, gnuradio, and android ... suggestions ? In-Reply-To: References: Message-ID: <20120719153421.14240.qmail@stuge.se> John Case wrote: > since I am starting with a completely blank slate, what would be > the simplest, most painless distro to set up a development and > build environment (cross compiling for arm, building osmocom, gnu > radio, and running android development tools and SDKs) ? > > I assume the answer must be either Debian or Ubuntu, but really have no > idea ... comments ? Debian and Ubuntu aren't really geared toward development. I rather see them as end-user distributions with development tool extras. I would suggest a source-based distribution, because by definition you will have easy access to a wealth of development tools. I'm extremely happy with Gentoo for my own needs. Gentoo calls itself a meta-distribution, it is built to accomodate people who create their own distribution, and it does very well at this. I build my own distributions for my systems on a build server, and after pressing the build button it takes about a day until my laptop tarball with ca. 1000 packages including various crosscompilers and other nice things falls out, which I unpack to a fresh partition and find my system ready to use, with the same configuration that I like to always have, because that is of course included in the build. This may seem extreme, but what you want to do is not very far from it. The osmocom projects and GNU radio are quite volatile, frequently changing, and more or less require staying constantly on the bleeding edge to get the most out of the projects, and to be able to contribute back of course! Very few distributions are equipped to handle anything bleeding edge, and in particular binary based distributions are useless, because you have to wait for someone else to build that last commit. Not what you want. Not all work must take place under control of a package manager of course. But on the other hand, since it is possible, then why not? Especially when you have to deal with the dependency hell of larger packages such as GNU radio, not having to do *everything* manually like on Slackware is a big relief and a time saver. > I think the nicest thing would be a distro that *already* had a full > complement of the GNU devel/conf/build tools that all the examples in the > wiki rely on ... so I wouldn;t have to worry about getting that environment > up from scratch ... They are usually available in every distribution. But the separation in binary distributions between "user" files and "developer" files (there is usually one package with the binaries, and a -dev or -devel package with any development files provided by that package; headers and maybe static libraries and so on) I find unhelpful on a system whose intended use is development. Gentoo allows you to customize pretty much everything, but abstracts compile time decisions into a harmoized set of "USE flags", so you can say both globally and per-package if you want examples installed, if you want documentation installed, if you want JPEG support, what databases you want supported in a package (assuming upstream allows choosing) and so on. Gentoo also has a very nice tool called crossdev, for building cross toolchains, which of course also integrates with the system package manager. It's a different mindset, but if you enjoy being in control of your system, rather than your system controlling you, then I think Gentoo would be worth a try for you. There are of course also other source based distributions! Some have left Gentoo for Archlinux, and there are several others. I have never needed anything which Gentoo did not provide, so I never had a reason to look for anything else. :) I'm sure that other distributions have users with exactly the same experience with those! :) //Peter From laforge at gnumonks.org Sat Jul 21 09:08:20 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 21 Jul 2012 11:08:20 +0200 Subject: Tooling up for osmocom, gnuradio, and android ... suggestions ? In-Reply-To: <20120719153421.14240.qmail@stuge.se> References: <20120719153421.14240.qmail@stuge.se> Message-ID: <20120721090820.GH22222@prithivi.gnumonks.org> Hi Peter, I really would like to stop this to go too far off-topic, but: On Thu, Jul 19, 2012 at 05:34:21PM +0200, Peter Stuge wrote: > The osmocom projects and GNU radio are quite volatile, frequently > changing, and more or less require staying constantly on the bleeding > edge to get the most out of the projects, and to be able to > contribute back of course! > > Very few distributions are equipped to handle anything bleeding edge, > and in particular binary based distributions are useless, because you > have to wait for someone else to build that last commit. Not what you > want. I'm not really sure how those two relate. I regularly build all of the osmoocom code on Debian stable (which is known for its ancient versions). So I really don't think we have any dependencies to something that would not be part of any more or less current distribution of the last 2-3 years. So I would think that all of those distributions (source-built or binary based) are equally well equipped to build and use any of the osmocom projects on them. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From peter at stuge.se Sat Jul 21 11:31:36 2012 From: peter at stuge.se (Peter Stuge) Date: Sat, 21 Jul 2012 13:31:36 +0200 Subject: Tooling up for osmocom, gnuradio, and android ... suggestions ? In-Reply-To: <20120721090820.GH22222@prithivi.gnumonks.org> References: <20120719153421.14240.qmail@stuge.se> <20120721090820.GH22222@prithivi.gnumonks.org> Message-ID: <20120721113136.14896.qmail@stuge.se> Harald Welte wrote: > > The osmocom projects and GNU radio are quite volatile, frequently > > changing, and more or less require staying constantly on the bleeding > > edge to get the most out of the projects, and to be able to > > contribute back of course! > > > > Very few distributions are equipped to handle anything bleeding edge, > > and in particular binary based distributions are useless, because you > > have to wait for someone else to build that last commit. Not what you > > want. > > I'm not really sure how those two relate. I regularly build all of the > osmoocom code on Debian stable (which is known for its ancient > versions). So I really don't think we have any dependencies to > something that would not be part of any more or less current > distribution of the last 2-3 years. Yes, but you have no option but to build everything manually, I call it slackware style, while with a source based distribution it is more likely that there is actual support for bleeding edge packages. In Gentoo they're called "live" ebuilds; latest git is built and managed by the package manager. Dependencies are resolved. It's quite nice. > So I would think that all of those distributions (source-built or binary > based) are equally well equipped to build and use any of the osmocom > projects on them. Certainly when building everything manually, but that's really quite primitive. Source based distributions generally have more powerful package management tooling was my message, which I think is on topic. //Peter From avwiseav at gmail.com Thu Jul 19 08:58:28 2012 From: avwiseav at gmail.com (bob) Date: Thu, 19 Jul 2012 01:58:28 -0700 (PDT) Subject: is my patch for capturing TCH frame correctly? Message-ID: <1342688308441-4025199.post@n3.nabble.com> Hi, everyone interesting the topic, this is my latest patch for TCH decode, fix few bug; but it not work well for TCH AMR decode, welcome everyone interesting it to review it and modify it! the most problem now I think is the capture of the Correct TCH frame, at the last ,there is some output for analysis --- app_ccch_scan.c 2012-03-14 16:08:11.305112000 +0800 +++ new_app_ccch_scan.c 2012-07-19 15:32:31.945314000 +0800 @@ -50,20 +50,80 @@ #include #include +#include +#include "conv_tch_afs.h" +//#include "../openbtsstuff/GSML1FEC.h" +//extern bool TCHFACCHL1Decoder::processBurst( const RxBurst& inBurst); +//const struct osmo_conv_code conv_tch_afs_12_2; +extern FILE *log_tmsi; extern struct gsmtap_inst *gsmtap_inst; +FILE *d_speech_file; +const unsigned char amr_nb_magic[6] = { 0x23, 0x21, 0x41, 0x4d, 0x52, 0x0a }; + +enum gsm690_amr_mode { + gsm690_4_75 = 0x01, + gsm690_5_15 = 0x02, + gsm690_5_90 = 0x04, + gsm690_6_70 = 0x08, + gsm690_7_40 = 0x10, + gsm690_7_95 = 0x20, + gsm690_10_2 = 0x40, + gsm690_12_2 = 0x80, +}; + +enum gsm690_amr_speech { + gsm690_4_75_len = 95, + gsm690_5_15_len = 103, + gsm690_5_90_len = 118, + gsm690_6_70_len = 134, + gsm690_7_40_len = 148, + gsm690_7_95_len = 159, + gsm690_10_2_len = 204, + gsm690_12_2_len = 244, +}; + +enum gsm690_amr_mode_flag { + CODEC_MODE_1 = 0b00000000, + CODEC_MODE_2 = 0b10111010, + CODEC_MODE_3 = 0b01011101, + CODEC_MODE_4 = 0b11100111, +}; + +/*gsm4.08 10.5.2.6 +enum channel_speed_mode{ + Signal = 0, + Speed_v1 = 0x01, + Speed_v2 = 0x21, + Speed_v3 = 0x41, +};*/ enum dch_state_t { DCH_NONE, + CCCH_ACTIVE, DCH_WAIT_EST, DCH_ACTIVE, + DCH_TCH, DCH_WAIT_REL, }; +static struct amr{ + uint8_t amr_acs; + uint8_t start_mode; +}; + +static struct amr_current{ + uint8_t mode; + uint8_t i; +}; + static struct { int has_si1; + int has_si3; int ccch_mode; - + int neci; + int sys_count; + enum dch_state_t dch_state; uint8_t dch_nr; int dch_badcnt; @@ -73,15 +133,76 @@ sbit_t bursts_dl[116 * 4]; sbit_t bursts_ul[116 * 4]; + sbit_t bursts_ccch[4][116*4]; + sbit_t mI[8][114]; struct gsm_sysinfo_freq cell_arfcns[1024]; uint8_t kc[8]; + uint8_t speed_mode; + struct amr amr_arg; + struct amr_current amr_cur; + + struct gsm48_ass_cmd ia; } app_state; +static char * +gen_filename(struct osmocom_ms *ms, struct l1ctl_burst_ind *bi) +{ + static char buffer[256]; + time_t d; + struct tm lt; + + time(&d); + localtime_r(&d, <); + + snprintf(buffer, 256, "voice_%04d%02d%02d_%02d%02d_%d_%d_%02x.amr", + lt.tm_year + 1900, lt.tm_mon, lt.tm_mday, + lt.tm_hour, lt.tm_min, + ms->test_arfcn, + ntohl(bi->frame_nr), + bi->chan_nr + ); + + return buffer; +} static void dump_bcch(struct osmocom_ms *ms, uint8_t tc, const uint8_t *data) { + if(app_state.dch_state == DCH_TCH) + { + //BCCH- SDCCH - BCCH -TCH + struct gsm48_ass_cmd *ia; + uint8_t ch_type, ch_subch, ch_ts; + + ia = &app_state.ia; + + rsl_dec_chan_nr(ia->chan_desc.chan_nr, &ch_type, &ch_subch, &ch_ts); + + if (!ia->chan_desc.h0.h) { + /* Non-hopping */ + uint16_t arfcn; + + arfcn = ia->chan_desc.h0.arfcn_low | (ia->chan_desc.h0.arfcn_high << 8); + + LOGP(DRR, LOGL_NOTICE, "ASS CMD(chan_nr=0x%02x, " + "ARFCN=%u, TS=%u, SS=%u, TSC=%u) ", + ia->chan_desc.chan_nr, arfcn, ch_ts, ch_subch, + ia->chan_desc.h0.tsc); + + /* request L1 to go to dedicated mode on assigned channel */ + l1ctl_tx_dm_est_req_h0(ms, + arfcn, ia->chan_desc.chan_nr, ia->chan_desc.h0.tsc, + GSM48_CMODE_SPEECH_EFR, 0); + } + else + { + printf("unsuport hopping!\n"); + } + + return; + } + struct gsm48_system_information_type_header *si_hdr; si_hdr = (struct gsm48_system_information_type_header *) data; @@ -115,18 +236,40 @@ #ifdef BCCH_TC_CHECK if (tc != 2 && tc != 6) LOGP(DRR, LOGL_ERROR, "SI3 on the wrong TC: %d\n", tc); -#endif - if (app_state.ccch_mode == CCCH_MODE_NONE) { - struct gsm48_system_information_type_3 *si3 = - (struct gsm48_system_information_type_3 *)data; - - if (si3->control_channel_desc.ccch_conf == RSL_BCCH_CCCH_CONF_1_C) - app_state.ccch_mode = CCCH_MODE_COMBINED; - else - app_state.ccch_mode = CCCH_MODE_NON_COMBINED; +#endif + if(!app_state.has_si3) + { + if (app_state.ccch_mode == CCCH_MODE_NONE) { + struct gsm48_system_information_type_3 *si3 = + (struct gsm48_system_information_type_3 *)data; + //printf("si3->control_channel_desc.ccch_conf = %d\n",si3->control_channel_desc.ccch_conf); + switch (si3->control_channel_desc.ccch_conf) { + case RSL_BCCH_CCCH_CONF_1_C: + app_state.ccch_mode = CCCH_MODE_COMBINED; + break; + case RSL_BCCH_CCCH_CONF_1_NC: + app_state.ccch_mode = CCCH_MODE_NON_COMBINED; + break; + case RSL_BCCH_CCCH_CONF_2_NC: + app_state.ccch_mode = CCCH_MODE_NON_COMBINED2; + break; + case RSL_BCCH_CCCH_CONF_3_NC: + app_state.ccch_mode = CCCH_MODE_NON_COMBINED4; + break; + case RSL_BCCH_CCCH_CONF_4_NC: + app_state.ccch_mode = CCCH_MODE_NON_COMBINED6; + break; + default: + fprintf(stderr, "\tUnknown CCCH_MODE\n"); + return; + } + app_state.neci = si3->cell_sel_par.neci; + app_state.has_si3 = 1; - l1ctl_tx_ccch_mode_req(ms, app_state.ccch_mode); + l1ctl_tx_ccch_mode_req(ms, app_state.ccch_mode); + } } + break; case GSM48_MT_RR_SYSINFO_4: #ifdef BCCH_TC_CHECK @@ -191,7 +334,10 @@ case GSM48_MT_RR_SYSINFO_5ter: break; default: - fprintf(stderr, "\tUnknown SI"); + app_state.sys_count++; + if(app_state.sys_count == 2) + l1ctl_tx_reset_req(ms, L1CTL_RES_T_FULL); + fprintf(stderr, "\tUnknown SI\n"); break; }; } @@ -207,16 +353,27 @@ struct gsm48_imm_ass *ia = msgb_l3(msg); uint8_t ch_type, ch_subch, ch_ts; int rv; + uint8_t chan_req_val, chan_req_mask, ra; /* Discard packet TBF assignement */ - //if (ia->page_mode & 0xf0) - if ((ia->page_mode & 0xf0) != 0x10) + if (ia->page_mode & 0xf0) return 0; /* If we're not ready yet, or just busy ... */ - if ((!app_state.has_si1) || (app_state.dch_state != DCH_NONE)) + if ((!app_state.has_si1) || (!app_state.has_si3) || (app_state.dch_state != DCH_NONE)) return 0; + printf("imm_ra %x,################!\n",ia->req_ref.ra); + //get the request cause +/* if(app_state.neci) + { + if(!((ia->req_ref.ra & 0xf0) == 0x10 ||(ia->req_ref.ra & 0xe0) == 0x80)) + return 0; + } else { + if(!((ia->req_ref.ra & 0xe0) == 0xe0 ||(ia->req_ref.ra & 0xe0) == 0x80)) + return 0; + } +*/ rsl_dec_chan_nr(ia->chan_desc.chan_nr, &ch_type, &ch_subch, &ch_ts); if (!ia->chan_desc.h0.h) { @@ -359,6 +516,8 @@ chan_need(pag->cneed1), mi_type_to_string(mi_type), mi_string); + fputs(mi_string,log_tmsi); + fputs("\n",log_tmsi); } /* check if we have a MI type in here */ @@ -380,10 +539,12 @@ chan_need(pag->cneed2), mi_type_to_string(mi_type), mi_string); + fputs(mi_string,log_tmsi); + fputs("\n",log_tmsi); } return 0; } - +char temp[20]; static int gsm48_rx_paging_p2(struct msgb *msg, struct osmocom_ms *ms) { struct gsm48_paging2 *pag; @@ -394,14 +555,23 @@ LOGP(DRR, LOGL_ERROR, "Paging2 message is too small.\n"); return -1; } - + memset(temp,0,sizeof(temp)); pag = msgb_l3(msg); LOGP(DRR, LOGL_NOTICE, "Paging1: %s chan %s to TMSI M(0x%x) \n", pag_print_mode(pag->pag_mode), chan_need(pag->cneed1), pag->tmsi1); + memset(temp,0,sizeof(temp)); + sprintf(temp, "%x", ntohl(pag->tmsi1)); + fputs(temp,log_tmsi); + fputs("\n",log_tmsi); + LOGP(DRR, LOGL_NOTICE, "Paging2: %s chan %s to TMSI M(0x%x) \n", pag_print_mode(pag->pag_mode), - chan_need(pag->cneed1), pag->tmsi2); + chan_need(pag->cneed2), ntohl(pag->tmsi2)); + memset(temp,0,sizeof(temp)); + sprintf(temp, "%x", pag->tmsi2); + fputs( temp,log_tmsi); + fputs("\n",log_tmsi); /* no optional element */ if (msgb_l3len(msg) < sizeof(*pag) + 3) @@ -425,15 +595,91 @@ "n/a ", mi_type_to_string(mi_type), mi_string); + fputs(mi_string,log_tmsi); + fputs("\n",log_tmsi); + return 0; +} +static int gsm48_rx_paging_p3(struct msgb *msg, struct osmocom_ms *ms) +{ + struct gsm48_paging3 *pag; + + if (msgb_l3len(msg) < sizeof(*pag)) { + LOGP(DRR, LOGL_ERROR, "Paging3 message is too small.\n"); + return -1; + } + + pag = msgb_l3(msg); + LOGP(DRR, LOGL_NOTICE, "Paging1: %s chan %s to TMSI M(0x%x) \n", + pag_print_mode(pag->pag_mode), + chan_need(pag->cneed1), pag->tmsi1); + memset(temp,0,sizeof(temp)); + sprintf(temp, "%x", ntohl(pag->tmsi1)); + fputs(temp,log_tmsi); + fputs("\n",log_tmsi); + LOGP(DRR, LOGL_NOTICE, "Paging2: %s chan %s to TMSI M(0x%x) \n", + pag_print_mode(pag->pag_mode), + chan_need(pag->cneed2), pag->tmsi2); + memset(temp,0,sizeof(temp)); + sprintf(temp, "%x", ntohl(pag->tmsi2)); + fputs(temp,log_tmsi); + fputs("\n",log_tmsi); + LOGP(DRR, LOGL_NOTICE, "Paging3: %s chan %s to TMSI M(0x%x) \n", + pag_print_mode(pag->pag_mode), + "n/a ", pag->tmsi3); + memset(temp,0,sizeof(temp)); + sprintf(temp, "%x", ntohl(pag->tmsi3)); + fputs(temp,log_tmsi); + fputs("\n",log_tmsi); + LOGP(DRR, LOGL_NOTICE, "Paging4: %s chan %s to TMSI M(0x%x) \n", + pag_print_mode(pag->pag_mode), + "n/a ", pag->tmsi4); + memset(temp,0,sizeof(temp)); + sprintf(temp, "%x", ntohl(pag->tmsi4)); + fputs(temp,log_tmsi); + fputs("\n",log_tmsi); return 0; } + int gsm48_rx_ccch(struct msgb *msg, struct osmocom_ms *ms) { struct gsm48_system_information_type_header *sih = msgb_l3(msg); int rc = 0; + if(app_state.dch_state == DCH_TCH) + { + //BCCH- SDCCH - BCCH -TCH + struct gsm48_ass_cmd *ia; + uint8_t ch_type, ch_subch, ch_ts; + + ia = &app_state.ia; + + rsl_dec_chan_nr(ia->chan_desc.chan_nr, &ch_type, &ch_subch, &ch_ts); + + if (!ia->chan_desc.h0.h) { + /* Non-hopping */ + uint16_t arfcn; + + arfcn = ia->chan_desc.h0.arfcn_low | (ia->chan_desc.h0.arfcn_high << 8); + + LOGP(DRR, LOGL_NOTICE, "ASS CMD(chan_nr=0x%02x, " + "ARFCN=%u, TS=%u, SS=%u, TSC=%u) ", + ia->chan_desc.chan_nr, arfcn, ch_ts, ch_subch, + ia->chan_desc.h0.tsc); + + /* request L1 to go to dedicated mode on assigned channel */ + l1ctl_tx_dm_est_req_h0(ms, + arfcn, ia->chan_desc.chan_nr, ia->chan_desc.h0.tsc, + GSM48_CMODE_SPEECH_EFR, 0); + } + else + { + printf("unsuport hopping!\n"); + } + + return 0; + } /* CCCH marks the end of WAIT_REL */ if (app_state.dch_state == DCH_WAIT_REL) app_state.dch_state = DCH_NONE; @@ -449,7 +695,7 @@ gsm48_rx_paging_p2(msg, ms); break; case GSM48_MT_RR_PAG_REQ_3: - LOGP(DRR, LOGL_ERROR, "PAGING of type 3 is not implemented.\n"); + gsm48_rx_paging_p3(msg, ms); break; case GSM48_MT_RR_IMM_ASS: gsm48_rx_imm_ass(msg, ms); @@ -483,9 +729,397 @@ return 0; } +void tch_deinterleave(ubit_t *mC, int blockOffset) +{ + int k; + for (k = 0; k < 456; k++) { + int B = ( k + blockOffset ) % 8; + int j = 2 * ((49 * k) % 57) + ((k % 8) / 4); + mC[k] = app_state.mI[B][j]; + app_state.mI[B][j] = 0; + //OBJDCOUT("deinterleave k="<=dpBase) { + *dp-- = value & 0x01; + value >>= 1; + } +} + +uint64_t count_tch = 0; +uint32_t flag = 0; + +static void process_tch_efr(struct osmocom_ms *ms,struct l1ctl_burst_ind *bi) +{ + int16_t rx_dbm; + uint16_t arfcn; + uint32_t fn,B; + uint8_t cbits, tn, lch_idx; + int ul, bid, i, k, length; + sbit_t *bursts, mC[456]; + ubit_t steal_bit[2], bt[114],convu[189],convd[189],tch_raw[260],TCHW[260],EFRBits[244],EFRAMR[8 + 244]; + + pbit_t voice[33]; + /* Get params (Only for SDCCH and SACCH/{4,8,F,H}) */ + arfcn = ntohs(bi->band_arfcn); + rx_dbm = rxlev2dbm(bi->rx_level); + + fn = ntohl(bi->frame_nr); + ul = !!(arfcn & ARFCN_UPLINK); + + cbits = bi->chan_nr >> 3; + tn = bi->chan_nr & 7; + + B = -1; + + if((fn%13)%4 == 0) flag= 1; + + if(!flag) return; + + B = count_tch % 8; + //printf("fn%13 %4 = %d\n",(fn%13)%4); + if (B == -1) + return; + + /* Clear if new set */ + if (B == 0){ + for(i=0; i<4; i++){ + memset(app_state.mI[i], 0x00, 114); + } + }else if(B == 4){ + for(i=4; i<8; i++){ + memset(app_state.mI[i], 0x00, 114); + } + } + + /* Unpack (ignore hu/hl) */ + osmo_pbit2ubit_ext(bt, 0, bi->bits, 0, 57, 0); + osmo_pbit2ubit_ext(bt, 57, bi->bits, 57, 57, 0); + osmo_pbit2ubit_ext(steal_bit, 0 , bi->bits, 114 , 2 , 0); + //printf("steal_bit %x , %x\n",steal_bit[0],steal_bit[1]); + /* Convert to softbits */ + for (i=0; i<114; i++) + app_state.mI[B][i] = bt[i] ? - (bi->snr >> 1) : (bi->snr >> 1); + + count_tch++; + // Deinterleave according to the diagonal "phase" of B. + // See GSM 05.03 3.1.3. + // Deinterleaves i[] to c[] + if((B % 4 ==3)&&(count_tch >= 7)){ + if(B == 3) + { + tch_deinterleave(mC, 4); + }else{ + tch_deinterleave(mC, 0); + } + + for (k = 0; k < 78; k++) { + tch_raw[182 + k] = mC[378 +k]; + } + + osmo_conv_decode(&conv_tch_afs_12_2, mC, convu); + + // 3.1.2.1 + // copy class 1 bits u[] to d[] + for (k = 0; k <= 90; k++) { + convd[2*k] = convu[k]; + convd[2*k+1] = convu[184-k]; + } + + memcpy(tch_raw,convd,182); // the last 78 bit has been stored! + + //now only process EFR or AMR 12_2, fix me! + tch_unmap(gsm660_bitorder, 260, TCHW, tch_raw); + + // Remove repeating bits and CRC to get raw EFR frame (244 bits) + for (k=0; k<71; k++) + EFRBits[k] = TCHW[k] & 1; + + for (k=73; k<123; k++) + EFRBits[k-2] = TCHW[k] & 1; + + for (k=125; k<178; k++) + EFRBits[k-4] = TCHW[k] & 1; + + for (k=180; k<230; k++) + EFRBits[k-6] = TCHW[k] & 1; + + for (k=232; k<252; k++) + EFRBits[k-8] = TCHW[k] & 1; + // Map bits as AMR 12.2k + tch_map(gsm690_12_2_bitorder, 244, EFRAMR + 8,EFRBits); + + // Put the whole frame (hdr + payload) + //mVFrameAMR.pack(mPrevGoodFrame); + //mPrevGoodFrameLength = 32; + fillField(EFRAMR, 0, 0x3c, 8); + voice[32] = 0; + length = osmo_ubit2pbit(voice, EFRAMR, 8 + 244); + fwrite(voice, 1, 32, d_speech_file); + } + +} + +int find_speech_mode(unsigned char codec,int j) +{ + int i,k; + k = 0; + for(i = 0;i<8;i++) + { + if(app_state.amr_arg.amr_acs & (1 << i)){ + k++; + if(k == j) + return i; + } + } +} + +static void process_tch_amr(struct osmocom_ms *ms,struct l1ctl_burst_ind *bi) +{ + int16_t rx_dbm; + uint16_t arfcn; + uint32_t fn,B; + uint8_t cbits, tn, lch_idx; + int ul, bid, i, k, length; + sbit_t *bursts, mC[456],hl,hu; + ubit_t steal_bit[2], bt[116],convu[260],convd[260],tch_raw[260],TCHW[260],EFRBits[244],EFRAMR[8 + 244]; + + pbit_t voice[33]; + /* Get params (Only for SDCCH and SACCH/{4,8,F,H}) */ + arfcn = ntohs(bi->band_arfcn); + rx_dbm = rxlev2dbm(bi->rx_level); + + fn = ntohl(bi->frame_nr); + ul = !!(arfcn & ARFCN_UPLINK); + + cbits = bi->chan_nr >> 3; + tn = bi->chan_nr & 7; + + B = -1; + + if(( fn % 13 ) % 4 == 0) flag = 1; + + if(!flag) return; + + //B = count_tch % 8; + B = ( fn % 13 ) % 8; + printf("fn % 26 = %d, fn % 13 = %d, B = %d\n",fn%26 , fn%13 , B); + + if (B == -1) + return; + + /* Unpack (ignore hu/hl) */ + osmo_pbit2ubit_ext(bt, 0, bi->bits, 0, 57, 0); + osmo_pbit2ubit_ext(bt, 57, bi->bits, 57, 57, 0); + //osmo_pbit2ubit_ext(steal_bit, 0 , bi->bits, 114 , 2 , 0); + //hl = bi->bits[14] & 0x10; + //hu = bi->bits[14] & 0x20; + + /* save stealing flags */ + bt[114] = !!(bi->bits[14] & 0x10); // hl + bt[115] = !!(bi->bits[14] & 0x20); // hu + printf("steal_bit %x , %x\n", bt[114],bt[115]); + +/* if (bt[114] || bt[115]) { + printf("might be FACCH %x , %x\n", bt[114], bt[115]); + return; + } +*/ + /* Convert to softbits */ + for (i=0; i<114; i++) + app_state.mI[B][i] = bt[i] ? - (bi->snr >> 1) : (bi->snr >> 1); + + count_tch++; + + // Decode AMR + if((B % 4 == 3) && (count_tch >= 7)){ + if(B == 3) + { + tch_deinterleave(mC, 4); + }else{ + tch_deinterleave(mC, 0); + } + + printf("****************** %d\n",( fn % 26) ); + if( ( fn % 26) == 3 || ( fn % 26) == 11 || ( fn % 26) == 20 ) + { + //abstract the codec mode + for(i = 0;i < 8 ; i++) + { + //printf("%x ",mC[i]); + if(mC[i] < 0) + app_state.amr_cur.mode = ( app_state.amr_cur.mode | (1 << i )); + else + app_state.amr_cur.mode = ( app_state.amr_cur.mode & (~(1 << i ))); + } + + switch(app_state.amr_cur.mode){ + case CODEC_MODE_1: + printf("codec 1\n"); + app_state.amr_cur.i = find_speech_mode(app_state.amr_arg.amr_acs, 1); + break; + case CODEC_MODE_2: + printf("codec 2\n"); + app_state.amr_cur.i = find_speech_mode(app_state.amr_arg.amr_acs, 2); + break; + case CODEC_MODE_3: + printf("codec 3\n"); + app_state.amr_cur.i = find_speech_mode(app_state.amr_arg.amr_acs, 3); + break; + case CODEC_MODE_4: + printf("codec 4\n"); + app_state.amr_cur.i = find_speech_mode(app_state.amr_arg.amr_acs, 4); + break; + default: + { + printf("unkown codec\n"); + return; + } + } + } + + memset(voice,0,32); + switch( 1 << app_state.amr_cur.i ){ + case gsm690_4_75: + printf("codec gsm690_4_75\n"); + osmo_conv_decode(&conv_tch_afs_4_75, &mC[8], convu); + memcpy(convd,convu,39); + memcpy(convd,&convu[45],56); + tch_map(gsm690_4_75_bitorder, gsm690_4_75_len, EFRAMR + 8,convd); + fillField(EFRAMR, 0, 0x04, 8); + length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_4_75_len, 1); + + break; + case gsm690_5_15: + printf("codec gsm690_5_15\n"); + osmo_conv_decode(&conv_tch_afs_5_15, &mC[8], convu); + memcpy(convd,convu,49); + memcpy(convd,&convu[55],54); + tch_map(gsm690_5_15_bitorder, gsm690_5_15_len, EFRAMR + 8,convd); + fillField(EFRAMR, 0, 0x0c, 8); + length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_5_15_len, 1); + + break; + case gsm690_5_90: + printf("codec gsm690_5_90\n"); + osmo_conv_decode(&conv_tch_afs_5_9, &mC[8], convu); + memcpy(convd,convu,55); + memcpy(convd,&convu[61],63); + tch_map(gsm690_5_9_bitorder, gsm690_5_90_len, EFRAMR + 8,convd); + fillField(EFRAMR, 0, 0x14, 8); + length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_5_90_len, 1); + + break; + case gsm690_6_70: + printf("codec gsm690_6_70\n"); + osmo_conv_decode(&conv_tch_afs_6_7, &mC[8], convu); + memcpy(convd,convu,55); + memcpy(convd,&convu[61],79); + tch_map(gsm690_6_7_bitorder, gsm690_6_70_len, EFRAMR + 8,convd); + fillField(EFRAMR, 0, 0x1c, 8); + length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_6_70_len, 1); + + break; + case gsm690_7_40: + printf("codec gsm690_7_40\n"); + osmo_conv_decode(&conv_tch_afs_7_4, &mC[8], convu); + memcpy(convd,convu,61); + memcpy(convd,&convu[67],87); + tch_map(gsm690_7_4_bitorder, gsm690_7_40_len, EFRAMR + 8,convd); + fillField(EFRAMR, 0, 0x24, 8); + length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_7_40_len, 1); + + break; + case gsm690_7_95: + printf("codec gsm690_7_95\n"); + osmo_conv_decode(&conv_tch_afs_7_95, &mC[8], convu); + memcpy(convd,convu,75); + memcpy(convd,&convu[81],84); + tch_map(gsm690_7_95_bitorder, gsm690_7_95_len, EFRAMR + 8,convd); + fillField(EFRAMR, 0, 0x2c, 8); + length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_7_95_len, 1); + break; + case gsm690_10_2: + printf("codec gsm690_10_2\n"); + osmo_conv_decode(&conv_tch_afs_10_2, &mC[8], convu); + memcpy(convd,convu,65); + memcpy(convd,&convu[71],139); + tch_map(gsm690_10_2_bitorder, gsm690_10_2_len, EFRAMR + 8,convd); + fillField(EFRAMR, 0, 0x34, 8); + length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_10_2_len, 1); + break; + case gsm690_12_2: + printf("codec gsm690_12_2\n"); + osmo_conv_decode(&conv_tch_afs_12_2, &mC[8], convu); + memcpy(convd,convu,81); + memcpy(convd,&convu[87],163); + tch_map(gsm690_12_2_bitorder, gsm690_12_2_len, EFRAMR + 8,convd); + fillField(EFRAMR, 0, 0x3c, 8); + length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_12_2_len, 1); + break; + default: + { + printf("unkown gsm690 codec\n"); + return; + } + } + + //printf("length is %d\n",length); + //printf("voice[0] is %x\n",voice[0]); + fwrite(voice, 1, length, d_speech_file); + } + +} + static void -local_burst_decode(struct l1ctl_burst_ind *bi) +local_burst_decode(struct osmocom_ms *ms,struct l1ctl_burst_ind *bi) { int16_t rx_dbm; uint16_t arfcn; @@ -514,6 +1148,24 @@ uint32_t fn_report; fn_report = (fn - (tn * 13) + 104) % 104; bid = (fn_report - 12) / 26; + printf(" SACCH fn = %d fn_report = %d\n",fn,fn_report); + }else{ + switch (app_state.speed_mode ) { + + case GSM48_CMODE_SPEECH_EFR: + process_tch_efr(ms,bi); + break; + + case GSM48_CMODE_SPEECH_AMR: + process_tch_amr(ms,bi); + break; + + default: + { + printf("unknown speed mode! %x\n",app_state.speed_mode); + return; + } + } } } else if ((cbits & 0x1e) == 0x02) { /* TCH/H */ lch_idx = cbits & 1; @@ -526,9 +1178,11 @@ } else if ((cbits & 0x1c) == 0x04) { /* SDCCH/4 */ lch_idx = cbits & 3; bid = bi->flags & 3; + printf(" SDCCH/4\n"); } else if ((cbits & 0x18) == 0x08) { /* SDCCH/8 */ lch_idx = cbits & 7; bid = bi->flags & 3; + //printf(" SDCCH/8\n"); } if (bid == -1) @@ -559,9 +1213,161 @@ if (bid == 3) { uint8_t l2[23]; - int rv; + int rv,i; + struct gsm48_ass_cmd *ia; + uint8_t ch_type, ch_subch, ch_ts; + uint8_t chan_req_val, chan_req_mask, ra; + rv = xcch_decode(l2, bursts); + if((l2[0] == 0x03) && (l2[4] == 0x2e)) + { + ia =(struct gsm48_ass_cmd *)&l2[5]; + + memcpy(&app_state.ia , ia, sizeof(struct gsm48_ass_cmd)); + + + //l1ctl_tx_reset_req(ms, L1CTL_RES_T_SCHED); + printf("the speed version is %x.\n",ia->chan_mode.voice_mode); + printf("the start mode is %x.\n",ia->mc.start_mode); + printf("the codec rate is %x.\n",ia->mc.codec_rate); + app_state.amr_arg.amr_acs = ia->mc.codec_rate; + app_state.amr_arg.start_mode = ia->mc.start_mode; + printf("Jump to TCH Channel\n"); + + app_state.speed_mode = ia->chan_mode.voice_mode; + + /* Clear if new set */ + for(i=0; i<8; i++){ + memset(app_state.mI[i], 0x00, 114); + } + + /* open speech file and configure d_tch_decoders */ + switch (app_state.speed_mode ) { + + case GSM48_CMODE_SPEECH_V1: + d_speech_file = fopen( "speech.au.gsm", "wb" ); + break; + + case GSM48_CMODE_SPEECH_EFR: + d_speech_file = fopen( gen_filename(ms,bi), "wb" ); + fwrite(amr_nb_magic, 1, 6, d_speech_file); /* Write header */ + break; + + case GSM48_CMODE_SPEECH_AMR: + d_speech_file = fopen( gen_filename(ms,bi), "wb" ); + fwrite(amr_nb_magic, 1, 6, d_speech_file); /* Write header */ + break; + + default: + { + printf("unknown speed mode! %x\n",app_state.speed_mode); + d_speech_file = NULL; + return; + } + } + app_state.dch_state = DCH_TCH; + + l1ctl_tx_reset_req(ms, L1CTL_RES_T_FULL); //BCCH- SDCCH - BCCH -TCH + + return; + + if (!ia->chan_desc.h0.h) { + /* Non-hopping */ + uint16_t arfcn; + + arfcn = ia->chan_desc.h0.arfcn_low | (ia->chan_desc.h0.arfcn_high << 8); + + LOGP(DRR, LOGL_NOTICE, "ASS CMD(chan_nr=0x%02x, " + "ARFCN=%u, TS=%u, SS=%u, TSC=%u) ", + ia->chan_desc.chan_nr, arfcn, ch_ts, ch_subch, + ia->chan_desc.h0.tsc); + + /* request L1 to go to dedicated mode on assigned channel */ + rv = l1ctl_tx_dm_est_req_h0(ms, + arfcn, ia->chan_desc.chan_nr, ia->chan_desc.h0.tsc, + GSM48_CMODE_SPEECH_EFR, 0); + } + #ifdef TCH_HOPPING + else { + /* Hopping is not support now! */ + uint8_t maio, hsn, ma_len; + uint16_t ma[64], arfcn; + int i, j, k; + + //initialize tch count and flag + count_tch = 0; + flag = 0; + + hsn = ia->chan_desc.h1.hsn; + maio = ia->chan_desc.h1.maio_low | (ia->chan_desc.h1.maio_high << 2); + + LOGP(DRR, LOGL_NOTICE, "ASS CMD( chan_nr=0x%02x, " + "HSN=%u, MAIO=%u, TS=%u, SS=%u, TSC=%u) ", + ia->chan_desc.chan_nr, hsn, maio, ch_ts, ch_subch, + ia->chan_desc.h1.tsc); + + /* decode mobile allocation */ + ma_len = 0; + for (i=1, j=0; i<=1024; i++) { + arfcn = i & 1023; + if (app_state.cell_arfcns[arfcn].mask & 0x01) { + k = ia->mob_alloc_len - (j>>3) - 1; + if (ia->mob_alloc[k] & (1 << (j&7))) { + ma[ma_len++] = arfcn; + } + j++; + } + } + + /* request L1 to go to dedicated mode on assigned channel */ + rv = l1ctl_tx_dm_est_req_h1(ms, + maio, hsn, ma, ma_len, + ia->chan_desc.chan_nr, ia->chan_desc.h1.tsc, + GSM48_CMODE_SPEECH_EFR, 0); + } + #endif + }/*else{ + return; + } +target sms sniffer + if( (l2[0] == 0x01)&&(l2[1] == 0x73)&&(l2[10] == 0x05) ) + { + unsigned int tmsi,object_tmsi; + tmsi = *(int *)&l2[12]; + for(i =12;i<12+4;i++) + { + printf("%x ",l2[i]); + } + printf("\n"); + object_tmsi = ntohl(0x97034024); + printf("object_tmsi is %x, tmsi is %x\n",object_tmsi,tmsi); + if(tmsi != object_tmsi) + { + printf("not match!\n"); + + l1ctl_tx_dm_rel_req(ms); + l1ctl_tx_fbsb_req(ms, ms->test_arfcn, + L1CTL_FBSB_F_FB01SB, 100, 0, + app_state.ccch_mode); + + + app_state.dch_state = DCH_WAIT_REL; + app_state.dch_badcnt = 0; + app_state.dch_ciph = 0; + + + if (app_state.fh) { + fclose(app_state.fh); + app_state.fh = NULL; + } + }else{ + + printf("$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$\n"); + } + + } +*/ if (rv == 0) { uint8_t chan_type, chan_ts, chan_ss; @@ -586,25 +1392,106 @@ } } -static char * -gen_filename(struct osmocom_ms *ms, struct l1ctl_burst_ind *bi) +static void +ccch_tn_decode(struct l1ctl_burst_ind *bi,uint8_t tn,struct osmocom_ms *ms) { - static char buffer[256]; - time_t d; - struct tm lt; + int16_t rx_dbm; + uint16_t arfcn; + uint32_t fn; + uint8_t cbits, lch_idx; + int ul, bid, i; + sbit_t *bursts; + ubit_t bt[116]; - time(&d); - localtime_r(&d, <); + /* Get params (Only for SDCCH and SACCH/{4,8,F,H}) */ + arfcn = ntohs(bi->band_arfcn); + rx_dbm = rxlev2dbm(bi->rx_level); + //printf("tn is %d\n",tn); + bursts = app_state.bursts_ccch[tn/2]; + + fn = ntohl(bi->frame_nr); - snprintf(buffer, 256, "bursts_%04d%02d%02d_%02d%02d_%d_%d_%02x.dat", - lt.tm_year + 1900, lt.tm_mon, lt.tm_mday, - lt.tm_hour, lt.tm_min, - ms->test_arfcn, - ntohl(bi->frame_nr), - bi->chan_nr - ); + cbits = bi->chan_nr >> 3; + + bid = -1; + + bid = bi->flags & 3; + //printf("cbits is %x\n",cbits); + if ( cbits == 0x12) { /* TCH/F */ + bid = bi->flags & 3; + } + + if (bid == -1) + return; + + /* Clear if new set */ + if (bid == 0) + memset(bursts, 0x00, 116 * 4); + + /* Unpack (ignore hu/hl) */ + osmo_pbit2ubit_ext(bt, 0, bi->bits, 0, 57, 0); + osmo_pbit2ubit_ext(bt, 59, bi->bits, 57, 57, 0); + bt[57] = bt[58] = 1; + + /* A5/x */ + if (app_state.dch_ciph) { + ubit_t ks_dl[114], ks_ul[114], *ks = ul ? ks_ul : ks_dl; + osmo_a5(app_state.dch_ciph, app_state.kc, fn, ks_dl, ks_ul); + for (i= 0; i< 57; i++) bt[i] ^= ks[i]; + for (i=59; i<116; i++) bt[i] ^= ks[i-2]; + } + + /* Convert to softbits */ + for (i=0; i<116; i++) + bursts[(116*bid)+i] = bt[i] ? - (bi->snr >> 1) : (bi->snr >> 1); + + /* If last, decode */ + if (bid == 3) + { + uint8_t l2[23]; + int rv; + rv = xcch_decode(l2, bursts); + + if (rv == 0) + { + struct msgb *msg; + msg = msgb_alloc_headroom(30 ,0,"layer3"); + msg->tail =30; + msg->l3h =l2; + msg->data_len = msg->len =23; + gsm48_rx_ccch(msg,ms); + //struct abis_rsl_rll_hdr *rllh = l2;//l3 + //printf("chan_nr = %x,bi->chan_nr = %x\n",rllh->chan_nr,bi->chan_nr); + uint8_t chan_type, chan_ts, chan_ss; + uint8_t gsmtap_chan_type; + + /* Send to GSMTAP */ + rsl_dec_chan_nr(bi->chan_nr, &chan_type, &chan_ss, &chan_ts); + gsmtap_chan_type = chantype_rsl2gsmtap( + chan_type, + bi->flags & BI_FLG_SACCH ? 0x40 : 0x00 + ); + gsmtap_send(gsmtap_inst, + arfcn, chan_ts, gsmtap_chan_type, chan_ss, + ntohl(bi->frame_nr), bi->rx_level, bi->snr, + l2, sizeof(l2) + ); + + /* Crude CIPH.MOD.COMMAND detect */ + if ((l2[3] == 0x06) && (l2[4] == 0x35) && (l2[5] & 1)) + app_state.dch_ciph = 1 + ((l2[5] >> 1) & 7); + } + } - return buffer; +} + +static void +local_ccch_burst_decode(struct l1ctl_burst_ind *bi,struct osmocom_ms *ms) +{ + uint8_t tn; + + tn = bi->chan_nr & 7; + ccch_tn_decode(bi,tn,ms); } void layer3_rx_burst(struct osmocom_ms *ms, struct msgb *msg) @@ -612,7 +1499,7 @@ struct l1ctl_burst_ind *bi; int16_t rx_dbm; uint16_t arfcn; - int ul, do_rel=0; + int ul,do_rel=0; /* Header handling */ bi = (struct l1ctl_burst_ind *) msg->l1h; @@ -621,6 +1508,8 @@ rx_dbm = rxlev2dbm(bi->rx_level); ul = !!(arfcn & ARFCN_UPLINK); + if (app_state.dch_state == DCH_NONE) + local_ccch_burst_decode(bi,ms); /* Check for channel start */ if (app_state.dch_state == DCH_WAIT_EST) { if (bi->chan_nr == app_state.dch_nr) { @@ -630,7 +1519,7 @@ app_state.dch_badcnt = 0; /* Open output */ - app_state.fh = fopen(gen_filename(ms, bi), "wb"); + //app_state.fh = fopen(gen_filename(ms, bi), "wb"); } else { /* Abandon ? */ do_rel = (app_state.dch_badcnt++) >= 4; @@ -643,19 +1532,44 @@ if (!ul) { /* Bad burst counting */ if (bi->snr < 64) - app_state.dch_badcnt++; + { + app_state.dch_badcnt++; + printf("sdcch app_state.dch_badcnt++\n"); + } + else if (app_state.dch_badcnt >= 2) + app_state.dch_badcnt -= 2; + else + app_state.dch_badcnt = 0; + + /* Release condition */ + do_rel = app_state.dch_badcnt >= 6; + } + } + + // when in TCH mode, we only measure the SACCH to kown the link quanlity + if (app_state.dch_state == DCH_TCH) { + //printf("app_state.dch_state == DCH_TCH\n"); + if (!ul && (bi->flags & BI_FLG_SACCH)) { + //printf("TCH SACCH\n"); + /* Bad burst counting */ + if (bi->snr < 40) + { + app_state.dch_badcnt++; + printf("sacch app_state.dch_badcnt++\n"); + } else if (app_state.dch_badcnt >= 2) app_state.dch_badcnt -= 2; else app_state.dch_badcnt = 0; /* Release condition */ - do_rel = app_state.dch_badcnt >= 600; + do_rel = app_state.dch_badcnt >= 6; } } /* Release ? */ if (do_rel) { + printf("The Delicate Channel is released because of bad SNR!\n"); /* L1 release */ l1ctl_tx_dm_rel_req(ms); l1ctl_tx_fbsb_req(ms, ms->test_arfcn, @@ -675,22 +1589,25 @@ } /* Save the burst */ - if (app_state.dch_state == DCH_ACTIVE) - fwrite(bi, sizeof(*bi), 1, app_state.fh); + if (app_state.dch_state == DCH_ACTIVE || app_state.dch_state == DCH_TCH) + //fwrite(bi, sizeof(*bi), 1, app_state.fh); /* Try local decoding */ - if (app_state.dch_state == DCH_ACTIVE) - local_burst_decode(bi); + if (!ul && (app_state.dch_state == DCH_ACTIVE || app_state.dch_state == DCH_TCH)) + local_burst_decode(ms,bi); } void layer3_app_reset(void) { /* Reset state */ app_state.has_si1 = 0; + app_state.has_si3 = 0; + app_state.neci = 0; app_state.ccch_mode = CCCH_MODE_NONE; app_state.dch_state = DCH_NONE; app_state.dch_badcnt = 0; app_state.dch_ciph = 0; + app_state.sys_count= 0; if (app_state.fh) fclose(app_state.fh); @@ -704,7 +1621,8 @@ { struct osmocom_ms *ms; struct osmobb_msg_ind *mi; - + struct osmobb_fbsb_res *fr; + if (subsys != SS_L1CTL) return 0; @@ -713,13 +1631,27 @@ mi = signal_data; layer3_rx_burst(mi->ms, mi->msg); break; + case S_L1CTL_FBSB_ERR: + fr=signal_data; + l1ctl_tx_reset_req(fr->ms, L1CTL_RES_T_FULL); + /* FIXME: L1CTL_RES_T_FULL doesn't reset dedicated mode + * (if previously set), so we release it here. */ + l1ctl_tx_dm_rel_req(fr->ms); + //printf("fr->band_arfcn is %d\n",ntohs(fr->band_arfcn)); + //return l1ctl_tx_fbsb_req(fr->ms, ntohs(fr->band_arfcn), + // L1CTL_FBSB_F_FB01SB, 100, 0, + // CCCH_MODE_NONE); + break; case S_L1CTL_RESET: + if(app_state.dch_state == DCH_ACTIVE) //if we are going TCH,we need rest_sched? + break; ms = signal_data; - layer3_app_reset(); + if(app_state.dch_state != DCH_TCH) + layer3_app_reset(); return l1ctl_tx_fbsb_req(ms, ms->test_arfcn, L1CTL_FBSB_F_FB01SB, 100, 0, - CCCH_MODE_NONE); + app_state.ccch_mode); break; } return 0; the output: <0001> app_ccch_scan.c:191 ASS CMD(chan_nr=0x09, ARFCN=622, TS=1, SS=0, TSC=2) fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 0 , 1 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 1 , 1 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 0 , 1 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 0 , 1 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 1 , 1 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 1 , 0 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 1 , 1 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 0 , 0 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 0 , 0 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 24 codec gsm690_4_75 SACCH fn = 489319 fn_report = 90 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 0 , 0 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 1 , 1 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 0 , 1 ****************** 3 unkown codec fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 1 , 0 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 0 , 0 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 0 , 0 ****************** 7 codec gsm690_4_75 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 1 , 0 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 0 , 0 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 1 , 0 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 1 , 1 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 0 , 1 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 1 , 0 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 0 , 0 ****************** 16 codec gsm690_4_75 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 1 , 0 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 0 , 1 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 1 , 1 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 1 , 0 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 0 , 0 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 1 , 0 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 1 , 1 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 24 codec gsm690_4_75 SACCH fn = 489345 fn_report = 12 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 1 , 1 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 1 , 1 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 1 , 1 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 1 , 1 ****************** 3 codec 1 codec gsm690_4_75 fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 0 , 0 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 0 , 0 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 0 , 0 ****************** 7 codec gsm690_4_75 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 1 , 0 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 0 , 0 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 1 , 1 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 1 , 0 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 1 , 1 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 0 , 1 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 0 , 1 ****************** 16 codec gsm690_4_75 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 0 , 0 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 1 , 1 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 0 , 1 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 1 , 0 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 0 , 0 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 0 , 0 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 1 , 0 ****************** 24 codec gsm690_4_75 SACCH fn = 489371 fn_report = 38 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 1 , 1 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 1 , 0 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 1 , 0 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 0 , 0 ****************** 3 unkown codec fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 1 , 0 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 1 , 0 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 0 , 1 ****************** 7 codec gsm690_4_75 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 1 , 1 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 1 , 0 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 1 , 1 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 0 , 0 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 0 , 0 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 0 , 0 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 0 , 0 ****************** 16 codec gsm690_4_75 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 1 , 0 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 1 , 0 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 1 , 0 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 1 , 0 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 1 , 0 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 1 , 1 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 1 , 0 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 24 codec gsm690_4_75 SACCH fn = 489397 fn_report = 64 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 0 , 0 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 1 , 1 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 0 , 0 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 1 , 1 ****************** 3 unkown codec fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 0 , 0 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 1 , 1 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 1 , 0 ****************** 7 codec gsm690_4_75 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 1 , 0 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 1 , 0 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 0 , 1 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 0 , 1 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 0 , 1 ****************** 16 codec gsm690_4_75 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 0 , 0 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 0 , 1 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 0 , 1 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 1 , 1 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 0 , 0 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 0 , 0 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 24 codec gsm690_4_75 SACCH fn = 489423 fn_report = 90 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 1 , 0 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 1 , 0 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 1 , 0 ****************** 3 unkown codec fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 1 , 0 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 1 , 0 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 0 , 0 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 0 , 1 ****************** 7 codec gsm690_4_75 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 0 , 1 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 0 , 0 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 1 , 1 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 0 , 1 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 0 , 0 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 1 , 1 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 0 , 0 ****************** 16 codec gsm690_4_75 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 1 , 1 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 0 , 0 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 1 , 1 ****************** 20 codec 4 codec gsm690_12_2 fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 0 , 0 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 0 , 0 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 1 ****************** 24 codec gsm690_12_2 SACCH fn = 489449 fn_report = 12 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 1 , 1 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 0 , 0 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 1 , 0 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 0 , 0 ****************** 3 unkown codec fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 0 , 0 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 0 , 0 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 0 , 0 ****************** 7 codec gsm690_12_2 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 1 , 0 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 1 , 1 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 0 , 1 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 1 , 1 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 0 , 0 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 1 , 0 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 0 , 0 ****************** 16 codec gsm690_12_2 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 1 , 1 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 0 , 1 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 1 , 1 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 1 , 1 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 0 , 0 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 0 , 0 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 1 ****************** 24 codec gsm690_12_2 SACCH fn = 489475 fn_report = 38 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 0 , 1 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 1 , 0 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 1 , 1 ****************** 3 unkown codec fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 1 , 1 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 0 , 1 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 1 , 1 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 0 , 0 ****************** 7 codec gsm690_12_2 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 1 , 1 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 0 , 1 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 0 , 1 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 0 , 1 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 0 , 0 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 0 , 0 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 0 , 0 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 0 , 0 ****************** 16 codec gsm690_12_2 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 0 , 0 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 1 , 1 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 0 , 1 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 0 , 0 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 0 , 1 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 1 , 0 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 24 codec gsm690_12_2 SACCH fn = 489501 fn_report = 64 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 1 , 1 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 0 , 1 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 0 , 0 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 0 , 0 ****************** 3 unkown codec fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 0 , 1 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 1 , 1 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 1 , 0 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 1 , 1 ****************** 7 codec gsm690_12_2 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 0 , 1 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 1 , 1 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 1 , 1 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 1 , 1 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 0 , 0 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 0 , 0 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 1 , 1 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 1 , 0 ****************** 16 codec gsm690_12_2 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 1 , 0 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 1 , 0 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 0 , 1 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 0 , 1 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 0 , 0 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 0 , 0 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 24 codec gsm690_12_2 SACCH fn = 489527 fn_report = 90 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 0 , 0 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 0 , 1 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 0 , 1 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 0 , 1 ****************** 3 unkown codec fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 0 , 1 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 1 , 1 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 0 , 0 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 0 , 0 ****************** 7 codec gsm690_12_2 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 1 , 1 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 1 , 0 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 1 , 0 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 1 , 1 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 0 , 0 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 0 , 0 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 1 , 1 ****************** 16 codec gsm690_12_2 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 1 , 1 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 1 , 1 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 1 , 0 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 1 , 1 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 0 , 1 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 1 , 0 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 0 , 1 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 1 , 1 ****************** 24 codec gsm690_12_2 SACCH fn = 489553 fn_report = 12 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 0 , 1 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 0 , 0 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 0 , 1 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 1 , 0 ****************** 3 unkown codec fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 0 , 0 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 0 , 0 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 0 , 0 ****************** 7 codec gsm690_12_2 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 1 , 1 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 0 , 1 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 1 , 1 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 1 , 0 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 1 , 1 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 1 , 1 ****************** 16 codec gsm690_12_2 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 1 , 0 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 0 , 1 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 1 , 1 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 0 , 0 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 1 , 1 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 1 , 1 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 24 codec gsm690_12_2 SACCH fn = 489579 fn_report = 38 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 0 , 1 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 1 , 1 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 1 , 0 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 1 , 1 ****************** 3 unkown codec fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 0 , 0 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 0 , 1 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 1 , 1 ****************** 7 codec gsm690_12_2 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 1 , 0 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 1 , 0 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 0 , 1 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 1 , 0 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 0 , 0 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 0 , 0 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 0 , 0 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 0 , 0 ****************** 16 codec gsm690_12_2 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 1 , 0 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 0 , 0 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 0 , 1 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 0 , 0 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 0 , 0 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 24 codec gsm690_12_2 SACCH fn = 489605 fn_report = 64 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 0 , 1 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 1 , 0 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 1 , 0 ****************** 3 unkown codec fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 0 , 0 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 1 , 0 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 1 , 1 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 0 , 0 ****************** 7 codec gsm690_12_2 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 1 , 1 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 1 , 1 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 0 , 1 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 0 , 1 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 1 , 0 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 1 , 1 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 1 , 1 ****************** 16 codec gsm690_12_2 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 0 , 1 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 1 , 1 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 0 , 0 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 1 , 0 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 0 , 0 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 0 , 0 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 24 codec gsm690_12_2 SACCH fn = 489631 fn_report = 90 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 0 , 1 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 1 , 0 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 1 , 1 ****************** 3 codec 1 codec gsm690_4_75 fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 1 , 0 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 0 , 1 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 1 , 0 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 0 , 1 ****************** 7 codec gsm690_4_75 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 0 , 1 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 1 , 1 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 1 , 0 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 1 , 0 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 0 , 0 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 1 , 0 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 1 , 1 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 0 , 1 ****************** 16 codec gsm690_4_75 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 0 , 1 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 0 , 1 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 0 , 0 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 1 , 1 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 0 , 1 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 0 , 1 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 1 , 0 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 24 codec gsm690_4_75 SACCH fn = 489657 fn_report = 12 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 0 , 0 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 1 , 1 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 0 , 1 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 0 , 0 ****************** 3 codec 1 codec gsm690_4_75 fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 0 , 0 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 0 , 0 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 0 , 0 ****************** 7 codec gsm690_4_75 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 0 , 1 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 1 , 0 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 1 , 0 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 1 , 1 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 1 , 0 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 0 , 0 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 1 , 0 ****************** 16 codec gsm690_4_75 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 1 , 1 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 1 , 0 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 0 , 1 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 0 , 1 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 1 , 1 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 0 , 1 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 1 , 1 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 1 , 1 ****************** 24 codec gsm690_4_75 SACCH fn = 489683 fn_report = 38 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 0 , 1 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 1 , 0 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 1 , 0 ****************** 3 unkown codec fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 0 , 1 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 0 , 1 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 0 , 1 ****************** 7 codec gsm690_4_75 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 1 , 0 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 1 , 0 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 1 , 1 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 1 , 0 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 0 , 0 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 0 , 0 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 0 , 0 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 0 , 0 ****************** 16 codec gsm690_4_75 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 1 , 1 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 0 , 1 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 0 , 0 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 0 , 0 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 1 , 0 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 0 , 1 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 1 , 1 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 24 codec gsm690_4_75 SACCH fn = 489709 fn_report = 64 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 0 , 1 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 0 , 1 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 1 , 0 ****************** 3 codec 1 codec gsm690_4_75 fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 0 , 1 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 1 , 1 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 1 , 0 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 0 , 1 ****************** 7 codec gsm690_4_75 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 0 , 0 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 0 , 0 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 1 , 0 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 0 , 1 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 0 , 1 ****************** 16 codec gsm690_4_75 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 1 , 0 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 1 , 1 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 1 , 0 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 0 , 0 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 0 , 0 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 0 , 0 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 24 codec gsm690_4_75 SACCH fn = 489735 fn_report = 90 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 1 , 0 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 0 , 0 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 0 , 1 ****************** 3 unkown codec fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 1 , 0 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 1 , 0 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 1 , 1 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 1 , 0 ****************** 7 codec gsm690_4_75 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 0 , 0 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 1 , 1 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 1 , 0 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 0 , 1 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 1 , 1 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 1 , 0 ****************** 16 codec gsm690_4_75 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 0 , 0 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 1 , 1 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 1 , 1 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 1 , 1 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 0 , 1 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 1 ****************** 24 codec gsm690_4_75 SACCH fn = 489761 fn_report = 12 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 0 , 1 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 1 , 1 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 0 , 0 ****************** 3 codec 1 codec gsm690_4_75 fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 0 , 0 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 0 , 0 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 0 , 0 ****************** 7 codec gsm690_4_75 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 0 , 0 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 1 , 1 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 0 , 1 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 1 , 1 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 0 , 0 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 0 , 1 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 1 , 0 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 1 , 0 ****************** 16 codec gsm690_4_75 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 0 , 1 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 1 , 1 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 0 , 0 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 0 , 0 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 0 , 1 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 0 , 0 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 1 , 1 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 24 codec gsm690_4_75 SACCH fn = 489787 fn_report = 38 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 1 , 1 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 1 , 0 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 1 , 0 ****************** 3 codec 1 codec gsm690_4_75 fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 1 , 1 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 1 , 1 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 1 , 0 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 0 , 0 ****************** 7 codec gsm690_4_75 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 1 , 0 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 1 , 0 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 1 , 0 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 0 , 1 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 0 , 0 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 0 , 0 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 0 , 0 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 0 , 0 ****************** 16 codec gsm690_4_75 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 0 , 0 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 1 , 0 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 1 , 0 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 1 , 0 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 0 , 0 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 1 , 1 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 24 codec gsm690_4_75 SACCH fn = 489813 fn_report = 64 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 1 , 1 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 0 , 1 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 1 , 1 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 0 , 0 ****************** 3 unkown codec fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 1 , 0 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 1 , 1 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 1 , 0 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 0 , 1 ****************** 7 codec gsm690_4_75 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 1 , 0 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 1 , 1 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 0 , 1 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 1 , 1 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 1 , 1 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 0 , 0 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 1 , 0 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 0 , 0 ****************** 16 codec gsm690_4_75 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 1 , 0 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 1 , 0 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 0 , 0 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 0 , 0 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 0 , 0 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 24 codec gsm690_4_75 SACCH fn = 489839 fn_report = 90 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 1 , 1 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 1 , 1 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 1 , 1 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 1 , 1 ****************** 3 unkown codec fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 1 , 0 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 1 , 0 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 1 , 1 ****************** 7 codec gsm690_4_75 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 1 , 0 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 0 , 0 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 1 , 1 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 1 , 0 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 1 , 1 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 0 , 0 ****************** 16 codec gsm690_4_75 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 1 , 0 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 1 , 0 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 0 , 0 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 0 , 0 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 0 , 1 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 0 , 0 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 1 , 0 ****************** 24 codec gsm690_4_75 SACCH fn = 489865 fn_report = 12 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 1 , 0 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 0 , 1 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 0 , 0 ****************** 3 unkown codec fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 0 , 0 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 0 , 0 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 0 , 0 ****************** 7 codec gsm690_4_75 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 0 , 0 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 1 , 1 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 0 , 1 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 0 , 1 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 0 , 0 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 0 , 1 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 1 , 0 ****************** 16 codec gsm690_4_75 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 1 , 0 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 1 , 1 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 1 , 1 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 1 , 1 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 1 , 0 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 0 , 1 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 24 codec gsm690_4_75 SACCH fn = 489891 fn_report = 38 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 0 , 1 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 0 , 1 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 1 , 0 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 0 , 0 ****************** 3 unkown codec fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 0 , 0 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 1 , 1 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 0 , 0 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 0 , 1 ****************** 7 codec gsm690_4_75 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 0 , 1 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 0 , 0 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 1 , 1 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 0 , 0 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 0 , 0 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 0 , 0 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 0 , 0 ****************** 16 codec gsm690_4_75 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 0 , 0 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 1 , 1 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 1 , 0 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 0 , 1 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 0 , 1 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 1 , 0 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 0 , 1 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 24 codec gsm690_4_75 SACCH fn = 489917 fn_report = 64 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 0 , 0 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 1 , 0 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 1 , 1 ****************** 3 unkown codec fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 1 , 1 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 1 , 0 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 1 , 1 ****************** 7 codec gsm690_4_75 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 0 , 1 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 1 , 1 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 0 , 1 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 1 , 0 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 1 , 1 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 0 , 0 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 0 , 1 ****************** 16 codec gsm690_4_75 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 1 , 0 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 0 , 1 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 1 , 0 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 0 , 1 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 0 , 0 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 0 , 0 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 0 , 0 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 24 codec gsm690_4_75 SACCH fn = 489943 fn_report = 90 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 1 , 1 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 0 , 0 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 1 , 0 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 0 , 0 ****************** 3 unkown codec fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 1 , 0 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 0 , 1 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 0 , 1 ****************** 7 codec gsm690_4_75 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 1 , 1 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 1 , 0 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 0 , 1 fn % 26 = 11, fn % 13 = 11, B = 3 steal_bit 1 , 1 ****************** 11 unkown codec fn % 26 = 13, fn % 13 = 0, B = 0 steal_bit 1 , 1 fn % 26 = 14, fn % 13 = 1, B = 1 steal_bit 1 , 1 fn % 26 = 15, fn % 13 = 2, B = 2 steal_bit 0 , 1 fn % 26 = 16, fn % 13 = 3, B = 3 steal_bit 1 , 1 ****************** 16 codec gsm690_4_75 fn % 26 = 17, fn % 13 = 4, B = 4 steal_bit 0 , 1 fn % 26 = 18, fn % 13 = 5, B = 5 steal_bit 0 , 1 fn % 26 = 19, fn % 13 = 6, B = 6 steal_bit 0 , 1 fn % 26 = 20, fn % 13 = 7, B = 7 steal_bit 0 , 0 ****************** 20 unkown codec fn % 26 = 21, fn % 13 = 8, B = 0 steal_bit 0 , 0 fn % 26 = 22, fn % 13 = 9, B = 1 steal_bit 1 , 0 fn % 26 = 23, fn % 13 = 10, B = 2 steal_bit 0 , 1 fn % 26 = 24, fn % 13 = 11, B = 3 steal_bit 0 , 0 ****************** 24 codec gsm690_4_75 SACCH fn = 489969 fn_report = 12 fn % 26 = 0, fn % 13 = 0, B = 0 steal_bit 0 , 1 fn % 26 = 1, fn % 13 = 1, B = 1 steal_bit 1 , 0 fn % 26 = 2, fn % 13 = 2, B = 2 steal_bit 0 , 0 fn % 26 = 3, fn % 13 = 3, B = 3 steal_bit 1 , 0 ****************** 3 unkown codec fn % 26 = 4, fn % 13 = 4, B = 4 steal_bit 0 , 0 fn % 26 = 5, fn % 13 = 5, B = 5 steal_bit 0 , 0 fn % 26 = 6, fn % 13 = 6, B = 6 steal_bit 0 , 0 fn % 26 = 7, fn % 13 = 7, B = 7 steal_bit 0 , 0 ****************** 7 codec gsm690_4_75 fn % 26 = 8, fn % 13 = 8, B = 0 steal_bit 1 , 1 fn % 26 = 9, fn % 13 = 9, B = 1 steal_bit 1 , 1 fn % 26 = 10, fn % 13 = 10, B = 2 steal_bit 1 , 0 -- View this message in context: http://baseband-devel.722152.n3.nabble.com/is-my-patch-for-capturing-TCH-frame-correctly-tp4025199.html Sent from the baseband-devel mailing list archive at Nabble.com. From rootbit at yahoo.com Thu Jul 19 10:52:40 2012 From: rootbit at yahoo.com (Gerard) Date: Thu, 19 Jul 2012 10:52:40 +0000 (UTC) Subject: is my patch for capturing TCH frame correctly? References: <1342688308441-4025199.post@n3.nabble.com> Message-ID: Hi Bob, thanks for sharing your patches. I'll try playing with them. From altaf329 at gmail.com Fri Jul 20 14:11:33 2012 From: altaf329 at gmail.com (Altaf) Date: Fri, 20 Jul 2012 07:11:33 -0700 (PDT) Subject: Working of ccch_scan and capturing the SDCCH. Message-ID: <1342793493322-4025206.post@n3.nabble.com> Hello Sylvain I am using the burst_ind branch and have some doubts. I am using a test network, and it has no encryption. Usually the n/w has a low load and the channel structure followed during the assignment is SDCCH/4 + SACCH/C4 or CBCH(SDCCH/4). and timeslot 0 . SDCCH is assigned on timeslot 0.. The ccch_scan is able to capture the SMS sent on timeslot 0 and also only one of the subchannel as per the above assignment. Just for testing, When I use two phones and send an SMS from both of them simultaneously both are assigned timeslot 0 and different subchannels. CCCH_scan could capture only one SMS. meaning that it could only get one subchannel. Am I right about ccch_scan or does it have the capability to get a complete timeslot. ? Thank you Altaf -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Working-of-ccch-scan-and-capturing-the-SDCCH-tp4025206.html Sent from the baseband-devel mailing list archive at Nabble.com. From 246tnt at gmail.com Fri Jul 20 14:23:24 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 20 Jul 2012 16:23:24 +0200 Subject: Working of ccch_scan and capturing the SDCCH. In-Reply-To: <1342793493322-4025206.post@n3.nabble.com> References: <1342793493322-4025206.post@n3.nabble.com> Message-ID: Hi, > I right about ccch_scan or does it have the capability to get a complete > timeslot. ? ccch_scan only follows 1 logical channel at a time, no matter what the logical channel is. The DSP patch and sniff task can do more and can even dump up to 4 timeslots simultaneously, it's just not programmed into ccch_scan. See the GPRS patch by lukas to see how to modify it to do more. ccch_scan is only meant as a quick tech demo, it is by no mean a complete application showing off all that's possible. Cheers, Sylvain From akibsayyed at gmail.com Sat Jul 21 08:02:10 2012 From: akibsayyed at gmail.com (Akib Sayyed) Date: Sat, 21 Jul 2012 13:32:10 +0530 Subject: Working of ccch_scan and capturing the SDCCH. In-Reply-To: References: <1342793493322-4025206.post@n3.nabble.com> Message-ID: On Fri, Jul 20, 2012 at 7:53 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > > > I right about ccch_scan or does it have the capability to get a complete > > timeslot. ? > > ccch_scan only follows 1 logical channel at a time, no matter what the > logical channel is. > > The DSP patch and sniff task can do more and can even dump up to 4 > timeslots simultaneously, Does current DSP patch without luca's patch can sniff 4 timeslots?? > it's just not programmed into ccch_scan. See > the GPRS patch by lukas to see how to modify it to do more. > ccch_scan is only meant as a quick tech demo, it is by no mean a > complete application showing off all that's possible. > > Cheers, > > Sylvain > > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Sat Jul 21 08:06:48 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 21 Jul 2012 10:06:48 +0200 Subject: Working of ccch_scan and capturing the SDCCH. In-Reply-To: References: <1342793493322-4025206.post@n3.nabble.com> Message-ID: >> The DSP patch and sniff task can do more and can even dump up to 4 >> timeslots simultaneously, > > Does current DSP patch without luca's patch can sniff 4 timeslots?? Yes, Luca's patch doesn't modify the DSP at all. It doesn't even really modify the sniffing primitives, it just triggers it 4 times per frame ... Cheers, Sylvain From akibsayyed at gmail.com Sat Jul 21 08:25:08 2012 From: akibsayyed at gmail.com (Akib Sayyed) Date: Sat, 21 Jul 2012 13:55:08 +0530 Subject: Working of ccch_scan and capturing the SDCCH. In-Reply-To: References: <1342793493322-4025206.post@n3.nabble.com> Message-ID: On Sat, Jul 21, 2012 at 1:36 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > >> The DSP patch and sniff task can do more and can even dump up to 4 > >> timeslots simultaneously, > > > > Does current DSP patch without luca's patch can sniff 4 timeslots?? > > Yes, Luca's patch doesn't modify the DSP at all. It doesn't even > really modify the sniffing primitives, it just triggers it 4 times per > frame ... > > so to take complete advantage of sniffing 4 time slots we need to modify only a ccch_scan app or some more modification also needed ?? and what is someone need to sniff either uplink or downlink?? about refering luca's patch do we need to refer only application part ?? (l2 l3) or also need to tamper with DSP. > Cheers, > > Sylvain > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Sat Jul 21 08:39:54 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 21 Jul 2012 10:39:54 +0200 Subject: Working of ccch_scan and capturing the SDCCH. In-Reply-To: References: <1342793493322-4025206.post@n3.nabble.com> Message-ID: > so to take complete advantage of sniffing 4 time slots we need to modify > only a ccch_scan app or some more modification also needed ?? > and what is someone need to sniff either uplink or downlink?? You need to modify part of the ARM code as well. There is 4 level of hierarchy: L3, L2, L1 (ARM code), L1 (DSP) Look at luca's patch, it should be pretty evident what needs to be done (and if it isn't then you're not familiar with the code enough to do the modification anyway) Cheers, Sylvain From luca at srlabs.de Sat Jul 21 08:57:09 2012 From: luca at srlabs.de (Luca Melette) Date: Sat, 21 Jul 2012 10:57:09 +0200 Subject: Working of ccch_scan and capturing the SDCCH. In-Reply-To: References: <1342793493322-4025206.post@n3.nabble.com> Message-ID: <20120721105709.46a3e398@c7h5n3o6.sofago.net> On Sat, 21 Jul 2012 10:39:54 +0200 Sylvain Munaut <246tnt at gmail.com> wrote: Hi list, > > so to take complete advantage of sniffing 4 time slots we need to modify > > only a ccch_scan app or some more modification also needed ?? > > and what is someone need to sniff either uplink or downlink?? I guess I have to do some maintenance to my patch... it's a bit old, and it must be merged with last master. The downlink/uplink is hard coded, so you need to compile the firmware once for down and once for up. The host software also needs some patching. Normally you would jump to the channel specified in the assignment, but here you need two ccch_scan versions: one for the "main" timeslot and one that jumps at timeslot + 1, if you need to capture all the 8 timeslots. I will send some update when I have time :) Cheers, LM From laforge at gnumonks.org Sat Jul 21 09:29:42 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 21 Jul 2012 11:29:42 +0200 Subject: Working of ccch_scan and capturing the SDCCH. In-Reply-To: <20120721105709.46a3e398@c7h5n3o6.sofago.net> References: <1342793493322-4025206.post@n3.nabble.com> <20120721105709.46a3e398@c7h5n3o6.sofago.net> Message-ID: <20120721092942.GL22222@prithivi.gnumonks.org> Hi Luca, On Sat, Jul 21, 2012 at 10:57:09AM +0200, Luca Melette wrote: > I guess I have to do some maintenance to my patch... > it's a bit old, and it must be merged with last master. > [...] > The downlink/uplink is hard coded, so you need to compile > the firmware once for down and once for up. It might make sense to have this run-time configurable/switchable via L1CTL or some other means. > I will send some update when I have time :) It would be much appreciated if you could bring it into a state where it can cleanly coexist with the other existing code, at which point it would become mergeable. I can see two options: 1) make the functionality available but not enabled by default, so a L1CTL command can configure + enable your code at the user option 2) really introduce a new firmware build target. It's possible, but we already have too many firmware images we build for each hardware target, and I'd prefer to see that number shrinking rather than growing. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From akibsayyed at gmail.com Sun Jul 22 07:45:33 2012 From: akibsayyed at gmail.com (Akib Sayyed) Date: Sun, 22 Jul 2012 13:15:33 +0530 Subject: Working of ccch_scan and capturing the SDCCH. In-Reply-To: <20120721105709.46a3e398@c7h5n3o6.sofago.net> References: <1342793493322-4025206.post@n3.nabble.com> <20120721105709.46a3e398@c7h5n3o6.sofago.net> Message-ID: On Sat, Jul 21, 2012 at 2:27 PM, Luca Melette wrote: > On Sat, 21 Jul 2012 10:39:54 +0200 > Sylvain Munaut <246tnt at gmail.com> wrote: > > Hi list, > > > > so to take complete advantage of sniffing 4 time slots we need to > modify > > > only a ccch_scan app or some more modification also needed ?? > > > and what is someone need to sniff either uplink or downlink?? > > I guess I have to do some maintenance to my patch... > it's a bit old, and it must be merged with last master. > > how luca when can we expect this patch cause. because i am really hasty to try that out. > The downlink/uplink is hard coded, so you need to compile > the firmware once for down and once for up. > The host software also needs some patching. Normally you > would jump to the channel specified in the assignment, > but here you need two ccch_scan versions: one for the > "main" timeslot and one that jumps at timeslot + 1, if > you need to capture all the 8 timeslots. > > did you mean 4 uplink and 4 downlink here?? i didnt get point you made for 2 ccch_scan could you please explain > I will send some update when I have time :) > > Cheers, > > LM > > > > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From akibsayyed at gmail.com Sun Jul 22 08:33:24 2012 From: akibsayyed at gmail.com (Akib Sayyed) Date: Sun, 22 Jul 2012 14:03:24 +0530 Subject: Working of ccch_scan and capturing the SDCCH. In-Reply-To: References: <1342793493322-4025206.post@n3.nabble.com> Message-ID: On Sat, Jul 21, 2012 at 2:09 PM, Sylvain Munaut <246tnt at gmail.com> wrote: > > so to take complete advantage of sniffing 4 time slots we need to modify > > only a ccch_scan app or some more modification also needed ?? > > and what is someone need to sniff either uplink or downlink?? > > You need to modify part of the ARM code as well. > > There is 4 level of hierarchy: L3, L2, L1 (ARM code), L1 (DSP) > > Look at luca's patch, it should be pretty evident what needs to be > done (and if it isn't then you're not familiar with the code enough to > do the modification anyway) > > is there anyone who would like to do this for community cause am not that familer with code to do modification > Cheers, > > Sylvain > -- Akib Sayyed Matrix-Shell akibsayyed at gmail.com akibsayyed at matrixshell.com Mob:- +91-966-514-2243 -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun Jul 22 11:01:27 2012 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 22 Jul 2012 13:01:27 +0200 Subject: Poll: Osmocom meeting 25th of July? Message-ID: <20120722110127.GX7693@prithivi.gnumonks.org> Hi all! On Wednesday, 25th of July we would have the next Osmocom meeting berlin. However, neither Holger nor I will be in Berlin on that day to host the event. I also know that Tobias will not be in Berlin. Nonetheless, if there are other people that want to meet up, there is no reason to not hold it! So I would like to get some feedback on who would want to attend next wednesday. If there are a couple of people, I'll try to find somebody who can open the CCCB for you. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From peter at stuge.se Sun Jul 22 15:23:36 2012 From: peter at stuge.se (Peter Stuge) Date: Sun, 22 Jul 2012 17:23:36 +0200 Subject: Poll: Osmocom meeting 25th of July? In-Reply-To: <20120722110127.GX7693@prithivi.gnumonks.org> References: <20120722110127.GX7693@prithivi.gnumonks.org> Message-ID: <20120722152336.6965.qmail@stuge.se> Harald Welte wrote: > if there are other people that want to meet up, there is no reason > to not hold it! So I would like to get some feedback on who > would want to attend next wednesday. If there are a couple of > people, I'll try to find somebody who can open the CCCB for you. I would be happy to meet with some people in CCCB for a chat. I don't have much of an agenda to suggest though.. I would be happy to talk about what I have learned about the Nokia MetroSite BTS, maybe show how to commission it and so on. //Peter From khorben at defora.org Sun Jul 22 20:12:28 2012 From: khorben at defora.org (Pierre Pronchery) Date: Sun, 22 Jul 2012 22:12:28 +0200 Subject: Poll: Osmocom meeting 25th of July? In-Reply-To: <20120722152336.6965.qmail@stuge.se> References: <20120722110127.GX7693@prithivi.gnumonks.org> <20120722152336.6965.qmail@stuge.se> Message-ID: <500C5EAC.5000706@defora.org> Hey, On 22/07/2012 17:23, Peter Stuge wrote: > Harald Welte wrote: >> if there are other people that want to meet up, there is no reason >> to not hold it! So I would like to get some feedback on who >> would want to attend next wednesday. If there are a couple of >> people, I'll try to find somebody who can open the CCCB for you. > > I would be happy to meet with some people in CCCB for a chat. Same for me, although I'm not sure I'll be able to make it yet. > I don't have much of an agenda to suggest though.. If I join we could have a look at the current state of Osmocom on NetBSD :) Another idea would be to check how to facilitate code re-use of the osmocon loader for other applications to load the firmware (like using the internal serial line on the Openmoko). > I would be happy to talk about what I have learned about the Nokia > MetroSite BTS, maybe show how to commission it and so on. Is it the same that we used during the last CCC Camp? Cheers, -- khorben From peter at stuge.se Sun Jul 22 20:27:29 2012 From: peter at stuge.se (Peter Stuge) Date: Sun, 22 Jul 2012 22:27:29 +0200 Subject: Poll: Osmocom meeting 25th of July? In-Reply-To: <500C5EAC.5000706@defora.org> References: <20120722110127.GX7693@prithivi.gnumonks.org> <20120722152336.6965.qmail@stuge.se> <500C5EAC.5000706@defora.org> Message-ID: <20120722202729.29319.qmail@stuge.se> Pierre Pronchery wrote: > > I don't have much of an agenda to suggest though.. > > If I join we could have a look at the current state of Osmocom on NetBSD :) Sure thing! > Another idea would be to check how to facilitate code re-use of the > osmocon loader for other applications to load the firmware (like using > the internal serial line on the Openmoko). This is a good idea as well. > > I would be happy to talk about what I have learned about the Nokia > > MetroSite BTS, maybe show how to commission it and so on. > > Is it the same that we used during the last CCC Camp? Yes, same kind but a different unit. //Peter From peter at stuge.se Wed Jul 25 13:05:14 2012 From: peter at stuge.se (Peter Stuge) Date: Wed, 25 Jul 2012 15:05:14 +0200 Subject: Poll: Osmocom meeting 25th of July? In-Reply-To: <20120722152336.6965.qmail@stuge.se> References: <20120722110127.GX7693@prithivi.gnumonks.org> <20120722152336.6965.qmail@stuge.se> Message-ID: <20120725130514.18453.qmail@stuge.se> Peter Stuge wrote: > I would be happy to meet with some people in CCCB for a chat. > > I don't have much of an agenda to suggest though.. I'll bring an HP 8922 handset tester tonight, and we will try to do some testing with it. See you there. //Peter From ml at mail.tsaitgaist.info Sun Jul 22 21:35:36 2012 From: ml at mail.tsaitgaist.info (Kevin Redon) Date: Sun, 22 Jul 2012 23:35:36 +0200 Subject: Poll: Osmocom meeting 25th of July? In-Reply-To: <20120722110127.GX7693@prithivi.gnumonks.org> References: <20120722110127.GX7693@prithivi.gnumonks.org> Message-ID: <1342992841-sup-4589@dennou> Hi, I would be there too, and happy to discuss, but have nothing to present. kevin Excerpts from Harald Welte's message of Sun Jul 22 13:01:27 +0200 2012: > Hi all! > > On Wednesday, 25th of July we would have the next Osmocom meeting > berlin. However, neither Holger nor I will be in Berlin on that day to > host the event. I also know that Tobias will not be in Berlin. > > Nonetheless, if there are other people that want to meet up, there is no > reason to not hold it! So I would like to get some feedback on who > would want to attend next wednesday. If there are a couple of people, > I'll try to find somebody who can open the CCCB for you. > > Regards, > Harald From altaf329 at gmail.com Mon Jul 23 07:40:45 2012 From: altaf329 at gmail.com (altaf sk) Date: Mon, 23 Jul 2012 09:40:45 +0200 Subject: Poll: Osmocom meeting 25th of July? In-Reply-To: <1342992841-sup-4589@dennou> References: <20120722110127.GX7693@prithivi.gnumonks.org> <1342992841-sup-4589@dennou> Message-ID: Hello I would like to attend the meeting and share some ideas. Can some one provide me the Rainbow Tables at the meeting. I have a 2TB Hard disk. Thank you Altaf On Sun, Jul 22, 2012 at 11:35 PM, Kevin Redon wrote: > Hi, > > I would be there too, and happy to discuss, but have nothing to present. > > kevin > > Excerpts from Harald Welte's message of Sun Jul 22 13:01:27 +0200 2012: > > Hi all! > > > > On Wednesday, 25th of July we would have the next Osmocom meeting > > berlin. However, neither Holger nor I will be in Berlin on that day to > > host the event. I also know that Tobias will not be in Berlin. > > > > Nonetheless, if there are other people that want to meet up, there is no > > reason to not hold it! So I would like to get some feedback on who > > would want to attend next wednesday. If there are a couple of people, > > I'll try to find somebody who can open the CCCB for you. > > > > Regards, > > Harald > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Mon Jul 23 08:47:37 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 23 Jul 2012 10:47:37 +0200 Subject: Poll: Osmocom meeting 25th of July? In-Reply-To: References: <20120722110127.GX7693@prithivi.gnumonks.org> <1342992841-sup-4589@dennou> Message-ID: > Can some one provide me the Rainbow Tables at the meeting. I have a 2TB Hard > disk. Assuming a 40 Mo/s transfer rate over USB disk (and that's optimistic), you're looking at 11h to make the copy ... Cheers, Sylvain From altaf329 at gmail.com Mon Jul 23 09:19:35 2012 From: altaf329 at gmail.com (altaf sk) Date: Mon, 23 Jul 2012 11:19:35 +0200 Subject: Poll: Osmocom meeting 25th of July? In-Reply-To: References: <20120722110127.GX7693@prithivi.gnumonks.org> <1342992841-sup-4589@dennou> Message-ID: Hello. I can lend the hard disk to whoever provides me the tables and I can collect it later. Thanks On Mon, Jul 23, 2012 at 10:47 AM, Sylvain Munaut <246tnt at gmail.com> wrote: > > Can some one provide me the Rainbow Tables at the meeting. I have a 2TB > Hard > > disk. > > Assuming a 40 Mo/s transfer rate over USB disk (and that's > optimistic), you're looking at 11h to make the copy ... > > Cheers, > > Sylvain > -------------- next part -------------- An HTML attachment was scrubbed... URL: From osmocom at ngolde.de Mon Jul 23 08:49:17 2012 From: osmocom at ngolde.de (Nico Golde) Date: Mon, 23 Jul 2012 10:49:17 +0200 Subject: Poll: Osmocom meeting 25th of July? In-Reply-To: <1342992841-sup-4589@dennou> References: <20120722110127.GX7693@prithivi.gnumonks.org> <1342992841-sup-4589@dennou> Message-ID: <20120723084916.GA13803@nybble.binarybase.org> Hi, * Kevin Redon [2012-07-23 10:47]: > I would be there too, and happy to discuss, but have nothing to present. Same here. Cheers Nico From avwiseav at gmail.com Tue Jul 24 08:16:24 2012 From: avwiseav at gmail.com (bob) Date: Tue, 24 Jul 2012 01:16:24 -0700 (PDT) Subject: The AMR decode segmentation fault Message-ID: <1343117784121-4025233.post@n3.nabble.com> Hi,List I use a TCH/AFS decoder written by Sylvain Munaut and mad to decode the TCH AMR, but it seems there are some bug, but I am not familiar with the convolution codes? the code is following, who are familiar can help me? very thanks! /* * conv_amr.c * * Convolutional code tables for TCH/AFS channels * * Copyright (C) 2011 Sylvain Munaut */ #include #include /* TCH/AFS12.2 */ /* ----------- */ //# AFS12.2 1/2, K=5, RSC static const uint8_t conv_afs12_2_next_output[][2] = {{0, 3}, {1, 2}, {0, 3}, {1, 2}, {0, 3}, {1, 2}, {0, 3}, {1, 2}, {0, 3}, {1, 2}, {0, 3}, {1, 2}, {0, 3}, {1, 2}, {0, 3}, {1, 2},}; static const uint8_t conv_afs12_2_next_state[][2] = {{0, 1}, {2, 3}, {4, 5}, {6, 7}, {9, 8}, {11, 10}, {13, 12}, {15, 14}, {1, 0}, {3, 2}, {5, 4}, {7, 6}, {8, 9}, {10, 11}, {12, 13}, {14, 15},}; static const uint8_t conv_afs12_2_next_term_output[] = {0, 1, 0, 1, 3, 2, 3, 2, 3, 2, 3, 2, 0, 1, 0, 1,}; static const uint8_t conv_afs12_2_next_term_state[] = {0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30,}; static const uint16_t conv_afs12_2_punct[] = {321, 325, 329, 333, 337, 341, 345, 349, 353, 357, 361, 363, 365, 369, 373, 377, 379, 381, 385, 389, 393, 395, 397, 401, 405, 409, 411, 413, 417, 421, 425, 427, 429, 433, 437, 441, 443, 445, 449, 453, 457, 459, 461, 465, 469, 473, 475, 477, 481, 485, 489, 491, 493, 495, 497, 499, 501, 503, 505, 507, -1,}; const struct osmo_conv_code conv_tch_afs_12_2 = { .N = 2, .K = 5, .len = 250, .next_output = conv_afs12_2_next_output, .next_state = conv_afs12_2_next_state, .next_term_output = conv_afs12_2_next_term_output, .next_term_state = conv_afs12_2_next_term_state, .puncture = conv_afs12_2_punct, }; //# AFS10.2 1/3, K=5, RSC static const uint8_t conv_afs10_2_next_output[][2] = {{0, 7}, {2, 5}, {4, 3}, {6, 1}, {2, 5}, {0, 7}, {6, 1}, {4, 3}, {0, 7}, {2, 5}, {4, 3}, {6, 1}, {2, 5}, {0, 7}, {6, 1}, {4, 3},}; static const uint8_t conv_afs10_2_next_state[][2] = {{0, 1}, {3, 2}, {5, 4}, {6, 7}, {9, 8}, {10, 11}, {12, 13}, {15, 14}, {1, 0}, {2, 3}, {4, 5}, {7, 6}, {8, 9}, {11, 10}, {13, 12}, {14, 15},}; static const uint8_t conv_afs10_2_next_term_output[] = {0, 5, 3, 6, 5, 0, 6, 3, 7, 2, 4, 1, 2, 7, 1, 4,}; static const uint8_t conv_afs10_2_next_term_state[] = {0, 2, 4, 6, 8, 10, 12, 14, 0, 2, 4, 6, 8, 10, 12, 14,}; const uint16_t conv_afs10_2_punct[] = {1, 4, 7, 10, 16, 19, 22, 28, 31, 34, 40, 43, 46, 52, 55, 58, 64, 67, 70, 76, 79, 82, 88, 91, 94, 100, 103, 106, 112, 115, 118, 124, 127, 130, 136, 139, 142, 148, 151, 154, 160, 163, 166, 172, 175, 178, 184, 187, 190, 196, 199, 202, 208, 211, 214, 220, 223, 226, 232, 235, 238, 244, 247, 250, 256, 259, 262, 268, 271, 274, 280, 283, 286, 292, 295, 298, 304, 307, 310, 316, 319, 322, 325, 328, 331, 334, 337, 340, 343, 346, 349, 352, 355, 358, 361, 364, 367, 370, 373, 376, 379, 382, 385, 388, 391, 394, 397, 400, 403, 406, 409, 412, 415, 418, 421, 424, 427, 430, 433, 436, 439, 442, 445, 448, 451, 454, 457, 460, 463, 466, 469, 472, 475, 478, 481, 484, 487, 490, 493, 496, 499, 502, 505, 508, 511, 514, 517, 520, 523, 526, 529, 532, 535, 538, 541, 544, 547, 550, 553, 556, 559, 562, 565, 568, 571, 574, 577, 580, 583, 586, 589, 592, 595, 598, 601, 604, 607, 609, 610, 613, 616, 619, 621, 622, 625, 627, 628, 631, 633, 634, 636, 637, 639, 640, -1,}; const struct osmo_conv_code conv_tch_afs_10_2 = { .N = 3, .K = 5, .len = 210, .next_output = conv_afs10_2_next_output, .next_state = conv_afs10_2_next_state, .next_term_output = conv_afs10_2_next_term_output, .next_term_state = conv_afs10_2_next_term_state, .puncture = conv_afs10_2_punct, }; //# AFS7.95 1/3, K=7, RSC static const uint8_t conv_afs7_95_next_output[][2] = {{0, 7}, {3, 4}, {2, 5}, {1, 6}, {2, 5}, {1, 6}, {0, 7}, {3, 4}, {3, 4}, {0, 7}, {1, 6}, {2, 5}, {1, 6}, {2, 5}, {3, 4}, {0, 7}, {3, 4}, {0, 7}, {1, 6}, {2, 5}, {1, 6}, {2, 5}, {3, 4}, {0, 7}, {0, 7}, {3, 4}, {2, 5}, {1, 6}, {2, 5}, {1, 6}, {0, 7}, {3, 4}, {0, 7}, {3, 4}, {2, 5}, {1, 6}, {2, 5}, {1, 6}, {0, 7}, {3, 4}, {3, 4}, {0, 7}, {1, 6}, {2, 5}, {1, 6}, {2, 5}, {3, 4}, {0, 7}, {3, 4}, {0, 7}, {1, 6}, {2, 5}, {1, 6}, {2, 5}, {3, 4}, {0, 7}, {0, 7}, {3, 4}, {2, 5}, {1, 6}, {2, 5}, {1, 6}, {0, 7}, {3, 4},}; static const uint8_t conv_afs7_95_next_state[][2] = {{0, 1}, {2, 3}, {5, 4}, {7, 6}, {9, 8}, {11, 10}, {12, 13}, {14, 15}, {16, 17}, {18, 19}, {21, 20}, {23, 22}, {25, 24}, {27, 26}, {28, 29}, {30, 31}, {33, 32}, {35, 34}, {36, 37}, {38, 39}, {40, 41}, {42, 43}, {45, 44}, {47, 46}, {49, 48}, {51, 50}, {52, 53}, {54, 55}, {56, 57}, {58, 59}, {61, 60}, {63, 62}, {1, 0}, {3, 2}, {4, 5}, {6, 7}, {8, 9}, {10, 11}, {13, 12}, {15, 14}, {17, 16}, {19, 18}, {20, 21}, {22, 23}, {24, 25}, {26, 27}, {29, 28}, {31, 30}, {32, 33}, {34, 35}, {37, 36}, {39, 38}, {41, 40}, {43, 42}, {44, 45}, {46, 47}, {48, 49}, {50, 51}, {53, 52}, {55, 54}, {57, 56}, {59, 58}, {60, 61}, {62, 63},}; static const uint8_t conv_afs7_95_next_term_output[] = {0, 3, 5, 6, 5, 6, 0, 3, 3, 0, 6, 5, 6, 5, 3, 0, 4, 7, 1, 2, 1, 2, 4, 7, 7, 4, 2, 1, 2, 1, 7, 4, 7, 4, 2, 1, 2, 1, 7, 4, 4, 7, 1, 2, 1, 2, 4, 7, 3, 0, 6, 5, 6, 5, 3, 0, 0, 3, 5, 6, 5, 6, 0, 3,}; static const uint8_t conv_afs7_95_next_term_state[] = {0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62,}; const uint16_t conv_afs7_95_punct[] = {1, 2, 4, 5, 8, 22, 70, 118, 166, 214, 262, 310, 317, 319, 325, 332, 334, 341, 343, 349, 356, 358, 365, 367, 373, 380, 382, 385, 389, 391, 397, 404, 406, 409, 413, 415, 421, 428, 430, 433, 437, 439, 445, 452, 454, 457, 461, 463, 469, 476, 478, 481, 485, 487, 490, 493, 500, 502, 503, 505, 506, 508, 509, 511, 512, -1,}; const struct osmo_conv_code conv_tch_afs_7_95 = { .N = 3, .K = 7, .len = 165, .next_output = conv_afs7_95_next_output, .next_state = conv_afs7_95_next_state, .next_term_output = conv_afs7_95_next_term_output, .next_term_state = conv_afs7_95_next_term_state, .puncture = conv_afs7_95_punct, }; //# AFS 7.4 1/3, K=5, RSC (2) static const uint8_t conv_afs7_4_next_output[][2] = {{0, 7}, {2, 5}, {4, 3}, {6, 1}, {2, 5}, {0, 7}, {6, 1}, {4, 3}, {0, 7}, {2, 5}, {4, 3}, {6, 1}, {2, 5}, {0, 7}, {6, 1}, {4, 3},}; static const uint8_t conv_afs7_4_next_state[][2] = {{0, 1}, {3, 2}, {5, 4}, {6, 7}, {9, 8}, {10, 11}, {12, 13}, {15, 14}, {1, 0}, {2, 3}, {4, 5}, {7, 6}, {8, 9}, {11, 10}, {13, 12}, {14, 15},}; static const uint8_t conv_afs7_4_next_term_output[] = {0, 5, 3, 6, 5, 0, 6, 3, 7, 2, 4, 1, 2, 7, 1, 4,}; static const uint8_t conv_afs7_4_next_term_state[] = {0, 2, 4, 6, 8, 10, 12, 14, 0, 2, 4, 6, 8, 10, 12, 14,}; const uint16_t conv_afs7_4_punct[] = {0, 355, 361, 367, 373, 379, 385, 391, 397, 403, 409, 415, 421, 427, 433, 439, 445, 451, 457, 460, 463, 466, 468, 469, 471, 472, -1,}; const struct osmo_conv_code conv_tch_afs_7_4 = { .N = 3, .K = 5, .len = 154, .next_output = conv_afs7_4_next_output, .next_state = conv_afs7_4_next_state, .next_term_output = conv_afs7_4_next_term_output, .next_term_state = conv_afs7_4_next_term_state, .puncture = conv_afs7_4_punct, }; //# AFS6.7 1/4, K=5, RSC static const uint8_t conv_afs6_7_next_output[][2] = {{0, 15}, {4, 11}, {8, 7}, {12, 3}, {4, 11}, {0, 15}, {12, 3}, {8, 7}, {0, 15}, {4, 11}, {8, 7}, {12, 3}, {4, 11}, {0, 15}, {12, 3}, {8, 7},}; static const uint8_t conv_afs6_7_next_state[][2] = {{0, 1}, {3, 2}, {5, 4}, {6, 7}, {9, 8}, {10, 11}, {12, 13}, {15, 14}, {1, 0}, {2, 3}, {4, 5}, {7, 6}, {8, 9}, {11, 10}, {13, 12}, {14, 15},}; static const uint8_t conv_afs6_7_next_term_output[] = {0, 11, 7, 12, 11, 0, 12, 7, 15, 4, 8, 3, 4, 15, 3, 8,}; static const uint8_t conv_afs6_7_next_term_state[] = {0, 2, 4, 6, 8, 10, 12, 14, 0, 2, 4, 6, 8, 10, 12, 14,}; const uint16_t conv_afs6_7_punct[] = {1, 3, 7, 11, 15, 27, 39, 55, 67, 79, 95, 107, 119, 135, 147, 159, 175, 187, 199, 215, 227, 239, 255, 267, 279, 287, 291, 295, 299, 303, 307, 311, 315, 319, 323, 327, 331, 335, 339, 343, 347, 351, 355, 359, 363, 367, 369, 371, 375, 377, 379, 383, 385, 387, 391, 393, 395, 399, 401, 403, 407, 409, 411, 415, 417, 419, 423, 425, 427, 431, 433, 435, 439, 441, 443, 447, 449, 451, 455, 457, 459, 463, 465, 467, 471, 473, 475, 479, 481, 483, 487, 489, 491, 495, 497, 499, 503, 505, 507, 511, 513, 515, 519, 521, 523, 527, 529, 531, 535, 537, 539, 543, 545, 547, 549, 551, 553, 555, 557, 559, 561, 563, 565, 567, 569, 571, 573, 575, -1,}; const struct osmo_conv_code conv_tch_afs_6_7 = { .N = 4, .K = 5, .len = 140, .next_output = conv_afs6_7_next_output, .next_state = conv_afs6_7_next_state, .next_term_output = conv_afs6_7_next_term_output, .next_term_state = conv_afs6_7_next_term_state, .puncture = conv_afs6_7_punct, }; //# AFS5.9 1/4, K=7, RSC static const uint8_t conv_afs5_9_next_output[][2] = {{0, 15}, {8, 7}, {4, 11}, {12, 3}, {4, 11}, {12, 3}, {0, 15}, {8, 7}, {8, 7}, {0, 15}, {12, 3}, {4, 11}, {12, 3}, {4, 11}, {8, 7}, {0, 15}, {8, 7}, {0, 15}, {12, 3}, {4, 11}, {12, 3}, {4, 11}, {8, 7}, {0, 15}, {0, 15}, {8, 7}, {4, 11}, {12, 3}, {4, 11}, {12, 3}, {0, 15}, {8, 7}, {0, 15}, {8, 7}, {4, 11}, {12, 3}, {4, 11}, {12, 3}, {0, 15}, {8, 7}, {8, 7}, {0, 15}, {12, 3}, {4, 11}, {12, 3}, {4, 11}, {8, 7}, {0, 15}, {8, 7}, {0, 15}, {12, 3}, {4, 11}, {12, 3}, {4, 11}, {8, 7}, {0, 15}, {0, 15}, {8, 7}, {4, 11}, {12, 3}, {4, 11}, {12, 3}, {0, 15}, {8, 7},}; static const uint8_t conv_afs5_9_next_state[][2] = {{0, 1}, {3, 2}, {5, 4}, {6, 7}, {9, 8}, {10, 11}, {12, 13}, {15, 14}, {17, 16}, {18, 19}, {20, 21}, {23, 22}, {24, 25}, {27, 26}, {29, 28}, {30, 31}, {32, 33}, {35, 34}, {37, 36}, {38, 39}, {41, 40}, {42, 43}, {44, 45}, {47, 46}, {49, 48}, {50, 51}, {52, 53}, {55, 54}, {56, 57}, {59, 58}, {61, 60}, {62, 63}, {1, 0}, {2, 3}, {4, 5}, {7, 6}, {8, 9}, {11, 10}, {13, 12}, {14, 15}, {16, 17}, {19, 18}, {21, 20}, {22, 23}, {25, 24}, {26, 27}, {28, 29}, {31, 30}, {33, 32}, {34, 35}, {36, 37}, {39, 38}, {40, 41}, {43, 42}, {45, 44}, {46, 47}, {48, 49}, {51, 50}, {53, 52}, {54, 55}, {57, 56}, {58, 59}, {60, 61}, {63, 62},}; static const uint8_t conv_afs5_9_next_term_output[] = {0, 7, 11, 12, 11, 12, 0, 7, 7, 0, 12, 11, 12, 11, 7, 0, 8, 15, 3, 4, 3, 4, 8, 15, 15, 8, 4, 3, 4, 3, 15, 8, 15, 8, 4, 3, 4, 3, 15, 8, 8, 15, 3, 4, 3, 4, 8, 15, 7, 0, 12, 11, 12, 11, 7, 0, 0, 7, 11, 12, 11, 12, 0, 7,}; static const uint8_t conv_afs5_9_next_term_state[] = {0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62,}; const uint16_t conv_afs5_9_punct[] = {0, 1, 3, 5, 7, 11, 15, 31, 47, 63, 79, 95, 111, 127, 143, 159, 175, 191, 207, 223, 239, 255, 271, 287, 303, 319, 327, 331, 335, 343, 347, 351, 359, 363, 367, 375, 379, 383, 391, 395, 399, 407, 411, 415, 423, 427, 431, 439, 443, 447, 455, 459, 463, 467, 471, 475, 479, 483, 487, 491, 495, 499, 503, 507, 509, 511, 512, 513, 515, 516, 517, 519, -1,}; const struct osmo_conv_code conv_tch_afs_5_9 = { .N = 4, .K = 7, .len = 124, .next_output = conv_afs5_9_next_output, .next_state = conv_afs5_9_next_state, .next_term_output = conv_afs5_9_next_term_output, .next_term_state = conv_afs5_9_next_term_state, .puncture = conv_afs5_9_punct, }; //# AFS5.15 1/5, K=5, RSC static const uint8_t conv_afs5_15_next_output[][2] = {{0, 31}, {4, 27}, {24, 7}, {28, 3}, {4, 27}, {0, 31}, {28, 3}, {24, 7}, {0, 31}, {4, 27}, {24, 7}, {28, 3}, {4, 27}, {0, 31}, {28, 3}, {24, 7},}; static const uint8_t conv_afs5_15_next_state[][2] = {{0, 1}, {3, 2}, {5, 4}, {6, 7}, {9, 8}, {10, 11}, {12, 13}, {15, 14}, {1, 0}, {2, 3}, {4, 5}, {7, 6}, {8, 9}, {11, 10}, {13, 12}, {14, 15},}; static const uint8_t conv_afs5_15_next_term_output[] = {0, 27, 7, 28, 27, 0, 28, 7, 31, 4, 24, 3, 4, 31, 3, 24,}; static const uint8_t conv_afs5_15_next_term_state[] = {0, 2, 4, 6, 8, 10, 12, 14, 0, 2, 4, 6, 8, 10, 12, 14,}; const uint16_t conv_afs5_15_punct[] = {0, 4, 5, 9, 10, 14, 15, 20, 25, 30, 35, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170, 180,190, 200, 210, 220, 230, 240, 250, 260, 270, 280,290, 300, 310, 315, 320, 325, 330, 334, 335, 340, 344, 345, 350, 354, 355, 360, 364, 365, 370, 374, 375, 380, 384, 385, 390, 394, 395, 400, 404, 405, 410, 414, 415, 420, 424, 425, 430, 434, 435, 440, 444, 445, 450, 454, 455, 460, 464, 465, 470, 474, 475, 480, 484, 485, 490, 494, 495, 500, 504, 505, 510, 514, 515, 520, 524, 525, 529, 530, 534, 535, 539, 540, 544, 545, 549, 550, 554, 555, 559, 560, 564, -1,}; const struct osmo_conv_code conv_tch_afs_5_15 = { .N = 5, .K = 5, .len = 109, .next_output = conv_afs5_15_next_output, .next_state = conv_afs5_15_next_state, .next_term_output = conv_afs5_15_next_term_output, .next_term_state = conv_afs5_15_next_term_state, .puncture = conv_afs5_15_punct, }; //# AFS4.75 1/5, K=7, RSC static const uint8_t conv_afs4_75_next_output[][2] = {{0, 31}, {24, 7}, {4, 27}, {28, 3}, {4, 27}, {28, 3}, {0, 31}, {24, 7}, {24, 7}, {0, 31}, {28, 3}, {4, 27}, {28, 3}, {4, 27}, {24, 7}, {0, 31}, {24, 7}, {0, 31}, {28, 3}, {4, 27}, {28, 3}, {4, 27}, {24, 7}, {0, 31}, {0, 31}, {24, 7}, {4, 27}, {28, 3}, {4, 27}, {28, 3}, {0, 31}, {24, 7}, {0, 31}, {24, 7}, {4, 27}, {28, 3}, {4, 27}, {28, 3}, {0, 31}, {24, 7}, {24, 7}, {0, 31}, {28, 3}, {4, 27}, {28, 3}, {4, 27}, {24, 7}, {0, 31}, {24, 7}, {0, 31}, {28, 3}, {4, 27}, {28, 3}, {4, 27}, {24, 7}, {0, 31}, {0, 31}, {24, 7}, {4, 27}, {28, 3}, {4, 27}, {28, 3}, {0, 31}, {24, 7},}; static const uint8_t conv_afs4_75_next_state[][2] = {{0, 1}, {3, 2}, {5, 4}, {6, 7}, {9, 8}, {10, 11}, {12, 13}, {15, 14}, {17, 16}, {18, 19}, {20, 21}, {23, 22}, {24, 25}, {27, 26}, {29, 28}, {30, 31}, {32, 33}, {35, 34}, {37, 36}, {38, 39}, {41, 40}, {42, 43}, {44, 45}, {47, 46}, {49, 48}, {50, 51}, {52, 53}, {55, 54}, {56, 57}, {59, 58}, {61, 60}, {62, 63}, {1, 0}, {2, 3}, {4, 5}, {7, 6}, {8, 9}, {11, 10}, {13, 12}, {14, 15}, {16, 17}, {19, 18}, {21, 20}, {22, 23}, {25, 24}, {26, 27}, {28, 29}, {31, 30}, {33, 32}, {34, 35}, {36, 37}, {39, 38}, {40, 41}, {43, 42}, {45, 44}, {46, 47}, {48, 49}, {51, 50}, {53, 52}, {54, 55}, {57, 56}, {58, 59}, {60, 61}, {63, 62},}; static const uint8_t conv_afs4_75_next_term_output[] = {0, 7, 27, 28, 27, 28, 0, 7, 7, 0, 28, 27, 28, 27, 7, 0, 24, 31, 3, 4, 3, 4, 24, 31, 31, 24, 4, 3, 4, 3, 31, 24, 31, 24, 4, 3, 4, 3, 31, 24, 24, 31, 3, 4, 3, 4, 24, 31, 7, 0, 28, 27, 28, 27, 7, 0, 0, 7, 27, 28, 27, 28, 0, 7,}; static const uint8_t conv_afs4_75_next_term_state[] = {0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62,}; const uint16_t conv_afs4_75_punct[] = {0, 1, 2, 4, 5, 7, 9, 15, 25, 35, 45, 55, 65, 75, 85, 95, 105, 115, 125, 135, 145, 155, 165, 175, 185, 195, 205, 215, 225, 235, 245, 255, 265, 275, 285, 295, 305, 315, 325, 335, 345, 355, 365, 375, 385, 395, 400, 405, 410, 415, 420, 425, 430, 435, 440, 445, 450, 455, 459, 460, 465, 470, 475, 479, 480, 485, 490, 495, 499, 500, 505, 509, 510, 515, 517, 519, 520, 522, 524, 525, 526, 527, 529, 530, 531, 532, 534, -1,}; const struct osmo_conv_code conv_tch_afs_4_75 = { .N = 5, .K = 7, .len = 101, .next_output = conv_afs4_75_next_output, .next_state = conv_afs4_75_next_state, .next_term_output = conv_afs4_75_next_term_output, .next_term_state = conv_afs4_75_next_term_state, .puncture = conv_afs4_75_punct, }; -- View this message in context: http://baseband-devel.722152.n3.nabble.com/The-AMR-decode-segmentation-fault-tp4025233.html Sent from the baseband-devel mailing list archive at Nabble.com. From osmocarpenter at gmail.com Tue Jul 24 13:53:43 2012 From: osmocarpenter at gmail.com (George Carpenter) Date: Tue, 24 Jul 2012 16:53:43 +0300 Subject: For sale some phones that are no longer required. Message-ID: Hello. I have some motorola phones that they are no longer required by my friends. These phones are with the filter rework done. The phones are complete with serial and antenna cables but can be sent without them. If anyone is interested, please send me a msg at irc (OsmoCarpenteR), do not reply to this msg. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From avwiseav at gmail.com Thu Jul 26 08:47:27 2012 From: avwiseav at gmail.com (bob) Date: Thu, 26 Jul 2012 01:47:27 -0700 (PDT) Subject: is the Viterbi decode for the AFS provided by Sylvain right? Message-ID: <1343292447286-4025236.post@n3.nabble.com> Hi ,List: search some materials, find that the decode method of AFS convolutional code is different from the EFS`, it use RSC, and need SOVA(soft output viterbi algorithm). am i right? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/is-the-Viterbi-decode-for-the-AFS-provided-by-Sylvain-right-tp4025236.html Sent from the baseband-devel mailing list archive at Nabble.com. From 246tnt at gmail.com Thu Jul 26 09:23:34 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 26 Jul 2012 11:23:34 +0200 Subject: is the Viterbi decode for the AFS provided by Sylvain right? In-Reply-To: <1343292447286-4025236.post@n3.nabble.com> References: <1343292447286-4025236.post@n3.nabble.com> Message-ID: > search some materials, find that the decode method of AFS convolutional > code is different from the EFS`, it use RSC, and need SOVA(soft output > viterbi algorithm). am i right? No. It _does_ use RSC (and the viterbi code in libosmocore supports RSC). But that has nothing to do with SOVA and SOVA is _not_ required at all. AFAIK, the AMR code I sent a while is correct. Just to be sure I attached the latest version I have. I haven't tested all the modes but at least 12.2 and 10.2 should be correct. Cheers, Sylvain -------------- next part -------------- A non-text attachment was scrubbed... Name: conv_tch_afs.c Type: text/x-csrc Size: 15081 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: conv_tch_afs.h Type: text/x-chdr Size: 625 bytes Desc: not available URL: From avwiseav at gmail.com Fri Jul 27 01:24:33 2012 From: avwiseav at gmail.com (bob) Date: Thu, 26 Jul 2012 18:24:33 -0700 (PDT) Subject: is the Viterbi decode for the AFS provided by Sylvain right? In-Reply-To: References: <1343292447286-4025236.post@n3.nabble.com> Message-ID: <1343352273369-4025238.post@n3.nabble.com> Hi, Sylvain I use your code to decode the AMR in my network, but have no positive result.I have some questions. 1.when I have decode the TCH, and ready write to file, how to set the last argument of the function. length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_12_2_len, 0/1);is it 0 or 1? I use your burst_id branch. 2.are you test your code relate to TCH AMR? have you ever succeed to listen the voice coded by AMR, in your clarifications about 27C3 GSM Sniff Talk, I find you hadn`t completed the AMR decode.you said:" - ... But since I'd like it to support AMR and viterbi soft output before that happens, it could take some time." how about your current process? 3.in your SDCCH sniffer demo, you use snr of the channel to decide a over of a channel, but in the speech of amr, because of DTX, it can not be used, how to settle the problem because I can`t implement the full stack. Look forwarding to communicate with you? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/is-the-Viterbi-decode-for-the-AFS-provided-by-Sylvain-right-tp4025236p4025238.html Sent from the baseband-devel mailing list archive at Nabble.com. From akibsayyed at gmail.com Fri Jul 27 03:18:53 2012 From: akibsayyed at gmail.com (Akib Sayyed) Date: Fri, 27 Jul 2012 08:48:53 +0530 Subject: is the Viterbi decode for the AFS provided by Sylvain right? In-Reply-To: <1343352273369-4025238.post@n3.nabble.com> References: <1343292447286-4025236.post@n3.nabble.com> <1343352273369-4025238.post@n3.nabble.com> Message-ID: Bob i will suggest u to try implementing amr for mobile app then test whether it works properly then start playing with burst ind Or is it possible for u to share your code i will try to implement it in mobile app Sent from Android On Jul 27, 2012 6:56 AM, "bob" wrote: > Hi, Sylvain > > I use your code to decode the AMR in my network, but have no positive > result.I have some questions. > > 1.when I have decode the TCH, and ready write to file, how to set the last > argument of the function. > length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_12_2_len, > 0/1);is it 0 or 1? I use your > burst_id branch. > > 2.are you test your code relate to TCH AMR? have you ever succeed to listen > the voice coded by AMR, in your clarifications about 27C3 GSM Sniff Talk, I > find you hadn`t completed the AMR decode.you said:" - ... But since I'd > like it to support AMR and viterbi soft output before that happens, it > could > take some time." how about your current process? > > 3.in your SDCCH sniffer demo, you use snr of the channel to decide a over > of > a channel, but in the speech of amr, because of DTX, it can not be used, > how > to settle the problem because I can`t implement the full stack. > > Look forwarding to communicate with you? > > > > > -- > View this message in context: > http://baseband-devel.722152.n3.nabble.com/is-the-Viterbi-decode-for-the-AFS-provided-by-Sylvain-right-tp4025236p4025238.html > Sent from the baseband-devel mailing list archive at Nabble.com. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Fri Jul 27 06:15:49 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 27 Jul 2012 08:15:49 +0200 Subject: is the Viterbi decode for the AFS provided by Sylvain right? In-Reply-To: References: <1343292447286-4025236.post@n3.nabble.com> <1343352273369-4025238.post@n3.nabble.com> Message-ID: > Bob i will suggest u to try implementing amr for mobile app then test > whether it works properly then start playing with burst ind > Or is it possible for u to share your code i will try to implement it in > mobile app Those are two _very_ different tasks. Decoding AMR is a fairly easy task compared to implementing it in mobile ... Cheers, Sylvain From 246tnt at gmail.com Fri Jul 27 06:14:26 2012 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 27 Jul 2012 08:14:26 +0200 Subject: is the Viterbi decode for the AFS provided by Sylvain right? In-Reply-To: <1343352273369-4025238.post@n3.nabble.com> References: <1343292447286-4025236.post@n3.nabble.com> <1343352273369-4025238.post@n3.nabble.com> Message-ID: > 1.when I have decode the TCH, and ready write to file, how to set the last > argument of the function. > length = osmo_ubit2pbit_ext(voice, 0, EFRAMR, 0, 8 + gsm690_12_2_len, > 0/1);is it 0 or 1? I use your > burst_id branch. Most likely 0 > 2.are you test your code relate to TCH AMR? have you ever succeed to listen > the voice coded by AMR, in your clarifications about 27C3 GSM Sniff Talk, I > find you hadn`t completed the AMR decode.you said:" - ... But since I'd > like it to support AMR and viterbi soft output before that happens, it could > take some time." how about your current process? The code isn't ready yet and since I'm not actively working on it ATM, it's not really progressing. > 3.in your SDCCH sniffer demo, you use snr of the channel to decide a over of > a channel, but in the speech of amr, because of DTX, it can not be used, how > to settle the problem because I can`t implement the full stack. The SAACH associated with TCH doesn't have DTX so you can check if the channel is active by only looking for power during the SAACH burts. Cheers, Sylvain From filipe.rc at hotmail.com Fri Jul 27 00:43:08 2012 From: filipe.rc at hotmail.com (Filipe RC -) Date: Fri, 27 Jul 2012 00:43:08 +0000 Subject: OSMOCOM RECEIVING BUT NOT SENDING DATA THROUGHT TXD - HARDWARE&SOFTWARE TESTED - GNUARM&OSMOCOM BUILT FROM OSMOCOM PAGE INSTRUCTIONS Message-ID: Hi, im having some problems in software only, that i describe bellow in my log: -FTDI based interface sold by tronix (vendor link on your site), usb2 to serial adaptor ( model TRX1227, CHIPSET FT232R ) -gnuarm&osmocom compiled from source on debian stable as per osmocom without a single problem. -ran osmocom from su (tried user as well), as instructed and as follows: $ ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/loader.compalram.bin output: whenever power button was pressed, all i got was some aparently random hex?(no expert on phone flashing here) with no getting to PROMPT1: "root at box:/home/box/osmocomm/osmocom-bb/src/host/osmocon# sudo ./osmocon -p /dev/ttyUSB0 -m c123 ../../target/firmware/board/compal_e88/loader.compalram.bin got 1 bytes from modem, data looks like: 00 . got 2 bytes from modem, data looks like: 00 00 .. got 3 bytes from modem, data looks like: 72 82 bf r.. got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: a6 . got 1 bytes from modem, data looks like: 51 Q got 1 bytes from modem, data looks like: d2 . got 1 bytes from modem, data looks like: 51 Q got 1 bytes from modem, data looks like: b2 . got 1 bytes from modem, data looks like: a4 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 4d M got 1 bytes from modem, data looks like: a3 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . 2nd press: got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . third press: got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . fourth press: got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 82 . got 1 bytes from modem, data looks like: bf . got 1 bytes from modem, data looks like: 7d } got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: a6 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . " Same output, (maybe with a few more presses) in hex, using gtkterm at 115200baud,8bit,nopar,1stop: " 00 F1 00 72 82 BF 7D FD 7F 00 A6 51 D2 51 B2 A4 12 00 4D A3 A3 68 23 00 00 00 F1 00 72 82 BF 7D FD 7F 00 A6 51 D2 51 A4 A4 12 00 4D A3 A3 68 23 00 00 00 F1 00 72 82 BF 7D FD 7F 00 A6 51 D2 51 B2 A4 12 00 4D A3 A3 64 23 00 00 00 F1 00 72 82 BF 7D FD 7F 00 A6 51 D2 51 A4 A4 12 00 4D A3 A3 64 23 00 00 00 F1 00 72 82 BF 7D FD 7F 00 A6 51 D2 51 B2 A4 12 00 4D A3 A3 48 23 00 00 00 F1 00 72 82 BF 7D FD 7F 00 A6 51 D2 51 B2 A4 12 00 4D A3 A3 64 23 00 00 00 F1 00 72 82 BF 7D FD 7F 00 A6 51 D2 51 B4 A4 12 00 4D A3 A3 48 23 00 00 00 F1 00 72 82 BF 7D FD 7F 00 A6 51 D2 51 A4 A4 12 00 4D A3 A3 48 23 00 00 " -/dev/USB0 permission check - good, even chmoded 777&chown on rc.local. -cable check: thought txd was broken, but wasnt. checked from linux with a led stuck to the txd end of the jack, echo "whatever" > /dev/ttyUSB0, led did flash. -chances i put are: osmocom dependent on some specific C123 firmware? some kind of hidden compilation complication? some kind of ftdi eeprom config/bitrate/parity config missing for osmocom? I hope i have managed to be concise enough. Great work guys. Greatings from portugal, Filipe RC -------------- next part -------------- An HTML attachment was scrubbed... URL: From filipe.rc at hotmail.com Fri Jul 27 00:52:29 2012 From: filipe.rc at hotmail.com (Filipe RC -) Date: Fri, 27 Jul 2012 00:52:29 +0000 Subject: C123 - OSMOCOM RECEIVING BUT NOT SENDING DATA THROUGHT TXD - HARDWARE&SOFTWARE TESTED - GNUARM&OSMOCOM BUILT FROM OSMOCOM PAGE INSTRUCTIONS In-Reply-To: References: Message-ID: Hi, im having some problems in software only, that i describe bellow in my log: -FTDI based interface sold by tronix (vendor link on your site), usb2 to serial adaptor ( model TRX1227, CHIPSET FT232R ) -gnuarm&osmocom compiled from source on debian stable as per osmocom without a single problem. -ran osmocom from su (tried user as well), as instructed and as follows: $ ./osmocon -p /dev/ttyUSB0 -m c123xor ../../target/firmware/board/compal_e88/loader.compalram.bin output: whenever power button was pressed, all i got was some aparently random hex?(no expert on phone flashing here) with no getting to PROMPT1: "root at box:/home/box/osmocomm/osmocom-bb/src/host/osmocon# sudo ./osmocon -p /dev/ttyUSB0 -m c123 ../../target/firmware/board/compal_e88/loader.compalram.bin got 1 bytes from modem, data looks like: 00 . got 2 bytes from modem, data looks like: 00 00 .. got 3 bytes from modem, data looks like: 72 82 bf r.. got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: a6 . got 1 bytes from modem, data looks like: 51 Q got 1 bytes from modem, data looks like: d2 . got 1 bytes from modem, data looks like: 51 Q got 1 bytes from modem, data looks like: b2 . got 1 bytes from modem, data looks like: a4 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 4d M got 1 bytes from modem, data looks like: a3 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . 2nd press: got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . third press: got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . fourth press: got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 82 . got 1 bytes from modem, data looks like: bf . got 1 bytes from modem, data looks like: 7d } got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: a6 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 00 . " Same output, (maybe with a few more presses) in hex, using gtkterm at 115200baud,8bit,nopar,1stop: " 00 F1 00 72 82 BF 7D FD 7F 00 A6 51 D2 51 B2 A4 12 00 4D A3 A3 68 23 00 00 00 F1 00 72 82 BF 7D FD 7F 00 A6 51 D2 51 A4 A4 12 00 4D A3 A3 68 23 00 00 00 F1 00 72 82 BF 7D FD 7F 00 A6 51 D2 51 B2 A4 12 00 4D A3 A3 64 23 00 00 00 F1 00 72 82 BF 7D FD 7F 00 A6 51 D2 51 A4 A4 12 00 4D A3 A3 64 23 00 00 00 F1 00 72 82 BF 7D FD 7F 00 A6 51 D2 51 B2 A4 12 00 4D A3 A3 48 23 00 00 00 F1 00 72 82 BF 7D FD 7F 00 A6 51 D2 51 B2 A4 12 00 4D A3 A3 64 23 00 00 00 F1 00 72 82 BF 7D FD 7F 00 A6 51 D2 51 B4 A4 12 00 4D A3 A3 48 23 00 00 00 F1 00 72 82 BF 7D FD 7F 00 A6 51 D2 51 A4 A4 12 00 4D A3 A3 48 23 00 00 " -/dev/USB0 permission check - good, even chmoded 777&chown on rc.local. -cable check: thought txd was broken, but wasnt. checked from linux with a led stuck to the txd end of the jack, echo "whatever" > /dev/ttyUSB0, led did flash. -chances i put are: osmocom dependent on some specific C123 firmware? some kind of hidden compilation complication? some kind of ftdi eeprom config/bitrate/parity config missing for osmocom? I hope i have managed to be concise enough. Great work guys. Greatings from portugal, Filipe RC -------------- next part -------------- An HTML attachment was scrubbed... URL: