SDR# TETRA Demodulator Trunk Tracking Demonstration

[thewraith2008]

Many Many thanks for this DMO version. It is just working perfect.
And also the new version of TMO is simple cleaver. I have never head so many talk group in use
on our local Metro. It seems that now there is speaks all time day and night.
Some thing major changes must have been done, since i did not heard this before.

If you need more sample i will create them. I can only think of one thing I am missing now.
Scan of DMO. But this can be difficult since even Tetra Radio can not scan DMO.

Tanks Again for this great software.

Your original samples where a big help. Glad it works for you well.
At the moment I will focus on getting DM-MS to DM-MS working at little better. Do radios refer to this as "Direct". What is the feature terminology used by the manufactures?

It would be good if you could create a IQ sample for "Direct" on the 'B' channel.

Adding any features for something that is barely implemented is a bit premature at the moment.
That said, what do you mean "Scan of DMO". Is that scanning a list of frequencies that DMO traffic appears on?

R3Natas has provided me a sample.
I have found where the error is and why no speech is heard. Now fixed.
Problem was I applied an incorrect bit mask to scrambler code.

In addition to this, DMO will only work on the current version of the plug-in if MNC is lower than 16383 (0-16382) because of the error described above.

 

[thewraith2008]

My area has a main frequency and a secondary frequency. Actually I noticed that sometimes a conversation starts in the secondary frequency. A sort of reserve frequency. But the larger flow is concentrated in the main. After the communication ends at the secondary frequency, then it returns to the main frequency along with the others. I realized that sometimes it happens.

So does the issue your having, happen when call on that second carrier or only on main carrier?

 

[lynzoid]

Do radios refer to this as "Direct". What is the feature terminology used by the manufactures?

big M uses 'MS - MS' setting to describe DMO w/o rep/gw.
I do have some moto radios (some of those with repeater mode) and was trying to get some IQ records, but my puny sdr setup gets overloaded when i PTT nearby. Will play with diff antennae and gain settings.

 

[thewraith2008]

thewraith2008 I want to inform you a mistake. Sometimes the snd_ssi_granted beep repeats 3 or 4 times when a second person answers a call. Example: User A calls User B. When user B responds to the call, the snd_ssi_granted beep fires 3 or 4 times quickly. If there is a way to disable this and you can guide me about it, I thank you! I use all beeps, according to the tutorial guidelines. In the previous version of TTT this bug did not happen. Thanks for the release! It's working perfectly so far! The TIMEOUT problem seems to be solved. I'm using configured in 3 seconds and it's perfect so far! Very good!

I've made a change and I think it's OK now.

FIXED: TTT call state/priority sounds - "snd_ssi_granted"
       The "snd_ssi_granted" sound was triggering multiple times. This was due to the handling of the
       2 types of "D_TX_Granted" PDUs that are seen. The code that "DeDUPs" this PDU should work better
       at detecting the 2 types and if the 2 PDU are related. (In which case won't pass it on)

Will be available in next release. (Hot-fix release hopefully).
I'm currently working on another issue and if it turns out that TTT needs fixing then I would like to fix it before it's release.

 

[paparazzo]

The error (log) unfortunately does not help solve the problem. It only points to an area in code, not what part of the decodeing cause it.
"Der angegebene Schlüssel war nicht im Wörterbuch angegeben." or "The specified key was not specified in the dictionary."
Indicates that something expected was looked up but not found (result is a crash). Without an IQ sample, I can do much to solve it.

As mentioned, I was a bit rough with this code.
Please, if people what to see this develop further then DMO IQ samples are going to be needed. Both DMO DM-MS and DM-REP types.

Okay, here is my I/Q Recording of the DMO Repeaters presence Beacon causing the crash.
It's a HAMRadio DMO 1 Repeater, MCC:901, MNC:16383.

Dropbox - 07-05-32_430375kHz.zip

 

[DarkAngelT]

So does the issue your having, happen when call on that second carrier or only on main carrier?

It happens on the main frequency and also on the other. Almost every hour. always in the call response. It is a problem that comes and goes. Apparently an intermittent problem. Something has happened from the previous version to this in relation to the behavior of the beep.

 

[thewraith2008]

Okay, here is my I/Q Recording of the DMO Repeaters presence Beacon causing the crash.
It's a HAMRadio DMO 1 Repeater, MCC:901, MNC:16383.

Thank you for the sample of the beacon (presence signal).
On the development version I'm not getting a crash but seems to be getting a OK decoding of DPRES-SYNC PDU.
I don't see any MCC/MNC broadcast in the signal (Is that supposed to be seen in that state?) but as I have said before, DM-REP code is at a minimum and currently I'm looking at (focusing on) MS-MS or Direct DMO implementation.
I haven't started on "DM-REP DPRES-SYNC PDU contents in SCH/H" which contains this information, I think.

 

[thewraith2008]

It happens on the main frequency and also on the other. Almost every hour. always in the call response. It is a problem that comes and goes. Apparently an intermittent problem. Something has happened from the previous version to this in relation to the behavior of the beep.

See earlier post

 

[DarkAngelT]

I've made a change and I think it's OK now.

FIXED: TTT call state/priority sounds - "snd_ssi_granted"
       The "snd_ssi_granted" sound was triggering multiple times. This was due to the handling of the
       2 types of "D_TX_Granted" PDUs that are seen. The code that "DeDUPs" this PDU should work better
       at detecting the 2 types and if the 2 PDU are related. (In which case won't pass it on)

Will be available in next release. (Hot-fix release hopefully).
I'm currently working on another issue and if it turns out that TTT needs fixing then I would like to fix it before it's release.

Very good!
I would like to inform you that the program displays Burst errors at all times. I do not know if it's normal or not. For yes or no, I am informing you.

 

[thewraith2008]

Very good!
I would like to inform you that the program displays Burst errors at all times. I do not know if it's normal or not. For yes or no, I am informing you.

Throw me a bone here. TTT mode?, TMO or DMO?

Probably many reasons for this. Weak signal, not tuned 100%ish, TTT dual mode and others?

from Plug-in changelog:

ADDED: 'Stronger burst detection' option
       This has pros's and con's.
       Pro's: Less false positives for burst type detect. Better if used with TTT in dual mode where VC is parked on un-used frequency.
              And better for DMO transmissions.
       Con's: Weaker signal may not decode as well

Use 'Stronger burst detection' option in 'Config > Settings' for better decodes.

 

[DarkAngelT]

Throw me a bone here. TTT mode?, TMO or DMO?

Probably many reasons for this. Weak signal, not tuned 100%ish, TTT dual mode and others?

from Plug-in changelog:

ADDED: 'Stronger burst detection' option
       This has pros's and con's.
       Pro's: Less false positives for burst type detect. Better if used with TTT in dual mode where VC is parked on un-used frequency.
              And better for DMO transmissions.
       Con's: Weaker signal may not decode as well

Use 'Stronger burst detection' option in 'Config > Settings' for better decodes.

I do not use this option! My Signal is between 57 and 58 and noise level between -40 and -50. SDR calibrated millimetrically within the frequency range! Both cold and hot! However, in one of the tabs of NetInfo (the penultima tab if I'm not mistaken) it displays these error messages constantly! I have informed you as it may not be anything or it may represent something to you during your corrections in the program.

 

[DarkAngelT]

I am sending you what is displayed from the moment the demodulator is turned on
In the tab Burst errors

10:40:54 NDB2-AACH crc error FN:01 - TN:2
10:40:54 NDB1-SCH/F crc error FN:01 - TN:3 - Common
10:40:54 SYNC Synchronized FAIL
10:40:54 SYNC-BKN2 crc error FN:18 - TN:2 - Unallocated (Could be BLCH)
10:41:00 SYNC-BKN2 crc error FN:18 - TN:4 - Unallocated (Could be BLCH)
10:41:06 SYNC-BKN2 crc error FN:18 - TN:3 - Unallocated (Could be BLCH)
10:41:11 SYNC-BKN2 crc error FN:18 - TN:2 - Unallocated (Could be BLCH)
10:41:17 SYNC-BKN2 crc error FN:18 - TN:4 - Unallocated (Could be BLCH)
10:41:22 SYNC-BKN2 crc error FN:18 - TN:3 - Unallocated (Could be BLCH)
10:41:27 SYNC-BKN2 crc error FN:18 - TN:2 - Unallocated (Could be BLCH)
10:41:33 SYNC-BKN2 crc error FN:18 - TN:4 - Unallocated (Could be BLCH)
10:41:38 SYNC-BKN2 crc error FN:18 - TN:3 - Unallocated (Could be BLCH)
10:41:43 SYNC-BKN2 crc error FN:18 - TN:2 - Unallocated (Could be BLCH)
10:41:49 SYNC-BKN2 crc error FN:18 - TN:4 - Unallocated (Could be BLCH)
10:41:55 SYNC-BKN2 crc error FN:18 - TN:3 - Unallocated (Could be BLCH)


Above you had asked me and I did not answer.
I was not using DMO mode. I was using normal tetra reception.
Currently using TTT in single mode

 

[thewraith2008]

I am sending you what is displayed from the moment the demodulator is turned on
In the tab Burst errors

10:40:54 NDB2-AACH crc error FN:01 - TN:2-------------------------------------Probably a false positive
10:40:54 NDB1-SCH/F crc error FN:01 - TN:3 - Common-------------------------Probably scrambling code has not been determined yet.
10:40:54 SYNC Synchronized FAIL----------------------------------------------Normally seen at start (Before Synchronization has occurs)
10:40:54 SYNC-BKN2 crc error FN:18 - TN:2 - Unallocated (Could be BLCH)-----BLCH is sent by BS (Something to do with transmitter)
10:41:00 SYNC-BKN2 crc error FN:18 - TN:4 - Unallocated (Could be BLCH)
10:41:06 SYNC-BKN2 crc error FN:18 - TN:3 - Unallocated (Could be BLCH) Mapping of BLCH is vague. May not be BLCH
10:41:11 SYNC-BKN2 crc error FN:18 - TN:2 - Unallocated (Could be BLCH) But there is a pattern there. FN:18 TN:2,4,3
10:41:17 SYNC-BKN2 crc error FN:18 - TN:4 - Unallocated (Could be BLCH) If BLCH, This can be ignored. Your not missing anything.
10:41:22 SYNC-BKN2 crc error FN:18 - TN:3 - Unallocated (Could be BLCH)
10:41:27 SYNC-BKN2 crc error FN:18 - TN:2 - Unallocated (Could be BLCH)
10:41:33 SYNC-BKN2 crc error FN:18 - TN:4 - Unallocated (Could be BLCH)
10:41:38 SYNC-BKN2 crc error FN:18 - TN:3 - Unallocated (Could be BLCH)
10:41:43 SYNC-BKN2 crc error FN:18 - TN:2 - Unallocated (Could be BLCH)
10:41:49 SYNC-BKN2 crc error FN:18 - TN:4 - Unallocated (Could be BLCH)
10:41:55 SYNC-BKN2 crc error FN:18 - TN:3 - Unallocated (Could be BLCH)


Above you had asked me and I did not answer.
I was not using DMO mode. I was using normal tetra reception.
Currently using TTT in single mode

You are always are going to see errors in an over the air system, it's just the way it is.
If errors are streaming down the screen, then you have something wrong that needs addressing.

 

[hamradionl]

You are always are going to see errors in an over the air system, it's just the way it is.
If errors are streaming down the screen, then you have something wrong that needs addressing.

Dual Mode
Send you PM Burst Error log

 

[R3Natas]

Another strange thing I noticed with the TETRA Demodulator plugin, that when the private call is made, in the Group section it shows the ISSI of the initiator of the call, but before there was 0, and all the users of this private call were shown in the Users section

 

[hamradionl]

I am sending you what is displayed from the moment the demodulator is turned on
In the tab Burst errors

I got the same ERRORS in DUAL mode CC + VC but Voice is 100% NO stutter

 

[R3Natas]

Also, sometimes, false ISSI'is occur, when call is initiated in the group between two terminals, sometimes another two or three ISSI occur, but I definitely know there are only two subscribers talking

 

[thewraith2008]

Another strange thing I noticed with the TETRA Demodulator plugin, that when the private call is made, in the Group section it shows the ISSI of the initiator of the call, but before there was 0, and all the users of this private call were shown in the Users section

When using TTT with the plug-in, you should be ignoring the plug-in SDR# side panel in both CC/VC SDR# for GSSI/ISSI values.
The "Network Info" call list is only 'valid'* while on CC and only for the CC SDR#. The PDU log panel is OK on both.
The VC SDR# as no idea whats going on and most of what is shown there is rubbish.

Also, sometimes, false ISSI'is occur, when call is initiated in the group between two terminals, sometimes another two or three ISSI occur, but I definitely know there are only two subscribers talking

Is this in TTT or in the "Network Info" call list panel?
Which mode is this for TMO/DMO?
* Do you use option in plug-in "Call list - Alternative generation". If not then you could be seeing anything there.


Just a notice to everyone using the 'Burst error' tab.
It was only for testing and there is no guarantee that what you are seeing is valid information.
I probably should have removed it before releasing it. Oh well live and learn.

 

[R3Natas]

I'm using only Demodulator itself, without TTT.
Problem with ISSI occurs in TMO and no, I'm not using this feature "Call list - Alternative generation", can you specify what it does?

 

[hamradionl]

thewraith2008
Sorry, mean not any harm just share information to get perfect. Please leave the panels in, other panels show handy information to use.
In your video i notice some analyzing tool, Personal iam interested in that plugin / tool.