tetra January 2017

tetra@lists.osmocom.org

4 participants
3 discussions

DMO Patch for sq5bpf rebase branch
by Jannik Jürgens 23 Jan '17

23 Jan '17

Hello, as already announced here is a first DMO patch for the sq5bpf rebase branch. I currently only modified the physical and lower mac layer. I added a new SAP: dp_sap_udata_ind but decided to forward the data to the TMO SAP because otherwise there would be a lot duplicate code. Best regards Jannik

1 0

osmo-tetra: Add DMO Code
by Jannik Jürgens 14 Jan '17

14 Jan '17

Dear Osmocom Community, I currently writing my masterthesis about TETRA. For this, I am currently writing my master thesis on TETRA. For this the support of DMO is necessary. Another student had already implemented a rudimentary DMO receiver (based on the Osmocom code) in his thesis, which I now develop further. I would like to add this code to the Osmocom project as a new branch so that other people can participate. I was unsure, based on which branch I should develop the code, but I decide for the laforge / sq5bpf-rebase-20161218 branch, because this is most useful for my purpose. I hope this is okay and doesn't lead to chaos. When trying to create a new branch and commit this, however I get an error message: $ Git push origin jj / dmo Error: no DAV locking support at https://git.osmocom.org/osmo-tetra/ Fatal: git-http-push failed Error: Error sending some references to 'https://git.osmocom.org/osmo-tetra' Unfortunately, I have not found instructions, who is at Osmocom allowed to commit code or how the process works. Can you help me with this or send me a link, where I find the appropriate information? Best regards, Jannik

4 4

Revamping osmo-tetra
by Harald Welte 13 Jan '17

13 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tetra January 2017