SDR# TETRA Demodulator Trunk Tracking Demonstration

DarkAngelT

Member
Joined
Sep 27, 2018
Messages
131
I was happy to hear that TSSDR returned to the forum and more! He came back by releasing an update! with you two the world of radio listening only has to win!
 

thewraith2008

Member
Joined
Nov 22, 2016
Messages
1,840
I post the here for those who are interested in this stuff.


A really bad transmission (call) that is flooded with stealing frames.

I understand the need for stealing frames but I don't understand why this occurs. The BS has lost it's mind.
It's quite stupid as the end result is almost all of the speech was stolen from the transmission. What's the point in signalling the MSes if the payload (speech) does not arrive intact.
The standard recommends 1 stealing frame in 1 multiframe (That's 1 burst in 18)
That's not what happening here in this sample.

Code:
This is the call as from the event log:
11/01/2019 7:32:41 PM - Call ID: 1506 - On carrier: 3604 TS:3 - Group: 123456 []
11/01/2019 7:32:41 PM - Call ID: 1506 - Calling SSI: 98765
11/01/2019 7:32:46 PM - Call ID: 1506 - VC D-TX-Ceased SSI: 98765
11/01/2019 7:32:48 PM - Call ID: 1506 - VC D-Released

Each line from 'bursts type' tab listed at bottom (next post) represents 60mS of audio.

Here's a break down: (sp=speech, c=signalling, blank=stolen frames)
Code:
# of frames for each burst type
===================================
5
4     sp          240mS
1
2     sp          120mS
3
2     sp          120mS
1
14     sp          840mS
12
1     sp           60ms
1
2     sp          120mS
14
1     sp           60mS
5
1     sp           60mS
12
1     c
1     s(1/2)      30mS
===================================
83     27.5   Total Frames / Total speech frames
===================================
4980mS 1620mS Total time / Total Speech time (what's not stolen)
-30          30mS not included (is signalling frame (c) - Not Audio)
4950mS        Total audio time of call
===================================
    3330mS Stolen speech frames from 4950mS of call audio
===================================

Continues in next post...
 

thewraith2008

Member
Joined
Nov 22, 2016
Messages
1,840
...continued from previous post.

This is from a 'burst type' tab I've included in the plug-in:
Code:
 19:32:41 PM   STCH   [MLE2] + STCH   [Fend] (FN:08 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:41 PM   STCH   [NULL] + STCH   [BNCH] (FN:09 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:41 PM   STCH   [MLE2] + STCH   [Fend] (FN:10 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:41 PM   STCH   [NULL] + STCH   [BNCH] (FN:11 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:41 PM   STCH   [MLE2] + STCH   [Fend] (FN:12 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:41 PM   TCH/F                 [VOICE] (FN:13 - TN:3) - Traffic     - MAC_Traffic
 19:32:41 PM   TCH/F                 [VOICE] (FN:14 - TN:3) - Traffic     - MAC_Traffic
 19:32:41 PM   TCH/F                 [VOICE] (FN:15 - TN:3) - Traffic     - MAC_Traffic
 19:32:41 PM   TCH/F                 [VOICE] (FN:16 - TN:3) - Traffic     - MAC_Traffic
 19:32:41 PM   STCH   [NULL] + STCH   [BNCH] (FN:17 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:41 PM   TCH/F                 [VOICE] (FN:01 - TN:3) - Traffic     - MAC_Traffic
 19:32:41 PM   TCH/F                 [VOICE] (FN:02 - TN:3) - Traffic     - MAC_Traffic
 19:32:41 PM   STCH   [NULL] + STCH   [BNCH] (FN:03 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:42 PM   STCH   [MLE2] + STCH   [Fend] (FN:04 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:42 PM   STCH   [NULL] + STCH   [BNCH] (FN:05 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:42 PM   TCH/F                 [VOICE] (FN:06 - TN:3) - Traffic     - MAC_Traffic
 19:32:42 PM   TCH/F                 [VOICE] (FN:07 - TN:3) - Traffic     - MAC_Traffic
 19:32:42 PM   STCH   [MLE2] + STCH   [Fend] (FN:08 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:42 PM   TCH/F                 [VOICE] (FN:09 - TN:3) - Traffic     - MAC_Traffic
 19:32:42 PM   TCH/F                 [VOICE] (FN:10 - TN:3) - Traffic     - MAC_Traffic
 19:32:42 PM   TCH/F                 [VOICE] (FN:11 - TN:3) - Traffic     - MAC_Traffic
 19:32:42 PM   TCH/F                 [VOICE] (FN:12 - TN:3) - Traffic     - MAC_Traffic
 19:32:42 PM   TCH/F                 [VOICE] (FN:13 - TN:3) - Traffic     - MAC_Traffic
 19:32:42 PM   TCH/F                 [VOICE] (FN:14 - TN:3) - Traffic     - MAC_Traffic
 19:32:42 PM   TCH/F                 [VOICE] (FN:15 - TN:3) - Traffic     - MAC_Traffic
 19:32:42 PM   TCH/F                 [VOICE] (FN:16 - TN:3) - Traffic     - MAC_Traffic
 19:32:42 PM   TCH/F                 [VOICE] (FN:17 - TN:3) - Traffic     - MAC_Traffic
 19:32:42 PM   TCH/F                 [VOICE] (FN:01 - TN:3) - Traffic     - MAC_Traffic
 19:32:42 PM   TCH/F                 [VOICE] (FN:02 - TN:3) - Traffic     - MAC_Traffic
 19:32:42 PM   TCH/F                 [VOICE] (FN:03 - TN:3) - Traffic     - MAC_Traffic
 19:32:43 PM   TCH/F                 [VOICE] (FN:04 - TN:3) - Traffic     - MAC_Traffic
 19:32:43 PM   TCH/F                 [VOICE] (FN:05 - TN:3) - Traffic     - MAC_Traffic
 19:32:43 PM   STCH   [NULL] + STCH   [BNCH] (FN:06 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:43 PM   STCH   [MLE2] + STCH   [Fend] (FN:07 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:43 PM   STCH   [NULL] + STCH   [BNCH] (FN:08 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:43 PM   STCH   [MLE2] + STCH   [Fend] (FN:09 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:43 PM   STCH   [NULL] + STCH   [BNCH] (FN:10 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:43 PM   STCH   [MLE2] + STCH   [Fend] (FN:11 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:43 PM   STCH   [NULL] + STCH   [BNCH] (FN:12 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:43 PM   STCH   [MLE2] + STCH   [Fend] (FN:13 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:43 PM   STCH   [NULL] + STCH   [BNCH] (FN:14 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:43 PM   STCH   [MLE2] + STCH   [Fend] (FN:15 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:43 PM   STCH   [NULL] + STCH   [BNCH] (FN:16 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:43 PM   STCH   [MLE2] + STCH   [Fend] (FN:17 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:43 PM   TCH/F                 [VOICE] (FN:01 - TN:3) - Traffic     - MAC_Traffic
 19:32:43 PM   STCH   [MLE2] + STCH   [Fend] (FN:02 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:44 PM   TCH/F                 [VOICE] (FN:03 - TN:3) - Traffic     - MAC_Traffic
 19:32:44 PM   TCH/F                 [VOICE] (FN:04 - TN:3) - Traffic     - MAC_Traffic
 19:32:44 PM   STCH   [NULL] + STCH   [BNCH] (FN:05 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:44 PM   STCH   [MLE2] + STCH   [Fend] (FN:06 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:44 PM   STCH   [NULL] + STCH   [BNCH] (FN:07 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:44 PM   STCH   [MLE2] + STCH   [Fend] (FN:08 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:44 PM   STCH   [NULL] + STCH   [BNCH] (FN:09 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:44 PM   STCH   [MLE2] + STCH   [Fend] (FN:10 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:44 PM   STCH   [NULL] + STCH   [BNCH] (FN:11 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:44 PM   STCH   [MLE2] + STCH   [Fend] (FN:12 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:44 PM   STCH   [NULL] + STCH   [BNCH] (FN:13 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:44 PM   STCH   [MLE2] + STCH   [Fend] (FN:14 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:44 PM   STCH   [NULL] + STCH   [BNCH] (FN:15 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:44 PM   STCH   [MLE2] + STCH   [Fend] (FN:16 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:44 PM   STCH   [NULL] + STCH   [BNCH] (FN:17 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:44 PM   STCH   [NULL] + STCH   [BNCH] (FN:01 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:44 PM   TCH/F                 [VOICE] (FN:02 - TN:3) - Traffic     - MAC_Traffic
 19:32:45 PM   STCH   [MLE2] + STCH   [Fend] (FN:03 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:45 PM   STCH   [NULL] + STCH   [BNCH] (FN:04 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:45 PM   STCH   [MLE2] + STCH   [Fend] (FN:05 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:45 PM   STCH   [NULL] + STCH   [BNCH] (FN:06 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:45 PM   STCH   [MLE2] + STCH   [Fend] (FN:07 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:45 PM   TCH/F                 [VOICE] (FN:08 - TN:3) - Traffic     - MAC_Traffic
 19:32:45 PM   STCH   [NULL] + STCH   [BNCH] (FN:09 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:45 PM   STCH   [MLE2] + STCH   [Fend] (FN:10 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:45 PM   STCH   [NULL] + STCH   [BNCH] (FN:11 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:45 PM   STCH   [MLE2] + STCH   [Fend] (FN:12 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:45 PM   STCH   [NULL] + STCH   [BNCH] (FN:13 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:45 PM   STCH   [MLE2] + STCH   [Fend] (FN:14 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:45 PM   STCH   [NULL] + STCH   [BNCH] (FN:15 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:45 PM   STCH   [MLE2] + STCH   [Fend] (FN:16 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:45 PM   STCH   [NULL] + STCH   [BNCH] (FN:17 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:45 PM   STCH   [NULL] + STCH   [BNCH] (FN:01 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:46 PM   STCH   [MLE2] + STCH   [Fend] (FN:02 - TN:3) - Traffic     - MAC_resource_[Start],MAC_frag_end
 19:32:46 PM   STCH   [NULL] + STCH   [BNCH] (FN:03 - TN:3) - Traffic     - MAC_resource_[NULL] ,Broadcast
 19:32:46 PM   SCH/HD [alAk] + SCH/HD [Fend] (FN:04 - TN:3) - Traffic     - MAC_resource        ,MAC_frag_end
 19:32:46 PM   STCH   [NULL] + TCH   [VOICE] (FN:05 - TN:3) - Traffic     - MAC_resource        ,MAC_Traffic
 

hamradionl

Member
Joined
Mar 23, 2014
Messages
730
Is this a "open" channel?
Motorola?
Old or new Hytera hardware?
Hopping channel ?
Voice frame is send (rolling) over different or more MAC or frames?
 

thewraith2008

Member
Joined
Nov 22, 2016
Messages
1,840
Is this a "open" channel? | What does this mean?
Motorola? | Yes
Old or new Hytera hardware? | No
Hopping channel ? | What does this mean?
Voice frame is send (rolling) over different or more MAC or frames?
Voice frames are sent on from the bursts to MAC_Traffic or TMD-SAP to the decoder.
When frames are stolen then the burst data can be sent on to the MAC_Resource (TMA-SAP) or MAC_Broadcast (TMB-SAP) for different purposes.
The output log as shown in 2nd post is what is seen on the assigned timeslot related to the Traffic Physical (TP) channel only during a call. CP/UP channels not logged/shown.
Voice is mainly on full slot and half slot are used when stealing exists or last voice frame is sent.
 

hamradionl

Member
Joined
Mar 23, 2014
Messages
730
Sorry, not sure what do you mean with "stealing or stolen".
Open channel = not using Encr.
Is your channel using Simplex or Duplex ?

In your example notice time interval is 30mS , 60mS, 120mS and 240mS
possible during the transmission some frames is temporarily moved to other slot or moved to other BS?
Or temporarily moved for 30mS into a memory hold / delay function and to be used some 240mS later?
Seeing the RAW data will help out?
 

thewraith2008

Member
Joined
Nov 22, 2016
Messages
1,840
Sorry, not sure what do you mean with "stealing or stolen".
Data in TETRA is sent as a burst with in blocks (bb,sb and bkn1 + bkn2) [Others exist but are not used here]
There are 3 burst types. Normal(x2) and Sync.
Normal 1 (NDB1) is a full slot. bkn1 + bkn2 is combined for higher protocols. (either voice or signalling)
Normal 2 (NDB2) is a half slot. bkn1, bkn2 are for 2 separate type of data for higher protocols. (either voice and signalling)
Stealing occurs on Normal 2 (NDB2) bursts for Traffic Physical (TP) channel only.
Voice is in TCH (bkn1 + bkn2) for a full slot (2 x 30mS audio frames)
For half slot (NDB2) it can be:
Signalling + Voice (1 x 30mS audio frame) [STCH + TCH]
Signalling + Signalling [STCH + STCH]
When STCH is seen, the voice data that occuppied that position is lost (gone forever) and a space it left.
The codec is supposed to mask this but it can't do magic. Gone is gone.

Open channel = not using Encr.
Is your channel using Simplex or Duplex ?
OK, got it.
All group calls are simplex

In your example notice time interval is 30mS , 60mS, 120mS and 240mS
possible during the transmission some frames is temporarily moved to other slot or moved to other BS?
Or temporarily moved for 30mS into a memory hold / delay function and to be used some 240mS later?
Seeing the RAW data will help out?

No. We are already on an assign timeslot. If call moved then the timeslot would become unallocated (and a PDU would be issued), and it's not doing that.
Voice data is pushed into a audiobuffer as it is received then played. Holding and delaying won't be a good idea for radio as it's already introducing processing delay, adding to it wouldn't help.
 

hamradionl

Member
Joined
Mar 23, 2014
Messages
730
Morning,
DMO that be great new function!
I send several PM did you receive?
 
Last edited:

hamradionl

Member
Joined
Mar 23, 2014
Messages
730
No. We are already on an assign timeslot. If call moved then the timeslot would become unallocated (and a PDU would be issued), and it's not doing that.
Voice data is pushed into a audiobuffer as it is received then played. Holding and delaying won't be a good idea for radio as it's already introducing processing delay, adding to it wouldn't help.

Notice its not one time 'stealing" but it keep coming back, look like there is some sort control behind this "stealing" process?
 

thewraith2008

Member
Joined
Nov 22, 2016
Messages
1,840
Morning,
DMO that be great new function!
I send several PM did you receive?

At this stage a very rough implementation. I only have one sample and that is only one sided.
Not sure if it would work if 2 parties were talking. IQ samples any one?
 

thewraith2008

Member
Joined
Nov 22, 2016
Messages
1,840
I got a bit more information out of the DMO PDUs: (removed duplicates for clarity)
Code:
 00:22:05 AM   DM-SETUP Source_SSI:819 Destination_SSI:141448
 00:22:05 AM   DM-OCCUPIED Source_SSI:819 Destination_SSI:141448
 00:22:14 AM   DM-RESERVED Source_SSI:819 Destination_SSI:141448
 

DarkAngelT

Member
Joined
Sep 27, 2018
Messages
131
for me today it has appeared in the log a few times:

Caller ID: 0 Disconnect_cause: SS_specific_disconnection D_Release
 

thewraith2008

Member
Joined
Nov 22, 2016
Messages
1,840
for me today it has appeared in the log a few times:

Caller ID: 0 Disconnect_cause: SS_specific_disconnection D_Release

The EN300-392-02 document said:
dummy call identity: call identity used by MS or LS before the SwMI has allocated a valid call identity
NOTE: In TETRA the value of the dummy call identity is zero.

As an example: (couple exist see EN300-392-02 for more detail)
The EN300-392-02 document said:
Individual call set-up phase - called user application rejects the call
NOTE: If the SwMI sends the D-RELEASE PDU as the first response to the calling MS, then it should contain
the dummy call reference.
 

thewraith2008

Member
Joined
Nov 22, 2016
Messages
1,840
OK here is DMO transmission via a repeater (DM-REP) playing with the plug-in. Another test transmission provide by oz1jua awhile back.

This is DM-MS via repeater (DM-REP).

Here is a video on YouTube I put up of it decoding


The standard defines two different types of DM channel:
  • Normal mode, only one DM channel may exist on a DM RF carrier. This DM channel is designated as channel A. (The one shown in previous post video)
  • Frequency efficient mode, two DM channels (designated channel A and channel B) may exist on a DM RF carrier.
The standard defines three different types of repeater:
  • Type 1A: single call single frequency repeater. (The one shown here in video)
  • Type 1B: single call two frequency repeater.
  • Type 2: two call two frequency repeater.
 

TSSDR

Newbie
Joined
Jan 12, 2019
Messages
4
Changelog in last release:
PHY level:
optimized pi/4 demodulator
added AFC
Mac level:
More that one mac pdu in mac block
stolen half slot
defragmentation
fill bits
Usignals PDU
Mle level:
increase parsed parameters

If needed i can show source code.
My pi/4 demodulator work fine with TMO and continous burst. For DMO need change demodulator synchronization.
 
Last edited:

thewraith2008

Member
Joined
Nov 22, 2016
Messages
1,840
8th Public Release - TETRA Trunk Tracker v1.0.8 - PART 1 of 2 post. Link in 2nd post

TETRA Trunk Tracker appears to be relatively stable and is no longer classified as alpha experimental.
I'm sure it's by no means perfect. This means is may contain errors that may cause issues with the other programs it
works with. i.e. crashing them or itself. Although I'm not seeing this.


TETRA Demodulator plug-in has been updated by me. "Tweaked Edition (Unofficial) v1.0.8.0"
It's is required for some SDS features to work with TETRA Trunk Tracker v1.0.8. Please read text files in zip for plug-in.

The "libtetradec.dll" has also been updated and is required to be used with this release

This plug-in version changes/adds and fixes some items:
Code:
v1.0.8.0

MD5 hash:
SDRSharp.Tetra.dll - 7e72308158af62033ca49489d59e9127
libtetradec.dll    - cf4f05be0ef38e1c4915716f3e82a206

 ***************************************************************************************************
*** This version of the plug-in also requires the updated audio decoder library (libtetradec.dll) ***
***  Failure to only use the supplied DLLs in this will result in a crash.                        ***
 ***************************************************************************************************


ADDED: Downlink signal quality indicator. (Estimated %)
       - As per ETSI EN 300 392-2 V3.8.1 - 10.3.2 (pg 190)
         "The quality of the radio downlink shall be estimated from the success rate of decoding the AACH"
       - Uses decode success/fail rate of AACH over 72 bursts. (1 multiframe or 18 frames)
       - Updates approx. every 1 second.
       - This is located under the red "Received" indicator/label on the main panel for the plug-in in SDR#.
       - The [x] value after "%" is the amount of decoded control signalling data. Lower is best. Higher could mean
         delays in call activity.

FIXED[with caveats]: As noted in the v1.0.7.0 changelog.
       "On occasions audio seems to get clipped or silence is inserted between frames where it shouldn't be."
       There was a couple of things that the plug-in was not doing right here.
       - Audio can arrive in either full slot (2 audio frames - 60mS) or in a half slot (1 audio frame - 30mS) bursts.
         The half slot audio was not being processed and therefore was lost.
         It left a gap in the audio buffer which sounded like dropouts and was made a little worse because of the delay
          in switching SDR# mute on and off.

       - In the 2 x half slot bursts, audio can be stolen (STCH) either 1 half slot or both halves. When this occurs, 1 or 2
          TCH (audio) frames are lost. A substitute half slot (1 audio frame) should be generated by codec to fill the missing slots.
         This was not happening.
         STCH - TCH bursts should have 1 audio frame generated (using previous good TCH) and use the TCH (1 audio frame) that was supplied in the burst.
         STCH - STCH bursts should have 2 audio frames generated.
         This required a change to the codec "libtetradec.dll". For the most part, code existed it just was not accessible to the plug-in.

       - Another problem was the way audio samples were pushed into the output audio buffer.
         When a gap appeared in the audio data (as described above or a signal dropout), the buffer was filled with silence.
         Problem is, this buffer length was larger than length of the audio that was to fill it on some occasions.

Caveats:
   It should be noted that dropouts (or lost segments of audio) can still occur because of different reasons.
   - Transmitting MS has poor connection to BS.
   - You are dropping bursts due to poor reception or poor decoding (for what ever reason).
   - Many STCH + STCH seen. The standard recommends 1 in every multiframe. I have seen many consecutive bursts with them
     which just kills the audio.
       
FIXED: Some control signalling was not being processed.
       Some data can be fragmented (split over consecutive bursts). This was not processed by plug-in.       
       This fix only allows processing of 1st fragment. I have not implemented the processing (reconstruction) of following
        fragments at this stage. Not all fragmented bursts are required for call control (CMCE) and when it is, the required
        information appears to be in the 1st fragment anyway.
        Segmentation (in advanced link) also is not dealt with at this time. I don't see these anyway and I don't think there
        are used for call control.

ADDED: Filled in some comment fields in Network Info > Current cell tab.
       This should help define/clarify some of those fields.

CHANGED: The option 'Listen only clear speech' is disabled. (This is for when you have mixed audio. e.g. clear and encrypted)
         This option does not have any code connected to it and it did nothing.
         If you manually select a timeslot, you will hear audio (encrypted or not). (Partly by design)
         If you select 'Auto', you won't hear encrypted audio because the code for 'Auto' blocks it.

ADDED:  MCCH/SCCH identification on SDR# side panel - Timeslot 1
        "MCCH" is displayed on timeslot 1 under "GSSI" column only when on the main carrier (CC)
        "SCCH = x" is displayed under "ISSI" column when on the main carrier (CC) and only if the value of SCCH is > 0
        MCCH (or SCCH when used), occupies the timeslot(s) solely for signalling and no speech shall be
        present on that timeslot at anytime.
        If SCCH is used, the value shall indicate how many SCCHs are used with MCCH and start from timeslot 2

        0 = TS1(MCCH)
        1 = TS1(MCCH), TS2(SCCH)
        2 = TS1(MCCH), TS2(SCCH), TS3(SCCH)
        3 = TS1(MCCH), TS2(SCCH), TS3(SCCH), TS3(SCCH). This would mean no speech exist on the main carrier (CC)
        
        SCCH is a secondary control channel that is used to share signalling to large population of users.
        The plug-in decodes all control signalling regardless. Unlike a MS. I have not seen a SCCH inuse.
        If someone does, I would like a IQ sample of it. I could change the plug-in to show SCCH on used slots.

ADDED: Beep for bad audio frames. This was more for testing.

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




*** Plug-in experimental/testing:

ADDED: 'Burst type' tab in 'Network Info' window. Only shows detail about traffic channels
        Currently only showing [TCH/F],[STCH,TCH], [STCH,STCH] and [SCH/HD,SCH/HD - TP only] - I used this for testing. It may not last.

ADDED: 'Burst errors' tab in 'Network Info' window. Shows errors that can occur with bursts and the internal blocks.
        I used this for testing. It may not last. All thought it could be useful in some way.
        3 burst types exist. Sync, Normal(x2) and are defined as TP(Traffic), CP(Control(x3), UP (Unallocated) types.
        Errors:
         - AACH CRC errors will prevent decoding of rest of burst.
         - BKN1,BKN2 CRC errors will prevent decoding of CP/UP data. TP data not test for errors here.
         - Synchronized error is a MN/FN/TN timebase counters issue. Internal counter does not match what BSCH reports as MN/FN/TN.
           Most likely because of a burst type error.
        NOTE: When used with TTT in Dual mode, the VC 'Burst errors' tab will generate a lot of errors when parked (on unused frequency)
              this is expected because of false positives detected in the plug-in.

ADDED: 'MS Registration' tab in 'Network Info' window. Shows MS registrations.
        Only works when on CC (Main carrier)
        This data may not be correct at all.

ADDED: Basic DMO decoding (DM-MS to DM-MS and DM-REP)
       It can be enabled in 'Config > Settings'. This option state is not saved by design at the moment.
       Use 'Stronger burst detection' option in 'Config > Settings' for better decodes.
       May sure you select timeslot 1 for 'A' channel. (I don't know if 2 calls works. Select timeslot 2 for 'B' channel, I think?)
       It currently only decodes DMAC/DPRES PDUs (sch/s and partly sch/h)
       No message types (DM-SETUP etc...) are decoded yet.
       Source SSI, Destination SSI and (if used) repeater address are shown in SDR# side panel in TS1: GSSI - ISSI and TS3: GSSI respectively.       
       Some information is output in the 'burst type tab' in the 'Network Info' window for now.
       This may not work in all cases. IQ samples would be helpful.
       There is no functionality with TTT as this stage.
       This code maybe VERY unstable.


Changes in libtetradec.dll
==========================
ADDED: Enabled the frame stealing code in the audio decoder to handle half slot TCH frames.
ADDED: BFI beep on bad frames. [was used for testing]
See 'changelog.txt' more details.

If SDR# is crashing when 'Demodulator' is enabled, it's because you have not set-up the plug-in correctly.
You MUST do this 1st. This is NOT TETRA Trunk Trackers fault.

You generally need to get these installed:
"Microsoft .NET Framework 4.6.2 (Offline Installer)"
"Microsoft .NET Framework 4.7.2 (Offline Installer)"
"Microsoft Visual C++ 2015 Redistributable" and install both 32/64 bit versions (if you use 64 bit OS)


Continued in next post...
 

thewraith2008

Member
Joined
Nov 22, 2016
Messages
1,840
8th Public Release - TETRA Trunk Tracker v1.0.8 - PART 2 of 2 post.



This TETRA Trunk Tracker version changes/adds and fixes some items:
Code:
v1.0.8.0

FIXED: There was no call release sound (when used) when D_Release PDU was not seen (when call timeout occurred)

CHANGED: TTT call state/priority sounds
         The call setup sound will not play if priority is triggered and if the priority sound exists.
         If the priority sound does not exist and priority is triggered then the call setup sound will play.
         Because playback of both sounds occur almost at same time, it can make it a bit hard to hear each sound.

ADDED: Option to disable the 'Network Info' window minimizing.
ADDED: Save/Restore 'Network Info' window position.

ADDED: G/SSI Editor - Right clicking in GSSI lisbox and pressing either "CTRL" or "Shift" will set or
       clear all GSSIs lockout states in the list respectively.
       A limitation of the listbox with checkbox means multi-select entries is not possible.

ADDED: Cancel the record 'Hold Delay' by clicking the visual counter for the record 'Hold Delay' when it is active.
       The counter is in the same place as the call timeout counter which is next to the call indicator and is redish when active.

FIXED: Position SDR#/Network Info window value, if not set would cause crash of TTT.
ADDED: If desktop size has changed since last run and window positions are outside desktop, then values will be
       reset to a default values inside desktop.

FIXED: TTT would hang on shutdown when SDR# was started with no dongles connected.

ADDED: Timeslot information to call event log entry. (as TS:#)

FIXED: Some D_TX_Granted PDUs where been missed because of a slight difference in element structure.

FIXED: Some D_TX_Ceased PDUs where been missed because of De-duplication of PDUs.
       These PDUs are fairly generic and where been removed in some cases.

ADDED: Defined rules for PDU 'D_STATUS'. NOTE: The Pre-coded values are mostly user defined (i.e. Unknown) except 0 which is 'Emergency'

FIXED: G/SSI Editor. The label "Seen SSI for GSSI (####)" was wrapping around on 4+ digit values.

CHANGED: Changes to the TETRA demodulator plug-in required a change to the Network Info PDU panel detection.

CHANGED: Mode (Dual/Single) change has always required a TTT restart.
         This change now forces a call halt state and pop-up message to restart.
         This is to prevent unknown errors because of the changed conditions.

ADDED/FIX: This is to deal with the missing "D_Release" PDUs
           I do not know why this PDU is missing:
           - I don't think dropped burst cause this (I don't see dropped burst when PDU is expected)
           - A bug with some MS radios. (I think the BS would still send if MS dropped out)
           - A bug with BS. Maybe a bug when radios drop out?
           - A guess is the call moves off the current LA. I think PDUs exits which would indicate this. But I don't see them.

          Plug-in (v1.0.8) now outputs when the timeslot becomes unallocated, This is to help deal with when "D_Release" is not seen.
          Normally "D_Release" will be seen before the unallocated timeslot occurs so the call with end as expected.
          TTT looks for this unallocated timeslot output during a call and if it see's it, will end the call rather than go into the
           usual timeout state. (which it will still do if both "D_Release" and unallocated timeslot detection are not seen.)
          This fix may prevent missing the following calls after a missing "D_Release" (GSSI related or not).

          I have seen when "D_Release" is not seen (and when unallocated timeslot detection is seen), calls seem to abruptly end.
          No further transmissions are usually seen and a call release does not occur. This for some reason results in the call just aborting.

          To disable this feature use '-du' on the commandline (shortcut). See v0.99.8 in changelog for creating shortcut.

FIXED: G/SSI Editor: The G/SSI label fields where only allowing ACSII characters up to 0x7F, this was preventing country specific characters.

CHANGED: The TTT call state/priority sounds presence is now scanned for about every second. No TTT restart is required when adding and removing the WAVs.

FIXED: Compact mode was not saving last state

CHANGED: Added MNC,LA labels to exiting MCC label in menu bar.
         Also added labels to entry in event log panel (when carrier changed on CC) if they exist.
         Will show # if no label exists.
         Will only show # when in compact mode. MNC/LA label will still be shown as a tooltip when mouse hover over "MNC:x  LA:x"
          in either mode.
         This menu bar is limited to a combined MCC/MNC/LA size of 65 characters. Anything over will be truncated.
         If you use an altered font sizes for windows and the labels overflow the menu bar area, Window corruption may result for TTT.
See 'changelog.txt' for more details.

Has been tested on Windows 7 - Basic (64 bit)
Has been tested on Windows 7 - Professional SP1 (32 bit), English
Has been tested on Windows 10 - Professional (64 bit)

I have created it to suit my needs. And it currently works for me with the TETRA network I monitor.

I make no claim that it will work for other networks.

Please read the provided files for set-up and usage:

  • TTT_set-up_manual.pdf
  • TTT_Features_and_Usage.pdf

I have tried to be as thorough as possible with the documentation to explain usage and features.
I believe any questions can be answered by reading these files.
These files most likely are not complete and contain errors and are not laid out as good as they could be.

It only works with the provided TETRA plug-in supplied in zip. (2019-January-10).
This version uses a custom compiled version of 'Net Remote' supplied in zip


It is only meant to be a temporary solution until something better comes along.

Hopefully all goes well for you setting it up.

[size=+2]Download link[/size]

MD5 HASH ba116affce865dee426efa760f65c813



Hopefully not to many bugs, after all these changes.:unsure:
 
Top