baseband-devel

baseband-devel@lists.osmocom.org

1982 discussions

by Dieter Spaar

Hello, here is some information about the current status of traffic channel support in Layer-1: - first of all its not yet complete and considered "alpha" because there are some stability problems which have to be solved and some further enhancments for a more general approach are needed. - What works: Signalling (FACCH/SACCH) for a Full Rate Traffic channel and voice (Full Rate or Enhanced Full Rate Codec). - TODO: The Layer-1 API has to be extended to allow switching the channel mode (e.g. Signalling only) or the Voice Codec. Also turning the audio path on and off is needed. - TODO: The Rx/Tx TPU Window has been modified to support Rx and Tx operation in the same frame. This always happens for a Traffic Channel but can sometimes also happen for other channels. For those cases its necessary that the Tx TPU Window is set differently. Some sort of state information that Rx is happening in the same frame has to be implemented, this currently only works for traffic channels. If you want to try it out you have to use the "dieter/tch_f" branch for Layer-1 and the Master branch for Layer-23 from Andreas (really great work, Andreas). With this combination you can use it with OpenBSC. Some minor adjustment is needed: The Layer-1 code currently sets the voice Codec to "Full Rate", however OpenBSC expects "Enhanced Full Rate" You either have to modify OpenBSC to set "Full Rate" or change "TCH_FS_MODE" to "TCH_EFR_MODE" in "layer1/prim_rx_nb.c", there is only one line which has to be changed. What you can do now is a MOC/MTC between OsmocomBB and another phone. Sometimes it can happen that the firmware hangs, you have to restart the phone in this case. However if you have a connected call, its working pretty good (one of the test calls was over 20 minutes). Maybe Andreas can give a short introduction how to use Layer-23 for this, I am not sure if there is some information in the Wiki yet. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

15 years

Who would attend a developer room / meeting at FrOSCon ?

by Harald Welte

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)

15 years

Re: Wanted: Osmocom logo

by Steve Markgraf

Hi, On 02.08.2010 14:36, Sylvain Munaut wrote: > A nice typo with just 'osmocom' and a free space to put the suffix > ('bb' 'sgsn' ...) either in another typo or just using the bold face > and then just some _discrete_ graphical element added to the typo ... > > But IMHO certainly not some complex graphical only element. Ack, that's what I'd suggest as well, something clean and simple. So here's my RFC: I've taken the wireless symbol Kevin posted, and added a lettering. The font used is "Yanone Kaffeesatz" [1], which is licensed under the Open Font License. I attached osmocom_inkscape.svg, for which you need to have the font installed, and can then play around and edit the text, and a "object-to-path" converted osmocom_paths.svg, which is just a plain vector graphic. If anyone has an idea how to decently make the difference between osmocomBB and BSC more clear, or even has a completely different idea, let us hear/see them :) Regards, Steve [1] http://www.yanone.de/typedesign/kaffeesatz/

15 years, 1 month

Re: OsmocomBB, Problem , prospects discussed

by Dev Purohit

Hello Peter, >Please reconsider this position. "once finished" is way too late to be useful, unless you plan on creating a product that you will sell. If you want cooperation and feedback from the community then I rather strongly suggest sharing source code immediately when you start the >work. Thanks you for your concerns, But as i have clearly mentioned that i have implemented Frequency Hoping, on DATA communication device ( telemetry on ISM Band) and Hardware Platform ,communication schemes , protocols and modulation technique were very different, so source can't be integrated with OsmocomBB at this stage , even patching also not that easy i estimated, and most difficult thing is i have very limited knowledge of G.S.M , my mostly time is consuming to study specifications .. Ohh, very lengthy subject.. anyways , I'm trying to deploy for cyclic FH first , choosing right algorithm. i have no problem or commercial value for sharing my work with great people , but it at least relevant and use full to this project. I'm neither developing any equipment not planning to sell it.. MatLab is simulation platform and codes cant be implemented in real-time or live environment, also it support TI DSP's long range. so we can debug change to C header after wards. Kind regards, Dev --- On Sun, 8/1/10, baseband-devel-request(a)lists.osmocom.org <baseband-devel-request(a)lists.osmocom.org> wrote: From: baseband-devel-request(a)lists.osmocom.org <baseband-devel-request(a)lists.osmocom.org> Subject: baseband-devel Digest, Vol 7, Issue 1 To: baseband-devel(a)lists.osmocom.org Date: Sunday, August 1, 2010, 10:00 AM Send baseband-devel mailing list submissions to baseband-devel(a)lists.osmocom.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/baseband-devel or, via email, send a message with subject or body 'help' to baseband-devel-request(a)lists.osmocom.org You can reach the person managing the list at baseband-devel-owner(a)lists.osmocom.org When replying, please edit your Subject line so it is more specific than "Re: Contents of baseband-devel digest..." Today's Topics: 1. OsmocomBB, Problem , prospects discussed.. with Mr. Spaar.. (Dev Purohit) 2. Re: OsmocomBB, Problem , prospects discussed.. with Mr. Spaar.. (Dieter Spaar) 3. Re: OsmocomBB, Problem , prospects discussed.. with Mr. Spaar.. (Peter Stuge) _______________________________________________ baseband-devel mailing list baseband-devel(a)lists.osmocom.org https://lists.osmocom.org/mailman/listinfo/baseband-devel

15 years, 1 month

sorry, my e-mail got hacked...

by Lubomir Schmidt

sorry for the spam mails. My e-mail got hacked...

15 years, 1 month

[ANNOUNCE] planet.osmocom.org

by Harald Welte

Hi! We now have a planet (RSS feed aggregator) for the Osmcoom project, it's running at http://planet.osmocom.org/ Please let me know if you think I should add any feeds to it. There is no strict requirement for contributions to the Osmocom project, but it should be technical and related to protocols / hacking / development of mobile telephony systems. 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)

15 years, 1 month

OsmocomBB, Problem , prospects discussed.. with Mr. Spaar..

by Dev Purohit

>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.

15 years, 1 month

Re: OsmocomBB, Problem , prospects discussed.. with Mr. Spaar..

by Dieter Spaar

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

15 years, 1 month

Some refactoring proposals

by Sylvain Munaut

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

15 years, 1 month

AW: Some refactoring proposals

by Andreas.Eversberg

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)

15 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel