Tetra decoding

[efalgae]

Problem with coordinates.

Hello everyone. First to say: sorry for my English.
Okay. I got a little problem. Yesterday (finally) I got my TETRA decoder working. Perfect voice, perfect everything.
But when I try to see the coordinates in Google Earth, I saw that the longitude has a prefix (459) that doesn't let Earth find the coordinates correctly.

FUNC:SDSDEC [CPTI:1 CalledSSI:190302 CallingSSI:190254 CallingEXT:0 UserData4: len:76 protoid:0A(Location information protocol) LIP:[SHORT LOCATION REPORT: lat:28.365305N lon:45913.875000W errorL20m speed:11.0km/h heading:NNE]] RX:1

Sorry for my english again. If you don't understand something, just ask and I'll try to answer my best.
Regards

 

[sq5bpf]

Hello everyone. First to say: sorry for my English.
Okay. I got a little problem. Yesterday (finally) I got my TETRA decoder working. Perfect voice, perfect everything.
But when I try to see the coordinates in Google Earth, I saw that the longitude has a prefix (459) that doesn't let Earth find the coordinates correctly.

FUNC:SDSDEC [CPTI:1 CalledSSI:190302 CallingSSI:190254 CallingEXT:0 UserData4: len:76 protoid:0A(Location information protocol) LIP:[SHORT LOCATION REPORT: lat:28.365305N lon:45913.875000W errorL20m speed:11.0km/h heading:NNE]] RX:1

send me telive.log, and the geographical coordinates of the area this is from (they don't need to be accurate, coordinates of the city centre are sufficient)

 

[bommel]

FUNC:SDSDEC [CPTI:1 CalledSSI:190302 CallingSSI:190254 CallingEXT:0 UserData4: len:76 protoid:0A(Location information protocol) LIP:[SHORT LOCATION REPORT: lat:28.365305N lon:45913.875000W errorL20m speed:11.0km/h heading:NNE]] RX:1

if you remove those "459" you will see on google maps that the position is around 17km away from your location ¿

 

[jordilell]

SDS messages (null)

Dear sirs!
I'm writing you again to ask about something weird that keeps showing up on TELIVE monitor.
In maybe one minute i'm getting about 7-8 lines with messages of this kind: SDS 10019 -> 210092 (null).
Is that normal? Since I'm not able to get any position info, could that be undecoded LIP messages?

I'm fully wishing to help collaborating with this amazing project provided that I were able!

 

[efalgae]

Contents of telive.log

As you can see, coordinates are ok, but I don't understand why that "459" prefix in longitude. How can I fix it so I can monitor these SSI's on Google Earth?

20150716 00:20:37 **** log start ****
20150716 00:20:59 FUNC:SDS [0100111101000000101110011011001010110000101010000001010000011110110001000000010111100010100010000111000110110010000000000001000000101000000000000001000010000000000000000000000000000000000]
20150716 00:20:59 FUNC:SDSDEC [CPTI:1 CalledSSI:190302 CallingSSI:190154 CallingEXT:0 UserData4: len:76 protoid:0A(Location information protocol) LIP:[SHORT LOCATION REPORT: lat:28.496078N lon:45913.886719W error<20m speed: 0.0km/h heading:N]] RX:1
20150716 00:20:59 FUNC-SDS DATA SSI:00190302 IDX:000 IDT:1 ENCR:0 RX:1
20150716 00:21:59 FUNC:SDS [0100111101000000101110011011001010110000101010000001010000011110110001000000010111110010100010000111000111100010000000000001000000101000000000000001000010000000000000000000000000000000000]
20150716 00:21:59 FUNC:SDSDEC [CPTI:1 CalledSSI:190302 CallingSSI:190154 CallingEXT:0 UserData4: len:76 protoid:0A(Location information protocol) LIP:[SHORT LOCATION REPORT: lat:28.496111N lon:45913.886719W error<20m speed: 0.0km/h heading:N]] RX:1
20150716 00:21:59 FUNC-SDS DATA SSI:00190302 IDX:000 IDT:1 ENCR:0 RX:1
20150716 00:22:59 FUNC:SDS [0100111101000000101110011011001010110000101010000001010000011110110001000000011000010010100010000111000111000010000000000001000000101000000000000001000010000000000000000000000000000000000]
20150716 00:22:59 FUNC:SDSDEC [CPTI:1 CalledSSI:190302 CallingSSI:190154 CallingEXT:0 UserData4: len:76 protoid:0A(Location information protocol) LIP:[SHORT LOCATION REPORT: lat:28.496090N lon:45913.886719W error<20m speed: 0.0km/h heading:N]] RX:1
20150716 00:22:59 FUNC-SDS DATA SSI:00190302 IDX:000 IDT:1 ENCR:0 RX:1
20150716 00:23:11 FUNC:SDS [0100111101000000101110011011001010110000101010000001010000011110110001000000010111010010100010000111000111010010000000000001000000101000000000000001000010000000000000000000000000000000000]
20150716 00:23:59 FUNC:SDSDEC [CPTI:1 CalledSSI:190302 CallingSSI:190154 CallingEXT:0 UserData4: len:76 protoid:0A(Location information protocol) LIP:[SHORT LOCATION REPORT: lat:28.496099N lon:45913.886719W error<20m speed: 0.0km/h heading:N]] RX:1
20150716 00:23:59 FUNC-SDS DATA SSI:00190302 IDX:000 IDT:1 ENCR:0 RX:1
20150716 00:24:38 FUNC:SDS [0100111101000000101110011011001010110000101010000001010000011110110001000000011000000010100010000111000110110010000000000001000000101000000000000001000010000000000000000000000000000000000]
20150716 00:24:59 FUNC:SDSDEC [CPTI:1 CalledSSI:190302 CallingSSI:190154 CallingEXT:0 UserData4: len:76 protoid:0A(Location information protocol) LIP:[SHORT LOCATION REPORT: lat:28.496078N lon:45913.886719W error<20m speed: 0.0km/h heading:N]] RX:1
20150716 00:24:59 FUNC-SDS DATA SSI:00190302 IDX:000 IDT:1 ENCR:0 RX:1
20150716 00:28:00 **** log end ****

-THANKS

 

[sq5bpf]

As you can see, coordinates are ok, but I don't understand why that "459" prefix in longitude. How can I fix it so I can monitor these SSI's on Google Earth?

thanks for the logs. you've found a bug in the longtitude calculation. please update osmo-tetra-sq5bpf

with the fixed version you will get:
CallingSSI:190154 CallingEXT:0 UserData4: len:76 protoid:0A(Location information protocol) LIP:[SHORT LOCATION REPORT: lat:28.496078N lon:13.885689W error<20m speed: 0.0km/h heading:N]

 

[sq5bpf]

I'm writing you again to ask about something weird that keeps showing up on TELIVE monitor.
In maybe one minute i'm getting about 7-8 lines with messages of this kind: SDS 10019 -> 210092 (null).
Is that normal? Since I'm not able to get any position info, could that be undecoded LIP messages?

no. this is a bug that appears sometimes when an empty sds is sent (or at least i think so, i don't have logs to verify this)

I'm fully wishing to help collaborating with this amazing project provided that I were able!

if you want to help, then send logs, not screenshots

 

[efalgae]

Hello. Thanks for helping me. But sorry, it didn't work...I think that you mistake. I think that you fixed the bug for that SSI (190154), but the others SSI show coordinate 0.00000 forever , Here's the log


20150716 20:24:28 **** log start ****
20150716 20:24:41 FUNC:SDS [0100111101000000101110011011001010110000101010000001010000011110110001000000010110100010100010000111000110010010000000000001000000101000000000000001000010000000000000000000000000000000000]
20150716 20:24:41 FUNC:SDSDEC [CPTI:1 CalledSSI:190302 CallingSSI:190154 CallingEXT:0 UserData4: len:76 protoid:0A(Location information protocol) LIP:[SHORT LOCATION REPORT: lat:28.496058N lon:13.885754W error<20m speed: 0.0km/h heading:N]] RX:1
20150716 20:24:41 FUNC-SDS DATA SSI:00190302 IDX:000 IDT:1 ENCR:0 RX:1
20150716 20:24:42 FUNC:SDS [0100111101000000101110011010001011110000101010000001010001100000000000000000000000000000000000000000000000001111111111111101000000101000000000000001000010000000000000000000000000000000000]
20150716 20:24:42 FUNC:SDSDEC [CPTI:1 CalledSSI:190302 CallingSSI:190091 CallingEXT:0 UserData4: len:76 protoid:0A(Location information protocol) LIP:[SHORT LOCATION REPORT: lat:0.000000N lon:0.000000E errorunknown speed:1123.6km/h heading:NNW]] RX:1
20150716 20:24:42 FUNC-SDS DATA SSI:00190302 IDX:000 IDT:1 ENCR:0 RX:1
20150716 20:24:51 FUNC:SDS [010011110111111111111111111111110111000000100010000101001000101101000000000000000001000010000000000000000000000000000000000]
20150716 20:24:51 FUNC:SDSDEC [CPTI:1 CalledSSI:22870 CallingSSI:16777213 CallingEXT:0 UserData4: len:9 protoid:0A(Location information protocol) LIP:[LONG PDU TYPE 1 Immediate location report request (not implemented yet)]] RX:1
20150716 20:24:51 FUNC-SDS DATA SSI:00022870 IDX:000 IDT:1 ENCR:0 RX:1
20150716 20:25:05 FUNC:SDS [0100111101000000101110011011100011110000101010000001010001100000000000000000000000000000000000000000000000001111111111111101000000101000000000000001000010000000000000000000000000000000000]
20150716 20:25:05 FUNC:SDSDEC [CPTI:1 CalledSSI:190302 CallingSSI:190179 CallingEXT:0 UserData4: len:76 protoid:0A(Location information protocol) LIP:[SHORT LOCATION REPORT: lat:0.000000N lon:0.000000E errorunknown speed:1123.6km/h heading:NNW]] RX:1
20150716 20:25:05 FUNC-SDS DATA SSI:00190302 IDX:000 IDT:1 ENCR:0 RX:1
20150716 20:25:15 FUNC:SDS [0100111101000000101110011011001010110000101010000001010000011110110001000000010111100010100010000111001000010010000000000001000000101000000000000001000010000000000000000000000000000000000]
20150716 20:25:15 FUNC:SDSDEC [CPTI:1 CalledSSI:190302 CallingSSI:190154 CallingEXT:0 UserData4: len:76 protoid:0A(Location information protocol) LIP:[SHORT LOCATION REPORT: lat:28.496143N lon:13.885710W error<20m speed: 0.0km/h heading:N]] RX:1
20150716 20:25:15 FUNC-SDS DATA SSI:00190302 IDX:000 IDT:1 ENCR:0 RX:1
20150716 20:25:15 FUNC:SDS [0100111101000000101110011010001011110000101010000001010001100000000000000000000000000000000000000000000000001111111111111101000000101000000000000001000010000000000000000000000000000000000]
20150716 20:25:15 FUNC:SDSDEC [CPTI:1 CalledSSI:190302 CallingSSI:190091 CallingEXT:0 UserData4: len:76 protoid:0A(Location information protocol) LIP:[SHORT LOCATION REPORT: lat:0.000000N lon:0.000000E errorunknown speed:1123.6km/h heading:NNW]] RX:1
20150716 20:25:15 FUNC-SDS DATA SSI:00190302 IDX:000 IDT:1 ENCR:0 RX:1
20150716 20:25:15 FUNC:SDS [0100111101000000101110011010001011110000101010000001010001100000000000000000000000000000000000000000000000001111111111111101000000101000000000000001000010000000000000000000000000000000000]
20150716 20:25:15 FUNC:SDSDEC [CPTI:1 CalledSSI:190302 CallingSSI:190091 CallingEXT:0 UserData4: len:76 protoid:0A(Location information protocol) LIP:[SHORT LOCATION REPORT: lat:0.000000N lon:0.000000E errorunknown speed:1123.6km/h heading:NNW]] RX:1
20150716 20:25:15 FUNC-SDS DATA SSI:00190302 IDX:000 IDT:1 ENCR:0 RX:1
20150716 20:25:38 FUNC:SDS [0100111101000000101110011011001010110000101010000001010000011110110001000000010110100010100010000111000110010010000000000001000000101000000000000001000010000000000000000000000000000000000]
20150716 20:25:38 FUNC:SDSDEC [CPTI:1 CalledSSI:190302 CallingSSI:190154 CallingEXT:0 UserData4: len:76 protoid:0A(Location information protocol) LIP:[SHORT LOCATION REPORT: lat:28.496058N lon:13.885754W error<20m speed: 0.0km/h heading:N]] RX:1
20150716 20:25:38 FUNC-SDS DATA SSI:00190302 IDX:000 IDT:1 ENCR:0 RX:1
20150716 20:25:39 FUNC:SDS [0100111101000000101110011010001011110000101010000001010001100000000000000000000000000000000000000000000000001111111111111101000000101000000000000001000010000000000000000000000000000000000]
20150716 20:25:39 FUNC:SDSDEC [CPTI:1 CalledSSI:190302 CallingSSI:190091 CallingEXT:0 UserData4: len:76 protoid:0A(Location information protocol) LIP:[SHORT LOCATION REPORT: lat:0.000000N lon:0.000000E errorunknown speed:1123.6km/h heading:NNW]] RX:1
20150716 20:25:39 FUNC-SDS DATA SSI:00190302 IDX:000 IDT:1 ENCR:0 RX:1
20150716 20:25:50 FUNC:SDS [010011110111111111111111111111110111000000100010000101001000101101000000000000000001000010000000000000000000000000000000000]
20150716 20:25:50 FUNC:SDSDEC [CPTI:1 CalledSSI:22870 CallingSSI:16777213 CallingEXT:0 UserData4: len:9 protoid:0A(Location information protocol) LIP:[LONG PDU TYPE 1 Immediate location report request (not implemented yet)]] RX:1
20150716 20:25:50 FUNC-SDS DATA SSI:00022870 IDX:000 IDT:1 ENCR:0 RX:1
20150716 20:26:06 FUNC:SDS [0100111101000000101110011011100011110000101010000001010001100000000000000000000000000000000000000000000000001111111111111101000000101000000000000001000010000000000000000000000000000000000]
20150716 20:26:06 FUNC:SDSDEC [CPTI:1 CalledSSI:190302 CallingSSI:190179 CallingEXT:0 UserData4: len:76 protoid:0A(Location information protocol) LIP:[SHORT LOCATION REPORT: lat:0.000000N lon:0.000000E errorunknown speed:1123.6km/h heading:NNW]] RX:1
20150716 20:26:06 FUNC-SDS DATA SSI:00190302 IDX:000 IDT:1 ENCR:0 RX:1
20150716 20:26:15 **** log end ****

 

[efalgae]

For now, forget that I said that. Let me test it tomorrow and I will let you know. Sorry for the inconvenience, and for my English.
73.

 

[jordilell]

telive.log SDS content

no. this is a bug that appears sometimes when an empty sds is sent (or at least i think so, i don't have logs to verify this)



if you want to help, then send logs, not screenshots

Thank you! Here are some lines from telive.log related to those SDS

20150716 00:04:29 FUNC:SDS [01001111010000000111010000110110011100000100000100000100001000001010001000000100000000000001000010000000000000000000000000000000000]
20150716 00:04:29 FUNC:SDSDEC [CPTI:1 CalledSSI:210092 CallingSSI:119001 CallingEXT:0 UserData4: len:24 protoid:82(Text Messaging) SDS-TL:[ MsgType:SDS-REPORT] ] RX:1
20150716 00:04:29 FUNC-SDS DATA SSI:00210092 IDX:000 IDT:1 ENCR:0 RX:1
20150716 00:04:29 FUNC:SDS [01001111010000000111010000110110011100000100000100000100001000000000000000000100001000001000000111111111111111111111111100000101010]
20150716 00:04:29 FUNC:SDSDEC [CPTI:1 CalledSSI:210092 CallingSSI:119001 CallingEXT:0 UserData4: len:24 protoid:82(Text Messaging) SDS-TL:[ MsgType:SDS-REPORT] ] RX:1


20150716 00:04:33 FUNC:SDS [01001111010000000111010000110110011100000100000100000100001000001010001001110100001000001000000111111111111111111111111100000101010]
20150716 00:04:33 FUNC:SDSDEC [CPTI:1 CalledSSI:211000 CallingSSI:119001 CallingEXT:0 UserData4: len:24 protoid:82(Text Messaging) SDS-TL:[ MsgType:SDS-REPORT] ] RX:1
20150716 00:04:33 FUNC-SDS DATA SSI:00211000 IDX:000 IDT:1 ENCR:0 RX:1

20150716 09:43:58 FUNC:SDS [01001111010000000111010000110110011100000100000100000100001000001010001110001110001000001000000111111111111111111111111100000101010]
20150716 09:43:58 FUNC:SDSDEC [CPTI:1 CalledSSI:211000 CallingSSI:119001 CallingEXT:0 UserData4: len:24 protoid:82(Text Messaging) SDS-TL:[ MsgType:SDS-REPORT] ] RX:1
20150716 09:43:58 FUNC-SDS DATA SSI:00211000 IDX:000 IDT:1 ENCR:0 RX:1
20150716 09:43:58 FUNC:SDS [01001111010000000111010000110110011100000100000100000100001000000000000110001110000000000001000010000000000000000000000000000000000]
20150716 09:43:58 FUNC:SDSDEC [CPTI:1 CalledSSI:211000 CallingSSI:119001 CallingEXT:0 UserData4: len:24 protoid:82(Text Messaging) SDS-TL:[ MsgType:SDS-REPORT] ] RX:1
20150716 09:43:58 FUNC-SDS DATA SSI:00211000 IDX:000 IDT:1 ENCR:0 RX:1

20150716 09:44:12 FUNC:SDS [01001111010000000111010000110110011100000100000100000100001000001010001110010000000000000001000010000000000000000000000000000000000]
20150716 09:44:12 FUNC:SDSDEC [CPTI:1 CalledSSI:211000 CallingSSI:119001 CallingEXT:0 UserData4: len:24 protoid:82(Text Messaging) SDS-TL:[ MsgType:SDS-REPORT] ] RX:1
20150716 09:44:12 FUNC-SDS DATA SSI:00211000 IDX:000 IDT:1 ENCR:0 RX:1
20150716 09:44:12 FUNC:SDS [01001111010000000111010000110110011100000100000100000100001000000000000110010000000000000001000010000000000000000000000000000000000]
20150716 09:44:12 FUNC:SDSDEC [CPTI:1 CalledSSI:211000 CallingSSI:119001 CallingEXT:0 UserData4: len:24 protoid:82(Text Messaging) SDS-TL:[ MsgType:SDS-REPORT] ] RX:1
20150716 09:44:12 FUNC-SDS DATA SSI:00211000 IDX:000 IDT:1 ENCR:0 RX:1

 

[efalgae]

Okay. Everything is working perfectly fine.
I'm happy for helping you finding bugs hahaha
Regards, 73

 

[osidovich]

Some quick questions about TETRA Air Interface:

Different Location Areas (LA), under the same MCC/MNC pair, are used to implement roaming of a MS, like in GSM or different LAs can be used for different services in the same network (ie. LA 1 is used only for buses, LA 2 for trams, LA 3 for subway in a TETRA netowrk of a public transport company)?

I can't grasp the difference between Colour code and LA. A coincise definition?


Also, I'm experiencing a strange behaviour with telive rxx and receiver1 of ommocom-tetra.

Sometimes it seems that they enter in a loop.

On rxx I listen, again and again, under the same logical channel, the voice call. Subsequent listenings seems to have some appended some additional seconds of conversation.
On receiver1, when I stop GRC flow, it continues to log TETRA PDU, like a buffer.

 

[sq5bpf]

Some quick questions about TETRA Air Interface:

Different Location Areas (LA), under the same MCC/MNC pair, are used to implement roaming of a MS, like in GSM or different LAs can be used for different services in the same network (ie. LA 1 is used only for buses, LA 2 for trams, LA 3 for subway in a TETRA netowrk of a public transport company)?

I can't grasp the difference between Colour code and LA. A coincise definition?

LA is for roaming. dfferent LAs are at different frequencies.

CC is used when there might be several channels from different towers on one frequency. suppose that you have two cities close by on the same frequency, with the same mcc/mnc. these two cities should have a different cc. usually it will not be a problem, even if it had the same cc. but when propagation is better the mobile terminals might receive towers from both cities (and vice versa). because the CC is used when coding the message, the base stations will only decode the uplinks with the correct cc (and the same goes for the downlink)

so if you're designing a network, take care that every station that has the same frequency, has a different CC, even when they are far away.

Also, I'm experiencing a strange behaviour with telive rxx and receiver1 of ommocom-tetra.

Sometimes it seems that they enter in a loop.

On rxx I listen, again and again, under the same logical channel, the voice call. Subsequent listenings seems to have some appended some additional seconds of conversation.
On receiver1, when I stop GRC flow, it continues to log TETRA PDU, like a buffer.

the only reason i can think of is that you're launching the gnuradio-companion flowgraph first, and receiver1 second. this way when the /tmp/fifoX is filled by gnuradio, receiver1 starts receiving this data forever (like from a circular buffer, but this is a fifo). this should not happen, and is a bug in the linux kernel. i used to have it on my previous install on my laptop, but can't reproduce it now. one quick way to check is to stop everything, and launch receiver1 anain. if it starts receiving traffic, then you've triggered this bug. unfortunately only a reboot will fix it.

or a more generic description: create a pipe, feed it lots of data, close the descriptor, open it for reading, and you will get the same data over and over. for some reason this isn't triggered every time i've tried. if i ever see a reliable way to trigger it on a recent kernel, i will send a bug report to linux-kernel

 

[sq5bpf]

Thank you! Here are some lines from telive.log related to those SDS

20150716 00:04:29 FUNC:SDS [01001111010000000111010000110110011100000100000100000100001000001010001000000100000000000001000010000000000000000000000000000000000]
20150716 00:04:29 FUNC:SDSDEC [CPTI:1 CalledSSI:210092 CallingSSI:119001 CallingEXT:0 UserData4: len:24 protoid:82(Text Messaging) SDS-TL:[ MsgType:SDS-REPORT] ] RX:1

ok, so it seems this is triggerend by a sds-report. i will fix it in some future release

 

[sq5bpf]

Okay. Everything is working perfectly fine.
I'm happy for helping you finding bugs hahaha

tnx for the logs!

btw you will still get these:
0150716 20:24:42 FUNC:SDSDEC [CPTI:1 CalledSSI:190302 CallingSSI:190091 CallingEXT:0 UserData4: len:76 protoid:0A(Location information protocol) LIP:[SHORT LOCATION REPORT: lat:0.000000N lon:0.000000E errorunknown speed:1123.6km/h heading:NNW]] RX:1

this is an unknown location (the location error is unknown. btw i will have to fix a bug in the formatting). probably the radio has just been switched on, and the gps never got a position fix, so it reports 0.0N 0.0E

you might also see something that looks like a valid position, but with "errorunknown". this is probably a gps that had a fix, but later lost view of the satelites (is in a garage etc)

 

[lfcf]

Hello from Portugal,

Using Kali Linux and the magic software Is this TETRA?

BURST
CRC COMP: 0x1d0f OK
SB1 58/18/1/000 type1: 001010110101100101110100000000001000011000000000000001110001
TMB-SAP SYNC CC 101101(0x2d) TN 01(1) FN 10010(18) MN 111010(58) MCC 0100001100(268) MNC 00000000000011(3)
TMV-UNITDATA.ind 58/18/1/000 BSCH CRC=1 SYNC
TMV-UNITDATA.ind 58/18/1/000 AACH CRC=1 ACCESS-ASSIGN
ACCESS-ASSIGN PDU: ACCESS1: A/1 ACCESS2: A/0
CRC COMP: 0x1d0f OK
SB2 58/18/1/000 type1: 1000111001111110001111000000101001101110011010100000001101111010000101010100000000010001010001011111111111111111110101100111
TMV-UNITDATA.ind 58/18/1/000 UNKNOWN CRC=1 BROADCAST
BNCH SYSINFO (DL 392762500 Hz, UL 382762500 Hz), service_details 0x0d67 LA:4421 Hyperframe 41015
Advanced link: 1
Air encryption: 1
SNDCP data: 1
unknown 0x8: 0
Circuit data: 0
Voice service: 1
Normal mode: 1
Migration supported: 0
Cell never uses minimum mode: 1
Priority cell: 0
De-registration mandatory: 1
Registration mandatory: 1




** SQ5BPF TETRA Monitor 1.5 ** MCC: 268 MNC: 3 ColourCode: 39 Down:390.5875MHz Up:380.5875MHz LA: 4409 mutessi:0 alldump:1 mute:0 record:0 log:0 verbose:4 lock:0 no filter []
*** Known frequencies: ***
Downlink:390.5875MHz Uplink:380.5875MHz MCC: 268 MNC: 3 LA: 4409 reason:[SN] RX:1
Downlink:392.7625MHz LA: 4421 reason:[SN] RX:1
Downlink:392.0375MHz LA: 4439 reason:[N] RX:1
Downlink:392.3625MHz LA: 5668 reason:[N] RX:1
Downlink:392.6875MHz LA: 5682 reason:[N] RX:1
Downlink:391.0125MHz LA: 4422 reason:[N] RX:1
Downlink:391.1125MHz LA: 4419 reason:[N] RX:1
Downlink:391.2125MHz LA: 4420 reason:[N] RX:1
Downlink:390.9625MHz LA: 4440 reason:[N] RX:1
Downlink:390.9125MHz LA: 4441 reason:[N] RX:1
Downlink:391.2625MHz LA: 4450 reason:[N] RX:1
Downlink:390.6875MHz LA: 4418 reason:[N] RX:1
Downlink:390.4125MHz LA: 4404 reason:[N] RX:1
Downlink:390.3125MHz LA: 4436 reason:[N] RX:1
Downlink:391.5625MHz LA: 4424 reason:[N] RX:1
Downlink:392.2875MHz LA: 5633 reason:[N] RX:1
Downlink:391.7625MHz LA: 5671 reason:[N] RX:1


Reguards

 

[jlxsolutions]

yes it is tetra lets hope you get some un encrypted signals to listen to

 

[hansheesbeen]

And its encrypted, think you hear only garbeled audio?

Verstuurd vanaf mijn D6603 met Tapatalk

 

[lfcf]

yes it is tetra lets hope you get some un encrypted signals to listen to

Great!! MNC 3, according to a website, belongs to a mobile phone operator in Portugal so i thought it was not TETRA (emergency services TETRA called SIRESP in Portugal).

This is a log from message window from telive:

20150719 00:08:57 FUNC:FREQINFO1 DLF:390962500 LA:4440 RX:1 Down:390.9125MHz Up:0.0000MHz LA:4441 MCC:0 MNC:0 reason:2 RX:1
20150719 00:08:57 FUNC:FREQINFO1 DLF:390912500 LA:4441 RX:1 Down:390.4125MHz Up:0.0000MHz LA:4404 MCC:0 MNC:0 reason:2 RX:1
20150719 00:08:57 FUNC:NETINFO1 CCODE:2d MCC:010c MNC:0003 DLF:392762500 ULF:382762500 LA:4421 RX:1 Down:391.0125MHz Up:0.0000MHz LA:4422 MCC:0 MNC:0 reason:2 RX:1
20150719 00:08:57 FUNC:FREQINFO1 DLF:390412500 LA:4404 RX:1 Down:390.9625MHz Up:0.0000MHz LA:4440 MCC:0 MNC:0 reason:2 RX:1
20150719 00:08:57 FUNC:FREQINFO1 DLF:391012500 LA:4422 RXNOW PLAYING 4
20150719 00:08:57 FUNC:FREQINFO1 DLF:390962500 LA:4440 RX:1 timeout rec /tetra/in/traffic_20150719_000834_22_0_0_0.out

I listen to lots of garbled voice

 

[sq5bpf]

I listen to lots of garbled voice

enable mutessi


btw i'm thinking that maybe i should enable it by default in the next versions? it would make the program loose some unencrypted voice traffic, but people won't report "garbled voice" anymore