osmo-tetra: Add DMO Code

Jannik Jürgens jjuergens at seemoo.tu-darmstadt.de
Sat Jan 14 11:10:23 UTC 2017


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



More information about the tetra mailing list