Tetra decoding

[passie101]

Proud to announce that I have just got the following working:

0. gnuradio-3.7.9
1. receiving data from an osmosdr source directly on the RPi2 (rtl-tcp)
2. getting it to work with Gnuradio-Companion on the host system
3. compiling the grc script modify it to run headless on the RPi2
4. running grc headless on the pi with direct hardware access (hence not using rtl-tcp)
5. running telive on the Rasberry Pi
6. encoding sound with opus
7. broadcasting metadata & voice to zeromq

Load average: 1.71, 1.79, 1.65 [verbose messages off in telive]

Indication of the cpu usage across the different components;

root     16485 71.0  7.0 204992 66796 pts/3    Sl+  23:33  16:34 python2 top_block.py
root     16491 12.8  7.2 221248 68912 pts/1    Sl+  23:33   3:00 python demod/python-3.7/simdemod2.py -o /dev/stdout -i /tmp/fifo1
root     16492 17.2  0.1   2856  1624 pts/1    R+   23:33   4:01 ./tetra-rx -a -i /dev/stdin
root     16581 11.2  0.6  25520  6080 pts/5    Sl+  23:41   1:47 ./telive

If people are interested I am happy to write up an in depth tutorial on this specific project. But I want to focus on the bigger picture

For now a small picture

I'm very interested in how you did this ! If you can write this tutorial will be great !

 

[racingfan360]

i've been asked via PM how to upgrade, and thought others may like this info too:
cd ~/tetra #or wherever you downloaded the sources
cd telive
#if you modified any files (like rxx) then rename them
git pull
make
[/code]

Usually I'm ok with these updates, but this one is giving me issues. Have followed the instructions, but seem to have issues running the final make on the telive dir. It's flagging several undefined references to xmlParseFile etc in telive.c

If anyone is able to offer suggestions/help, I'd appreciate it (please no patronizing comments on my basic linux skills - that doesn't count as helpful).

 

[sq5bpf]

Usually I'm ok with these updates, but this one is giving me issues. Have followed the instructions, but seem to have issues running the final make on the telive dir. It's flagging several undefined references to xmlParseFile etc in telive.c

did you do this?
sudo apt-get update
sudo apt-get install libxml2-dev

what distribution is this on?

log please so that i can see the error messages

If anyone is able to offer suggestions/help, I'd appreciate it (please no patronizing comments on my basic linux skills - that doesn't count as helpful).

once upon a time many years ago patronizing comments on computer-related mailing lists served an important purpose: they bullied people into reading manuals and trying to figure out things themselves. but now i'm not so sure that it still works this way

 

[racingfan360]

Thanks for your help.

>did you do this?
>sudo apt-get update
>sudo apt-get install libxml2-dev
Yes to all of the above.

>what distribution is this on?
Linux Mint 17.1

>log please so that i can see the error messages

So no issues up to this point.......and rxx renamed as stated:

jim@Aspire ~/osmo-tetra-sq5bpf/src/telive $ git pull
Merge made by the 'recursive' strategy.
Makefile | 2 +-
rxx | 6 +
scripts/install_telive.sh | 276 ++
telive.c | 280 +-
telive_doc.pdf | Bin 253705 -> 299071 bytes
telive_doc.txt | 195 +-
tetra.xml | 8974 +++++++++++++++++++++++++++++++++++++++++++++
7 files changed, 9618 insertions(+), 115 deletions(-)
create mode 100755 scripts/install_telive.sh
create mode 100644 tetra.xml
jim@Aspire ~/osmo-tetra-sq5bpf/src/telive $ make
gcc `xml2-config --cflags --libs` telive.c -o telive -lncurses -g
/tmp/ccIC2zqz.o: In function `tetraxml_read':
/home/jim/osmo-tetra-sq5bpf/src/telive/telive.c:218: undefined reference to `xmlParseFile'
/tmp/ccIC2zqz.o: In function `tetraxml_query':
/home/jim/osmo-tetra-sq5bpf/src/telive/telive.c:243: undefined reference to `xmlXPathNewContext'
/home/jim/osmo-tetra-sq5bpf/src/telive/telive.c:254: undefined reference to `xmlXPathEvalExpression'
/home/jim/osmo-tetra-sq5bpf/src/telive/telive.c:256: undefined reference to `xmlXPathFreeContext'
/home/jim/osmo-tetra-sq5bpf/src/telive/telive.c:257: undefined reference to `xmlXPathFreeObject'
/home/jim/osmo-tetra-sq5bpf/src/telive/telive.c:263: undefined reference to `xmlNodeListGetString'
/home/jim/osmo-tetra-sq5bpf/src/telive/telive.c:265: undefined reference to `xmlFree'
/home/jim/osmo-tetra-sq5bpf/src/telive/telive.c:270: undefined reference to `xmlXPathEvalExpression'
/home/jim/osmo-tetra-sq5bpf/src/telive/telive.c:272: undefined reference to `xmlXPathFreeContext'
/home/jim/osmo-tetra-sq5bpf/src/telive/telive.c:273: undefined reference to `xmlXPathFreeObject'
/home/jim/osmo-tetra-sq5bpf/src/telive/telive.c:278: undefined reference to `xmlNodeListGetString'
/home/jim/osmo-tetra-sq5bpf/src/telive/telive.c:280: undefined reference to `xmlFree'
/home/jim/osmo-tetra-sq5bpf/src/telive/telive.c:282: undefined reference to `xmlXPathFreeContext'
/home/jim/osmo-tetra-sq5bpf/src/telive/telive.c:283: undefined reference to `xmlXPathFreeObject'
collect2: error: ld returned 1 exit status
make: *** [telive] Error 1


Is this an issue with linking in the ncurses lib?

> they bullied people into reading manuals and trying to figure out things themselves
Well, I'm one who likes to try and work things out myself, and help others where I can: I've manged to find my way on all other aspects of linux, but this one stumped me.

 

[sq5bpf]

update telive and try again

according to what i've found on the internet the linker behaviour has changed, and:
gcc -lsomething program.c -o program can fail
but:
gcc program.c -o program -lsomething will work

lets hope this fixes it. btw on debian both ways work without problems

 

[racingfan360]

update telive and try again

lets hope this fixes it. btw on debian both ways work without problems

It did !! Not sure if I changed something or you did, but the re-run of the telive update and make worked this morning.

Thanks again.

 

[sq5bpf]

only bugs that bother me is SDS parsing bug (he is aware of)

should be fixed now, please update osmo-tetra-sq5bpf

BTW could people on networks which get lots of text SDS see if they don't get the SDS truncated now? (for example you used to get DATA:[hello everyone] but now you get DATA:[hello everyon] )

 

[jlxsolutions]

Aight updated telive and waiting to see how it decodes sds.
But i could not get (figure out how) testsds to compile.
Would be nice to run against the old logs.

 

[jlxsolutions]

Ran into a odd problem i don't seem to be able to create more then a 6channel setup
What i have done is to create a receiver1 (2,3,4,5,6,7,8,9,10,11,12) and rxx1(2,3,4,5,6,7,8,9,10,11,12) each on its own port.
and then /tetra/ /tetra2(3,4,5,6,7,8,9,10,11,12) (and copied files of course)

in rxx file logs and out in directories points to first /tetra/ and bin points to each individual /tetra#/bin)

Worked fine up till 6channels but after 6
7 to 12 telive windows display the same frequency and channel info as ch6 in gnuradio all frequencies show correctly.
fifos are created when i run the ./receiver# #

ie
./receiver1 1&
./receiver2 2&
./receiver3 3&

 

[sq5bpf]

Aight updated telive and waiting to see how it decodes sds.
But i could not get (figure out how) testsds to compile.
Would be nice to run against the old logs.

make testsds

and then run ./testsds 1010100101... (where the 010101010 is copy/pasted from the telive log).

 

[sq5bpf]

Ran into a odd problem i don't seem to be able to create more then a 6channel setup

must be some stupid mistake, have a good look at your scripts. there is nothing that would limit the number of receivers.

you can also verify the udp traffic to telive with tcpdump

 

[jlxsolutions]

make testsds

and then run ./testsds 1010100101... (where the 010101010 is copy/pasted from the telive log).

Alrighty this worked and SDS decodes diffrently now but still hex output
example

/tetra/osmo-tetra-sq5bpf/src# ./testsds 010011110111110110011100001010011001001001011110110101001000110010001001000101001111101011111011
Ascii/binary dump:
Bit shift 0:  [ O} \x9C  ) \x92  ^ \xD4 \x8C \x89 \x14 \xFA \xFB ]	bits left: 0
Bit shift 1:  [\x9E \xFB  8S$ \xBD \xA9 \x19 \x12  ) \xF5 ]	bits left: 7
Bit shift 2:  [ = \xF6  p \xA6  I{R2$S \xEB ]	bits left: 6
Bit shift 3:  [ { \xEC \xE1  L \x92 \xF6 \xA4  dH \xA7 \xD7 ]	bits left: 5
Bit shift 4:  [\xF7 \xD9 \xC2 \x99  % \xED  H \xC8 \x91  O \xAF ]	bits left: 4
Bit shift 5:  [\xEF \xB3 \x85  2K \xDA \x91 \x91  " \x9F  _]	bits left: 3
Bit shift 6:  [\xDF  g \x0A  d \x97 \xB5  #"E> \xBE ]	bits left: 2
Bit shift 7:  [\xBE \xCE \x14 \xC9  /jFD \x8A  }}]	bits left: 1


CPTI:1 CalledSSI:1 CallingSSI:16150694 CallingEXT:0 UserData2: 0x25 0xED 0x48 0xC8

 

[sq5bpf]

Alrighty this worked and SDS decodes diffrently now but still hex output

TETRA people love proprietary protocols, and you will get only hexdumps for these.

you can try to decode some proprietary messages if you have enough traffic (like i've done with the proprietary 0x80 simple location protocol). users usually don't use the text messaging function of their radios (so most messages are like "test123" or "hello", although that depends on the user base)

btw SDS can have 4 variants: userdata1 (allows transfer of 2 bytes), userdata2 (allows transfer of 4 bytes), userdata3 (allows transfer of 8 bytes, and actually doesn't make sense because you can send the same 8 bytes in an userdata4 message with the same overhead), and userdata4 which allows arbitrary length up to around 2000 bytes. userdata4 is used for text messaging, location and most other stuff, but the userdata1-3 messages are also interesting because they are used for stuff like alarms, panic buttons etc (of course it is not documented).


the whole protocol specification is written to be ambiguous and allow manufacturers to break interoperability by implementing their own stuff (vendor lock-in). example: for location there are: Location Information Protocol (nice, very robust protocol), and Location protocol and Simple Location protocol (actually the same protocol, but one has the sds-tl header). the latter both have the option for proprietary extensions. so you have 3 protocols for location, and the vendor will invent a fourth one to lock the user into using only his hardware.

 

[passie101]

must be some stupid mistake, have a good look at your scripts. there is nothing that would limit the number of receivers.

you can also verify the udp traffic to telive with tcpdump

Same problem here with more the 6 receivers, I have looked at GNU script but can find the problem.

Very strange problem

 

[jlxsolutions]

Same problem here with more the 6 receivers, I have looked at GNU script but can find the problem.

Very strange problem

Lemme guess when you created the Gnuradio file you copied the previuos one and just filled in freq etc
Check the X lating FIR filter.
i also changed values there to match new ones in fifo offset etc
and voila it works.
odd part is i did not change those before and have had more then 6ch im guessing it has something to do with the AFC that thoose values have to be correct as well.

 

[passie101]

Lemme guess when you created the Gnuradio file you copied the previuos one and just filled in freq etc
Check the X lating FIR filter.
i also changed values there to match new ones in fifo offset etc
and voila it works.
odd part is i did not change those before and have had more then 6ch im guessing it has something to do with the AFC that thoose values have to be correct as well.

YES ! it looks that is fixed my problem

 

[passie101]

Lemme guess when you created the Gnuradio file you copied the previuos one and just filled in freq etc
Check the X lating FIR filter.
i also changed values there to match new ones in fifo offset etc
and voila it works.
odd part is i did not change those before and have had more then 6ch im guessing it has something to do with the AFC that thoose values have to be correct as well.

Fixed The FIR filter but still strange thing happend, ik look like a echo or some thing you hear 2times the same QSO.

 

[jlxsolutions]

Fixed The FIR filter but still strange thing happend, ik look like a echo or some thing you hear 2times the same QSO.

Read documentation file
about Telive_Lock
you need that in the Rxx file

 

[passie101]

Read documentation file
about Telive_Lock
you need that in the Rxx file

No it has nothing to do with the lock file, I run 7 receivers into 1 telive. so no multiple telive sessions

 

[jlxsolutions]

that won't work my estimate if same network around 4 to 6 before they start mixing up.
That's the reason why i run a separate instance of telive for each channel now days.