sq5bpf at lipkowski.org
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
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