baseband-devel October 2016

baseband-devel@lists.osmocom.org

7 participants
10 discussions

Start a nNew thread

Engagetted !
by Sébastien Lorquet 14 Oct '25

14 Oct '25

http://www.engadget.com/2010/12/29/researchers-eavesdrop-on-encrypted-gsm-c… Congrats!

7 7

OpenBTS OsmocomBB Asterisk
by trixbox.t 14 Jul '18

14 Jul '18

Hello! I Need Help I install these three programs OpenBTS, OsmocomBB, Asterisk Then run them, Everything works well OpenBTS sent an SMS to my phones I answered and he checked me I registered into OpenBTS a second phone I tried to transfer SMS between phones - all good but when I try to call from one to another I did not get Asterisk writes ================================================================ *CLI> Retransmission timeout reached on transmission 755803415(a)127.0.0.1 for seqno 179 (Critical Response) -- See wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions Packet timed out after 32001ms with no response ================================================================ Why? What do I do? -- View this message in context: http://baseband-devel.722152.n3.nabble.com/OpenBTS-OsmocomBB-Asterisk-tp402… Sent from the baseband-devel mailing list archive at Nabble.com.

6 14

Moving from trac to a single redmine
by Holger Freyther 28 Dec '16

28 Dec '16

Hi guys, I think some of us would like to move to redmine and start using public tickets more frequently. So in case we move there are some topics to be discussed and I would like to start with a couple of them right now. Tickets: Redmine has a global linear sequence of ticket numbers. If we move from many tracs to a single redmine we can either: * not import tickets * only import from one project * deal with changing ticket numbers In terms of installations the GMR trac is broken in regard to tickets, there are some for SDR that are probably not being fixed anytime soon, baseband might be relevant and OpenBSC is unlikely to be relevant. I don't think we have ever used ticket reference in OpenBSC commit messages so in terms of OpenBSC having changing ticket numbers would not be a big deal. E.g. we could add a custom field with the old trac number? Wiki: We have external references that should be redirected to the new place. Is there any way besides maintaining a list in the apache2/nginx configuration and making redirects as we find broken references? Can we proactively manage this? Is anybody willing to come up with a script and nginx configuration for doing this? kind regards holger

8 26

Sniffing GPRS
by canarion 12 Dec '16

12 Dec '16

Hi, After compiling osmocom-bb and apply sylvain/burst_ind branch and gprs_multi.patch, I execute it and try to sniff gprs traffic. I loaded the layer1 into my C139 and I obtained an ARFCN code (883). When I run ccch_scan -a 883 I get the next result: opyright (C) 2010 Harald Welte <laforge(a)gnumonks.org> Contributions by Holger Hans Peter Freyther License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Failed to connect to '/tmp/osmocom_sap'. Failed during sap_open(), no SIM reader <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(1476410343) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(1207963561) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x1ad1cda) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x41ae98f9) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to imsi M(214031385056117) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3306441249) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214031482053520) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214036185306441) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4207880193) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4135931713) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4214223105) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3388536385) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(134915836) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3961436929) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4229756769) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(531909) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214034185316455) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3829437761) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214033485554660) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3639403521) <0001> app_ccch_scan.c:105 SI1 received. <0001> app_ccch_scan.c:464 unknown PCH/AGCH type 0x00 <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3827744513) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(335734299) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3561969409) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4294310401) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3698994241) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3682615617) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(67866789) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4003487553) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3770351169) <0001> app_ccch_scan.c:400 Paging1: Normal paging chan tch/f to TMSI M(0x41ae98f9) <0001> app_ccch_scan.c:403 Paging2: Normal paging chan tch/f to TMSI M(0x1ad1cda) <0001> app_ccch_scan.c:426 Paging3: Normal paging chan n/a to imsi M(214031385056117) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3306441249) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214031482053520) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214036185306441) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4102036289) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(4135931713) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to imsi M(214032485273805) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3798414145) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(134915836) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3988859137) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(3735175681) <0001> app_ccch_scan.c:360 Paging1: Normal paging chan tch/f to tmsi M(531909) <0001> app_ccch_scan.c:248 GSM48 IMM ASS (ra=0x78, chan_nr=0x0f, HSN=24, MAIO=1, TS=7, SS=0, TSC=1) Dropping frame with 55 bit errors <000c> l1ctl.c:238 Dropping frame with 55 bit errors <000c> l1ctl.c:290 BURST IND: @(830928 = 0626/20/36) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830928 = 0626/20/36) (-110 dBm, SNR 8) <000c> l1ctl.c:290 BURST IND: @(830929 = 0626/21/37) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830929 = 0626/21/37) ( -83 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830930 = 0626/22/38) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830930 = 0626/22/38) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830931 = 0626/23/39) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830931 = 0626/23/39) ( -83 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830932 = 0626/24/40) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830932 = 0626/24/40) ( -88 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830933 = 0626/25/41) (-105 dBm, SNR 8, UL, SACCH) <000c> l1ctl.c:290 BURST IND: @(830933 = 0626/25/41) (-107 dBm, SNR 5, SACCH) <000c> l1ctl.c:290 BURST IND: @(830934 = 0626/00/42) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830934 = 0626/00/42) ( -88 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830935 = 0626/01/43) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830935 = 0626/01/43) ( -83 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830936 = 0626/02/44) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830936 = 0626/02/44) ( -88 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830937 = 0626/03/45) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830937 = 0626/03/45) ( -89 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830938 = 0626/04/46) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830938 = 0626/04/46) ( -88 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830939 = 0626/05/47) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830939 = 0626/05/47) ( -82 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830940 = 0626/06/48) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830940 = 0626/06/48) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830941 = 0626/07/49) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830941 = 0626/07/49) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830942 = 0626/08/50) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830942 = 0626/08/50) ( -86 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830943 = 0626/09/00) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830943 = 0626/09/00) ( -86 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830944 = 0626/10/01) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830944 = 0626/10/01) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830945 = 0626/11/02) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830945 = 0626/11/02) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830947 = 0626/13/04) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830947 = 0626/13/04) ( -84 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830948 = 0626/14/05) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830948 = 0626/14/05) ( -85 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830949 = 0626/15/06) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830949 = 0626/15/06) ( -88 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830950 = 0626/16/07) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830950 = 0626/16/07) ( -89 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830951 = 0626/17/08) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830951 = 0626/17/08) ( -88 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830952 = 0626/18/09) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830952 = 0626/18/09) ( -85 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830953 = 0626/19/10) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830953 = 0626/19/10) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830954 = 0626/20/11) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830954 = 0626/20/11) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830955 = 0626/21/12) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830955 = 0626/21/12) (-106 dBm, SNR 0) <000c> l1ctl.c:290 BURST IND: @(830956 = 0626/22/13) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830956 = 0626/22/13) (-107 dBm, SNR 5) <000c> l1ctl.c:290 BURST IND: @(830957 = 0626/23/14) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830957 = 0626/23/14) (-106 dBm, SNR 2) <000c> l1ctl.c:290 BURST IND: @(830958 = 0626/24/15) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830958 = 0626/24/15) (-108 dBm, SNR 1) <000c> l1ctl.c:290 BURST IND: @(830959 = 0626/25/16) (-106 dBm, SNR 2, UL, SACCH) <000c> l1ctl.c:290 BURST IND: @(830959 = 0626/25/16) (-109 dBm, SNR 5, SACCH) <000c> l1ctl.c:290 BURST IND: @(830960 = 0626/00/17) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830960 = 0626/00/17) (-108 dBm, SNR 3) <000c> l1ctl.c:290 BURST IND: @(830961 = 0626/01/18) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830961 = 0626/01/18) (-106 dBm, SNR 2) <000c> l1ctl.c:290 BURST IND: @(830962 = 0626/02/19) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830962 = 0626/02/19) (-108 dBm, SNR 3) <000c> l1ctl.c:290 BURST IND: @(830963 = 0626/03/20) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830963 = 0626/03/20) (-107 dBm, SNR 0) <000c> l1ctl.c:290 BURST IND: @(830964 = 0626/04/21) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830964 = 0626/04/21) ( -85 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830965 = 0626/05/22) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830965 = 0626/05/22) ( -87 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830966 = 0626/06/23) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830966 = 0626/06/23) ( -85 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830967 = 0626/07/24) ( -47 dBm, SNR 255, UL) <000c> l1ctl.c:290 BURST IND: @(830967 = 0626/07/24) ( -86 dBm, SNR 255) <000c> l1ctl.c:290 BURST IND: @(830968 = 0626/08/25) (-107 dBm, SNR 6, UL) <000c> l1ctl.c:290 BURST IND: @(830968 = 0626/08/25) (-109 dBm, SNR 0) <000c> l1ctl.c:290 BURST IND: @(830969 = 0626/09/26) (-101 dBm, SNR 6, UL) But it stop to capture frames, seems to be left in a standby state and I don't know why that is. With gprsdecode I can see the next image in the wireshark: http://baseband-devel.722152.n3.nabble.com/file/n3712433/wireshark-capture.… If someone knows what is the problem, please tell me. Thanks in advance. Cheers, Dani -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Sniffing-GPRS-tp3712433p3712433.… Sent from the baseband-devel mailing list archive at Nabble.com.

8 12

USRP Free BULK SMS SMS device
by superben 10 Dec '16

10 Dec '16

https://youtu.be/YJ_qkJEFNcg UGS is a portable system designed to send SMS messages and data to GSM phones in a pre-defined area. Unlike existed advertisement systems UGS sends normal or flash SMS instead of broadcast messages (receipt of broadcast messages can be disabled by mobile phone user); UGS is an independent stand-alone system, which does not require any cooperation with cellular operators. UGS does not use phone numbers of mobile phones, hence there is no need in the lists of phone numbers to be obtained from various sources. Those lists are often not complete, outdated, irrelevant and costly. The UGS can be used for commercial or security purposes: Send commercial advertisements, announcements, free gift coupons, useful information or welcome messages in specific places: shopping areas, banks, restaurants, train or bus stations, exhibitions, shows, etc. Send warning messages or requests to the people in the case of emergency. Send messages with the request to contact police to potential crime witnesses in the crime areas. SMS messages can be sent: To New in the Area or To Known in the Area or To pre-defined groups or To everyone, The UGS can be installed in a fixed location or carried to the places of need in a small, hand carry suitcase. Potential users of the system are small stores, large organizations, advertisement providers, rescue services, police forces and others. System can be operated locally or remotely via the Internet. SMS sent by the system are free of charge; neither owner of the system nor mobile phone users pay for them. The system is comprised of compact Base Station Unit and notebook computer. Because of unique sophisticated algorithm implemented in the system, the UGS transmits very low power and does not interfere with existed GSM networks. User can define any phone number or name of the sender, which will appear on the screens of mobile phones. Main specifications: Frequency coverage: 850, 900, 1800, 1900 MHz Number of SMS: No limitations Number of handsets: No limitations System output: From 10mW up to 10w (adjustable) Power: 220V / 110V / 24V / 12-16V or Batteries Operation Range: 10...1500 m SMS language: All languages -- View this message in context: http://baseband-devel.722152.n3.nabble.com/USRP-Free-BULK-SMS-SMS-device-tp… Sent from the baseband-devel mailing list archive at Nabble.com.

2 1

"Type not handled! 40" gprsdecode
by George Andguladze 21 Nov '16

21 Nov '16

Hey there, I bumped into this error when testing gprsdecode from srldabs.de When I try the sample .dat files provided from srlabs.de it works fine though. Any hints? Kind Regards George AndguladzeSenior Software EngineerBusiness Management Technology www.bmt.ge

2 1

Re: omsocombb not receiving calls
by robert 26 Oct '16

26 Oct '16

Hi, I didn’t find anything useful yet. Everything seems normal during the IMSI attach procedure (location updating request, authentication request/response, identity request/response …), I can call and send SMS normally but the phone doesn’t get paged in any way. It seems strange that no differences can be seen during the IMSI attach procedure while some sim cards do not work. On Mar 4, 2016, at 7:13 PM, Dennis Eisenbarth <dennis.eisenbarth(a)gmail.com> wrote: > GSM specs, it is. > > On 04.03.2016 17:32, robert wrote: >> >> I read about sim card types since it must be a sim card problem but I didn’t find anything useful. >> >> >> On Mar 4, 2016, at 6:05 PM, Dennis Eisenbarth <dennis.eisenbarth(a)gmail.com> wrote: >> >>> A good start would be a look into the specifications. >>> >>> >>> On 04.03.2016 14:31, robert wrote: >>>> >>>> Hi, >>>> >>>> I tried two sim cards one that works fine and another one that doesn’t get paged, I noticed that during the location update procedure everything is exactly the same (using wireshark). The log files are also similar. Although both cards work fine if used in a normal phone (even with a motorola c123/118 …). >>>> >>>> Another thing to mention is that some sim cards only work when i stick them on a BTS that has the "SI type 3, GPRS indicator" as follows: >>>> "3G Early Classmark Sending Restriction: Neither UTRAN, CDMA2000 nor GERAN IU MODE CLASSMARK CHANGE message shall be sent with the Early classmark sending" >>>> while they can only make calls without being able to receive anything on other BTS where the "SI type 3, GPRS indicator" is as follows: >>>> "3G Early Classmark Sending Restriction: The sending of UTRAN,CDMA2000 and GERAN IU MODE CLASSMARK CHANGE messages are controlled by the Early Classmark Sending Control parameter" >>>> I would be very grateful if anyone has some explanations to what is going on. >>>> >>>> >>>> >>>> Best regards, >>>> Robert, >>>> >>>> >>>> On Jan 26, 2016, at 6:30 PM, Tomcsányi Domonkos <domi(a)tomcsanyi.net> wrote: >>>> >>>>> Hi Robert, >>>>> >>>>> I think it would help us out a lot if you could provide at least one complete log file from the output of the mobile app, so we can start having some ideas. >>>>> >>>>> >>>>> Cheers, >>>>> Domi >>>>> >>>>> >>>>>> 2016. jan. 26. dátummal, 17:24 időpontban robert steve <robert.steve07(a)gmail.com> írta: >>>>>> >>>>>> Hi, >>>>>> I would first like to thank all those who participated in this nice project. >>>>>> I recently started working with osmocombb and was able to have it working fine on a motorola c118. >>>>>> However, I noticed that some sim cards can connect normally to the BTS, can make calls and send SMS but can’t receive anything. They simply don't get paged. While for some other sim cards everything seems to be working fine. >>>>>> >>>>>> Does anyone know what might be causing this issue ? >>>>>> >>>>>> thanks, >>>>>> Robert >>>>> >>>> >>> >> >

4 22

Solution to the shortage of Calypso devices
by Mychaela Falconia 20 Oct '16

20 Oct '16

Hello baseband hacking folks, I have heard several people complain that they are no longer able to find/obtain a Motorola C1xx phone or any other Calypso device for playing with OsmocomBB. I assume these complaints probably come from people in the EU and other 900/1800 MHz regions, as US band C139 phones are still readily available on ebay (63 listings as of right now, all dirt cheap), but either way, I have what I believe to be the proper solution to the shortage and the crippled nature of all pre-existing Calypso devices: a new Calypso board. Back in 2012 Harald Welte posted here saying that his company was going to be making a new Calypso board for the very same purpose of addressing the shortage and the deficiencies of pre-existing devices, but as far as I know, no such product has ever been produced - nor do I know if whoever was behind that project even got as far as creating the design for it. Fast-forwarding to the present, we now have a ready-to-build design for a Calypso development board called FCDEV3B, which stands for FreeCalypso development board, triband. It is based on a reuse of the known-working Calypso modem design from Openmoko, reuse at the level of physical PCB layout, based on the GTA02 design files which Openmoko founder Mr. Sean Moss-Pultz released in April of 2015 at my urging. Back in 2012 Harald was saying that he was only going to release PDF schematics but not the full design files for his board; I feel differently about such matters, hence the complete design files for *my* board are free to the world: ftp://ftp.freecalypso.org/pub/GSM/FreeCalypso/fcdev3b/ Now we need to get these boards physically made, and toward that end I have started a crowdfunding campaign: https://www.gofundme.com/fcdev3b-board-production-2umevjw In the interest of transparency, I have to disclose (most people know it already, but I have to state it anyway) that I do not use OsmocomBB and will never contribute to Osmocom software because I am working on my own personally preferred alternative GSM MS firmware implementation, but when it comes to the hardware I seek to build and offer to the community, there is no reason why it won't work with OsmocomBB - it should work just fine. Because my board is a derivative of Openmoko's modem design and the part that is different between Openmoko's board and mine (the flash chip - I will populate a higher-capacity chip on the same footprint) is not used by OsmocomBB software, the images currently built in board/gta0x/*.highram.bin should work as-is on my FCDEV3B without needing any code changes. Hasta la Victoria, Siempre, M~

2 2

[PATCH] adjust Makefile.mtk so that mtk-firmware works again
by Craig Comstock 15 Oct '16

15 Oct '16

--- src/target/firmware/Makefile.mtk | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/src/target/firmware/Makefile.mtk b/src/target/firmware/Makefile.mtk index 30fa2fc..927e31a 100644 --- a/src/target/firmware/Makefile.mtk +++ b/src/target/firmware/Makefile.mtk @@ -4,14 +4,16 @@ BOARDS?=mt62xx # List of all applications (meant to be overridden on command line) APPLICATIONS?=loader_mtk -mtkram_LDS=board/mediatek/ram.lds -mtkram_OBJS=board/mediatek/start.ram.o +APP_loader_mtk_ENVIRONMENTS=mtkram + +ENV_mtkram_LDS=board/mediatek/ram.lds +ENV_mtkram_OBJS=board/mediatek/start.ram.o mtk_COMMON_OBJS=board/mediatek/uart.o # Mediatek MT62xx -mt62xx_OBJS=$(mtk_COMMON_OBJS) board/mt62xx/init.o -mt62xx_ENVIRONMENTS=mtkram +BOARD_mt62xx_OBJS=$(mtk_COMMON_OBJS) board/mt62xx/init.o +BOARD_mt62xx_ENVIRONMENTS=mtkram # Global include path INCLUDES=-Iinclude/ -I../../../include -I../../shared/libosmocore/include -- 2.1.4

1 0

Re: nuttx-bb layout? inside or outside nuttx?
by Craig Comstock 13 Oct '16

13 Oct '16

Yes, my plan was: - get osmocom-bb (layer1/rssi) firmware working (without graphics probably) - use that work side-by-side to integrate into fernvale nuttx - create a layer1 "app" in nuttx - port "mobile" app to nuttx With the goal being that you can call/text from the nuttx shell. I have the following hardware with which to experiment: - c139 motorola phones - pirelli phone - a few other calypso phones - seeedstudio rephone (mtk6261) - sim800 of various types - several watch phones (dz09 gt08 v9, both 6260 and 6261) - raw 6260 chips which I hope to design a custom pcb for My end goal which is far too ambitious is to make a rock-like device which has no ports/holes: - bluetooth serial to nuttx shell - qi wireless charging - accelerometer gestures for basic controls - bone conducting speaker - speech synth (sam/espeak) and voice recognition (pocketsphinx) - all source is included on-device, even to the point that I would like to port all this work to a forth-like language of my own invention so you can debug, learn and experiment on the device I have so far fixed up the existing mtk-firmware target and was debating whether to submit that small patch or wait until I get some 626x work done. On that front I have the basic registers and an initial BSI power on routine written (but not tested). Thanks to all the giants upon whose shoulders I stand to do this work, Craig -------------------------------------------- On Thu, 10/13/16, Harald Welte <laforge(a)gnumonks.org> wrote: Subject: Re: nuttx-bb layout? inside or outside nuttx? To: "Craig Comstock" <craig_comstock(a)yahoo.com> Cc: "Marcin Mielczarczyk" <marcin.mielczarczyk(a)gmail.com>, "baseband-devel" <baseband-devel(a)lists.osmocom.org> Date: Thursday, October 13, 2016, 2:09 AM Hi Craig, this is just a small note that I just met Marcin Mielczarczyk (who did the existing but still incomplete MTK support work a few years back) at Embedded Linux Conf Europe, and informed him about your work. It is really exciting for both of us to see somebody picking this up and trying to bring things together. If I'm not mistaken, you basically have the following agenda: * Structure OsmocomBB in a way that it can be built 'side-by-side into Nuttx * Build /integrate it from the fernvale nuttx port that is available * Implement the bulk of the MTK L1 integration, i.e. the interface to the DSP. And afterwards hope that you have something that supports either the Fernvale, SIM800H, Linkit One, or other MTK 2G baseband chips out there. Please let me know this was an accurate understanding. 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)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel October 2016