- baseband-devel - lists.osmocom.org

by Tiago Maluta

Hi, First I'd like to thank all people involved with the project. I don't know about GSM but as Harald said [1] I can contribute with microcontroller development. I have an old functional Motorola C200 phone. I'd like to know if it's possible use it? I've search for some information about C200 baseband processor without success, so I'm asking in the list. [1] http://lists.osmocom.org/pipermail/baseband-devel/2010-February/000000.html --tm

14 years, 2 months

2
4
0 0

Re: [airprobe-main] Cell phone tracking using ss7 hlr lookups

by Karsten Nohl

Hi Yanis, I'm CCing the OsmoconBB list who could perhaps help setup a MSC-GPS data collector. On Feb 22, 2010, at 8:09 PM, Yanis Pavlidis wrote: > Hi all, > > not exactly related to airprobe itself, but I am sure people on this > list could answer my question. > So, after reading Tobias Engels' presentation on 25c3 ( http://events.ccc.de/congress/2008/Fahrplan/attachments/1262_25c3-locating-… > ), I found out you can perform an HLR lookup and come up with the > current MSC number that "controls" the connection of the subscriber, > for any subscriber. Yes, every telco company and VoIP provider with SS7 access in the world always knows where you are. Scary. > My question is, is this MSC number, visible from the mobile phone > side? If yes, somebody could actually wardrive, to get the MSC > number-to-location mapping? > Can airprobe, or OpenBTS help? Creating the {MSC -> location} mapping database would be a very worthwhile exercise. The data collection would have to happen from phones. Either we create an application for one of the popular phone platforms (Symbian, Android, iPhone). Anybody on the list knows if these phones expose the MSC number to application software? Alternative, the Osmocon project could probably expose the MSC information easily. The project is still in early stages and it will take a few months until a collector software could be running. I wonder if any of the supported Motorola phones have GPS? > Forgive my ignorance on all-things-gsm, I am just beginning exploring! Thanks for bringing up the topic! > Thanks all, > Yanis Cheers, -Karsten

14 years, 2 months

5
4
0 0

Where to start?

by Huseyin Turan

Hi; It is really a good work. Congratulations... I hope to develop in this project. Although I do not have any experience about microcontroller development and gsm, I think I can do. I can develop with C or C++. Does anyone suggest me any document, site to start? Thanks...

14 years, 2 months

1
0
0 0

some links for Nokia N95

by Benjamin Hagemann

Hello together, I have collected some informations / links for Nokia N95 and similar topics. Maybe some of them are good enough for the wiki. http://www.nokiaport.de/n95info/?id=processor http://www.nokiaport.de/n95info/?id=pcb http://www.phonewreck.com/wiki/index.php?title=Nokia_N95#Bill_of_Materials RF Transceiver: STMicroelectronics #4380206 Quad-band GSM/GPRS/EDGE, Dual-band UMTS/HSPDA (Unmarked) http://www.phonewreck.com/wiki/images/thumb/8/85/Nokia_N95_pcb_back.jpg/800… http://www.phonewreck.com/wiki/images/thumb/4/4b/Nokia_N95_pcb_front.jpg/80… http://www2.electronicproducts.com/Nokia_N95-whatsinside_text-61.aspx "Under the Hood: Hot 3G phone owes debt to analog" http://www.eetimes.com/showArticle.jhtml?articleID=202800251 http://i.cmpnet.com/eet/news/07/10/DC1500_UTH_1_PG_36.gif Nokia disassembly (Nokia N Gage, N96, N95 8GB, N95, N85, N82, N81 8GB, N80, E90, E71, http://www.gsm-extreme.net/showthread.php?t=25493 OMAP2420 -> ARM11, TMS320C55x DSP, ... http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=dsp&sectio… http://focus.ti.com/docs/prod/folders/print/tms320c55.html # Improving 32-Channel DTMF Decoders in PBX Systems Using the TMS320C5x DSP (HTM, 8 KB) 486 views 01 Jun 1996 Read Abstract http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumbe… # Use of the TMS320C5x Internal Oscillator With External Crystals or Resonators (HTM, 8 KB) 404 views 01 Jul 1995 Read Abstract http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumbe… http://focus.ti.com/dsp/docs/dspfindtoolswresults.tsp?sectionId=3&tabId=162… DSP/BIOS 5.x Real-Time Operating System DSPBIOS5 LANsEND LANsEnd uCLinux LEOs® (Linux Embedded Operating System) OSEck http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/index.ht… http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dspbios/… http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dspbios/… http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.85.1703&rep=rep1&t… Trends in Hardware Architecture for Mobile Devices Dr. Margarita Esponda Institut für Informatik Freie Universität Berlin Takustr. 9 14195 Berlin November 2004 Page 11: 2.3 Modern DSP Architectures 2.3.1 The TMS320C55 series Page 13: 2.3.2 The TigerSHARK Architecture Page 14: 3 Moving from voice to data centric systems 3.1 Hybrid Processors http://pdf1.alldatasheet.com/datasheet-pdf/view/29043/TI/TMS320C50.html TCS Modem http://www.worldlogic.com.hk/tcs_versions.html http://en.wikipedia.org/wiki/Base_Band_5 Nokia BB5 General information ;) http://forum.gsmhosting.com/vbb/showthread.php?s=34c3b939b47546c9d6c523bb36… Nokia SIM Lock Server (SL-1, SL-2, SL-3) http://www.nokiaport.de/index.php?mid=&pid=dct http://www.nokiaport.de/forum/thread.php?threadid=4666&sid=cf6be43b2f93404b… "Added support for RAPIDO SL_2 based models (al phones who is unlocked by credits with DK, MT, UB)" http://www.gsm-forum.eu/latest-files-shared-nokia/28691-nokia-free-unlock-r… http://www.gsm2back.com/2009/04/hot-free-unlock-rapido-bb5-plus.html http://www.mygsmbd.com/bb5-nokia-base-band-5/914-bb5-contact-service-trun-o… http://www.gsmchevli.com/support/ http://www.gsmchevli.com/support/BANDLOCK/ http://www.gsmchevli.com/support/BB5PM/N95-1/ -- kind regards, Benny gpg 0xFC505AB0 jabber benny(a)benny.de sip benny(a)benny.de

14 years, 2 months

2
2
0 0

AW: Phone acting as a BTS

by Andreas.Eversberg

>> But I guess you can use two MSs, one for transmit and one for receive to >> overcome this limitation. Is there any problems with this approach other >> then good clock synchronization? > >You need a very good clock sync :) But that's something that could be >tried I guess. maybe.. you could sync the "receiver phone" to the "transmitter phone" by using one timeslot. (TS7) or you could sync the receiver phone to a nearby bts and use a control line on the serial link to sync the transmitter phone to the receiver phone. (you need to cross-connect the serial ports on the phones for signalling anyway.) andreas

14 years, 2 months

1
0
0 0

Re: Phone acting as a BTS

by Sylvain Munaut

> But I guess you can use two MSs, one for transmit and one for receive to > overcome this limitation. Is there any problems with this approach other > then good clock synchronization? You need a very good clock sync :) But that's something that could be tried I guess. > PS Looking at pictures of ip.access Nanostation we didn't find any duplexers. > How does it work then? Or have we just missed duplexers on the photos? Nope, no duplexers. There is a TX antenna and a RX antenna. I think they are patch antenna that don't radiate sideways so that they don't leak into one another. There is also a massive chunk of metal between them to isolate :) Sylvain

14 years, 2 months

1
0
0 0

Re: Phone acting as a BTS

by Dieter Spaar

Hello Sylvain, On Wed, 24 Feb 2010 00:06:54 +0100, "Sylvain Munaut" <246tnt(a)gmail.com> wrote: > > Since the beginning, I'm wondering if it would be possible to turn one > of those cheap phone into a BTS. I'm n ot talking a full featured BTS > and the mod will involve hardwares changes obviously. > The more I look at it and the more I think it might work. No, I'm not > crazy, please bear with me until the end of this post :) No, you are not crazy, to be true I thought about it for a while too ;-) It all depends on what you want to do. Just transmitting a C0 so that other phones nearby would recognize the new BTS should be rather easy. You can synhronize on an offical network to adjust the clock, the clock should be stable enough for a while so that other phones can detect the new BTS. There should also be no severe limitations from any filter when transmitting. You are probably out of the specification for the transceiver and maybe the power amplifier but the power should still be good enough to cover an area large enough for experiments. Transmitting the required SBs and FBs should not be too difficult, the DSP cannot generate them, however its rather easy to programm the ABB with the raw bits of a burst. Receiving is more difficult. The filters will influence the signal quite a lot, however it should be still possible to receive strong signals without the requirement for a hardware modification. I already did a few experiments to find out how far the transceiver could be tuned out of range, for GSM-900 I was able to detect the frequency bursts of a 840 Mhz signal with about 40 dBm less strength than receiving a similar signal inside the GSM-900 band. 840 Mhz would be more than enough for receiving uplink signals in GSM-900. I did not yet tried it for the transmitter, however I expect that it can be used to transmit downlink frequencies too. Just as an example for the influence of the filter: The Openmoko Freerunner uses a Calypso based Tri-Band GSM modem, its available for GSM-900 or GSM-850, the difference is mainly a different filter in the RX path. However you can still use the GSM-850 variant with GSM-900 if you are close enough to the BTS. One real problem for the "phone as a BTS" idea is the detection of the RACH bursts. You most certainly cannot use the DSP "as is" for this task because it does not know about the special RACH burst. It would probably require some modification (patches) to the DSP if you want to detect and handle them. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

14 years, 2 months

1
0
0 0

Phone acting as a BTS

by Sylvain Munaut

Hi, Since the beginning, I'm wondering if it would be possible to turn one of those cheap phone into a BTS. I'm n ot talking a full featured BTS and the mod will involve hardwares changes obviously. The more I look at it and the more I think it might work. No, I'm not crazy, please bear with me until the end of this post :) So, what are the obstacles (taking the C118 as an example): * RX filters : Obviously you would need to remove one and replace it with one for the good band. I would only replace one of them so that you can use the 900 band for BTS and the 1800 band for MS for example (so that you can still listen to a official bts and calibrate the clock). * RX/TX switch Those have ports that have frequency bands ... but .. do they really filter that much ? * MS can't TX/RX simultaneously. I think you can take advantage of the fact. Imagine that you only ever allocate channels on TS0,1 & 2. ( BCCH+SDCCH/4 + 2*TCH/F ), you could divide your time like this : TS0 - Capture FCCH of a nearby station to calibrate local vcxo TS1 - Our BTS TS0 TX TS2 - Our BTS TS1 TX TS3 - Our BTS TS2 TX TS4 - Our BTS TS0 RX TS5 - Our BTS TS1 RX TS6 - Our BTS TS2 RX TS7 - nothing ... But this can still be a battery powered handheld BTS :) Sylvain

14 years, 2 months

2
1
0 0

Calypso status update

by Harald Welte

Hi! I've done a day of bugfixing today, mostly regarding the timing and sequencing of the TPU window during receive (and transmit). The biggest new feature is the #define TPU_DEBUG which will transfer the content of the TPU RAM to the host PC every time tpu_enable(1) is called. There's a TPU debugger (tpu_debug.c) as part of osmocon which receives, decodes and prints the TPU instructions. This way you can clearly see the exact sequence (and timing) of the commands that are executed by the TPU. What turned out to be the major problem that I was hunting most of the day: Whe first did the downlink calibration (BLDCAL), then waited for a specific time, and then enabled the downlink path (BDLENA). This worked fine so far. I then added code to disable the TRF6151 after the downlink path is closed (twl3025_downlink(0)). Suddenly not a single burst was received anymore. Now the sequence of events seems correct, at least in the little testing I did. 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)

14 years, 2 months

3
3
0 0

introduce myself

by Andreas.Eversberg

hi there, my name is andreas eversberg. i worked for the mISDN and openbsc project before. after joining the openbsc project, i mainly worked on the call control protocol and the application interface, as well as E1 kernel driver improvements for openbsc. i expanded my linux-call-router application to be able to link with openbsc, so both become a mobile network, as used on the 26c3. i like to put my experience into the osmocomBB project. therfore i started working on the layer 3 "call control" (network layer, mobile side) already. (TS 04.08) the application interface is almost identical, so osmocomBB can be used with linux-call-router also. the next goal is to implement "radio ressource" protocol and "mobility management" protocol (real state machine), and i hope to get help with that. all three protocols are required to do voice calls. my motivations for joining the project are at the moment: - having a cool (graphical) network monitor - backup line for PBX, PBX in a car. - attaching (virtual) test SIM via phone's menu - changing IMEI via phone's menu i hope this project make as much phun as openbsc. andreas

14 years, 2 months

2
1
0 0

Re: Memory Leaking. _talloc_zero panics

by Harald Welte

On Sun, Feb 21, 2010 at 06:03:08PM +0100, Sylvain Munaut wrote: > > I will think about how to solve this. Either we introduce some busy-waiting > > until more space is available, or I will try to fill existing buffers even > > beyond the end-of-line. > > I've seen the commit to fill up the msgb more. But this exposed > another bug in msgb I think. > The headroom allocation doesn't work AFAICT. In msgb.h there is : > > static inline int msgb_tailroom(const struct msgb *msgb) > { > return (msgb->data + msgb->data_len) - msgb->tail; > } you are right, it should be msgb->head + msgb->data_len, I've fixed that now. I've also changed to busy-wait until we have msgb's available again. dsp_dump and hello_world as well as l1test seem to work again now. It's all still a big hack and later we need to determine if we're called from a context that supports busy-waiting at all. Imagine this code being executed from the FIQ context, while new memory will always only be available from IRQ context (UART Tx FIFO interrupt): We will deadlock. Cheers, 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)

14 years, 2 months

1
0
0 0

SIM

by azrael01

Hi, I'm new at this project and I've no experience to program a complete SIM card. But I've experience to implement the ISO-7816 standard on a ARM-Cortex-M3, so that you have a SIM-interface (SIM emulation) between the PC an the Mobile equipment. However, if I can help I'll be pleased to hear from you. cheers, Carsten

14 years, 2 months

2
1
0 0

some questions

by Ilya Petrov

Hi! I read few pages at http://bb.osmocom.org but didnt find answer for some little questions. What this code is based on? Is this a port of some rtos to calypso? -- wbr, Ilya ICQ: none, Jabber: ilya.muromec(a)jabber.ru

14 years, 2 months

3
4
0 0

Memory Leaking. _talloc_zero panics

by Sylvain Munaut

Hi, I've noticed that hello_world and compal_dsp_dump now crash pretty early. I've traced it down to talloc_zero panicing by running out of free msgb. Augmenting the number to 64 makes the software go a little further but they still crash in the end. I'm hoping that the person who wrote this part will see an obvious place where the problem lies :) Sylvain

14 years, 2 months

2
2
0 0

Sim

by Sébastien Lorquet

Hi all, congrats for your awesome research and work, this is truly impressive. The little ant that I am (compared to you) was interested in helping you with the SIM aspects of the project. I think I know javacard sufficiently to implement a basic sim card that can be totally controlled. I already started to think on how to do that. This will include making host side tools, too. If javacard is not open enough, we can also look at native cards using PIC, for example. In our previous discussions, the main problem was the availability of SIM sized cards, be them javacards or not. pros and cons - javacard is an industry standard, coupled with GlobalPlatform specs this is a portable way to put an application on a card without being locked with a card manufacturer. - native PIC cards benefit from a lot of open tools such as the gp* PIC tools, asm, sdcc for compiler and gpsim for simulation. - some projects exists already, I don't know them well, maybe they can be used, forked, improved. - availability must be checked. I'd like to request precisions on how the things should be done, what are the minimal requirements (files, etc) and when the openSim project will be needed regarding to your progress. Regards Sebastien

14 years, 2 months

3
3
0 0

Links to schematics in the wiki ?

by Sylvain Munaut

Hi, I'm wondering if it's ok or not to put links (and only links obviously) to schematics of GSM in the Wiki ? IANAL so I'm not sure exactly what the situation is ... and I'd rather ask before I start adding too much of them :) Cheers, Sylvain

14 years, 2 months

2
1
0 0

New build process / libosmocore

by Harald Welte

Hi! After much delibeation I have devoted today to 'fix' the way how we build the project and how things depend on each other. We have a couple of challenges: 1) there is (and should be!) a lot of infrastructure code sharing between OpenBSC and OsmocomBB Layer2/3. I'm referring to stuff like linuxlist.h, msgb.[hc], bitvec.[hc], the various GSM protocol header files, timers, etc. 2) we want to do the layer2/layer3 development on the PC, while the layer1 resides on the target phone. However, the code should be API compatible and just compile when we later decide to move (parts of) it into the phone. 3) there is already some code like "msgb" which is used both in layer2(PC) and the phone. 4) I don't want to have too many build dependencies as it makes it unneccesarily difficult to get started with the project. So everything should build from the git tree we provide 5) we dislike the idea of code duplication or copy+paste. This means that we need to build some stuff like libosmocore twice; for the host PC and for ARM The solution looks like this: * libosmocore lives in its own git://git.osmocom.org/libosmocore.git repository. This is where we make changes to it. * libosmocore is 'squashed' into the osmocom-bb.git repository by means of git-subtree[1] to make sure challenge '4' is fulfilled. This is transparent to the user who clones our tree. However, if you want to make changes, please ensure that a commit either only touches files within src/shared/libosmocore or outside of that directory. Mixed commits will require manual action and are tiresome. * everything is built using autotools, except for the 'firmware' (what used to be hello_world) * there's now a top-level Makefile, which * builds libosmocore for the host * builds libosmocore for the target * builds osmocon for the host * builds layer2 for the host * builds the target firmware I understand that this process is quite a bit more complex than what we used to have, but it is the best option that I could come up with. I particularly hope that I didn't do something stupid which would break Cygwin builds... we want to keep Dieter as productive as he currently is, after all :) Regards, Harald [1] git://github.com/apenwarr/git-subtree.git -- - 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)

14 years, 2 months

1
0
0 0

[PATCH] fix typo in documentation

by Timo Juhani Lindfors

--- src/README.building | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/README.building b/src/README.building index f940d09..bfd86b6 100644 --- a/src/README.building +++ b/src/README.building @@ -23,5 +23,5 @@ we do not officially support this. # cd osmocom-bb/src/host/layer2 # autoreconf -i - # ./confiugre + # ./configure # make -- 1.5.6.5

14 years, 2 months

2
1
0 0

OpenBSC questions

by Christopher Friedt

So let me ask a couple of questions about OpenBSC to clarify things for myself. What are the requirements for running OpenBSC ? a) a USRP2 b) some kind of computer with gigabit ethernet (recommended hardware? what kind of load would this be responsible for?) b) a broadband internet connection c) anything else? Some kind of VOIP account somewhere? The reason I'm asking is that I've been doing quite a bit of work with the USRP2 at university, and have been considering buying one for myself for quite some time (although as a student, it's hard to justify the price). My professional / academic / hobby interests definitely involve hacking mobiles, investigating mobile radio, hacking various arm devices, even hardware design, etc, and I guess that OpenBSC would be ideal to for testing out osmocom baseband firmware (rather than having a commercial provider's black box for a BS). I guess another question I could pose to the list would be: Is the USRP2 hardware-capable of supporting something UMTS, EDGE, etc? I know that the spec sheets say that it's capable of 50 MHz of instantaneous bandwidth, but I believe that the high data rate 3G (and further) protocols are using wideband OFDM. From my understanding, I would imagine that it would be necessary to support much more than 50 MHz of instantaneous bandwidth, or somehow be able to load the transceiver buffers quickly and sequentially. then push a broad spectrum in parallel. Perhaps this can be achieved with a MIMO configuration, or with a specialized daughter card. Any thoughts? C

14 years, 2 months

5
5
0 0

newer more expensive phones

by Mohammad Hosein

i've got a couple of newer Motorola phones like the milestone also some new HTC phones around any chance these can be used to start playing ?

14 years, 2 months

3
2
0 0

Layer2 Wireshark integration

by Harald Welte

Hi! I've recycled the old GSMTAP wireshark plugin that I originally wrote for project airprobe. Using this patch (now in our git tree as well, applies against current wireshark svn) and the layer2 host program as well as the l1test.bin target program, you can watch BCCH messages in realtime. The architecture is like this: * DSP forwards decoded normal burst data to layer1/sync.c * layer1/sync.c generates L1A_L23 protocol message and sends it via the SERCOMM HDLC layer over RS232 * "osmocon" receives the HDLC frame and relays it to the Unix domain socket * "layer2" receives the L1A_L23 protocol message on the Unix domain socket, adds a GSMTAP header and sends it to the GSMTAP UDP port on localhost * wireshark captures on the 'lo' interface and calls the GSMTAP dissector plugin for everything received on the GSMTAP UDP port number. Have fun! -- - 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)

14 years, 2 months

1
0
0 0

good work!

by Christopher Friedt

Congratulations to all of the developers that worked on this project - you must be very proud at this point! At some point, when I have some free time, I hope to contribute to the codebase (although I don't have a motorola c123, I'm hacking on some other handhelds currently). C

14 years, 2 months

1
0
0 0

Announcing project OsmocomBB: Open Source GSM Stack

by Harald Welte

Good news, everyone [tm]! I am hereby publicly announcing project OsmocomBB: A Free and Open Source software project to create a Free Software GSM baseband firmware. The baseband chipset is the part of a mobile phone that actuall communicates directly with the GSM network. It typically includes a DSP and a microprocessor running some RTOS, drivers for the baseband chipset, the GSM protocol stack and some kind of user interface. GSM has been deployed first 19 years ago. Despite billions of phones deployed world wide, all of them run a proprietary baseband firmware, consisting of proprietary drivers, RTOS and GSM protocol stack. OsmocomBB has set out to change this. We do not want our phones to be a black box connected 24/7 to a public network. We want to decide what kind of data our phone reveals about us or not. The authors behind the project have already spent the last 15 months implementing an Open Source GSM network side protocol implementation called OpenBSC. In January 2010, they decided to go after the phone side protocol stack - which turned into OsmocomBB. => What is the project status? Right now we are at a state where we have full control over the baseband hardware, including the DSP and ARM cores, the analog baseband chip, the RF transceiver, keypad, LCD display and other components. We can scan the GSM band for cells, perform FCCH detection, run automatic gain control to synchronize to the cells carrier, detect the SCH to get BSIC and GSM frame number, as well as dump the BCCH and CCCH of the cell. => What does Osmocom mean? Open Source MObile COMmunications. It is meant as an umbrella name for various FOSS projects related to communications, including OsmocomBB but also including sister projects like OpenBSC. => Can I make phone calls yet? No. We are currently in Rx (receive) only mode, and have no Layer2 or Layer3 implementation yet. However, the difficult parts of driving the GMS hardware and implementing a minimal Layer1 are behind us, so we are confident to proceed to actual phone calls during the months to come. => Where can I get the source? The git repository is at git://git.osmocom.org/osmocom-bb.git The mailing lists are at http://lists.osmocom.org/ The project homepage including wiki is at http://bb.osmocom.org/ => What phones are supported? We are implementing OsmocomBB as hardware-independent as possible. At the moment, we only have drivers for the Ti Calypso Digital Baseband chip. Our main target are the following Motorola-branded phones (made by Compal): C115/116/117/118/119/120/121/122/123/139/140/155 Adding support for other Calypso-based phones should be relatively easy, but porting it to a different baseband chip is a lot of work, especially without access to good documentation. => How can you help? We need developers who have experience in microcontroller development working on an ARM7TDMI core. You do not need to know anything about GSM in order to help us with tasks such as the UI, driving the battery charging controller, etc. If you want to join, get yourself a phone, serial cable, join the developer mailing list and introduce yourself! Happy Hacking Harald Welte -- - 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)

14 years, 2 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel