baseband-devel July 2010

baseband-devel@lists.osmocom.org

11 participants
17 discussions

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

20 Jul '12

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

2 5

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

15 Mar '12

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

8 17

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

26 Jan '11

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

6 10

Wanted: Osmocom logo
by Harald Welte 24 Aug '10

24 Aug '10

Hi! It's about time that we find some kind of graphical project logo for the Osmocom project. Osmocom is intended as an umbrella project for software like OpenBSC, OsmoSGSN, OsmocomBB and others. So it might even be interesting to have some kind of 'family' of logos that all have the same general theme.... At least the bigger projects like OpenBSC and OsmocomBB definitely deserve their own incarnation within that family. If you want to contribute to our project but are not a die-hard C developer, this is your option to contribute! The logo must be under a license that permits use+modification for the Osmocom project itself. Editability for the general public is not important. With regard to formats, I would prefer something as SVG that we can then render into pngs of various sizes whenever there is demand for it. If you have a proposal, simply send it (or a link to a URL) to the openbsc(a)lists.gnumonks.org mailing list. Thanks in advance for any submissions! -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

5 5

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

04 Aug '10

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

3 4

OsmocomBB, Problem , prospects discussed.. with Mr. Spaar..
by Dev Purohit 01 Aug '10

01 Aug '10

>Do you already have experience with Osmocom and tried it >with a phone ? No i haven't , tried Osmocom with a phone yet, i have C139 and C117 available, once i tried but it reach up to downloading finish (of binary in firmware folder). after that it keeps in that state for quite some time and shows download NACK after wards, something went wrong , then operation aborted. i tried many times with it. As i don't have much experience with HDLC or serial communication to UART, some binary files even do not download completely and receive FMTOOL abort.. while downloading I'm using prolific USB serial DATA cable ( seems very noisy) but no choice as my notebook doesn't have a serial port :-( I'm thinking to assemble new PC though. I need you kind suggestions in this regard. >What exactly do you want to do ? Only receive voice traffic ? >You want to switch to an ARFCN and timelslot and listen to >the voice traffic ? Of course this only works if the channel >is not encrypted or you have Kc for decryption. Yet again if i'm able to run the code and even able to interact using L2/3 or osmoload with phone i don't know how to use phones analogue BaseBand ( ADC) and download the fetched raw data after ( (of desired ARFCN n TS) to host PC and save it in *.cfile format or MatLab( simulink) supported format , if i'm able to do up to this extent i'm pretty sure i can convert it into Voice as i'm reasonably sound with MatLab... Of course , the TCH/F should be without encryption, but i will create a interface in MatLab codes to supply Kc , if available, for future use. ( for digital BB processing ) >What about frequency hopping ? Without knowing the hopping > sequence its not possible to follow a hopping channel. Though i'm not die -hard with C or C++ , but rather fine. have previous understanding for implementing frequency hopping in ISM band, have seen protocol analysis using wireshark we can can easily extract hopping sequence and and chase it , big problem is not to tune PLL synthesizer, but Time slot. and collecting the buffered data for processing , for this i have clear vision, i will share my source codes with you once finish my work.

2 1

Re: OsmocomBB, Problem , prospects discussed.. with Mr. Spaar..
by Dieter Spaar 31 Jul '10

31 Jul '10

Hello Dev, On Sat, 31 Jul 2010 04:21:57 -0700 (PDT), "Dev Purohit" <devpurohit19(a)yahoo.com> wrote: > Yet again if i'm able to run the code and even able to interact using > L2/3 or osmoload with phone i don't know how to use phones analogue > BaseBand ( ADC) and download the fetched raw data after ((of desired ARFCN > n TS) to host PC and save it in *.cfile format or MatLab( simulink) > supported format , if i'm able to do up to this extent i'm pretty sure i > can convert it into Voice as i'm reasonably sound with MatLab... The DSP does not directly deliver the raw ADC samples. You can get them with some tricks but this won't help much because the UART is not fast enough to transfer them continuously to the PC. As far as I know Sylvain is trying to get the demodulated raw data bits out of the DSP, he can tell you better about his progress. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Some refactoring proposals
by Sylvain Munaut 29 Jul '10

29 Jul '10

Here's a few refactoring proposal that I'd like to get done. But before I invest too much time in them I'd like to be sure there are no objections ... (I hate implementing stuff for nothing). * Split layer23/src into - common: what makes liblayer23, purely generic stuff that needs binding together to define an app - mobile: The real complete mobile application - misc: The test applications and their support code layer23 (which I'd rename bcch_dump since that's what it does), echo_test, bcch_scan) * Move away from dispatching L1CTL message using signals ... Only L1CTL works like that and I just can't figure out why ... we read the l1ctl messages just to move their data into another structure to redispatch them to a handler ... l1ctl.c should just contain: - The l1ctl_tx_XXX primitives - A function for the 'application' to register it's own handler for L1CTL messages. - The rx call back to be called by lower layer when a l1ctl frame is received. This one would get the frame, set the hdr pointers, do basic checks, possibly allow signal dipatching for the RESET signal (which is kinda special), and then just hand the frame to the registered handler. * Split lapdm.c : Currently it contains lapdm code and RSLms. They should be split and lapdm code should not be tied to a specific usage but be 'instantiated'/configured in each app as they see fit. Some app might need to track more than 2 lapdm channels ... - lapdm.c would be in common/ (more like an utility lapdm library than 'business' code) - rslms.c would probably be in mobile/ * Rework the app in misc/ to remove the over-engineered bits. It's clear from the sources that layer23 intended to become the full featured phone and as such, is split in a bunch of elements for ... not much in the end since Jolly restarted from scratch, splitting better. So I'd like to simplify as much as possible those apps while still separating 'utilities' function (like dump_bcch) to allow re-use between them. Theses are only the first few steps. My goal is to make it more easy to write small test applications and to clearly separate that from the full featured / layered mobile implementation while still sharing the relevant 'library type' code. Cheers, Sylvain

3 6

AW: Some refactoring proposals
by Andreas.Eversberg 28 Jul '10

28 Jul '10

surely i agree! (as i noted in my last mail) -----Ursprüngliche Nachricht----- Von: Harald Welte [mailto:laforge@gnumonks.org] Gesendet: Mittwoch, 28. Juli 2010 09:17 An: Sylvain Munaut Cc: baseband-devel; Andreas.Eversberg Betreff: Re: Some refactoring proposals On Tue, Jul 27, 2010 at 09:02:02PM +0200, Sylvain Munaut wrote: > Hi, > > >> * Split layer23/src into > >> - common: what makes liblayer23, purely generic stuff that needs > >> binding together to define an app > >> - mobile: The real complete mobile application > >> - misc: The test applications and their support code layer23 (which > >> I'd rename bcch_dump since that's what it does), echo_test, bcch_scan) > > > > Sounds fine with me. If Andreas doesn't mind, I'm happy to merge a branch > > containing this split > > Ok, this is done. It's waiting in my pending branch with a bunch of > other fixes. It requires a libosmocore update as well. I'll wait for some feedback from Andreas. If he either agrees or doesn't care, then I'll merge it. > (I moved a func to libosmocore, which required to update it, which > bringed the msgb checks, which broke the target build and required > fixing, it also showed some bugs in fw and layer23 code that required > fixing as well ...) I've merged your pending libosmocore changes to libosmocore.git master. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

AW: Some refactoring proposals
by Andreas.Eversberg 28 Jul '10

28 Jul '10

>> Here's a few refactoring proposal that I'd like to get done. But >> before I invest too much time in them I'd like to be sure there are no >> objections ... (I hate implementing stuff for nothing). >> >> * Split layer23/src into >> - common: what makes liblayer23, purely generic stuff that needs >> binding together to define an app >> - mobile: The real complete mobile application >> - misc: The test applications and their support code layer23 (which >> I'd rename bcch_dump since that's what it does), echo_test, bcch_scan) > > Sounds fine with me. If Andreas doesn't mind, I'm happy to merge a branch > containing this split i don't mind!

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel July 2010