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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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@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
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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@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@gnumonks.org> http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
participants (3)
-
Harald Welte -
Pau Espin Pedrol -
Shingirai Simba