3 Jan
2013
3 Jan
'13
4:20 p.m.
On Thu, Jan 3, 2013 at 8:10 AM, jolly <andreas(a)eversberg.eu> wrote:
hi thomas,
i saw your work for your master of science. i must say: congratulations! it
really brings both openbts and openbsc projects together. it allows to use
both sdr and real bts together in one network. as shown at the chaos
communication congress (29c3), sylvain presented a compal phone with
firmware to turn it into a trx for openbts. with your code, it is possible
to use it with openbsc. this is something i aimed at too.
i like to know if your work is (only) a proof of concept or something that
could be used in a productive environment. i would help to review the
changes to osmo-bts and help to get them merged to the current master
branch. iirc, there are just some fixes and minor issues to solve.
Thanks, I'm glad my contribution is useful in some way to the
community. I think it's safe to say it's mostly proof of concept;
although I was able to get it running and working pretty well on my
setup, others have told me they have problems. As I graduated and no
longer have a USRP, I can't really do much troubleshooting
unfortunately. Also since I was pressed for time to graduate, the code
may not have all the bugs worked out or be fully tested for all
different GSM scenarios and machines.
You are correct about the osmo-bts changes being minor fixes. I
remember Harald wanted me to get everything straightened up, but I
just have never had the time. I'm sure any help from you on this work
would be appreciated. His plan was:
* remove your re-implemented headers and use our real header files
(git clone git@git.sysmocom.de:sysmo-bts/femtobts-firmware.git)
* get it working with most current public version of OpenBTS and osmo-bts
* we can merge the osmo-bts part almost immediately
* see if and how the OpenBTS part can be merged into the official range
networks tree, or keep a custom git tree on git.osmocom.org
i already had planed a similar approach: but instead of using source from
openbts, i wanted to do scheduling and coding/fec inside osmo-bts. code from
libosmocore could be used for that. instead of using the device to the
femto-dsp as an interface, i wanted to add the trx manager's udp interface
to osmo-bts code. this way it would not require an additional process to run
a trx with osmo-bts. special things regarding to the trx could be configured
with the osmo-bts' config.
as some guys at the 29c3 might have noticed, i was a little shocked when i
read about your work. i was highly motivated to do a work that i found it
was already done, so my motivation dropped to zero. i would like to
apologize for my bad mood at the congress.
Your plan to discard the extra OpenBTS process by moving its L1 to
osmo-bts sounds great. I would have preferred to do it that way if I
had more time. I'm sorry to have ruined your motivation, hopefully you
can be inspired to improve/merge with my work! Let me know if I can
help with anything (with my limited capabilities).
-Tom C.
best regards,
andreas