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