From laforge at gnumonks.org  Sat Dec 10 19:11:39 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 10 Dec 2016 20:11:39 +0100
Subject: RFC: OsmoDevCon 2017 planning
Message-ID: <20161210191139.rxtzqrdmsifwgi4s@nataraja>

Dear Osmocom Community,

[please respect the Reply-To and post all follow-up discussion to this
 to openbsc at 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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Sun Dec 18 01:11:55 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 18 Dec 2016 02:11:55 +0100
Subject: Osmo tetra -DMO option
In-Reply-To: <CAASEGBbbM9utzBExxNxcTVVczNB02kSGWFE4PeMvmhOLiB9FfQ@mail.gmail.com>
References: <CAASEGBbbM9utzBExxNxcTVVczNB02kSGWFE4PeMvmhOLiB9FfQ@mail.gmail.com>
Message-ID: <68EC7B71-7AA7-40FD-9BDF-458E84A4BD7F@gnumonks.org>

Sorry for the late response.

The dqpsk demodulator which we use is very slow in synchronizing to the symbols of the signal. So it only works with continuous signals like they are used in TMO (particularly downlink) where the BTS broadcasts the signal continuously.

For DMO to work (at least on short tslk-spurts) you would need to implement/use a demodulator that syncs within one tetra burst period.

Hope this helps.

Regards,
Harald
-- 
Sent from a mobile device. Please excuse my brevity.


From laforge at gnumonks.org  Sun Dec 18 14:24:50 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 18 Dec 2016 15:24:50 +0100
Subject: Revamping osmo-tetra
Message-ID: <20161218142450.5k4hzeguynuslw22@nataraja>

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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at gnumonks.org  Sun Dec 18 23:32:23 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 19 Dec 2016 00:32:23 +0100
Subject: Revamping osmo-tetra
In-Reply-To: <alpine.DEB.2.11.1612182306430.649@mailn.lipkowski.org>
References: <20161218142450.5k4hzeguynuslw22@nataraja>
 <alpine.DEB.2.11.1612182306430.649@mailn.lipkowski.org>
Message-ID: <20161218233223.gcusynm6upybjmyn@nataraja>

Hi Jacek,

thanks for your quick answer.

On Sun, Dec 18, 2016 at 11:29:57PM +0100, Jacek Lipkowski wrote:
> 
> Thanks for the invitation. I'd also like to see the code im mainline. The
> only reason for the fork was that it was far too ugly to send you patches :)

Well, I also didn't really pay any attention to osmo-tetra during recent
years, but I finally merged the gr3.7 branch and some of the smaller
fixes (etsi voice codec download script, etsi voice code 64bit,
simdemod2).

> Yes, i have the energy. time is a bit of a problem, but i'm working on it :)

I know the feeling, no worries.

> The problem with my code is that it was written for a particular purpose
> (which was running telive), and is really really ugly. It would be better to
> agree on a nice standardised way to get data from osmo-tetra to external
> programs (not gsmtap, i want cooked data, not raw). 

The question is what kind of information you're relly looking for.

Parsing all the data in hand-crafted C code and then re-encoding it into
some other intermediary format doesn't really seem like a great idea,
unless you have an army of developers at hand who like to do that :)

The wireshark tetra dissector solved that problem by transcribing the
TETRA messages as ASN.1 with UPER encoding rules.  We could do something
similar and use asn1c to do an automatic "transcoding" to XER (XML
Encoding Rules) or simply pass the parsed C structures generated by
asn1c around.

Yes, XML is ugly.  But a generic, machine-parseable interpretation
is quite usefulU, and the number of signalling messages on a tetra
channel is quite low, i.e. the CPU overhead might not be that much of a
problem.  Unfortunately asn1c doesn't have JSER or GSER support,
otherwise that would have been my preference over XER.

but I digress.  Let's start with you explaining a bit (maybe with
example data) what kind of information you actually need.

Looking forward to working together.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)