14 Jan
2017
14 Jan
'17
6:10 a.m.
Thanks for your reply.
On Fri, 13 Jan 2017, Harald Welte wrote:
Unrelated to your work, Sylvain has recently published
some DMO related
wokr in the users/tnt/dmo branch. We had a quick conversation about DMO
at 33C3 and he started right away to modify the demodulator/decoder from
the osmo-gmr project. Have you seen that yet? Did you play with it yet?
I looked
at it briefly. To be honest, I did not really understand the
code or its intention at the first glance.
It would be preferable to develop related changes
based on master. The
sq5bpf code (as you can see by recent mails on the list) is more
experimental and (as can be seen from only looking at coding style)
unfortuntely needs some more clean up before it can be merged.
Maybe we create a
feature branch for DMO based on master and I will
create patch for the sq5bpf code because I already have written some
code for this branch. My intention is not to write quick and dirty code
which is not usable for further development. I personally will develop
my code first for the sq5bpf branch, but an integration into the master
branch afterwards should not be so much overhead.
However, I'm tempted to migrate osmo-tetra over to
gerrit. What do you
think? Have you worked with gerrit before?
I have not worked with it yet.
On Fri, 13.01.2017, Jacek Lipkowski wrote:
i don't know the quality of the code, but maybe
merge it into
https://github.com/sq5bpf/osmo-tetra-sq5bpf ?
i doubt you're able to write uglier code than i did, so that's not an
issue.
this code gets regular use by hundreds of people (or rather thousands,
many people that use it would like to stay under the radar so you
won't hear from them), so you will hear about any bugs quick. also i
will add support for it in telive (frontend application to
listen/record/log/whatever)
Sounds nice, but we should avoid parallel development
in two different
repositories. Because my changes for DMO only affects the osmocom part
of telive, I would prefer to develop the code in the osmocom project.
However, I already developed the DMO support for your code, so I will
send you a patch. But if someone finds a bug, we should be alert to
update the osmocom branch.
I will clean up my code and optimize the DMO support. Probably next week
I will send you a patch or create a feature branch.
Regards,
Jannik
On Fri, 13 Jan 2017, Harald Welte wrote:
It would be preferable to develop related changes
based on master. The
sq5bpf code (as you can see by recent mails on the list) is more
experimental and (as can be seen from only looking at coding style)
unfortuntely needs some more clean up before it can be merged.
i don't know the quality of the code, but maybe merge it into
https://github.com/sq5bpf/osmo-tetra-sq5bpf ?
i doubt you're able to write uglier code than i did, so that's not an
issue.
this code gets regular use by hundreds of people (or rather thousands,
many people that use it would like to stay under the radar so you
won't hear from them), so you will hear about any bugs quick. also i
will add support for it in telive (frontend application to
listen/record/log/whatever)
you will also find interesting things not currently present in stock
osmo-tetra, like fragment reassembly (useful to put long sds messages
together), or a simple (and ugly) interface for other programs to get
data from it.
and eventually i will try to merge all of this code into osmo-tetra
(and clean it up beforehand). so even if you loose interest after your
thesis is over there will be someone working on it.
jacek