This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/tetra@lists.osmocom.org/.
Jannik Jürgens jjuergens at seemoo.tu-darmstadt.deThanks 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