SDR# TETRA Demodulator Trunk Tracking Demonstration

[Ubbe]

It looks as if the site only accepts radio terminals using encryption to attach to the cell and that ISSI does not have that permission in the system database.

/Ubbe

 

[digiman1]

Hi

Got this message while monitoring my local cell. What does it mean?

View attachment 90833

I get this constantly, I always get NOT ACCEPTED then the same MS comes up as ACCEPTED a few seconds later.

 

[Ubbe]

It's usually multiple messages being sent when a terminal switches site, one for the affilation and one for the encryption. It shouldn't reject and then accept the same type of request.

/Ubbe

 

[oscar6]

This is the first and last time that I saw message like this.
For roaming, I got 'roaming location updating' messages

 

[digiman1]

This is the first and last time that I saw message like this.
For roaming, I got 'roaming location updating' messages

Ahh actually, mines is ROAMING LOCATION UPDATING, not MS UPDATING.

 

[digiman1]

I remember you mentioned that you would like to have ported this across to SDRUno, now that they support plugins do you think this will happen or is that plan pretty much dead in the water?

 

[thewraith2008]

I remember you mentioned that you would like to have ported this across to SDRUno, now that they support plugins do you think this will happen or is that plan pretty much dead in the water?

At these stage I have no further plans for development of a plug-in, it would have been based around the plug-in TNM uses.
I'm just not motivated at the moment to learn yet another API to create another TETRA plug-in (been there done that)

If SDR# continues down the road of striping functionality I may start focusing on SDRUno instead of SDR#.
I would prefer to stick with SDR# as it is simpler and more intuitive interface for working with digital signals where you don't want all the DSP.

 

[DarkAngelT]

Hello @thewraith2008 master!
What a miracle you are here!
Any news on plugins fusion?
These days I was wondering if you would ever become a great manufacturer of physical SDR receivers!
I hope to see news soon! I'm your fan!

 

[maxthered]

Hi, when I open SdrSharp this error comes up

I confirm and program start, in TTT 1.7.1.0 there's is CC TCP Error, is SDR# open for CC ?



When a signal arrives, the Timeslot lights up but does not decode anything.

Solutions ?

Another question, Auto Timeslot isn't enabled ?

Tnx from Italy

 

[thewraith2008]

Hi, when I open SdrSharp this error comes up

The error is saying the TETRA demodulator plug-in cannot create (i.e. write) a required file to the SDR# folder.
Because of this error, the TETRA demodulator plug-in does not complete startup and won't work with TTT.

I confirm and program start, in TTT 1.7.1.0 there's is CC TCP Error, is SDR# open for CC ?

When a signal arrives, the Timeslot lights up but does not decode anything.

This is because of first error and because the TETRA demodulator plug-in is in TTT enabled mode.

Solutions ?

You need to determine why there is a write access issue in the SDR# folder.

Another question, Auto Timeslot isn't enabled ?

When using the TETRA demodulator plug-in with TTT, TTT controls the timeslot selection.



Latest version (v1.7.1.0) can be found here: Release post

 

[maxthered]

I did a clean installation of SdrSharp and TTT, RtlSdr is no longer recognized but AirSpy yes.
Now there's no more error and everything works but nothing is heard when they are talking, I listen simultaneously with another receiver to understand when they speak.
Signal is OK, Output "Virtual Cable", WFM and Bandwidth 25.000.

 

[ATCTech]

Set the SDR# sound output to your speakers. With a single copy of SDR# running and the TETRA Demodulator plug-in installed and "Demodulator" enabled there's no need for a virtual cable as the signal isn't leaving SDR# until the audio is fed as analog. With 2 copies of SDR# running and TTT mode enabled in the plug-in for both copies and in the external TTT program you still use your speakers directly as the output in the SDR# configurations. The CC role copy will cause the "beep" sounds if you so desire while the VC role copy is used by TTT for the voice audio.

 

[thewraith2008]

RtlSdr is no longer recognized but AirSpy yes.

The file 'rtlsdr.dll' is most likely missing. You will need to run the batch file 'install-rtlsdr.bat' to download it again.
Or just copy 'rtlsdr.dll' from your last installed SDR#.

Now there's no more error and everything works but nothing is heard when they are talking, I listen simultaneously with another receiver to understand when they speak.
Signal is OK, Output "Virtual Cable", WFM and Bandwidth 25.000.

As mentioned, set your audio output device to your speakers.
e.g. [MME] Microsoft Sound Mapper - Output or [Windows Directsound] Primary Sound Driver or a device that is your speakers.



Latest version (v1.7.1.0) can be found here: Release post

 

[oz1jua]

I got a very strange behaver on DMO Gateway Call. Has this ever been testet in real.
It is connected to a Gateway and gSSI says: 0 and never change.
Then when trafic is recevied. The GSSI and ISSI show some odd behaver.
GSSI stays with all call 16777215 and ISSI is show c for clear but has lots of wrong numbers.
My Radio show correct numbers. But SDR# has change ISSI to some other numbers.
The signal is not perfect. But I do not think that this is the problem. When signal is 100% it still shows wrong.
And some times the MCC and MNC change to 1023 and 16383 but the GSSI is only show all call 16777215.
I do not understand this and what is the gSSI small letter g under GATE ?
Has this gSSI somthing to to do with what the Gateway Radio has selected as TMO Talkgroup ?.

PS: Not using TTT with this and is Unselected. The Auto is enabled. Have also try to select Stronger Burst Detection and Audio Bandpass.

 

[thewraith2008]

I got a very strange behaver on DMO Gateway Call. Has this ever been testet in real.

The DMO gateway implementation only goes as far as to detect that it is a gateway.
This was to at least indicate the presence of it and to stop crashing when it saw it.
Most likely any call activity (call control) may not be correctly processed.

I was only given a small IQ sample of a DMO gateway beacon which looks like a CAP+ in rest mode.
There was not any call activity to be able to test further.

It is connected to a Gateway and gSSI says: 0 and never change.
Then when trafic is recevied. The GSSI and ISSI show some odd behaver.
GSSI stays with all call 16777215 and ISSI is show c for clear but has lots of wrong numbers.
My Radio show correct numbers. But SDR# has change ISSI to some other numbers.
The signal is not perfect. But I do not think that this is the problem. When signal is 100% it still shows wrong.
And some times the MCC and MNC change to 1023 and 16383 but the GSSI is only show all call 16777215.
I do not understand this and what is the gSSI small letter g under GATE ?
Has this gSSI somthing to to do with what the Gateway Radio has selected as TMO Talkgroup ?.

PS: Not using TTT with this and is Unselected. The Auto is enabled. Have also try to select Stronger Burst Detection and Audio Bandpass.

IQ sample I have also returns GATE: 0
The '16777215' may be a gateway address (DMO-MS to Gateway) like 16777184 is for E.184 phone gateway.

"GATE:" is the gateway address.
"gSSI:" is the Gateway SSI, but this may not be the correct usage.

More info can be seen in EN 300-396-05 v1.3.1 - 14.1.2 DPRES-SYNC PDU (page 220)
- see element 'Usage restriction type (URT)'.
- see conditional element 'Addressing for URT' which depends on value of the above element.

I have not spent much time reading into the DMO gateway, so what I understand of it is limited.



Latest version (v1.7.1.0) can be found here: Release post

 

[Ubbe]

Gateways sends out a gateway number that the DMO mobiles attach to. I think that 1023 are that GW number. Isn't the GW to system link encrypted and that's why you see all TG and ISSI numbers being different and changing but the DMO frequency are non-encrypted? Or is it a fully open system?

/Ubbe

 

[thewraith2008]

The standards do indicate that some values used by 'Usage restriction type (URT)' are always encrypted. (see references in my last post)

Any encryption used in (DMO) call control PDUs would require that the 'air interface encryption' element to be set.
I'm sure (not looked at code for awhile), that the plug-in ignores a PDUs when the 'air interface encryption' is set.

The strange addresses been seen can also come down to usage of 'Pseudo SSI' (i.e fake)
This is indicated by : 'Source address type' or 'Destination address type' elements.
- see 9.3.5 Destination address type (page 161), 9.3.27 Source address type (page 166)



Latest version (v1.7.1.0) can be found here: Release post

 

[digiman1]

I currently have an AOR DV1 Receiver which allows Tetra monitoring, my issue of course is that my network has a mixture of Enc and Clear comms meaning I get the garbled audio coming though on my DV1 most of the time, they said the DV1 should not be bringing through any garbled audio, it should mute this.

AOR Have asked me to provide some IQ from SDR# Files with the mixture of clear and enc comms taking place so they can study it, I was able to get the IQ files I needed but my question is, within the demodulator plugin can I have the encrypted audio come through, more for peace of mind that I am sending them IQ Files with actual enc voice comms taking place. At the minute when I see an encrypted call taking place I cannot unmute this to be able to hear the garbled audio, I do however remember being able to do this in the past, can this still be done and if so, how?

Cheers.

 

[thewraith2008]

In the plug-in settings: Uncheck the "Listen only clear speech" option and it should allow encrypted speech to pass so it can be heard.

Programmatically from a plug-in (or SDR) stand point, there is no way to tell if the speech bursts are encrypted or not.
The speech bursts that are received, do not indicate if the are encrypted or not. This is indicated via encrypted PDUs, which we can't decode.

Real radios don't suffer this affliction because they detect if encryption is used via the MAC and then apply the appropriate decryption (as determined from other encrypted PDUs) so they can decode the call control PDUs to then associate the usage marker in the PDUs and the access-assign PDU (AACH) with speech bursts.

Muting encrypted speech is a case of, if no PDUs are seen with the usage marker that matches the one in the speech burst (in AACH), Then mute speech.



Latest version (v1.7.1.0) can be found here: Release post

 

[digiman1]

In the plug-in settings: Uncheck the "Listen only clear speech" option and it should allow encrypted speech to pass so it can be heard.

I tried this but I am unable to unmute, as soon as I click the speaker icon it just mutes itself again.