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! С наилучшими пожеланиями, Яницкий Вадим.
Hi Vadim, On Thu, Jun 23, 2016 at 3:45 PM, Вадим Яницкий <axilirator@gmail.com> 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
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 <alexander.chemeris@gmail.com> To: Вадим Яницкий <axilirator@gmail.com> Cc: baseband-devel <baseband-devel@lists.osmocom.org>; Andreas Eversberg <jolly@eversberg.eu> 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, Вадим Яницкий <axilirator@gmail.com> 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
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 <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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 <laforge@gnumonks.org> 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 <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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 <alexander.chemeris@gmail.com> :
Hi Vadim,
On Thu, Jun 23, 2016 at 3:45 PM, Вадим Яницкий <axilirator@gmail.com> 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
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 <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Harald, On Jun 24, 2016 11:15 AM, "Harald Welte" <laforge@gnumonks.org> 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
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 <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Fri, Jun 24, 2016 at 11:33 AM, Harald Welte <laforge@gnumonks.org> 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
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 <alexander.chemeris@gmail.com> wrote:
On Fri, Jun 24, 2016 at 11:33 AM, Harald Welte <laforge@gnumonks.org> 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
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 <laforge@gnumonks.org>:
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 <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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, Вадим Яницкий <axilirator@gmail.com> 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 <laforge@gnumonks.org>:
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 <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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 <craig_comstock@yahoo.com>:
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, Вадим Яницкий <axilirator@gmail.com> 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 <laforge@gnumonks.org>:
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 <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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
On Tue, Jun 28, 2016 at 06:51:57PM +0600, Vadim Yanitskiy wrote:
As I know, both L2 and L3 in 3G is the same as in 2G. Only L1 isn't.
Wrong. Only some part of L3 is inherited (and significantly extended). L2 is completely different, L1 and the radio modem couldn't be any more different. The L3 "changes" on the PS side are bigger than those on the CS side. UMTS is not one telphony system, but more like an arbitray number of tools in a toolbox able to create any possible telephony system from it. Try understanding the phyiscal channels, transport channels and transport channel bundles of L2. That alone is a nightmare of complexity. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
participants (5)
-
Alexander Chemeris -
Craig Comstock -
Harald Welte -
Vadim Yanitskiy -
Вадим Яницкий