24 Oct
2018
24 Oct
'18
11:40 a.m.
Dear Osmocom team,
Omar has thankfully submitted patches for inclusion of OC-2G support
to gerrit, see https://gerrit.osmocom.org/#/c/osmo-bts/+/11447/ for the
bulk of the code.
An initial review showed there are *many* parts that are identical to
osmo-bts-litecell15, and we generally don't like "copy+paste"
programming. In the end we have multiple compies of essentially the
same source files, becoming a maintenance problem over time, when fixes
are applied to one copy, but not the other.
I've manually looked through each of the files and looked at the
differences between the oc2g and the lc15 counterpart.
== 100% identical to osmo-bts-sysmo or osmo-bts-lc15:
oml_router.c
oml_router.h
misc/oc2gbts_nl.c
== 99% identical to lc15 (just names changed)
hw_misc.h
hw_misc.c
l1_transp.h
l1_trans_hw.c
oc2gbts.c / lc15bts.c
oc2gbts_vty.c / lc15bts_vty.c
oml.c
tch.c
utils.c
utils.h
l1_if.h
misc/oc2gbts_bts.h
misc/oc2gbts_bid.h
misc/oc2gbts_clock.h
misc/oc2gbts_clock.c
misc/oc2gbts_led.c
misc/oc2gbts_swd.c
misc/oc2gbts_swd.h
== 80% identical to lc15 (some small changes)
l1_if.c
misc/oc2gbts_bts.c
misc/oc2gbts_mgr.c
misc/oc2gbts_mgr.h
misc/oc2gbts_mgr_nl.c
misc/oc2gbts_temp.c
misc/oc2gbts_temp.h
== more differences compared to lc15, possibly not intentional? / what to do?
misc/oc2gbts_temp.c
misc/oc2gbts_mgr_vty.c
misc/oc2gbts_misc.c
misc/oc2gbts_par.c
misc/oc2gbts_power.c
misc/oc2gbts_util.c
So we have to discuss how to go about this. The 100% identical files
are easy, one can simply lik the existing implementation. We could also
introduce a "src/nuran-common" directory for common code between the
different models.
For those parts with less similarity, this may require some refactoring,
so that common/shared code goes to common/shared files and really only
those bits that differ are handled in the respective implementations.
Given that osmo-bts-litecell15 also started as copy of osmo-bts-sysmo,
there may be room for further unification, but let's not conflate those
two discussions.
In terms of process,
* we could first merge all the copies and then further unify the code, or
* we could first modify the existing core/lc15 code to be able to merge
OC2G coe without introducing lots of copied code.
Any comments/suggestions/ideas?
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
24 Oct
24 Oct
12:41 p.m.
Hi,
We should add another point into the discussion. Who and how are going
to test these changes?
If I understand correctly code from Omar is rebased on top of current
osmo-bts master, and has been tested at least in some general scenarios?
If that's the case, it probably makes sense to merge them as it is now,
and then either or both:
* Do the refactoring and ask someone with an OC-2G to test again after
refactoring
* Add automatic testing for OC-2G to make sure we don't break stuff
** Add support for OC-2G in osmo-gsm-tester
** Add support for OC-2G in TTCN3(+osmo-gsm-tester)
Once it's merged, we can create a ticket with information from your
e-mail on how to do the refactor.
Regards,
Pau
--
- Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
1:01 p.m.
On Wed, Oct 24, 2018 at 12:41:19PM +0200, Pau Espin Pedrol wrote:
We should add another point into the discussion. Who
and how are going to
test these changes?
Using actual OC-2G hardware with both osmo-gsm-tester as well as with
BTS_Tests.ttcn, even with an extended version of BTS_Tests.ttcn
addressing its various gaps in coverage so far.
If I understand correctly code from Omar is rebased on
top of current
osmo-bts master, and has been tested at least in some general scenarios?
I don't know anything about that, sorry. I would presume some basic
manual testing with a few phones was performed?
--
- 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 Oct
29 Oct
7:56 a.m.
Hie
Does anyone know a good place to get OC-2G hardware manufactured.
Regards
Shingy
On Wed, Oct 24, 2018 at 1:10 PM Harald Welte <laforge(a)gnumonks.org> wrote:
On Wed, Oct 24, 2018 at 12:41:19PM +0200, Pau Espin
Pedrol wrote:
We should add another point into the discussion.
Who and how are going to
test these changes?
Using actual OC-2G hardware with both osmo-gsm-tester as well as with
BTS_Tests.ttcn, even with an extended version of BTS_Tests.ttcn
addressing its various gaps in coverage so far.
If I understand correctly code from Omar is
rebased on top of current
osmo-bts master, and has been tested at least in some general scenarios?
I don't know anything about that, sorry. I would presume some basic
manual testing with a few phones was performed?
--
- 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)
9:46 p.m.
Hi Shingy,
this question is a bit off-topic here, but...
On Mon, Oct 29, 2018 at 08:56:45AM +0200, Shingirai Simba wrote:
Does anyone know a good place to get OC-2G hardware
manufactured.
At this point, to the best of my knowledge, OC-2G yet has to deliver on their
open hardware promise. The design files like schematics / PCB layouts / mechanical
drawings / BOM, etc. are yet to be published. I could only find those of OC-SDR and
OC-LTE on the OpenCellular git repository so far.
I did inquire with the OpenCellular working group chair (Kashif) and asked
for those files to be released.
Without those files, it's hard to guess who could be a good match to manufacture
the related units. The details of the design determine the complexity and therefore
the required capabilities for any contract manufacturer.
In any case, even with [hopefully] all the related files released as OSHW, there's
the equally important question of validation, production testing, calibration, etc.
which needs to be implemented and executed.
Which brings me to the question of: How many units do you need? I think unless
you have at least a binding quantity of several hundred and a realistic forecast to
thousands of units, there's very little point in wasting time thinking about
setting up any alternative / custom manufacturing, rather than to buy
from the original supplier/vendor (NuRAN).
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
8 Nov
8 Nov
12:09 p.m.
New subject: OC-2G design files released (was Re: OC-2G merge to osmo-bts)
Hi all,
following up on a thread from ~ 10 days ago:
On Mon, Oct 29, 2018 at 09:46:37PM +0100, Harald Welte wrote:
At this point, to the best of my knowledge, OC-2G yet
has to deliver on their
open hardware promise. The design files like schematics / PCB layouts / mechanical
drawings / BOM, etc. are yet to be published. I could only find those of OC-SDR and
OC-LTE on the OpenCellular git repository so far.
There has been an update from OpenCellular today:
OC-2G files are now pushed into mainline:
https://github.com/Telecominfraproject/OpenCellular/tree/master/electronics… <<
electronics files.
https://github.com/Telecominfraproject/OpenCellular/tree/master/hardware/oc… <<
enclosure/system
I havent yet had time to look at them myself, but I know there are several
people interested in it here...
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
2004
days inactive
2019
days old
5 comments
3 participants
participants (3)
-
Harald Welte -
Pau Espin Pedrol -
Shingirai Simba