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
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
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)
