Tetra decoding

[oz1jua]

Sorry to hear that you have had so much problems, I've myself tried installing this software 6 different times without any problem, I've been running both Ubuntu 14.04.1 (32 bit and 64 bit), Ubuntu 14.10 (32 bit), and Lubuntu 14.04.1 (64 bit), both in virtual machines, running side to Windows and on NUC's, totally 4 completely different machines, oldest a 7 year old laptop. All installations succeeded.

However if seems from your previous posts that you tried to fix things that were not broken. I also got some of the warnings that you quoted then, but those were nothing that caused any problem. Easiest, but maybe not best, is to follow the guide you quoted at rtl-sdr, exactly as it says. However there are some things I believe can be missed:

The gnuradio installation have to end with a "-o" (might be missed since the o appears on the next row)

Do a cd~ before installing telive. I'm not sure if that matters, but I like to have it in the root, and that's how they referred to it when explaining how to start the software later in the guide.

Finally, the guide doesn't mention how to release the rtl-sdr if it's been taken as a TV-card by ubuntu;
sudo rmmod dvb_usb_rtl28xxu

or more permanent;
sudo su
echo blacklist dvb_usb_rtl28xxu > /etc/modprobe.d/rtlsdr.conf
exit

I also recommend that you read the telive_doc.pdf which explains some things in more detail, like how to compile in 64 bit os.

So just try to follow the guides, for me it works just fine, despite there are some warnings on the way.

Thanks for the quick answer. Then I will try to ignore all warnings then. But it did not get if it is Desktop or Server version you have install the system on. I asume it is the desktop version.
I did not have any errors when installing GNU Radio and yes I have copy all line with -o at last.
It just takes a while to install 4-5 hours..... And when it has been done several times its a long time to do nothing. Hope I will manage to get it to work in this Chrismas.

 

[sm0vec]

Thanks for the quick answer. Then I will try to ignore all warnings then. But it did not get if it is Desktop or Server version you have install the system on. I asume it is the desktop version.
I did not have any errors when installing GNU Radio and yes I have copy all line with -o at last.
It just takes a while to install 4-5 hours..... And when it has been done several times its a long time to do nothing. Hope I will manage to get it to work in this Chrismas.

I've only tested running the desktop versions.

One last thing that came to mind, a wild guess based on previous problem in a completely different case... you write "copy all lines", if you actually do copy it's maybe a good idea to type manually instead. I once had a lot of problems when importing subversion repositories to a new server, the instruction I followed was in html format, and when I copied the text the - sign was not the same ascii character as the server expected. It was impossible to spot on the screen, and the svn-server just ignored the switch, but when I finally typed everything manually it worked. I've then checked the ascii of each character on the website and realized the cause of my previous problem.

 

[velu]

try to monitor a network with air encryption:0 , and if necssesary enable mutessi

also you may have a problem with the codecs, but you have already checked this according to the documentation, right?

I monitored for few hours yesterday and was able get sound only when some particular X person talks. He talks with some one else, Play lights up on the screen as if some one else is replying him, but no audio from others are heard.

If Mutessi is enabled there are fewer audios recorded. How to see whether a channel is scrambled? Because in ./receiver1 1 terminal it says Air Encryption: 0 and also scrolling very fast hard to read much.

 

[sq5bpf]

I do not think I have any Feedback from the other post I have ask here. Do I have to write in polish
before getting any answer ??
God Jul. sq5bpf

this software was installed by a lot of people (even without linux skills) without problems under various distributions (also other than debian, which is recommended in the documentation). some people just don't get along with linux well, even with their best efforts to learn it, and i don't know the reason (i used to teach basic linux for a few semesters, and never figured this out). if this is the case then look at the very first post in this thread.

so regarding your question, the answer is no, you don't have to write in polish, and i doubt that my replying in in danish would help anything either

 

[sm0vec]

I monitored for few hours yesterday and was able get sound only when some particular X person talks. He talks with some one else, Play lights up on the screen as if some one else is replying him, but no audio from others are heard.

If Mutessi is enabled there are fewer audios recorded. How to see whether a channel is scrambled? Because in ./receiver1 1 terminal it says Air Encryption: 0 and also scrolling very fast hard to read much.

Your installation seems to work just fine. Only hearing one party talking is quite normal in systems with individual calls and users on many sites. It becomes logical if you think from the perspective of the actual user, he doesn't need to hear his own transmission, only the other part he's talking to. If both users are connected to the same site you will hear both users but on different slots. But if they are on different sites, you would have to monitor several sites to hear the full conversation. This means that systems with many sites and only individual calls will be quite boring to monitor.

I think mutessi solves the effect of a bug, so you will get less recorded calls, but the calls that would be recorded with mutessi on will anyway be empty. I though don't think anything is missed since those empty calls seems to come from some background activity, but not any actual call.

I've also noticed that there are many systems with almost no traffic at all. Some of them seems to be test and demo systems setup without any real users.

 

[velu]

So it means, the frequency I am monitoring is the transmitting frequency of that X and his listening frequency might be something else. So I am not able to hear his respondents talking back. Another thing is that they may have simply setup with empty traffic and may be even testing.

Different sites means different frequencies or using Ch2, Ch3 might catch those? Atpresent when I scanned I can find typical Tetra sound on 392.45 which is loud and at 392.0 which is of lesser intensity. Apart from that no other frequencies I was able to find. I tried using Ch_2 and managed to tune both but ./receiver1 2 don't show activity if it is tuned to 392.0 and it gets to life if it is tuned to 392.45.

 

[sm0vec]

So it means, the frequency I am monitoring is the transmitting frequency of that X and his listening frequency might be something else. So I am not able to hear his respondents talking back. Another thing is that they may have simply setup with empty traffic and may be even testing.

Different sites means different frequencies or using Ch2, Ch3 might catch those? Atpresent when I scanned I can find typical Tetra sound on 392.45 which is loud and at 392.0 which is of lesser intensity. Apart from that no other frequencies I was able to find. I tried using Ch_2 and managed to tune both but ./receiver1 2 don't show activity if it is tuned to 392.0 and it gets to life if it is tuned to 392.45.

The opposite actually, you are listening to someones listening frequency. What you hear is what the mobile station connected to that site hear. When the mobile station transmits, that audio will only be sent on the in-frequency (380 MHz), but not re-broadcasted on the same time slot.

Each site (location of the transmitter) can have several channels. A site normally have 2 or 4 channels. This means that you need to receive 2 or 4 channels at the same time since the call might move between the different channels (on the same site) during the call.

 

[RMW1010]

Type in terminal: rtl_test -t

Please, read the message and follow the instruction, if you read something with kernel module.

Thanks! Blacklisting did the trick.

Next issue is, after I execute the flowgraph, the window comes up, but there is no grid and no signal line.

I tried with the 1ch and the 1ch simple graph, result is the same.

Thanks for any help.;

 

[kermit_t_f]

Is anyone running the decoder in VMware?
I'm getting some buffer underflows from the dongle from time zu time, sometimes it even won't start from GRC. The text box in the bottom runs foll of 0.
I can't confirm it, but I've got the impression, that this became worse since the update to VMware 11.

 

[sq5bpf]

Thanks! Blacklisting did the trick.

Next issue is, after I execute the flowgraph, the window comes up, but there is no grid and no signal line.

I tried with the 1ch and the 1ch simple graph, result is the same.

Thanks for any help.;

is the receiver1 script working? if not, then the flowgraph will freeze when you execute the flowgraph

 

[sq5bpf]

So it means, the frequency I am monitoring is the transmitting frequency of that X and his listening frequency might be something else. So I am not able to hear his respondents talking back.

this is the case with duplex calls, since there are really two separate calls, and you only hear one part. try to enable recording, and monitor multiple channels from the same system. if both users are on this system then you might record two calls at the same time, with similar duration, each recording will hold the one part of the conversation (which is very annoying btw, you can stich them together in audacity if you like).

with half-duplex calls you will hear both sides.

i would do this: enable the 1 channel simple grc (the one with two spectrum displays and click-to-tune), and tune through everything that looks like tetra, for every frequency theat you get something note the control channel up/down frequencies, colour code, nmc, mcc. frequencies that have these parameters the same will probably belong to the same system (but not always, there might be a misconfiguration, that will not be noticed by the users)

 

[sm0vec]

The ColourCode may vary within the same system, but the MNC (Mobile Network Code) and MCC (Mobile Country Code) gives an unique system identity which should be the same.

The ColourCode is used to direct the call to the right base station when the same frequency is used on several sites in a system. If the same frequency is reused on several base stations in the same system, then several base stations might actually capture the traffic, which is solved by using unique colour codes.

More about this can be found in EN300392-2.

 

[RMW1010]

is the receiver1 script working? if not, then the flowgraph will freeze when you execute the flowgraph

Happy Christmas and thanks for your reply.

Yes the receiver script seems to be working. I can see data scrolling, but only the BURST messages.
Telive has got the correct MCC, MNC and frequencies.

The flowgraph remains empty, not even some lines in the beginning.

Thanks!

 

[sq5bpf]

Happy Christmas and thanks for your reply.

Yes the receiver script seems to be working. I can see data scrolling, but only the BURST messages.
Telive has got the correct MCC, MNC and frequencies.

The flowgraph remains empty, not even some lines in the beginning.

Thanks!

are you using this under a vitrual machine? maybe its some graphics problem

 

[sq5bpf]

i was asked to debug problems with installation of gnuradio using build-gnuradio on debian 7.7.

it turned out that the user installed almost every possible package. to fix the system i had to uninstall all gnuradio packages, and also usrp specific stuff: libuhd, libuhd-dev and cutesdr. while the first is obvious, the second might not be (at least not for me).

 

[RMW1010]

are you using this under a vitrual machine? maybe its some graphics problem

Yes, it's running in a virtual machine. Could be a graphics issue, tried different settings, but no luck so far.

I have it also running on an other laptop in Debian, there it works.
But on that one the audio (live and recording) is very choppy.

Thought that the laptop is to slow (centrino duo processor), that why I wanted to try it in a VM on my i5 laptop.

 

[firefather_sdr]

Yes, it's running in a virtual machine. Could be a graphics issue, tried different settings, but no luck so far.

I have it also running on an other laptop in Debian, there it works.
But on that one the audio (live and recording) is very choppy.

Thought that the laptop is to slow (centrino duo processor), that why I wanted to try it in a VM on my i5 laptop.

I think, the audio is very choppy, because the signal is encrypted. Look in receiver1-window, if air encryption: 1 appears. You can scroll in the terminal.

 

[sq5bpf]

Yes, it's running in a virtual machine. Could be a graphics issue, tried different settings, but no luck so far.

look at some graphics acceleration settings etc, and try to disable them

I have it also running on an other laptop in Debian, there it works.
But on that one the audio (live and recording) is very choppy.

Thought that the laptop is to slow (centrino duo processor), that why I wanted to try it in a VM on my i5 laptop.

yes, that might be slow.

try to disable the spectrum display, this way it eats less cpu. if it is still bad, then mute the audio, and play the resulting ogg files automatically (this isn't exactly realtime, but the delay is a few minutes) - i've posted a script to do this a few posts ago.

also look at memory usage, maybe you could kill a few unneeded processes to free some?

 

[sq5bpf]

i made a minor update to osmo-tetra-sq5bpf to show the LA (Location Area) parameter, which is useful to distingiush cells. you can see it in tetra-rx (receiver1 etc) output, and telive.log if you enable alldump.

after enabling alldump in telive.log you will see something like:
20141227 22:48:09 FUNC:NETINFO1 CCODE:02 MCC:0104 MNC:xxxx DLF:39xxxxxxx ULF:38xxxxxxx LA:2 RX:1
which means that the first receiver (the one that reads from /tmp/fifo1) got a broadcast from network with colour code 2 and LA 2

 

[sm0vec]

i made a minor update to osmo-tetra-sq5bpf to show the LA (Location Area) parameter, which is useful to distingiush cells. you can see it in tetra-rx (receiver1 etc) output, and telive.log if you enable alldump.

after enabling alldump in telive.log you will see something like:
20141227 22:48:09 FUNC:NETINFO1 CCODE:02 MCC:0104 MNC:xxxx DLF:39xxxxxxx ULF:38xxxxxxx LA:2 RX:1
which means that the first receiver (the one that reads from /tmp/fifo1) got a broadcast from network with colour code 2 and LA 2

Thanks for the update, I just tested this and it works just fine.

I hope you have a lot of spare time during holidays so we can see more nice updates, maybe adding an "export=" in the rxx file allowing the user to modify the setting in telive at startup, eg "export START_FUNCTION="lmR" means that telive automatically will start logging, mute essi and recording