23 Jun
2016
23 Jun
'16
2:45 p.m.
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!
С наилучшими пожеланиями,
Яницкий Вадим.
23 Jun
23 Jun
3:30 p.m.
Hi Vadim,
On Thu, Jun 23, 2016 at 3:45 PM, Вадим Яницкий <axilirator(a)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
4:56 p.m.
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(a)gmail.com>
To: Вадим Яницкий <axilirator(a)gmail.com>
Cc: baseband-devel <baseband-devel(a)lists.osmocom.org>rg>; Andreas Eversberg
<jolly(a)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(a)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
24 Jun
24 Jun
10:14 a.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
1:02 p.m.
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(a)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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
23 Jun
23 Jun
6:56 p.m.
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(a)gmail.com>
:
> Hi Vadim,
>
> On Thu, Jun 23, 2016 at 3:45 PM, Вадим Яницкий <axilirator(a)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
>
24 Jun
24 Jun
10:11 a.m.
New subject: (xtrx sim card interface) Re: OsmocomBB hardware migration to SDR
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
10:29 a.m.
New subject: (xtrx sim card interface) Re: OsmocomBB hardware migration to SDR
Hi Harald,
On Jun 24, 2016 11:15 AM, "Harald Welte" <laforge(a)gnumonks.org> wrote:
On Thu, Jun 23, 2016 at 04:30:42PM +0300, Alexander
Chemeris wrote:
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
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.
10:33 a.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
1:30 p.m.
On Fri, Jun 24, 2016 at 11:33 AM, Harald Welte <laforge(a)gnumonks.org> wrote:
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
On Thu, Jun 23, 2016 at 06:45:45PM +0600, Вадим
Яницкий wrote:
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.
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.
1:56 p.m.
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(a)gmail.com> wrote:
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
On Fri, Jun 24, 2016 at 11:33 AM, Harald Welte
<laforge(a)gnumonks.org> wrote:
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.
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.
3:57 p.m.
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(a)gnumonks.org>rg>:
> 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(a)gnumonks.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
> (ETSI EN 300 175-7 Ch.
> A6)
>
11:12 p.m.
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(a)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(a)gnumonks.org>rg>:
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
28 Jun
28 Jun
2:51 p.m.
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(a)yahoo.com>om>:
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(a)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(a)gnumonks.org>rg>:
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(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch.
A6)
29 Jun
29 Jun
6:44 a.m.
New subject: osmocom-bb port to MediaTek chips (6260, 6261, 6735)
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
1 Jul
1 Jul
9:56 p.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
2864
days inactive
2872
days old
baseband-devel@lists.osmocom.org
15 comments
5 participants
participants (5)
-
Alexander Chemeris -
Craig Comstock -
Harald Welte -
Vadim Yanitskiy -
Вадим Яницкий