tetra

tetra@lists.osmocom.org

162 discussions

Revamping osmo-tetra
by Harald Welte 14 Jan '17

14 Jan '17

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)

2 2

Osmo tetra -DMO option
by Daniel Kosi 18 Dec '16

18 Dec '16

Hello! I would like to know it is possible to add DMO rx option in osmo tetra and how? It only support TMO for now,am i right? Have a nice day!

2 1

RFC: OsmoDevCon 2017 planning
by Harald Welte 11 Dec '16

11 Dec '16

Dear Osmocom Community, [please respect the Reply-To and post all follow-up discussion to this to openbsc(a)lists.osmocom.org, so we avoid having long threads cross-posted to several mailing lists.] >From 2012 to 2016 we were running a series of small, invitation-only Osmocom Developer Conferences. Access was intentionally restricted to those community members who have demonstrated an existing track record of contribution to any of the projects under the Osmocom umbrella. This format of a small, tightly knit group of about 20 people has been successful over the years, and I have received a lot of positive feedback from past participants. On the other hand, the Osmocom project has grown in scope and diversity, and some of those projects don't have all that much relationship to each other - except being started by people from within the same group. There's the cellular communications (GSM/GPRS/EDGE/UMTS and hopefully at some point LTE) protocols which is attracting a lot of professional users. And then there's pure community projects like rtl-sdr, OsmocomBB, OsmocomGMR and many other efforts. Particularly the cellular infrastructure projects (OsmoBTS, OsmoPCU, OsmoBTS, OsmoNITB, OsmoSGSN, OpenGGSN, OsmoIuh & co) are somehow "standing out" of the othe projects in the context of having a wider user bsae, and in that user base also primarily commercial users. So I'd like to start a discussion on how to possibly change the event format to accomodate the various interests and parties. I definitely don't want to loose the "annual meeting of old friends" atmosphere, while at the same time also opening up to other interested parties. One idea would be to keep OsmoDevCon as-is and have a separate event where non-contributing/developing users / sysadmins / system integrators could also be attending. Another idea would be to split into a 'user day' and 'developer days' format. This is something the netfilter developer workshops have been using for many years, and from my limited insight quite successfully so. The "user day" is more like a traditional tech conference, with a large auditorium and talks oriented towards users / sysadmins / integrators of the software. The "developer days" are the invitation-only part, for known contributing developers only, similar to what we have at OsmoDevCon. Having both events (or both parts of an event) back-to-back has the advantage that a large number of potential speakers for the 'user day' are already present, and they don't have to travel yet another time. One could even structure it further and say we have one user day, one public 'Osmocom cellular developer day' and then the closed 'OsmoDevCon classic', maybe reduced from 4 days to 3 or even 2 days only? What is the general opinion about this? Are there people lurking on this list who would be interested in attending a public 'user day' or even 'developer day' about the Osmocom cellular projects, with presentations and workshops around topics such as running Osmocom based cellular networks? In terms of when/where, I would suggest to keep the tradition of April in Berlin/Germany. But I'm of course very happy if somebody wants to host it some place else... Regards, and looking forward to meeting you [again] in 2017, 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)

1 0

crude pseudo AFC for float_to_bits
by Jacek Lipkowski 03 Feb '16

03 Feb '16

Hello I've added a very crude pseudo AFC to float_to_bits. It uses an averaging filter on the input values, and compensates for any fixed offset it finds in the input data (if all bit combinations are equally likely to appear in the input stream, then a long-term average should be 0). This helps a bit when decoding a mistuned signal (due to receiver frequency drift etc). From a quick test yesterday normally the receiver works when the signal is mistuned from -1.6 to 1.3kHz, with the -a option the receiver works when the signal is mistuned from -2.8 to 2kHz. Diff included, or source here: https://github.com/sq5bpf/osmo-tetra-sq5bpf/blob/master/src/float_to_bits.c Jacek

1 0

Mixed C and Python Code
by martin 26 Aug '15

26 Aug '15

Hello, i want to ask why there is a mix of python and c code with lots of pipes in between. It is a design decision? Or was it some kind of easyer? Greetings Martin

2 1

4/24/2015 11:42:35 AM
by Graham Palmer 24 Apr '15

24 Apr '15

http://www.kino-popcorn.ru/bfn/kglavwzzgzlifsyxongtwoohxv.qclxkinuniflrgzvw… 4/24/2015 11:42:35 AM

1 0

Patch for GNUradio 3.7
by Timothée COCAULT 05 Apr '15

05 Apr '15

Hi, The scripts in src/demod/python/ don't work with GNUradio 3.7. Mike Jameson wrote a patch for UHD and I completed with a patch for osmo-sdr receivers : https://github.com/m0mik/osmo-tetra/commit/5429a1e3abf3e5c1aeadc0253169233f… https://github.com/Tim---/osmo-tetra/commit/374e651264dc2cbe02366b9affc2f5e… Unfortunately I don't have the hardware to test the other scripts but the modifications should be similar. Regards. Timothée.

1 0

tetra-demod.py chain pipe error
by Espectro Digital 04 Apr '15

04 Apr '15

Hello, I'm trying to receive tetra signal from rtl_sdr by tetra-demod.py, but I got this error: rtl_sdr -s 195312 -f 392.1M -|demod/python/tetra-demod.py -s 195312 -i /dev/stdin -o /dev/stdout|./float_to_bits /dev/stdin /dev/stdout|./tetra-rx /dev/stdin Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 000000xx Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner >>> gr_fir_ccc: using SSE sample rate: 195312 >>> gr_fir_ccf: using SSE Invalid sample rate: 195312 Hz WARNING: Failed to set sample rate. Tuned to 392100000 Hz. Tuner gain set to automatic. Reading samples in async mode... Signal caught, exiting! Signal caught, exiting! Short write, samples lost, exiting! EOF User cancel, exiting... FAQ: Q: Why don't you use osmosdr-tetra_demod_fft.py instead tetra-demod.py? A: osmosdr-tetra_demod_fft.py is a nightmare for tuning, I've never got to center a signal successfully, so I want to modify rtl_sdr for tunning with mouse wheel. Q: Why don't you modify osmosdr-tetra_demod_fft.py? A: Well, I have a large experience programming c, not idea of programming python. Q: Why don't you learn python? A: That's the last bullet in my belt, but i wanna try something faster :) Now a question for you all. Why is not there a C version of tetra demodulator? Thanks and regards.

2 4

Announcing OsmoDevCon 2015
by Harald Welte 13 Feb '15

13 Feb '15

Dear Osmocom.org project members, I'm happy to be able to announce the annual incarnation of OsmoDevCon. The Date is set for March 27 through 30. Venue: As usual, IN-Berlin e.V. in Berlin, Germany. Further details can be obtained from http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2015 Attendance, as usual, is restricted to people with an active history in the Project by contributions in terms of code, patches, discussions, documentation or in other form. = Registration = If you have wiki access, please add yourself to the #Requested section. Alternatively, you can send me private e-mail about it. After review, your (nick)name will be listed in the #Confirmed section. Looking forward to meeting all of you again soon! -- - 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)

1 0

PLU interval?
by Ralph A. Schmid, dk5ras 16 Jan '15

16 Jan '15

Hi, is there a fixed PLU interval for TETRA systems, or is it somewhere announced in the MCCH? I have seen a clear 4 hour interval and wonder who is responsible for it :) Ralph.

1 1

← Newer
1
2
3
4
5
6
7
...
17
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tetra