From laforge at gnumonks.org Wed Sep 1 21:41:45 2010 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 1 Sep 2010 23:41:45 +0200 Subject: assignment command / status of RR In-Reply-To: References: Message-ID: <20100901214145.GI6802@prithivi.gnumonks.org> Dear Andreas, sorry once again for my overly delayed answers. Time has been flying by, and many tasks have always pre-empted (personal/family related issues, paid work, now some new GPL legal case drawing a lot of my attention, ...) On Mon, Aug 16, 2010 at 09:55:39AM +0200, Andreas.Eversberg wrote: > as you can see in the git log, i checked in the "ASSIGNMENT COMMAND" > processing. it modifies timeslot, subslot, and hopping sequence. this is > required when the network assigns an SDCCH before the actual TCH is > allocated: after receiving the "ASSIGNMENT COMMAND", the layer2 is > release locally (without sending anything), the dedicated mode is > released and established with a new parameters (e.g. TCH/F), and the > layer2 is established again, finally the "ASSIGNMENT COMPLETE" is sent > to the network. this process is incomplete, but it should work in most > cases. (no "starting time" processing). this is (as usual) great news. As part of my paid work I have to add support for live frequency changes into OpenBSC anyway. This means the OML, RSL and 04.08 messages for changing the ARFCN of a given TRX will all be synchronized by the same 'starting time' parameters. I have no clue how well commercial GSM stacks in mobile phones implement this feature, as a frequency plan change is something that happens so rare in a regular network that you can probably afford to drop some calls once you do it. Once that work on OpenBSC is finished (I cannot provide a schedule yet), we will be able to test the OsmocomBB side. > in my local copy of the git, i already completed the assignment process. > additionally "FREQUENCY REDEFINITION" is completed, "IMMEDIATE > ASSIGNMENT" supports "starting time", MDL-error processing is added, and > "HANDOVER COMMAND" parsing is done. the handover process is not > completed, because it depends on unimplemented layer1 features, like > RX-only channels or "4 successive HANDOVER ACCESS bursts on DCCH". > except the handover process, the RR protocol for basic phone calls is > complete now. once again, great news. handover support is important in the mid to long term, but I think lots of other issues have a higher priority now (like SIM card support, encryption, as well as reliable TS4..7 support) > before i can check it in, it depends on two things. first, there are > additional messages to be defined in osmocore: > "[osmocore] Adding handover and frequency redefiniton message headers" > http://home.eversberg.eu/osmocore.patch I've finally committed that to libosmocore.git > second, it depends on "starting time" support for layer1: > http://home.eversberg.eu/modify.patch > it adds a L1CTL message to store modified frequency allocations (ma, > ma_len, HSN, MAIO, TSC) for hopping and a "starting time". this starting > time is the frame number at which the modified frequencies are used. if > the frame number lies in the past, the new modified frequencies are used > after the L1CTL message is received. > sylvain already noted, that the event of "starting time" should be > triggered by the scheduler. since i don't know how the scheduler exactly > works, i would ask someone to change my patch. note that the dedicated > mode can be released before the "starting time" elapses. I'm sorry but I don't really think I'll have time to dig into this and modify your patch anytime soon (in fact, I fear not throughout the next 2-3 months). Using the scheduler should be relatively easy, you can simply call sched_gsmtime() and provide it a framenumber and a 'tdma_sched_item'. the latter will contain the callback that is to be called once the current framenumber will reach 'fn' as specified. I think that should be fairly straight-forward for you to try by yourself. After it works, feel free to commit it to master. 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 Andreas.Eversberg at versatel.de Tue Sep 7 11:54:01 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Tue, 7 Sep 2010 13:54:01 +0200 Subject: AW: assignment command / status of RR Message-ID: > Using the scheduler should be relatively easy, you can simply call > sched_gsmtime() and provide it a framenumber and a 'tdma_sched_item'. the > latter will contain the callback that is to be called once the current > framenumber will reach 'fn' as specified. what if there is already a scheduled item? in this case i must schedule the frequency change item before any other item. also the frame number of frequency change may be more than 255 frames ahead. my suggestion: because hopping sequence is a function of time, the starting time should also be included in this function (rfch.c). From 246tnt at gmail.com Tue Sep 7 12:09:32 2010 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Tue, 07 Sep 2010 12:09:32 +0000 Subject: AW: assignment command / status of RR In-Reply-To: Message-ID: <00c09fc2bd080dccd1048faa451a@google.com> > what if there is already a scheduled item? in this case i must schedule > the frequency change item before any other item. also the frame number > of frequency change may be more than 255 frames ahead. Feel free to extend the scheduler to fit your needs. > my suggestion: because hopping sequence is a function of time, the > starting time should also be included in this function (rfch.c). The only function in rfch.c returns the parameter for a given time. It does _NOT_ and should _NOT_ make any change to the parameter itself. That's left up to the caller because we need to call that function several time. If you want to introduce some call that configure the channel and make changes and stuff, put it into another function and make sure it's called when required. Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Eversberg at versatel.de Tue Sep 7 14:41:20 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Tue, 7 Sep 2010 16:41:20 +0200 Subject: AW: AW: assignment command / status of RR Message-ID: > The only function in rfch.c returns the parameter for a given time. > It does _NOT_ and should _NOT_ make any change to the parameter itself. > That's left up to the caller because we need to call that function several time. > If you want to introduce some call that configure the channel and make changes and stuff, put it into another function and make sure it's called when required. then i would suggest to expand the scheduling thing. i will see how complex that would be... From Andreas.Eversberg at versatel.de Wed Sep 8 08:29:08 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Wed, 8 Sep 2010 10:29:08 +0200 Subject: AW: AW: assignment command / status of RR Message-ID: > then i would suggest to expand the scheduling thing. i will see how > complex that would be... ok, i see that there is also a "one shot" scheduler with full frame number range. (sched_gsmtime.c) i think that i can use this to modify the current channel set. i have code to test it. i don't know if the callback function of the scheduled event is called before or after the actual transmission/reception of the burst, which also sets the right frequency. even if not, there will be only one frame lost. From 246tnt at gmail.com Wed Sep 8 08:43:25 2010 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Wed, 08 Sep 2010 08:43:25 +0000 Subject: AW: AW: assignment command / status of RR In-Reply-To: Message-ID: <0015174c4122c9b8b2048fbb819f@google.com> Hi, > ok, i see that there is also a "one shot" scheduler with full frame > number range. (sched_gsmtime.c) i think that i can use this to modify > the current channel set. i have code to test it. Yes, I'm pretty sure that's the one I pointed you to. That's the one used for RACH scheduling as well. > i don't know if the > callback function of the scheduled event is called before or after the > actual transmission/reception of the burst, which also sets the right > frequency. even if not, there will be only one frame lost. It's undefined I think. Because the one-shot scheduler will push it's event in the same pool as the other events once in range. But a priority associated with each task would be useful. Something like: -1 Before any burst 0...7 Timeslot (so that task can be scheduled in order of timeslot, would allow sdcch [4..7] ) 8 After all bursts Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwjohn0 at gmail.com Wed Sep 1 05:53:42 2010 From: jwjohn0 at gmail.com (John Wu) Date: Wed, 1 Sep 2010 13:53:42 +0800 Subject: Hi all, why osmocombb need Ti Calypso/Iota/Rita GSM baseband chipset Message-ID: Hi all, from what i learned, osmocombb provide gsm protocol stack and dsp signal process code. So why need to use Ti Calypso/Iota/Rita. Is it possible to run on other common arm7+dsp chipset? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwjohn0 at gmail.com Wed Sep 1 07:21:30 2010 From: jwjohn0 at gmail.com (John Wu) Date: Wed, 1 Sep 2010 15:21:30 +0800 Subject: Hi all, why osmocombb need Ti Calypso/Iota/Rita GSM baseband chipset In-Reply-To: References: Message-ID: Hi all, from what i learned, osmocombb provide gsm protocol stack and dsp signal process code. So why need to use Ti Calypso/Iota/Rita. Is it possible to run on other common arm7+dsp chipset? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwjohn0 at gmail.com Wed Sep 1 07:24:14 2010 From: jwjohn0 at gmail.com (John Wu) Date: Wed, 1 Sep 2010 15:24:14 +0800 Subject: Hi all, why osmocombb need Ti Calypso/Iota/Rita GSM baseband chipset In-Reply-To: References: Message-ID: Hi all, from what i learned, osmocombb provide gsm protocol stack and dsp signal process code. So why need to use Ti Calypso/Iota/Rita. Is it possible to run on other common arm7+dsp chipset? -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Wed Sep 1 08:18:00 2010 From: 246tnt at gmail.com (246tnt at gmail.com) Date: Wed, 01 Sep 2010 08:18:00 +0000 Subject: Hi all, why osmocombb need Ti Calypso/Iota/Rita GSM baseband chipset In-Reply-To: Message-ID: <001517503bc4f240ab048f2e55c2@google.com> On Sep 1, 2010 9:24am, John Wu wrote: > Hi all, from what i learned, osmocombb provide gsm protocol stack True > and dsp signal process code. False. Osmocom-bb doesn't have demodulation or dsp code. It contains dsp drivers to control the calypso DSP stuff. > So why need to use Ti Calypso/Iota/Rita. Is it possible to run on other > common arm7+dsp chipset? See above. All the DSP code, as well as all the dirty details about timing / rf path configuration / dsp stuff is completely calypso specific. If you wanted to support another one, it's possible. But you'd have to write the equivalent of all the "target" code for your target and it would talk to the l23 stuff using our l1ctl protocol. Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej.grela at gmail.com Wed Sep 1 08:22:33 2010 From: maciej.grela at gmail.com (Maciej Grela) Date: Wed, 1 Sep 2010 10:21:33 +0159 Subject: Hi all, why osmocombb need Ti Calypso/Iota/Rita GSM baseband chipset In-Reply-To: References: Message-ID: 2010/9/1 John Wu : > Hi all, from what i learned, osmocombb provide gsm protocol stack and dsp > signal process code. > So why need to use Ti Calypso/Iota/Rita. Is it possible to run on other > common arm7+dsp chipset? > Because a board designed from scratch would cost a 100 euros and a Calypso phone can be bought for 5. Best regards, Maciej Grela From lists at infosecurity.ch Fri Sep 3 10:35:01 2010 From: lists at infosecurity.ch (Fabio Pietrosanti (naif)) Date: Fri, 03 Sep 2010 12:35:01 +0200 Subject: osmocom with USRP1 as a sw-only MS? Message-ID: <4C80CF55.3070006@infosecurity.ch> Hi all, after some days digging into the various tools around the GSM opensource playground arena i started understanding better the various piece of software. It seems to me that there's a net separation between the GSM implementation stack of OpenBTS and Osmocom, also because the projects are born with different goals. With the current bb implementation of Osmocom inside Calypso based baseband processor of motorola, all the DSP logic is done directly by the mobile phones chip, right? Which with OpenBTS, it's OpenBTS itself that does the modulation/demodulation along with the USRP. Is there some project and or ideas to bring together the DSP codebase of OpenBTS, together with OsmocomBB to make a MS terminal based on USRP1 device with RFX900 boards? Fabio From 246tnt at gmail.com Fri Sep 3 12:09:20 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 3 Sep 2010 14:09:20 +0200 Subject: osmocom with USRP1 as a sw-only MS? In-Reply-To: <4C80CF55.3070006@infosecurity.ch> References: <4C80CF55.3070006@infosecurity.ch> Message-ID: > With the current bb implementation of Osmocom inside Calypso based > baseband processor of motorola, all the DSP logic is done directly by > the mobile phones chip, right? Yes > Which with OpenBTS, it's OpenBTS itself that does the > modulation/demodulation along with the USRP. Yes, > Is there some project and or ideas to bring together the DSP codebase of > OpenBTS, together with OsmocomBB to make a MS terminal based on USRP1 > device with RFX900 boards? Idea, yes sure. It's obvious that it would be useful and has been mentioned several time. But there is no active project AFAIK. It's far from trivial both because openbts code is meant to be the clock master and because there is a bunch of part that are just missing to do the link. (essentially the whole layer1.bin of osmocom-bb). There aren't _that_ many active developers in the GSM projects and they're all pretty busy. But if you either have : - The time and expertise to do it yourself or - The budget to finance a full (or part) time developer to work on that then by all mean go ahead. Cheers, Sylvain From 246tnt at gmail.com Tue Sep 14 11:33:59 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 14 Sep 2010 13:33:59 +0200 Subject: osmocom with USRP1 as a sw-only MS? In-Reply-To: <20100911174927.GA58019@thre.at> References: <4C80CF55.3070006@infosecurity.ch> <20100911174927.GA58019@thre.at> Message-ID: Hi, > What's the easiest way to list out the API for layer1.bin? (I can start > searching through the code myself but I thought I would ask first.) See include/l1ctl_proto.h But it's a pretty high level: things like - Go camp on the bcch/ccch - Open a dedicated channel with those parameters - Send this L2 frame ... PS: Make sure to answer to the list and not me. Sylvain From Andreas.Eversberg at versatel.de Thu Sep 16 10:41:57 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Thu, 16 Sep 2010 12:41:57 +0200 Subject: interface for measurement reports Message-ID: hi, i like to add layer1 control for measurement reports. my idea is use use normal L1CTL_DATA_REQ with SACCH channel type for sending the (updated) report to layer1. the protocol and message type will be decoded by layer1, so it can detect if this is a measurement report or not. if it is a measurement report, it will overwrite the last stored measuement report. it will be sent whenever there is no other SACCH message in the queue of SACCH messages. if it is not a measurement report, it will be queued as usual. any better idea? andreas From laforge at gnumonks.org Thu Sep 16 20:11:33 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 16 Sep 2010 22:11:33 +0200 Subject: interface for measurement reports In-Reply-To: References: Message-ID: <20100916201133.GU3646@prithivi.gnumonks.org> Hi Andreas, > i like to add layer1 control for measurement reports. my idea is use use > normal L1CTL_DATA_REQ with SACCH channel type for sending the (updated) > report to layer1. > > the protocol and message type will be decoded by layer1, so it can > detect if this is a measurement report or not. if it is a measurement > report, it will overwrite the last stored measuement report. it will be > sent whenever there is no other SACCH message in the queue of SACCH > messages. if it is not a measurement report, it will be queued as usual. I think this approach makes a lot of sense. Thanks! -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From 246tnt at gmail.com Thu Sep 16 11:13:38 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Thu, 16 Sep 2010 13:13:38 +0200 Subject: Some L1 updates Message-ID: Hi, In my sylvain/testing branch, there a a few interesting changes: * Priority support for items in a scheduler bucket Basically for each sched_item, there is a now a priority field and they are executed in order. This allows for example to ensure that a scheduled freq change is executed before accesing the L1 parameters, or to make sure that a control channel RX is scheduled before a RACH TX ... For new items added into the bucket while executing itself (like the abort), those will obviously not be able to obey the priority and will always be executed afterwards. * Common DSP & TPU Scenario init & end Previously, each primitive _cmd initialized the TPU (with network/offset) to the timeslot and also ended the tpu & dsp scenario. This scheme doesn't work when you have several primitives that have a TPU window to open and/or a dsp scenario to run. (this happens when doing RACH in the same frame as reading a CCCH/BCCH bursts, or in the case of SDCCH8[4:7]). Now, each item specifies via some flags if he has a need for TPU and/or DSP. If one item of the bucket needs it, then the common code will handle. : - Aligning the TPU (via offset/network) to the 'base' timeslot (+3 TX offset still has to be added by the primitive) - Restoring base TPU alignement at the end. - Ending both TPU / DSP scenario when everything is done. * A5 support Andreas actually made L23 support and added a stub l1ctl_ command itself. Dieter and I actually made the L1 work in // and not surprisingly came up with very similar results given it's mainly: . Load the key in DSP API NDB & set the mode. . Set a fn parameter properly at each frame The rest is handled inside the dsp. I will now work on merging Dieter's work into the main branch above what I did. - TOA regulation loop to prevent drifting - TX power control - TCH support Cheers, Sylvain Munaut From Andreas.Eversberg at versatel.de Thu Sep 16 12:18:25 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Thu, 16 Sep 2010 14:18:25 +0200 Subject: AW: Some L1 updates Message-ID: really great work! i will check and play with it this weekend. looks like osmocom is getting to a state where it is "usable" very soon. andreas From laforge at gnumonks.org Thu Sep 16 20:23:52 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 16 Sep 2010 22:23:52 +0200 Subject: Some L1 updates In-Reply-To: References: Message-ID: <20100916202351.GV3646@prithivi.gnumonks.org> Sylvain, Dieter, Andreas: It's great to see the kind of progress you guys are making. Congratulations! Unfortuately, for both personal and work reasons, I don't really see me being able to contribute significantly to OsmocomBB throguh at least the next two months. I wish it were different, but there are some priorities. Nonetheless, I will follow your progress and will try to give input as mcuh as I can on this mailinglist. Sylvain: Feel free to commit your stuff to master once you are confident about it. No need for waiting for me to review every line. My main objective with regard to the code in master is: * it should be one commit per feature * we should not try to introduce new 'hacks' but rather remove old ones by proper code * Linux kernel coding style must be followed closely Happy coding, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From Andreas.Eversberg at versatel.de Fri Sep 17 10:34:38 2010 From: Andreas.Eversberg at versatel.de (Andreas.Eversberg) Date: Fri, 17 Sep 2010 12:34:38 +0200 Subject: AW: Some L1 updates Message-ID: > * we should not try to introduce new 'hacks' but rather remove old > ones by proper code hi harald, if you sync the osmocore of osmocom-bb, i could remove some "#warning"s due to unavailable structures: struct gsm48_frq_redef struct gsm48_ho_cpl struct gsm48_ho_fail regards, andreas From 246tnt at gmail.com Fri Sep 17 12:08:42 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 17 Sep 2010 14:08:42 +0200 Subject: Some L1 updates In-Reply-To: References: Message-ID: > if you sync the osmocore of osmocom-bb, i could remove some "#warning"s > due to unavailable structures: I just tried that, unfortunately there has been some "non-target-friendly" code introduced in libosmocore that need to be fixed first :( Looking at it now ... Sylvain From 246tnt at gmail.com Fri Sep 17 12:56:07 2010 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 17 Sep 2010 14:56:07 +0200 Subject: Some L1 updates In-Reply-To: References: Message-ID: >> if you sync the osmocore of osmocom-bb, i could remove some "#warning"s >> due to unavailable structures: > > I just tried that, unfortunately there has been some > "non-target-friendly" code introduced in libosmocore that need to be > fixed first :( Ok, fixed & pushed. Sylvain From fr at gsmk.de Mon Sep 20 13:14:16 2010 From: fr at gsmk.de (Frank Rieger) Date: Mon, 20 Sep 2010 15:14:16 +0200 Subject: job offer in berlin - breaking basebands, write open GSM tools Message-ID: <8229B755-5ED3-4158-A2BE-6464C02411D1@gsmk.de> I have a job offer in my company for a project to research into and build defenses against over-the air attacks breaking current 2G/3G basebands. The location is in Berlin, Germany, starting soon if possible. Remote work arrangements are not an option. The project is solidly financed by a public research grant, the company is nicely profitable for many years now. Requirements are detailed GSM knowledge, very good reverse engineering and at least decent C/C++ coding skills plus ability to work with a small team in english or german language. All research results of the project will be public and large parts of the development aspect will be on improving the open GSM / 3G tools and thus flow back to the community. Working hours are very relaxed, we are looking for someone who really dives into his work and does not just attend it. Mail me off list if you think you fit the profile. Thanks & Greetings from Berlin, Frank Rieger From laforge at gnumonks.org Thu Sep 23 07:56:45 2010 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 23 Sep 2010 09:56:45 +0200 Subject: Suggestions regarding the SIM code Message-ID: <20100923075645.GB22348@prithivi.gnumonks.org> Hi! I just found some time to have a look at the recent commit history and had a look at the SIM related code and had the following suggestions: 1) split the definitions from GSM TS 11.11 into a separate header file from the definitions that are OsmocomBB specific, and move the 11.11 header file into libosmocore 2) use msgb's for SIM messages. This way we can avoid all those manual buffer[N] = M type assignments and rather use msgb_put() constructs 3) even if not going for suggestion '2', it might be good to add some kind of a inline function abstracting out all the blocks that look like + buffer[0] = GSM1111_CLASS_GSM; + buffer[1] = GSM1111_INST_TERMINAL_PROFILE; + buffer[2] = 0x00; + buffer[3] = 0x00; + buffer[4] = length; with something like a "sim_buf_init(buffer, GSM11_INST_TERMINAL_PROFILE);" Of course those are simply suggestions... maybe for the day where somebody on this list is feeling bored and is looking for a quick and easy task to resolve. 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 arback at gmail.com Fri Sep 24 08:27:12 2010 From: arback at gmail.com (Andrew Back) Date: Fri, 24 Sep 2010 09:27:12 +0100 Subject: Presenting at event. Message-ID: <20100924082712.GC3359@mosschops.osmosoft.com> Hello, I'm involved with an open source hardware user group based in London: http://oshug.org Our next meeting is on Thursday 21st October and for which the theme is radio. We have one confirmed speaker who will be presenting on OpenHPSDR, and wondered if there might be someone around London at that time who might be willing to do a presentation on OsmocomBB and/or OpenBSC. For more info on OSHUG see the website for details of previous talks and photos and video. Regards, Andrew -- Andrew Back mailto:arback at gmail.com From technosabby at gmail.com Wed Sep 29 22:34:31 2010 From: technosabby at gmail.com (Marten Christophe) Date: Wed, 29 Sep 2010 22:34:31 +0000 Subject: OsmocomBB.TCH. Message-ID: Hello, Thanks u all this gr8.. work .. forgive me for my little novice question.. most probably goes to Mr. Deiter.. but any one from list be kind enough help me from list.. I'm pretty new to Osmocombb i made a setup as advised on *Sun, 01 Aug 2010* blog. with hp8922. ===Q=== " You just "tune" to the right ARFCN and time slot (I don't use hopping during testing) and see that you get your code running." ===UQ== Q.1) i learned from wiki how to change ARFCN from Layer on application by using below command, but how to tune right TS ? ./layer23 -a 871 -i 127.0.0.1 Q.2) even If OsmocomBB Layer1 CTL is able to tune to right ARFCN and Time Slot, will i be able to listen what so ever broadcasting from HP8922 from C123 speaker or PC speaker. non-encrypted, debugging non-hopping) Q.3) what command and interface will be used to enter the frequency hoping parameter, in case i will use FH option? to tune OsmocomBB l1CTL Q.4) How to enter Minimalistic L1 interface, what is interface available to insert theses command to layer1 DEDIC_MODE_EST_REQ , LAYER1_RESET, DEDIC_MODE_DATA_IND thanks , Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From technosabby at gmail.com Wed Sep 29 23:00:44 2010 From: technosabby at gmail.com (Marten Christophe) Date: Wed, 29 Sep 2010 23:00:44 +0000 Subject: OsmocomBB.TCH. In-Reply-To: References: Message-ID: Hello, Thanks u all this gr8.. work .. forgive me for my little novice question.. most probably goes to Mr. Deiter.. but any one from list be kind enough help me from list.. I'm pretty new to Osmocombb i made a setup as advised on *Sun, 01 Aug 2010* blog. with hp8922. ===Q=== " You just "tune" to the right ARFCN and time slot (I don't use hopping during testing) and see that you get your code running." ===UQ== Q.1) i learned from wiki how to change ARFCN from Layer on application by using below command, but how to tune right TS ? ./layer23 -a 871 -i 127.0.0.1 Q.2) even If OsmocomBB Layer1 CTL is able to tune to right ARFCN and Time Slot, will i be able to listen what so ever broadcasting from HP8922 from C123 speaker or PC speaker. non-encrypted, debugging non-hopping) Q.3) what command and interface will be used to enter the frequency hoping parameter, in case i will use FH option? to tune OsmocomBB l1CTL Q.4) How to enter Minimalistic L1 interface, what is interface available to insert theses command to layer1 DEDIC_MODE_EST_REQ , LAYER1_RESET, DEDIC_MODE_DATA_IND thanks , Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From technosabby at gmail.com Wed Sep 29 23:55:24 2010 From: technosabby at gmail.com (Marten Christophe) Date: Wed, 29 Sep 2010 23:55:24 +0000 Subject: Fwd: OsmocomBB.TCH. In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Marten Christophe Date: Wed, Sep 29, 2010 at 11:00 PM Subject: OsmocomBB.TCH. To: baseband-devel at lists.osmocom.org Hello, Thanks u all this gr8.. work .. forgive me for my little novice question.. most probably goes to Mr. Deiter.. but any one from list be kind enough help me from list.. I'm pretty new to Osmocombb i made a setup as advised on *Sun, 01 Aug 2010* blog. with hp8922. ===Q=== " You just "tune" to the right ARFCN and time slot (I don't use hopping during testing) and see that you get your code running." ===UQ== Q.1) i learned from wiki how to change ARFCN from Layer on application by using below command, but how to tune right TS ? ./layer23 -a 871 -i 127.0.0.1 Q.2) even If OsmocomBB Layer1 CTL is able to tune to right ARFCN and Time Slot, will i be able to listen what so ever broadcasting from HP8922 from C123 speaker or PC speaker. non-encrypted, debugging non-hopping) Q.3) what command and interface will be used to enter the frequency hoping parameter, in case i will use FH option? to tune OsmocomBB l1CTL Q.4) How to enter Minimalistic L1 interface, what is interface available to insert theses command to layer1 DEDIC_MODE_EST_REQ , LAYER1_RESET, DEDIC_MODE_DATA_IND thanks , Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From spaar at mirider.augusta.de Thu Sep 30 08:53:44 2010 From: spaar at mirider.augusta.de (Dieter Spaar) Date: Thu, 30 Sep 2010 08:53:44 CEST Subject: OsmocomBB.TCH. Message-ID: <4ca45018.mirider@mirider.augusta.de> Hello Marten, First of all please be aware that OsmocomBB is now in a state where it can be used for voice calls without any special tricks so there is no need to tune on the voice traffic of the HP8922 GSM testset, you can use the GSM testset as a normal basestation. On Wed, 29 Sep 2010 23:00:44 +0000, "Marten Christophe" wrote: > > Q.1) i learned from wiki how to change ARFCN from Layer on application by > using below command, but how to tune right TS ? > > ./layer23 -a 871 -i 127.0.0.1 For my inital TCH testing I did not use Layer23 at all, I only used Layer1 in the phone with special test code using a fixed ARFCN. > Q.2) even If OsmocomBB Layer1 CTL is able to tune to right ARFCN and Time > Slot, will i be able to listen what so ever broadcasting from HP8922 from > C123 speaker or PC speaker. non-encrypted, debugging non-hopping) Yes. > Q.3) what command and interface will be used to enter the frequency hoping > parameter, in case i will use FH option? to tune OsmocomBB l1CTL You have to write your one code if you want to do this without Signalling beeing involved. > Q.4) How to enter Minimalistic L1 interface, what is interface available to > insert theses command to layer1 You can use the L1CTL API to setup a TCH with your own code, but its probably easier to setup the TCH with signalling (either MOC or MTC), this way you don't need to modify the code and still get the TCH running. Best regards, Dieter -- Dieter Spaar, Germany spaar at mirider.augusta.de From technosabby at gmail.com Wed Sep 29 23:04:42 2010 From: technosabby at gmail.com (Marten Christophe) Date: Wed, 29 Sep 2010 23:04:42 +0000 Subject: No subject Message-ID: Hello, Thanks u all this gr8.. work .. forgive me for my little novice question.. most probably goes to Mr. Deiter.. but any one from list be kind enough help me from list.. I'm pretty new to Osmocombb i made a setup as advised on Sun, 01 Aug 2010 blog. with hp8922. ===Q=== " You just "tune" to the right ARFCN and time slot (I don't use hopping during testing) and see that you get your code running." ===UQ== Q.1) i learned from wiki how to change ARFCN from Layer on application by using below command, but how to tune right TS ? ./layer23 -a 871 -i 127.0.0.1 Q.2) even If OsmocomBB Layer1 CTL is able to tune to right ARFCN and Time Slot, will i be able to listen what so ever broadcasting from HP8922 from C123 speaker or PC speaker. non-encrypted, debugging non-hopping) Q.3) what command and interface will be used to enter the frequency hoping parameter, in case i will use FH option? to tune OsmocomBB l1CTL Q.4) How to enter Minimalistic L1 interface, what is interface available to insert theses command to layer1 DEDIC_MODE_EST_REQ , LAYER1_RESET, DEDIC_MODE_DATA_IND thanks , Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: