From axilirator at gmail.com Mon Jun 13 08:50:23 2016 From: axilirator at gmail.com (=?UTF-8?B?0JLQsNC00LjQvCDQr9C90LjRhtC60LjQuQ==?=) Date: Mon, 13 Jun 2016 14:50:23 +0600 Subject: L1 power measurement logs Message-ID: Hello everyone! During power measurement process we can see some messages like: PM MEAS: ARFCN=8, 55 dBm at baseband, -83 dBm at RF If I understood correctly, in this example received signal has -83 dBm (about 5e-12 W) strength before amplifier and 55 dBm (about 316.2 W) strength after one. It looks like the strength of amplified signal should be printed as -55 (about 3.2e-9 W), because 316.2 W is very high value. Am I right? Or is it internal signal strength representation used by DSP? ? ?????????? ???????????, ??????? ?????. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri Jun 17 07:20:43 2016 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 17 Jun 2016 09:20:43 +0200 Subject: L1 power measurement logs In-Reply-To: References: Message-ID: <98440143-960A-476D-9B5C-F2FEE391F9AF@gnumonks.org> We're talking about a reverse engineered baseband chip, co always take things with a grain of salt. Your general assumption makes sense that +55dBm is unrealistic. Please keep in mind that those readings are off by quite a bit as we use no devices individual calibration tables. -- Sent from a mobile device. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cosmin_ioan.petrisor at cti.pub.ro Sat Jun 18 13:48:20 2016 From: cosmin_ioan.petrisor at cti.pub.ro (Cosmin - Ioan PETRI?OR) Date: Sat, 18 Jun 2016 13:48:20 +0000 Subject: OsmocomBB on Openmoko GTA02 Message-ID: Hi guys, I have a lot of problems using osmocom-bb with an Openmoko GTA02. First of all, I followed all the instructions from here [1] and uploaded layer1.highram.bin via external jack serial port (second tutorial). Well, after the firmware is downloaded on the phone osmocon prints: " Finished, sent 54 blocks in total Received branch ack, your code is running now! " and nothing is printed anymore. Moreover, I see no activity on the serial port, all LEDs on my USB adapter being off. When I try to run cell_log from my PC, it prints the following error message and blocks / does nothing: " Failed to connect to '/tmp/osmocom_sap'. Failed during sap_open(), no SIM reader <000e> cell_log.c:804 Scanner initialized Mobile initialized, please start phone now! " I've read about this error and figured out that it is not fatal, but still cell_log doesn't work, nor does the 'mobile' application. I tried the code from master and from sylvain/testing branch and I uncommented "CONFIG_TX_ENABLE". I even tried hello_world.highram.bin and that doesn't print anything after loading it. I don't know what to do anymore. [1] http://bb.osmocom.org/trac/wiki/OpenMoko#no1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From edachleger at yahoo.com Mon Jun 20 19:32:04 2016 From: edachleger at yahoo.com (Erich Dachleger) Date: Mon, 20 Jun 2016 19:32:04 +0000 (UTC) Subject: Sv: 2G repeater/booster w/ osmocom-bb? or 3G w/ osmocom-bb? In-Reply-To: References: <1918452970.853082.1464013260680.JavaMail.yahoo@mail.yahoo.com> Message-ID: <935026031.10949315.1466451124789.JavaMail.yahoo@mail.yahoo.com> Does anybody know if it would be possible to use some of the old vodaphone-femtocells together with openbsc/osmo-bts? RegardsErich Den Mandag, 23. mai 2016 11.46 skrev etienne . : Short answer: no & no 1 - A gsm repeater is an analog device. With osmocom-bb phones you would need to demodulate/remodulate bursts. This will mess with timing advance, and you won't be able to send bursts in the same frame/timeslot they were received. 2 - Calypso don't/won't support 3G. Regards On Mon, May 23, 2016 at 4:21 PM, Craig Comstock wrote: The place where I normally play with osmocom-bb has pretty bad 2G coverage and I was wondering if I could make a signal booster/repeater with a couple of osmocom phones? Also wondering if 3G would require totally different hardware than the old Calypso motorola phones or if it could be achieved with firmware+DSP changes? I have a 3G cell spot that boost that signal so just trying to find a way to make an osmocom-bb phone work well in my place. Thanks,Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig_comstock at yahoo.com Tue Jun 21 01:00:09 2016 From: craig_comstock at yahoo.com (Craig Comstock) Date: Mon, 20 Jun 2016 20:00:09 -0500 Subject: Sv: 2G repeater/booster w/ osmocom-bb? or 3G w/ osmocom-bb? Message-ID: <93473CB0-D451-4866-B5A9-3B073D782F9F@yahoo.com> I found a 1900 band analog booster/repeater to try. > On Jun 20, 2016, at 2:32 PM, Erich Dachleger wrote: > > Does anybody know if it would be possible to use some of the old vodaphone-femtocells together with openbsc/osmo-bts? > RegardsErich > > Den Mandag, 23. mai 2016 11.46 skrev etienne . : > > > Short answer: no & no > 1 - A gsm repeater is an analog device. With osmocom-bb phones you would need to demodulate/remodulate bursts. > This wi From domi at tomcsanyi.net Tue Jun 21 10:53:44 2016 From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=) Date: Tue, 21 Jun 2016 12:53:44 +0200 (CEST) Subject: Sv: 2G repeater/booster w/ osmocom-bb? or 3G w/ osmocom-bb? In-Reply-To: <935026031.10949315.1466451124789.JavaMail.yahoo@mail.yahoo.com> References: <1918452970.853082.1464013260680.JavaMail.yahoo@mail.yahoo.com> <935026031.10949315.1466451124789.JavaMail.yahoo@mail.yahoo.com> Message-ID: <2AEA08D9-A3F7-4668-9D26-E45E9127DEFB@tomcsanyi.net> Hi, Those femtocells use ipsec to which the keys are not available (yet). The ones that were not automatically upgraded by Vodafone and therefore expose a serial shell might be used, but that requires some more investigation (and sadly not much of un-upgraded versions exists...also downgrading isn't an option if I'm correct because they do this inside the IPsec tunnel). Maybe Kevin has more memories about them :). Other femtocells (e.g. SFR) that use EAP-SIM should be easily connected to an open core network by simply using SIM cards with known keys. Cheers, Domi 2016. j?n. 20. d?tummal, 21:36 id?pontban Erich Dachleger ?rta: > Does anybody know if it would be possible to use some of the old vodaphone-femtocells together with openbsc/osmo-bts? > > Regards > Erich > > > Den Mandag, 23. mai 2016 11.46 skrev etienne . : > > > Short answer: no & no > 1 - A gsm repeater is an analog device. With osmocom-bb phones you would need to demodulate/remodulate bursts. > This will mess with timing advance, and you won't be able to send bursts in the same frame/timeslot they were received. > 2 - Calypso don't/won't support 3G. > > Regards > > On Mon, May 23, 2016 at 4:21 PM, Craig Comstock wrote: > The place where I normally play with osmocom-bb has pretty bad 2G coverage and I was wondering if I could make a signal booster/repeater with a couple of osmocom phones? > > Also wondering if 3G would require totally different hardware than the old Calypso motorola phones or if it could be achieved with firmware+DSP changes? > > I have a 3G cell spot that boost that signal so just trying to find a way to make an osmocom-bb phone work well in my place. > > Thanks, > Craig > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Thu Jun 23 12:45:45 2016 From: axilirator at gmail.com (=?UTF-8?B?0JLQsNC00LjQvCDQr9C90LjRhtC60LjQuQ==?=) Date: Thu, 23 Jun 2016 18:45:45 +0600 Subject: OsmocomBB hardware migration to SDR Message-ID: Hi lists! It's no secret for everyone, that today OsmocomBB is not actively maintained as well as OpenBSC, for example. I think it's mostly due to supported hardware limitations. Currently supported platforms is still a bit of 'black box'. Moreover every day it's harder to find and buy a new one. Fortunately, there are many SDR platforms available now. Especially interesting devices are USRP, UmTRX, bladeRF, and recently introduced LimeSDR. They can be easily programmed to support just about any type of wireless standard, of course, including some mobile telecommunication stacks. As well as for network side back-end, they can be used to perform MS side operations, excepting frequency-hopping and some phone specific features (like SIM I/O). So, I think there is a way to bring a new live to, amazing child of the Osmocom umbrella, OsmocomBB. We can make one work on SDR hardware platforms implementing a 'bridge' between both already implemented L2/L3 and OsmoTRX. I know that there already was some attempts (see sylvain/ms-sdr branch) to make described dreams come true, but development was stopped. And now I am going to start to work around this direction. What for? - GPRS and EDGE support - More flexible voice routing - Multi SIM support - Next generation networks support (UMTS, LTE) - ... Currently I am looking for developers interested in this subject. So, any ideas and contributions are welcome! Together we can realize all the things faster and create a new area of research and development. Also for me it's very important to know opinions of Osmocom community members and exactly OsmocomBB founders/developers. Thanks! ? ?????????? ???????????, ??????? ?????. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.chemeris at gmail.com Thu Jun 23 13:30:42 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Thu, 23 Jun 2016 16:30:42 +0300 Subject: OsmocomBB hardware migration to SDR In-Reply-To: References: Message-ID: Hi Vadim, On Thu, Jun 23, 2016 at 3:45 PM, ????? ??????? wrote: > Fortunately, there are many SDR platforms available now. Especially interesting > devices are USRP, UmTRX, bladeRF, and recently introduced LimeSDR. They can be > easily programmed to support just about any type of wireless standard, of course, > including some mobile telecommunication stacks. As well as for network side back-end, > they can be used to perform MS side operations, excepting frequency-hopping and some > phone specific features (like SIM I/O). Btw, the first release of XTRX (http://xtrx.io) will have a SIM driver, so it'll be possible to connect it directly to a SIM card slot, as per the miniPCIe standard. If users will find this feature useful for users, it'll make it to the final release. > So, I think there is a way to bring a new live to, amazing child of the Osmocom > umbrella, OsmocomBB. We can make one work on SDR hardware platforms implementing > a 'bridge' between both already implemented L2/L3 and OsmoTRX. Also note an 'ms' branch of osmo-trx. It's not a full functionality required for an MS and the code is pretty dated, but it's close enough to start. > I know that there > already was some attempts (see sylvain/ms-sdr branch) to make described dreams > come true, but development was stopped. And now I am going to start to work around > this direction. It was a combination of circumstances that work was not finished and I would totally support an effort to finish it. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co From craig_comstock at yahoo.com Thu Jun 23 14:56:39 2016 From: craig_comstock at yahoo.com (Craig Comstock) Date: Thu, 23 Jun 2016 14:56:39 +0000 (UTC) Subject: OsmocomBB hardware migration to SDR In-Reply-To: References: Message-ID: <213380025.237267.1466693799091.JavaMail.yahoo@mail.yahoo.com> Hi All, I hope to make a usable phone. Currently my plan is to dig into the MT6260 as started by the fernly/fernvale project. Current target is the SIM800H which contains the MT6260. I saw both that sysmocom has a $150 fernvale setup and Lime SDR has a USB bare-board for $250+ but I have to stick with something that is "phone" like and so am working on designing a small SIM800H/MT6260-based phone which can be expanded and/or used to experiment. If there was something like LimeSDR that was small and less expensive I would go that route. I imagine there will be before long. :) Meanwhile, I'd definitely like to contribute as I can to MS software/osmocom-bb. I will do what I can. Thanks,Craig github for my project... as yet it's just a "manifesto"/vapor-ware but I have a lot of half-done bits and pieces laying around... ;) https://github.com/craigcomstock/rockphone From: Alexander Chemeris To: ????? ??????? Cc: baseband-devel ; Andreas Eversberg Sent: Thursday, June 23, 2016 8:30 AM Subject: Re: OsmocomBB hardware migration to SDR Hi Vadim, On Thu, Jun 23, 2016 at 3:45 PM, ????? ??????? wrote: > Fortunately, there are many SDR platforms available now. Especially interesting > devices are USRP, UmTRX, bladeRF, and recently introduced LimeSDR. They can be > easily programmed to support just about any type of wireless standard, of course, > including some mobile telecommunication stacks. As well as for network side back-end, > they can be used to perform MS side operations, excepting frequency-hopping and some > phone specific features (like SIM I/O). Btw, the first release of XTRX (http://xtrx.io) will have a SIM driver, so it'll be possible to connect it directly to a SIM card slot, as per the miniPCIe standard. If users will find this feature useful for users, it'll make it to the final release. > So, I think there is a way to bring a new live to, amazing child of the Osmocom > umbrella, OsmocomBB. We can make one work on SDR hardware platforms implementing > a 'bridge' between both already implemented L2/L3 and OsmoTRX. Also note an 'ms' branch of osmo-trx. It's not a full functionality required for an MS and the code is pretty dated, but it's close enough to start. > I know that there > already was some attempts (see sylvain/ms-sdr branch) to make described dreams > come true, but development was stopped. And now I am going to start to work around > this direction. It was a combination of circumstances that work was not finished and I would totally support an effort to finish it. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Thu Jun 23 16:56:55 2016 From: axilirator at gmail.com (=?UTF-8?B?0JLQsNC00LjQvCDQr9C90LjRhtC60LjQuQ==?=) Date: Thu, 23 Jun 2016 22:56:55 +0600 Subject: OsmocomBB hardware migration to SDR In-Reply-To: References: Message-ID: Hi Alexander, > Btw, the first release of XTRX (http://xtrx.io) will have a SIM > driver, so it'll be possible to connect it directly to a SIM card > slot, as per the miniPCIe standard. If users will find this feature > useful for users, it'll make it to the final release. So, that is really good news! Also I think it would be great to extend existing SAP interface/protocol implementation with multiple SIM cards support and finish some unimplemented things in this area. > Also note an 'ms' branch of osmo-trx. It's not a full functionality > required for an MS and the code is pretty dated, but it's close enough > to start. Yes, Sylvain already said me about this branch. > It was a combination of circumstances that work was not finished and I > would totally support an effort to finish it. It is nice to know about that. Thank you! With best regards, Vadim Yanitskiy. 2016-06-23 19:30 GMT+06:00 Alexander Chemeris : > Hi Vadim, > > On Thu, Jun 23, 2016 at 3:45 PM, ????? ??????? > wrote: > > Fortunately, there are many SDR platforms available now. Especially > interesting > > devices are USRP, UmTRX, bladeRF, and recently introduced LimeSDR. They > can be > > easily programmed to support just about any type of wireless standard, > of course, > > including some mobile telecommunication stacks. As well as for network > side back-end, > > they can be used to perform MS side operations, excepting > frequency-hopping and some > > phone specific features (like SIM I/O). > > Btw, the first release of XTRX (http://xtrx.io) will have a SIM > driver, so it'll be possible to connect it directly to a SIM card > slot, as per the miniPCIe standard. If users will find this feature > useful for users, it'll make it to the final release. > > > So, I think there is a way to bring a new live to, amazing child of the > Osmocom > > umbrella, OsmocomBB. We can make one work on SDR hardware platforms > implementing > > a 'bridge' between both already implemented L2/L3 and OsmoTRX. > > Also note an 'ms' branch of osmo-trx. It's not a full functionality > required for an MS and the code is pretty dated, but it's close enough > to start. > > > I know that there > > already was some attempts (see sylvain/ms-sdr branch) to make described > dreams > > come true, but development was stopped. And now I am going to start to > work around > > this direction. > > It was a combination of circumstances that work was not finished and I > would totally support an effort to finish it. > > -- > Regards, > Alexander Chemeris. > CEO, Fairwaves, Inc. > https://fairwaves.co > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri Jun 24 08:11:38 2016 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 24 Jun 2016 10:11:38 +0200 Subject: (xtrx sim card interface) Re: OsmocomBB hardware migration to SDR In-Reply-To: References: Message-ID: <20160624081138.GF14342@nataraja> Hi Alexander, On Thu, Jun 23, 2016 at 04:30:42PM +0300, Alexander Chemeris wrote: > > Btw, the first release of XTRX (http://xtrx.io) will have a SIM > driver, so it'll be possible to connect it directly to a SIM card > slot, as per the miniPCIe standard. If users will find this feature > useful for users, it'll make it to the final release. definitely keep it. I suppose it is just a few wires routed to the FPGA in the borad design, so I don't think there is any reason to remove it? So why raise the question in the first place? Even if there is no soft-core for the ISO7816 master integrated in the FPGA yet, poeple could certianly add it later if needed. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri Jun 24 08:14:51 2016 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 24 Jun 2016 10:14:51 +0200 Subject: OsmocomBB hardware migration to SDR In-Reply-To: <213380025.237267.1466693799091.JavaMail.yahoo@mail.yahoo.com> References: <213380025.237267.1466693799091.JavaMail.yahoo@mail.yahoo.com> Message-ID: <20160624081451.GG14342@nataraja> Hi Craig, good to hear that you're working on something as exciting as MTK support of OsmocomBB. On Thu, Jun 23, 2016 at 02:56:39PM +0000, Craig Comstock wrote: > I hope to make a usable phone. Currently my plan is to dig into the MT6260 as > started by the fernly/fernvale project. Current target is the SIM800H which > contains the MT6260. I saw both that sysmocom has a $150 fernvale setup and > Lime SDR has a USB bare-board for $250+ but I have to stick with something that > is "phone" like and so am working on designing a small SIM800H/MT6260-based > phone which can be expanded and/or used to experiment. I would strongly encourage you not to spend time in designing more hardware rather than working on the software side of things. Understanding the DSP/ARM interface of mediatek baesband chips is the primary key into creating a L1 adaptation of OsmocomBB that works on such hardware. > If there was something like LimeSDR that was small and less expensive I would > go that route. I imagine there will be before long. :) I don't think a General Purpose SDR solution will lead to a usable phone. The GP SDR is too large and power hungry to begin with, and then you need a host processor that can do all the signal processing, and you're suddenly talking more about an embedded PC rather than a battery powered phone. > Meanwhile, I'd definitely like to contribute as I can to MS software/ > osmocom-bb. I will do what I can. Pleaes do so. I'm happy to review and give feedback. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Fri Jun 24 08:29:25 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Fri, 24 Jun 2016 11:29:25 +0300 Subject: (xtrx sim card interface) Re: OsmocomBB hardware migration to SDR In-Reply-To: <20160624081138.GF14342@nataraja> References: <20160624081138.GF14342@nataraja> Message-ID: Hi Harald, On Jun 24, 2016 11:15 AM, "Harald Welte" wrote: > On Thu, Jun 23, 2016 at 04:30:42PM +0300, Alexander Chemeris wrote: > > > > Btw, the first release of XTRX (http://xtrx.io) will have a SIM > > driver, so it'll be possible to connect it directly to a SIM card > > slot, as per the miniPCIe standard. If users will find this feature > > useful for users, it'll make it to the final release. > > definitely keep it. I suppose it is just a few wires routed to the FPGA > in the borad design, so I don't think there is any reason to remove it? > So why raise the question in the first place? Even if there is no > soft-core for the ISO7816 master integrated in the FPGA yet, poeple > could certianly add it later if needed. > The key element there is a SIM card voltage level converter chip. XTRX is quite densely populated, so we may remove unused features to free some space for something we think is more useful. It's like garbage collection :) So it would be great if someone actually use it, that's all I'm saying. -- Regards, Alexander Chemeris CEO Fairwaves, Inc. https://fairwaves.co -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Fri Jun 24 08:33:09 2016 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 24 Jun 2016 10:33:09 +0200 Subject: OsmocomBB hardware migration to SDR In-Reply-To: References: Message-ID: <20160624083309.GH14342@nataraja> Hi Vadim, On Thu, Jun 23, 2016 at 06:45:45PM +0600, ????? ??????? wrote: > > It's no secret for everyone, that today OsmocomBB is not actively maintained > as well as OpenBSC, for example. This is true, but even OpenBSC and related projects are suffering from a lack of attention. Despite being one of the founders of sysmocom, I really don't like to see the development and maintenance responsibility within one entity (or, let's say Holger and me privately, and sysmocom asa company). We need more contributors in all Osmocom projects. > I think it's mostly due to supported hardware limitations. Honestly, I'm not sure. The big difference is that there are commercial users of OpenBSC, OsmoBTS, etc., and they can afford to fund some of the work on those projects. For OsmocomBB I don't think there's much of a chacne for commercial interest. You can buy an entire phone for USD 10 these days, including a license for the protocol stack / software - so why bother investing in a "new" implementation of GSM. There are some exceptions like test devices or virtual phones for load generation, but those are also not interesting to most people anymore in 2016. OsmocomBB doesn't support GPRS, EDGE, UMTS, HSPA and likely never will, unless a maniac comes around who invests several months of full-time + spare-time work into what most people would considre a hopeless cause. For LTE, there's luckily the excellent free software srsUE implemntation. However, it requires a Core-i5, unless somebody manages to transplant the protocol stack onto one of the commercially found LTE baseband / PHY implementations actually used in phones. Getting back further to your question: Even on the supported hardware (Calypso based phones), there are still many bugs and features missing, and nobody contributes. It makes me quite sad, as Andreas and I have put in a lot of energy to get the project going, but then nobody really got int carrying it along further. > Currently I am looking for developers interested in this subject. We all are, but mostly the work gets done when we are not looking but actually writing code :P No offence, I just couldn't resist... All the best, I'd definitely love to see progress on the "SDR based PHY for OsmocomBB" front. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From craig_comstock at yahoo.com Fri Jun 24 11:02:22 2016 From: craig_comstock at yahoo.com (Craig Comstock) Date: Fri, 24 Jun 2016 06:02:22 -0500 Subject: OsmocomBB hardware migration to SDR In-Reply-To: <20160624081451.GG14342@nataraja> References: <213380025.237267.1466693799091.JavaMail.yahoo@mail.yahoo.com> <20160624081451.GG14342@nataraja> Message-ID: <3490334C-B693-4BCC-B607-3505418251C3@yahoo.com> Thanks Herald! I was trying to design a very basic working hardware so that more debug/diagnostic capabilities were available such as JTAG and maybe monitor any pin coming out of mt6260 with a scope/analyzer. My other hope was to leverage the existing firmware such as embedded at or linkit os/api to confirm the hardware a bit and give me something I could write the UI for earlier. Basically if I use the sim800h that is a working phone. I break out all if the pins it provides and I hope I have more visibility inside. Granted I suppose with sim800h I no longer have access to that critical dsp/arm interface? I'm not sure. Thanks again for the encouragement. I did just get fernly running on my dfrobot shield with a sim800h in it! Reported as a 6260, so "game on." > On Jun 24, 2016, at 3:14 AM, Harald Welte wrote: > > Hi Craig, > > good to hear that you're working on something as exciting as MTK support > of OsmocomBB. > >> On Thu, Jun 23, 2016 at 02:56:39PM +0000, Craig Comstock wrote: >> I hope to make a usable phone. Currently my plan is to dig into the MT6260 as >> started by the fernly/fernvale project. Current target is the SIM800H which >> contains the MT6260. I saw both that sysmocom has a $150 fernvale setup and >> Lime SDR has a USB bare-board for $250+ but I have to stick with something that >> is "phone" like and so am working on designing a small SIM800H/MT6260-based >> phone which can be expanded and/or used to experiment. > > I would strongly encourage you not to spend time in designing more > hardware rather than working on the software side of things. > Understanding the DSP/ARM interface of mediatek baesband chips is the > primary key into creating a L1 adaptation of OsmocomBB that works on > such hardware. > >> If there was something like LimeSDR that was small and less expensive I would >> go that route. I imagine there will be before long. :) > > I don't think a General Purpose SDR solution will lead to a usable > phone. The GP SDR is too large and power hungry to begin with, and > then you need a host processor that can do all the signal processing, > and you're suddenly talking more about an embedded PC rather than a > battery powered phone. > >> Meanwhile, I'd definitely like to contribute as I can to MS software/ >> osmocom-bb. I will do what I can. > > Pleaes do so. I'm happy to review and give feedback. > -- > - Harald Welte http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) From alexander.chemeris at gmail.com Fri Jun 24 11:30:11 2016 From: alexander.chemeris at gmail.com (Alexander Chemeris) Date: Fri, 24 Jun 2016 14:30:11 +0300 Subject: OsmocomBB hardware migration to SDR In-Reply-To: <20160624083309.GH14342@nataraja> References: <20160624083309.GH14342@nataraja> Message-ID: On Fri, Jun 24, 2016 at 11:33 AM, Harald Welte wrote: > On Thu, Jun 23, 2016 at 06:45:45PM +0600, ????? ??????? wrote: >> It's no secret for everyone, that today OsmocomBB is not actively maintained >> as well as OpenBSC, for example. > > This is true, but even OpenBSC and related projects are suffering from a > lack of attention. Despite being one of the founders of sysmocom, I > really don't like to see the development and maintenance responsibility > within one entity (or, let's say Holger and me privately, and sysmocom > asa company). We need more contributors in all Osmocom projects. I think telecom in general has been lacking attention from open-source developers. How bad is that when every vendor, even the smallest one has its own proprietary SS7 stack. >> I think it's mostly due to supported hardware limitations. > > Honestly, I'm not sure. The big difference is that there are commercial > users of OpenBSC, OsmoBTS, etc., and they can afford to fund some of the > work on those projects. For OsmocomBB I don't think there's much of a > chacne for commercial interest. You can buy an entire phone for USD 10 > these days, including a license for the protocol stack / software - so > why bother investing in a "new" implementation of GSM. > > There are some exceptions like test devices or virtual phones for load > generation, but those are also not interesting to most people anymore in > 2016. I second this. The whole reason the work for SDR support for OsmocomBB started back then, was because we had some funding available for this. Since then I haven't seen anyone commercially interested in supporting OsmocomBB, which is quite unfortunate. It's not impossible to get it to a state when there will be commercial use for it, but it's so much work (GPRS, EDGE, 3G...) that either someone really stubborn should do it for free, or someone really philanthropic should fund this. That said, I hope that either one of the other will happen and we'll see it working. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co From craig_comstock at yahoo.com Fri Jun 24 11:56:21 2016 From: craig_comstock at yahoo.com (Craig Comstock) Date: Fri, 24 Jun 2016 06:56:21 -0500 Subject: OsmocomBB hardware migration to SDR In-Reply-To: References: <20160624083309.GH14342@nataraja> Message-ID: <8F15A63E-CA58-405F-B6B5-51D46AD4E11B@yahoo.com> FWIW I figure I have about 20 more years in the software field and due to my lack of experience figure it will take a good chunk of that time to learn all this stuff. So I am planning on being stubborn. Cheers, Craig > On Jun 24, 2016, at 6:30 AM, Alexander Chemeris wrote: > >> On Fri, Jun 24, 2016 at 11:33 AM, Harald Welte wrote: >>> On Thu, Jun 23, 2016 at 06:45:45PM +0600, ????? ??????? wrote: >>> It's no secret for everyone, that today OsmocomBB is not actively maintained >>> as well as OpenBSC, for example. >> >> This is true, but even OpenBSC and related projects are suffering from a >> lack of attention. Despite being one of the founders of sysmocom, I >> really don't like to see the development and maintenance responsibility >> within one entity (or, let's say Holger and me privately, and sysmocom >> asa company). We need more contributors in all Osmocom projects. > > I think telecom in general has been lacking attention from open-source > developers. How bad is that when every vendor, even the smallest one > has its own proprietary SS7 stack. > >>> I think it's mostly due to supported hardware limitations. >> >> Honestly, I'm not sure. The big difference is that there are commercial >> users of OpenBSC, OsmoBTS, etc., and they can afford to fund some of the >> work on those projects. For OsmocomBB I don't think there's much of a >> chacne for commercial interest. You can buy an entire phone for USD 10 >> these days, including a license for the protocol stack / software - so >> why bother investing in a "new" implementation of GSM. >> >> There are some exceptions like test devices or virtual phones for load >> generation, but those are also not interesting to most people anymore in >> 2016. > > I second this. > > The whole reason the work for SDR support for OsmocomBB started back > then, was because we had some funding available for this. Since then I > haven't seen anyone commercially interested in supporting OsmocomBB, > which is quite unfortunate. It's not impossible to get it to a state > when there will be commercial use for it, but it's so much work (GPRS, > EDGE, 3G...) that either someone really stubborn should do it for > free, or someone really philanthropic should fund this. That said, I > hope that either one of the other will happen and we'll see it > working. > > -- > Regards, > Alexander Chemeris. > CEO, Fairwaves, Inc. > https://fairwaves.co From axilirator at gmail.com Fri Jun 24 13:57:00 2016 From: axilirator at gmail.com (=?UTF-8?B?0JLQsNC00LjQvCDQr9C90LjRhtC60LjQuQ==?=) Date: Fri, 24 Jun 2016 19:57:00 +0600 Subject: OsmocomBB hardware migration to SDR In-Reply-To: <20160624083309.GH14342@nataraja> References: <20160624083309.GH14342@nataraja> Message-ID: Hello Harald! > This is true, but even OpenBSC and related projects are suffering from a > lack of attention. Despite being one of the founders of sysmocom, I > really don't like to see the development and maintenance responsibility > within one entity (or, let's say Holger and me privately, and sysmocom > asa company). We need more contributors in all Osmocom projects. Well, IMHO this lack of contribution partially caused by ignorance of some developers about the Osmocom project existence. Despite the fact, that one and it's child projects already was presented on multiple international forums and congresses, there are some people who aren't observing these events or who have no opportunity to do so, I think. This is why I am currently writing the publications about Osmocom project (mostly about OsmocomBB yet) for the most popular IT blog in Russia, named Habrahabr. After the first publication I found, that many people didn't knew anything about Open Source mobile telecommunications so far. But now some of them are interested in contribution and research in this area. I hope it will help to improve current situation. > Honestly, I'm not sure. The big difference is that there are commercial > users of OpenBSC, OsmoBTS, etc., and they can afford to fund some of the > work on those projects. For OsmocomBB I don't think there's much of a > chacne for commercial interest. You can buy an entire phone for USD 10 > these days, including a license for the protocol stack / software - so > why bother investing in a "new" implementation of GSM. Yes, but except commercial demands there is also an educational side of OsmocomBB. Personally for me, one has played a key role in mobile telecommunications learning process. In our educational institutions students are learning mobile networks very superficially, mostly the physical basics of Um-interface, while some important hw and sw details isn't covered as well. So, nowadays SDR devices becomes more and more available, I think it's time to bring a 'wind of change' to this area. > For LTE, there's luckily the excellent free software srsUE > implemntation. However, it requires a Core-i5, unless somebody manages > to transplant the protocol stack onto one of the commercially found LTE > baseband / PHY implementations actually used in phones. I saw this project, this guys exactly prefer to use SDR platforms. BTW, do you know anything about industrial/commercial demands of this project? > Getting back further to your question: Even on the supported hardware > (Calypso based phones), there are still many bugs and features missing, > and nobody contributes. It makes me quite sad, as Andreas and I have > put in a lot of energy to get the project going, but then nobody really > got int carrying it along further. Yes, agree with you. Supported hardware takes a place in this problem too. I know some people who have no opportunity to contribute because it's impossible to find even one out of stock Motorola phone in their locations. This makes me feeling sad too. > We all are, but mostly the work gets done when we are not looking but > actually writing code :P No offence, I just couldn't resist... No problem, I am completely agree with you and going to start working as soon as I will have free time. At the moment I have some pending exams. > All the best, I'd definitely love to see progress on the "SDR based PHY > for OsmocomBB" front. Thank you very much! Your opinion is important for me. With best regards, Vadim Yanitskiy. 2016-06-24 14:33 GMT+06:00 Harald Welte : > Hi Vadim, > > On Thu, Jun 23, 2016 at 06:45:45PM +0600, ????? ??????? wrote: > > > > It's no secret for everyone, that today OsmocomBB is not actively > maintained > > as well as OpenBSC, for example. > > This is true, but even OpenBSC and related projects are suffering from a > lack of attention. Despite being one of the founders of sysmocom, I > really don't like to see the development and maintenance responsibility > within one entity (or, let's say Holger and me privately, and sysmocom > asa company). We need more contributors in all Osmocom projects. > > > I think it's mostly due to supported hardware limitations. > > Honestly, I'm not sure. The big difference is that there are commercial > users of OpenBSC, OsmoBTS, etc., and they can afford to fund some of the > work on those projects. For OsmocomBB I don't think there's much of a > chacne for commercial interest. You can buy an entire phone for USD 10 > these days, including a license for the protocol stack / software - so > why bother investing in a "new" implementation of GSM. > > There are some exceptions like test devices or virtual phones for load > generation, but those are also not interesting to most people anymore in > 2016. > > OsmocomBB doesn't support GPRS, EDGE, UMTS, HSPA and likely never will, > unless a maniac comes around who invests several months of full-time + > spare-time work into what most people would considre a hopeless cause. > > For LTE, there's luckily the excellent free software srsUE > implemntation. However, it requires a Core-i5, unless somebody manages > to transplant the protocol stack onto one of the commercially found LTE > baseband / PHY implementations actually used in phones. > > Getting back further to your question: Even on the supported hardware > (Calypso based phones), there are still many bugs and features missing, > and nobody contributes. It makes me quite sad, as Andreas and I have > put in a lot of energy to get the project going, but then nobody really > got int carrying it along further. > > > Currently I am looking for developers interested in this subject. > > We all are, but mostly the work gets done when we are not looking but > actually writing code :P No offence, I just couldn't resist... > > All the best, I'd definitely love to see progress on the "SDR based PHY > for OsmocomBB" front. > > -- > - Harald Welte > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig_comstock at yahoo.com Fri Jun 24 21:12:33 2016 From: craig_comstock at yahoo.com (Craig Comstock) Date: Fri, 24 Jun 2016 16:12:33 -0500 Subject: OsmocomBB hardware migration to SDR In-Reply-To: References: <20160624083309.GH14342@nataraja> Message-ID: Any thoughts about 2G versus 3G and beyond? I was sad to learn I probably won't have 2g for more than a few more years (2020 for t-mobile this year for AT&T). So my thoughts turn to newer mtk chips... I have one to start poking at... Zte obsidian with mt6735. No clue what "getting in" will entail or if hacking into mt6260 would reap rewards reusable for later mtk chips... Which seems somewhat likely. There is a sim5230a which supports 3G but I'm not sure what core/rf is in there yet. Thanks, Craig > On Jun 24, 2016, at 8:57 AM, ????? ??????? wrote: > > Hello Harald! > > > This is true, but even OpenBSC and related projects are suffering from a > > lack of attention. Despite being one of the founders of sysmocom, I > > really don't like to see the development and maintenance responsibility > > within one entity (or, let's say Holger and me privately, and sysmocom > > asa company). We need more contributors in all Osmocom projects. > > Well, IMHO this lack of contribution partially caused by ignorance of > some developers about the Osmocom project existence. Despite the fact, > that one and it's child projects already was presented on multiple > international forums and congresses, there are some people who aren't > observing these events or who have no opportunity to do so, I think. > > This is why I am currently writing the publications about Osmocom project > (mostly about OsmocomBB yet) for the most popular IT blog in Russia, named > Habrahabr. After the first publication I found, that many people didn't > knew anything about Open Source mobile telecommunications so far. But now > some of them are interested in contribution and research in this area. > I hope it will help to improve current situation. > > > Honestly, I'm not sure. The big difference is that there are commercial > > users of OpenBSC, OsmoBTS, etc., and they can afford to fund some of the > > work on those projects. For OsmocomBB I don't think there's much of a > > chacne for commercial interest. You can buy an entire phone for USD 10 > > these days, including a license for the protocol stack / software - so > > why bother investing in a "new" implementation of GSM. > > Yes, but except commercial demands there is also an educational side of > OsmocomBB. Personally for me, one has played a key role in mobile > telecommunications learning process. In our educational institutions > students are learning mobile networks very superficially, mostly the > physical basics of Um-interface, while some important hw and sw details > isn't covered as well. So, nowadays SDR devices becomes more and more > available, I think it's time to bring a 'wind of change' to this area. > > > For LTE, there's luckily the excellent free software srsUE > > implemntation. However, it requires a Core-i5, unless somebody manages > > to transplant the protocol stack onto one of the commercially found LTE > > baseband / PHY implementations actually used in phones. > > I saw this project, this guys exactly prefer to use SDR platforms. BTW, > do you know anything about industrial/commercial demands of this project? > > > Getting back further to your question: Even on the supported hardware > > (Calypso based phones), there are still many bugs and features missing, > > and nobody contributes. It makes me quite sad, as Andreas and I have > > put in a lot of energy to get the project going, but then nobody really > > got int carrying it along further. > > Yes, agree with you. Supported hardware takes a place in this problem > too. I know some people who have no opportunity to contribute because > it's impossible to find even one out of stock Motorola phone in their > locations. This makes me feeling sad too. > > > We all are, but mostly the work gets done when we are not looking but > > actually writing code :P No offence, I just couldn't resist... > > No problem, I am completely agree with you and going to start working as > soon as I will have free time. At the moment I have some pending exams. > > > All the best, I'd definitely love to see progress on the "SDR based PHY > > for OsmocomBB" front. > > Thank you very much! Your opinion is important for me. > > > With best regards, > Vadim Yanitskiy. > > 2016-06-24 14:33 GMT+06:00 Harald Welte : >> Hi Vadim, >> >> On Thu, Jun 23, 2016 at 06:45:45PM +0600, ????? ??????? wrote: >> > >> > It's no secret for everyone, that today OsmocomBB is not actively maintained >> > as well as OpenBSC, for example. >> >> This is true, but even OpenBSC and related projects are suffering from a >> lack of attention. Despite being one of the founders of sysmocom, I >> really don't like to see the development and maintenance responsibility >> within one entity (or, let's say Holger and me privately, and sysmocom >> asa company). We need more contributors in all Osmocom projects. >> >> > I think it's mostly due to supported hardware limitations. >> >> Honestly, I'm not sure. The big difference is that there are commercial >> users of OpenBSC, OsmoBTS, etc., and they can afford to fund some of the >> work on those projects. For OsmocomBB I don't think there's much of a >> chacne for commercial interest. You can buy an entire phone for USD 10 >> these days, including a license for the protocol stack / software - so >> why bother investing in a "new" implementation of GSM. >> >> There are some exceptions like test devices or virtual phones for load >> generation, but those are also not interesting to most people anymore in >> 2016. >> >> OsmocomBB doesn't support GPRS, EDGE, UMTS, HSPA and likely never will, >> unless a maniac comes around who invests several months of full-time + >> spare-time work into what most people would considre a hopeless cause. >> >> For LTE, there's luckily the excellent free software srsUE >> implemntation. However, it requires a Core-i5, unless somebody manages >> to transplant the protocol stack onto one of the commercially found LTE >> baseband / PHY implementations actually used in phones. >> >> Getting back further to your question: Even on the supported hardware >> (Calypso based phones), there are still many bugs and features missing, >> and nobody contributes. It makes me quite sad, as Andreas and I have >> put in a lot of energy to get the project going, but then nobody really >> got int carrying it along further. >> >> > Currently I am looking for developers interested in this subject. >> >> We all are, but mostly the work gets done when we are not looking but >> actually writing code :P No offence, I just couldn't resist... >> >> All the best, I'd definitely love to see progress on the "SDR based PHY >> for OsmocomBB" front. >> >> -- >> - Harald Welte http://laforge.gnumonks.org/ >> ============================================================================ >> "Privacy in residential applications is a desirable marketing option." >> (ETSI EN 300 175-7 Ch. A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajay.fuloria at gmail.com Tue Jun 28 12:35:45 2016 From: ajay.fuloria at gmail.com (Ajay Fuloria) Date: Tue, 28 Jun 2016 18:05:45 +0530 Subject: Issue with c139 Message-ID: Hi all, I have been using C123 for a long time with FTDI cable. I recently bought a C139 on which I wanted to run layer1 fw, i check the SW version using #02# and software version is "1.3.29", UART Flag is "0" On going through the mailing list I found these to be sufficient for using osmocom-bb but some how there is a problem on loading. When I use the fwg command ./osmocon -p /dev/ttyUSB0 -m c140 -c ../../target/firmware/board/compal_e86/layer1.highram.bin I get the following got 2 bytes from modem, data looks like: 04 81 .. got 5 bytes from modem, data looks like: 1b f6 02 00 41 ....A got 1 bytes from modem, data looks like: 01 . got 1 bytes from modem, data looks like: 40 @ Received PROMPT1 from phone, responding with CMD read_file(chainloader): file_size=32, hdr_len=4, dnload_len=15341 got 1 bytes from modem, data looks like: 1b . got 1 bytes from modem, data looks like: f6 . got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 43 C Received PROMPT2 from phone, starting download handle_write(): 4096 bytes (4096/15341) handle_write(): 4096 bytes (8192/15341) handle_write(): 4096 bytes (12288/15341) handle_write(): 3053 bytes (15341/15341) handle_write(): finished It receives prompt2 and loads the file but doesn't move ahead, the phone does not show layer1 on the screen either. when i use fwg command (add -m c140xor ) ./osmocon -p /dev/ttyUSB0 -m c140xor -c ../../target/firmware/board/compal_e86/layer1.highram.bin I get the fwg: got 1 bytes from modem, data looks like: 04 . got 1 bytes from modem, data looks like: 81 . got 5 bytes from modem, data looks like: 1b f6 02 00 41 ....A got 1 bytes from modem, data looks like: 01 . got 1 bytes from modem, data looks like: 40 @ Received PROMPT1 from phone, responding with CMD read_file(chainloader): file_size=32, hdr_len=4, dnload_len=15341 got 1 bytes from modem, data looks like: 1b . got 1 bytes from modem, data looks like: f6 . got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 43 C Received PROMPT2 from phone, starting download handle_write(): 4096 bytes (4096/15341) handle_write(): 4096 bytes (8192/15341) handle_write(): 4096 bytes (12288/15341) handle_write(): 3053 bytes (15341/15341) handle_write(): finished got 1 bytes from modem, data looks like: 1b . got 1 bytes from modem, data looks like: f6 . got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 03 . got 1 bytes from modem, data looks like: 57 W Received MAGIC NACK from phone, you need to have "1003" at 0x803ce0 got 1 bytes from modem, data looks like: 66 f got 1 bytes from modem, data looks like: 74 t got 1 bytes from modem, data looks like: 6d m got 1 bytes from modem, data looks like: 74 t got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 6c l Received FTMTOOL from phone, ramloader has aborted got 1 bytes from modem, data looks like: 65 e got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 72 r It now move ahead and says the received MAGIC NACK and also that you need to have "1003" at 0x803ce0, this is a documented problem and i believe in compal_e86 binaries must have been taken care of. Any ideas on how can I get around this and load the firmware on my c139 ? I am again usung the same cable FTDI which works perfectly with c123. My setup is native Ubuntu 14.04 , host machine and Intel i5.. (hw does not seem to be the problem) Looking forward to hear from you guys. Thanks in advance. Regards, Ajay merlinsignals.blogspot.in -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Tue Jun 28 12:51:57 2016 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Tue, 28 Jun 2016 18:51:57 +0600 Subject: OsmocomBB hardware migration to SDR In-Reply-To: References: <20160624083309.GH14342@nataraja> Message-ID: As I know, both L2 and L3 in 3G is the same as in 2G. Only L1 isn't. So, we can use already implemented things in OsmocomBB without any problems. The only required thing is MS side UMTS implementation. Correct me, if I'm wrong. With best regards, Vadim Yanitskiy. 2016-06-25 3:12 GMT+06:00 Craig Comstock : > Any thoughts about 2G versus 3G and beyond? I was sad to learn I probably > won't have 2g for more than a few more years (2020 for t-mobile this year > for AT&T). So my thoughts turn to newer mtk chips... I have one to start > poking at... Zte obsidian with mt6735. No clue what "getting in" will > entail or if hacking into mt6260 would reap rewards reusable for later mtk > chips... Which seems somewhat likely. > > There is a sim5230a which supports 3G but I'm not sure what core/rf is in > there yet. > > Thanks, > Craig > > On Jun 24, 2016, at 8:57 AM, ????? ??????? wrote: > > Hello Harald! > > > This is true, but even OpenBSC and related projects are suffering from a > > lack of attention. Despite being one of the founders of sysmocom, I > > really don't like to see the development and maintenance responsibility > > within one entity (or, let's say Holger and me privately, and sysmocom > > asa company). We need more contributors in all Osmocom projects. > > Well, IMHO this lack of contribution partially caused by ignorance of > some developers about the Osmocom project existence. Despite the fact, > that one and it's child projects already was presented on multiple > international forums and congresses, there are some people who aren't > observing these events or who have no opportunity to do so, I think. > > This is why I am currently writing the publications about Osmocom project > (mostly about OsmocomBB yet) for the most popular IT blog in Russia, named > Habrahabr. After the first publication I found, that many people didn't > knew anything about Open Source mobile telecommunications so far. But now > some of them are interested in contribution and research in this area. > I hope it will help to improve current situation. > > > Honestly, I'm not sure. The big difference is that there are commercial > > users of OpenBSC, OsmoBTS, etc., and they can afford to fund some of the > > work on those projects. For OsmocomBB I don't think there's much of a > > chacne for commercial interest. You can buy an entire phone for USD 10 > > these days, including a license for the protocol stack / software - so > > why bother investing in a "new" implementation of GSM. > > Yes, but except commercial demands there is also an educational side of > OsmocomBB. Personally for me, one has played a key role in mobile > telecommunications learning process. In our educational institutions > students are learning mobile networks very superficially, mostly the > physical basics of Um-interface, while some important hw and sw details > isn't covered as well. So, nowadays SDR devices becomes more and more > available, I think it's time to bring a 'wind of change' to this area. > > > For LTE, there's luckily the excellent free software srsUE > > implemntation. However, it requires a Core-i5, unless somebody manages > > to transplant the protocol stack onto one of the commercially found LTE > > baseband / PHY implementations actually used in phones. > > I saw this project, this guys exactly prefer to use SDR platforms. BTW, > do you know anything about industrial/commercial demands of this project? > > > Getting back further to your question: Even on the supported hardware > > (Calypso based phones), there are still many bugs and features missing, > > and nobody contributes. It makes me quite sad, as Andreas and I have > > put in a lot of energy to get the project going, but then nobody really > > got int carrying it along further. > > Yes, agree with you. Supported hardware takes a place in this problem > too. I know some people who have no opportunity to contribute because > it's impossible to find even one out of stock Motorola phone in their > locations. This makes me feeling sad too. > > > We all are, but mostly the work gets done when we are not looking but > > actually writing code :P No offence, I just couldn't resist... > > No problem, I am completely agree with you and going to start working as > soon as I will have free time. At the moment I have some pending exams. > > > All the best, I'd definitely love to see progress on the "SDR based PHY > > for OsmocomBB" front. > > Thank you very much! Your opinion is important for me. > > > With best regards, > Vadim Yanitskiy. > > 2016-06-24 14:33 GMT+06:00 Harald Welte : > >> Hi Vadim, >> >> On Thu, Jun 23, 2016 at 06:45:45PM +0600, ????? ??????? wrote: >> > >> > It's no secret for everyone, that today OsmocomBB is not actively >> maintained >> > as well as OpenBSC, for example. >> >> This is true, but even OpenBSC and related projects are suffering from a >> lack of attention. Despite being one of the founders of sysmocom, I >> really don't like to see the development and maintenance responsibility >> within one entity (or, let's say Holger and me privately, and sysmocom >> asa company). We need more contributors in all Osmocom projects. >> >> > I think it's mostly due to supported hardware limitations. >> >> Honestly, I'm not sure. The big difference is that there are commercial >> users of OpenBSC, OsmoBTS, etc., and they can afford to fund some of the >> work on those projects. For OsmocomBB I don't think there's much of a >> chacne for commercial interest. You can buy an entire phone for USD 10 >> these days, including a license for the protocol stack / software - so >> why bother investing in a "new" implementation of GSM. >> >> There are some exceptions like test devices or virtual phones for load >> generation, but those are also not interesting to most people anymore in >> 2016. >> >> OsmocomBB doesn't support GPRS, EDGE, UMTS, HSPA and likely never will, >> unless a maniac comes around who invests several months of full-time + >> spare-time work into what most people would considre a hopeless cause. >> >> For LTE, there's luckily the excellent free software srsUE >> implemntation. However, it requires a Core-i5, unless somebody manages >> to transplant the protocol stack onto one of the commercially found LTE >> baseband / PHY implementations actually used in phones. >> >> Getting back further to your question: Even on the supported hardware >> (Calypso based phones), there are still many bugs and features missing, >> and nobody contributes. It makes me quite sad, as Andreas and I have >> put in a lot of energy to get the project going, but then nobody really >> got int carrying it along further. >> >> > Currently I am looking for developers interested in this subject. >> >> We all are, but mostly the work gets done when we are not looking but >> actually writing code :P No offence, I just couldn't resist... >> >> All the best, I'd definitely love to see progress on the "SDR based PHY >> for OsmocomBB" front. >> >> -- >> - Harald Welte >> http://laforge.gnumonks.org/ >> >> ============================================================================ >> "Privacy in residential applications is a desirable marketing option." >> (ETSI EN 300 175-7 Ch. >> A6) >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig_comstock at yahoo.com Wed Jun 29 04:44:04 2016 From: craig_comstock at yahoo.com (Craig Comstock) Date: Wed, 29 Jun 2016 04:44:04 +0000 (UTC) Subject: osmocom-bb port to MediaTek chips (6260, 6261, 6735) In-Reply-To: References: <20160624083309.GH14342@nataraja> Message-ID: <171771677.677868.1467175444822.JavaMail.yahoo@mail.yahoo.com> So I played around with the ZTE Obsidian I have and found that the fernly usb loader works somewhat. I dug into some android linux kernel sources for MT6735 and found some memory map-like files and read the data there with fernly usb loader and it's use of MT Bootloader commands. Next I think I'll try and see if I can parse out the vibrator control from linux and make it work via fernly, eventually get the fernly shell working and from there use their qemu remote debug method to poke around and start working on L1. In the "gonkai to open source" blog post they mention cracking open the MT source and translating "facts" to their scriptic language. Does this seem viable? When I get more working I'll push the changes and some info up to my github repo and post a message here. If anyone has some ideas on how to start on this project please chime in. -Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajay.fuloria at gmail.com Tue Jun 28 11:51:34 2016 From: ajay.fuloria at gmail.com (Ajay Fuloria) Date: Tue, 28 Jun 2016 11:51:34 -0000 Subject: Issue with C139 Message-ID: Hi all, I have been using C123 for a long time with FTDI cable. I recently bought a C139 on which I wanted to run layer1 fw, i check the SW version using #02# and software version is "1.3.29", UART Flag is "0" On going through the mailing list I found these to be sufficient for using osmocom-bb but some how there is a problem on loading. When I use the fwg command ./osmocon -p /dev/ttyUSB0 -m c140 -c ../../target/firmware/board/compal_e86/layer1.highram.bin I get the following got 2 bytes from modem, data looks like: 04 81 .. got 5 bytes from modem, data looks like: 1b f6 02 00 41 ....A got 1 bytes from modem, data looks like: 01 . got 1 bytes from modem, data looks like: 40 @ Received PROMPT1 from phone, responding with CMD read_file(chainloader): file_size=32, hdr_len=4, dnload_len=15341 got 1 bytes from modem, data looks like: 1b . got 1 bytes from modem, data looks like: f6 . got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 43 C Received PROMPT2 from phone, starting download handle_write(): 4096 bytes (4096/15341) handle_write(): 4096 bytes (8192/15341) handle_write(): 4096 bytes (12288/15341) handle_write(): 3053 bytes (15341/15341) handle_write(): finished It receives prompt2 and loads the file but doesn't move ahead, the phone does not show layer1 on the screen either. when i use fwg command (add -m c140xor ) ./osmocon -p /dev/ttyUSB0 -m c140xor -c ../../target/firmware/board/compal_e86/layer1.highram.bin I get the fwg: got 1 bytes from modem, data looks like: 04 . got 1 bytes from modem, data looks like: 81 . got 5 bytes from modem, data looks like: 1b f6 02 00 41 ....A got 1 bytes from modem, data looks like: 01 . got 1 bytes from modem, data looks like: 40 @ Received PROMPT1 from phone, responding with CMD read_file(chainloader): file_size=32, hdr_len=4, dnload_len=15341 got 1 bytes from modem, data looks like: 1b . got 1 bytes from modem, data looks like: f6 . got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 43 C Received PROMPT2 from phone, starting download handle_write(): 4096 bytes (4096/15341) handle_write(): 4096 bytes (8192/15341) handle_write(): 4096 bytes (12288/15341) handle_write(): 3053 bytes (15341/15341) handle_write(): finished got 1 bytes from modem, data looks like: 1b . got 1 bytes from modem, data looks like: f6 . got 1 bytes from modem, data looks like: 02 . got 1 bytes from modem, data looks like: 00 . got 1 bytes from modem, data looks like: 41 A got 1 bytes from modem, data looks like: 03 . got 1 bytes from modem, data looks like: 57 W Received MAGIC NACK from phone, you need to have "1003" at 0x803ce0 got 1 bytes from modem, data looks like: 66 f got 1 bytes from modem, data looks like: 74 t got 1 bytes from modem, data looks like: 6d m got 1 bytes from modem, data looks like: 74 t got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 6c l Received FTMTOOL from phone, ramloader has aborted got 1 bytes from modem, data looks like: 65 e got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 72 r got 1 bytes from modem, data looks like: 6f o got 1 bytes from modem, data looks like: 72 r It now move ahead and says the received MAGIC NACK and also that you need to have "1003" at 0x803ce0, this is a documented problem and i believe in compal_e86 binaries must have been taken care of. Any ideas on how can I get around this and load the firmware on my c139 ? I am again usung the same cable FTDI which works perfectly with c123. My setup is native Ubuntu 14.04 , host machine and Intel i5.. (hw does not seem to be the problem) Looking forward to hear from you guys. Thanks in advance. Regards, Ajay merlinsignals.blogspot.in -------------- next part -------------- An HTML attachment was scrubbed... URL: