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
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
On Mon, 19 Dec 2016, Harald Welte wrote:
thanks for your quick answer.
now sorry for my late answer :)
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.
information that can be used by an external program without having to implement that which is already in osmo-tetra. this would be:
- signalling data (d-setup, d-sds etc) with the fields (SSI etc) in some easy to interpret format (xml is fine)
- binary data (voice frames, data frames etc), maybe along with a little bit of metadata
- "housekeeping data" that is internally generated, but is useful for the application (telive version, frame count, information if the decoder is currently picking up frames, error rates etc)
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 :)
you're right. on the other hand there is not that much pdu types which are interesting to me (d-setup, d-release etc), and if someone needs to implement yet another pdu, then he can easily do it.
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.
this looks like a *LOT* of work (at least to me). i'd start with what is already implemented.
btw i was also thinking about xml. unfortunately there will be overhead. currently you can run the code (gnuradio, qpsk decoder, my fork of osmo-tetra and telive) on a raspberry pi 3, and this can work for 2-3 channels simultaneously. i'm not sure this will still be possible with a full blown xml implementation, but we'll see.
any thoughts aout the interface to other applications? my fork just sends everything in udp packets (which can get lots/reordered etc). there must be a better way (tcp is not one of them). any ideas?
jacek
-
Harald Welte -
Jacek Lipkowski