tetra December 2016

tetra@lists.osmocom.org

1 participants
3 discussions

Revamping osmo-tetra
by Harald Welte 14 Jan '17

14 Jan '17

Dear all, osmo-tetra has been without much progress (or the much needed gnuradio 3.7 support) for way too long time. I would like to see the project move forward. There was a lot of good work by sq5bpf, but unfortunately that work has happened in a fork outside osmocom.org. Also, the code has various coding style issues and the commit messages never consist out of a very short single line. To the benefit of other reders and developers, that needs to be expanded a bit. I would like to invite sq5bpf to become part of the Osmocom TETRA proejct and would love to see a lot of that code go "mainline". Also, I am open to eventual co-maintainership. In order to facilitate this, I have moved osmo-tetra into gerrit.osmocom.org. This allows us to have a structured community review process (which I hope some of you will participate, particularly our friend horiz0n) and vote on patches before merging them. sq5bpf: I hope you have some time and energy to go the extra mile and get your code merged and work together on a better osmo-tetra for everyone. I've started with a re-base of the sq5bpf/master branch on top of the osmocom/master branch and pushed that to laforge/sq5bpf-rebase-20161218 >From a review through the patches, I believe we should create several feature branches: 1) minor fixes and extensions 2) SDS related 3) voice related Looking through the commits, I have several comments and questions (mostly a result of the very terse commit logs, which is exactly a reason why they should become more verbose): * ppm support. Is this about some specific hardware / gnuardio source? Do you expect it to break other receivers? How can this be generalized? edb7fce4ac8496ae1fe0a920bd49d7affcdd83c8 (simdemod2) * simdemod2: should just be merged cae3e848751d746431300dc65f7fc178f5e1bf35 (simdemod shellscript fixes) * should be squashed in the above e7be1e8672d48aebd1b6595a13c8bdd7a9037407 (codec tweaks) * This neesd to be re-split into a patch series like the original, and simply modify those original patches + README rather than adding a separate set of those 6587739eb074741e64ad46777383a2257b28ea7e (correct tetra_upper_mac.c) * what does it correct * remove all the whitespace changes! * adopt osmocom coding style throughout the code * replace magic numbers with explanatiosn and/or #defines * split into individual bug fixes and extension patches 593b9821e1267e19db9922fdd74525cc0f7c73c5 (fix sds crash) * squash in whatever commit it fixes 8acfc998f0b7463f7ca3a303061611b5edbd072b (LIP / location system) * remove all the whitespace changes! * adopt osmocom coding style throughout the code 948ca3ebdde088ff68a8479364c12f24d8c91099 (add missing break) * squash in whatever commit it fixes 538e8485637276a95216823770ede1e137279ae1 (better lip parsing) * remove all the whitespace changes! * adopt osmocom coding style throughout the code * explain what exactly is better/extended in commitlog bdf8c371b1d1b5662b031fdad0a3568129b90db7 (var fix) * squash in whatever commit it fixes a1fb5c348e6fb1102185131f38df8a8459a0cd83 (codec 64bit compilation) * modify on top of cleaned up e7be1e8672d48aebd1b6595a13c8bdd7a9037407 4eeb3340ba75ad1a823dba8eb66031f80a5d5019 (gr 3.6 and 3.7 versions) * copy+paste style development is rather ugly, is there no way to share at least parts of the code and create a module that works with multiple versions? * if that's not possible, we should simply abandon all old code and require 3.7 or higher. a6b961a7554222dc3d9ce4ae25d859a645bbf109 (float2bits inside tetra-rx) * the proper way is to have the related code once and use it in multiple executables, rather than copying it around 6733e6c6edc2091b5e5c700cb26d7635dc08fac5 (move sds parsing to tetra_sds.c) * should be squashed with original commits to avoid adding it to tetra_upper_mac.c in the first place 72008e4418cd222cfe1846513cb8345709cdab78 (company-assigned tetra IDs) * great, but avoid mixing whitespace change with functional changes 7145d09d5b236881edec659883f595f40fe38b88 (remove fifo) * if the FIFO is no longer needed, this commit should be squashed with those that introduce the FIFO support in the first place 59b036f59550a6d082b3d51635e381c4ef7e700b (add includes) * squash with whatever commit that requires those #includes 6d38669f055b0355a71683a4b10fe3fea852b868 (fix d-setup parser) * squash into commit that introduces the to-be-fixed code Looking forward to getting this cleaned up and merged :) 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)

2 2

Osmo tetra -DMO option
by Daniel Kosi 18 Dec '16

18 Dec '16

Hello! I would like to know it is possible to add DMO rx option in osmo tetra and how? It only support TMO for now,am i right? Have a nice day!

2 1

RFC: OsmoDevCon 2017 planning
by Harald Welte 11 Dec '16

11 Dec '16

Dear Osmocom Community, [please respect the Reply-To and post all follow-up discussion to this to openbsc(a)lists.osmocom.org, so we avoid having long threads cross-posted to several mailing lists.] >From 2012 to 2016 we were running a series of small, invitation-only Osmocom Developer Conferences. Access was intentionally restricted to those community members who have demonstrated an existing track record of contribution to any of the projects under the Osmocom umbrella. This format of a small, tightly knit group of about 20 people has been successful over the years, and I have received a lot of positive feedback from past participants. On the other hand, the Osmocom project has grown in scope and diversity, and some of those projects don't have all that much relationship to each other - except being started by people from within the same group. There's the cellular communications (GSM/GPRS/EDGE/UMTS and hopefully at some point LTE) protocols which is attracting a lot of professional users. And then there's pure community projects like rtl-sdr, OsmocomBB, OsmocomGMR and many other efforts. Particularly the cellular infrastructure projects (OsmoBTS, OsmoPCU, OsmoBTS, OsmoNITB, OsmoSGSN, OpenGGSN, OsmoIuh & co) are somehow "standing out" of the othe projects in the context of having a wider user bsae, and in that user base also primarily commercial users. So I'd like to start a discussion on how to possibly change the event format to accomodate the various interests and parties. I definitely don't want to loose the "annual meeting of old friends" atmosphere, while at the same time also opening up to other interested parties. One idea would be to keep OsmoDevCon as-is and have a separate event where non-contributing/developing users / sysadmins / system integrators could also be attending. Another idea would be to split into a 'user day' and 'developer days' format. This is something the netfilter developer workshops have been using for many years, and from my limited insight quite successfully so. The "user day" is more like a traditional tech conference, with a large auditorium and talks oriented towards users / sysadmins / integrators of the software. The "developer days" are the invitation-only part, for known contributing developers only, similar to what we have at OsmoDevCon. Having both events (or both parts of an event) back-to-back has the advantage that a large number of potential speakers for the 'user day' are already present, and they don't have to travel yet another time. One could even structure it further and say we have one user day, one public 'Osmocom cellular developer day' and then the closed 'OsmoDevCon classic', maybe reduced from 4 days to 3 or even 2 days only? What is the general opinion about this? Are there people lurking on this list who would be interested in attending a public 'user day' or even 'developer day' about the Osmocom cellular projects, with presentations and workshops around topics such as running Osmocom based cellular networks? In terms of when/where, I would suggest to keep the tradition of April in Berlin/Germany. But I'm of course very happy if somebody wants to host it some place else... Regards, and looking forward to meeting you [again] in 2017, 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)

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tetra December 2016