Revamping osmo-tetra

Jacek Lipkowski sq5bpf at
Fri Jan 13 13:37:52 UTC 2017

On Mon, 19 Dec 2016, Harald Welte wrote:

> thanks for your quick answer.

now sorry for my late answer :)

>> The problem with my code is that it was written for a particular purpose
>> (which was running telive), and is really really ugly. It would be better to
>> agree on a nice standardised way to get data from osmo-tetra to external
>> programs (not gsmtap, i want cooked data, not raw).
> The question is what kind of information you're relly looking for.

information that can be used by  an external program  without having to 
implement that which is already in osmo-tetra. this would be:

- signalling data (d-setup, d-sds etc) with the fields (SSI etc) in some easy 
to interpret format (xml is fine)

- binary data (voice frames, data frames etc), maybe along with a little bit of 

- "housekeeping data" that is internally generated, but is useful for the 
application (telive version, frame count, information if the decoder is 
currently picking up frames, error rates etc)

> Parsing all the data in hand-crafted C code and then re-encoding it into
> some other intermediary format doesn't really seem like a great idea,
> unless you have an army of developers at hand who like to do that :)

you're right. on the other hand there is not that much pdu types which are 
interesting to me (d-setup, d-release etc), and if someone needs to implement 
yet another pdu, then he can easily do it.

> The wireshark tetra dissector solved that problem by transcribing the
> TETRA messages as ASN.1 with UPER encoding rules.  We could do something
> similar and use asn1c to do an automatic "transcoding" to XER (XML
> Encoding Rules) or simply pass the parsed C structures generated by
> asn1c around.

this looks like a *LOT* of work (at least to me). i'd start with what is 
already implemented.

btw i was also thinking about xml. unfortunately there will be overhead. 
currently you can run the code (gnuradio, qpsk decoder, my fork of osmo-tetra 
and telive) on a raspberry pi 3, and this can work for 2-3 channels 
simultaneously. i'm not sure this will still be possible with a full blown xml 
implementation, but we'll see.

any thoughts aout the interface to other applications? my fork just sends 
everything in udp packets (which can get lots/reordered etc). there must be a 
better way (tcp is not one of them). any ideas?


More information about the tetra mailing list