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/.
Jacek Lipkowski sq5bpf at lipkowski.orgOn 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 metadata - "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? jacek