I tried this but I am unable to unmute, as soon as I click the speaker icon it just mutes itself again.
SDR# TETRA Demodulator Trunk Tracking Demonstration
- Thread starter thewraith2008
- Start date
-
- Tags
- digital tetra trunktracking
I tried this but I am unable to unmute, as soon as I click the speaker icon it just mutes itself again.
Disregard this.. I had the TTT Mode Enable Checked. That's it working now. Thank you.
I've been playing around with TTT plugin the past few days.... (I have been using just the modified version of the SDR# plugin for a while (because the russian one kept crashing randomly).
But I've got two SDR's running in dual mode, and while it works fine, I find that often times when there is more than one group talking, it will not switch to the other group when the first one stops transmitting. And it's not the call timeout thing, because I set the timeout to under 5 seconds, it just does not switch to it, and the log window says Call timeout ocurred - did not see D-Release.
Using the SDR# plugin on another machine at the same time on its own without TTT, it switches to the other groups immediately.
I'm not sure if I'm explaining it correctly.
Maybe this varies between systems, I'm using this in Toronto monitoring the Toronto Transit.
But I've got two SDR's running in dual mode, and while it works fine, I find that often times when there is more than one group talking, it will not switch to the other group when the first one stops transmitting. And it's not the call timeout thing, because I set the timeout to under 5 seconds, it just does not switch to it, and the log window says Call timeout ocurred - did not see D-Release.
Using the SDR# plugin on another machine at the same time on its own without TTT, it switches to the other groups immediately.
I'm not sure if I'm explaining it correctly.
Maybe this varies between systems, I'm using this in Toronto monitoring the Toronto Transit.
To be honest, If I didn't have the standalone client running on a separate machine monitoring just the basic groups I use for my stream, I wouldn't have realized it.
It did the same thing in single mode, as well as dual mode. I'm not even sure what the benefit of dual mode is on the TTC, it acted exactly the same, both SDR# windows are tuned into the same frequency.
ATCTech
Active Member
- Joined
- Aug 13, 2002
- Messages
- 1,857
Agreed, but I do like the ability to hold on a group and set priority levels. As for automatic time slot changing or frequency hopping I'm lost as to whether it's not working or if it's simply not supposed to work on the TTC system at least.
Yeah, the priority level can be set in the standalone tetra plugin as well. The timeslot thing is a bit of a deal breaker, as you can miss a LOT of traffic. i've seen it hang and not switch over for over a minute or longer if they keep talking on the timeslot that it didn't change to, basically till all the timeslots clear.
thewraith2008
Member
- Joined
- Nov 22, 2016
- Messages
- 1,845
TTT is design to follow a call in it's entirety (call setup to call release) across the network. (To any carrier belonging to current MNC)
The old plug-in does not do this, which is why this fork of the plug-in and TTT exists.
The TETRA Demodulator plug-in and TTT will only follow on going calls only if there are call setups still been sent.
Private calls only send a call setup once, so if you don't act on it the first time, it will never switch to it later.
Just because the 'calls list' shows calls, it does not mean that the call is still on going. (no call setups).
The control channel does not indicate when a call is released, that's why a timer is used to clear call(s) from list.
An exception would be if a call was on main carrier, then it should clear off the list as soon as the release is seen.
This means that if a call that lasted for only 5 seconds, it would still be visible in the list for 30 seconds. (if not on main carrier)
TTT does not switch to calls that are shown in list because there is no way to know for sure if the call is still in progress (if no call setups are been sent), most of the time the calls have completed and you just end up sitting around waiting for timers to expire before it returns and waits for next call to occur.
If you see "Call timeout occurred - did not see D-Release" it's because the 'Call Timeout' value is too low.
The BS usually allows X time (no talking) between 'overs' before it releases a call. The 'Call Timeout' value should not be less than this X time.
45 seconds is a good around value and it works better when private calls are seen, these seem to allow for larger pauses between 'overs' than group calls do.
TTT dual works best if your network uses multiple carriers. This allows priorities and private duplex calls to work correctly.
If your network (MNC) only uses the main carrier and you don't need or see private duplex calls, then TTT single mode would be OK to use.
Missing calls on a trunk network is a fact of life, you can never hear all of them at once so worrying about it pointless. The best you can do is use the priorities to follow the groups you are more interested in.
Latest version (v1.7.1.0) can be found here: Release post
The old plug-in does not do this, which is why this fork of the plug-in and TTT exists.
The TETRA Demodulator plug-in and TTT will only follow on going calls only if there are call setups still been sent.
Private calls only send a call setup once, so if you don't act on it the first time, it will never switch to it later.
Just because the 'calls list' shows calls, it does not mean that the call is still on going. (no call setups).
The control channel does not indicate when a call is released, that's why a timer is used to clear call(s) from list.
An exception would be if a call was on main carrier, then it should clear off the list as soon as the release is seen.
This means that if a call that lasted for only 5 seconds, it would still be visible in the list for 30 seconds. (if not on main carrier)
TTT does not switch to calls that are shown in list because there is no way to know for sure if the call is still in progress (if no call setups are been sent), most of the time the calls have completed and you just end up sitting around waiting for timers to expire before it returns and waits for next call to occur.
If you see "Call timeout occurred - did not see D-Release" it's because the 'Call Timeout' value is too low.
The BS usually allows X time (no talking) between 'overs' before it releases a call. The 'Call Timeout' value should not be less than this X time.
45 seconds is a good around value and it works better when private calls are seen, these seem to allow for larger pauses between 'overs' than group calls do.
TTT dual works best if your network uses multiple carriers. This allows priorities and private duplex calls to work correctly.
If your network (MNC) only uses the main carrier and you don't need or see private duplex calls, then TTT single mode would be OK to use.
Missing calls on a trunk network is a fact of life, you can never hear all of them at once so worrying about it pointless. The best you can do is use the priorities to follow the groups you are more interested in.
Latest version (v1.7.1.0) can be found here: Release post
The thing, is I'm also running your version of the Tetra Demodulator on a separate system, standalone without TTT plugin, and it switches to the other active timeslots instantly, without any timeout issues, just like the original russian plugin did. I have it running side by side, that's how I noticed the difference.
BTW, is there any way for the standalone plugin to display the group names next to the timeslots? (like the original plugin did). The group names can be entered in the Net Info/Groups. I'm using your plugin standalone because it's stable (doesnt random crash SDR#), but this crucial feature is missing to use it more easily to simply identify the groups as they display.
TTT seems not to work too great on this particular system at least.
thewraith2008
Member
- Joined
- Nov 22, 2016
- Messages
- 1,845
The old plug-in worked in a promiscuous mode which really does nothing to help properly identify call activity.
Timeslot activity doesn't not necessarily mean a valid call setup was seen for it (which TTT ignores these types), this activity could be audio that is 'patched' in from another LA. You won't hear the local LA MS audio because it's sent to the other LA.
I would probably need an IQ sample (from IF recorder) showing what you are seeing so I could see for myself what you are seeing.
From what I gather, all your activity occurs on one carrier only (the main carrier). This would work well for IQ sample recording.
This plug-in was based off the original plug-in and that never displayed the group names in the call list.
While the this fork of the plug-in can be used in standalone form, it's development is centered to work with TTT.
Latest version (v1.7.1.0) can be found here: Release post
Timeslot activity doesn't not necessarily mean a valid call setup was seen for it (which TTT ignores these types), this activity could be audio that is 'patched' in from another LA. You won't hear the local LA MS audio because it's sent to the other LA.
I would probably need an IQ sample (from IF recorder) showing what you are seeing so I could see for myself what you are seeing.
From what I gather, all your activity occurs on one carrier only (the main carrier). This would work well for IQ sample recording.
This plug-in was based off the original plug-in and that never displayed the group names in the call list.
While the this fork of the plug-in can be used in standalone form, it's development is centered to work with TTT.
Latest version (v1.7.1.0) can be found here: Release post
Well, I dont know what to tell ya, but @ATCTech seems to have the same issue, so it could be something peculiar to the system we are monitoring.
The Demodulator plugin works well enough on its own for me, I can make a priority of the few talkgroups I like to monitor and ignore the rest, and it doesnt seem to suffer from the issue of not switching to other active time slots.
I appreciate that on its own, because the Russian plugin crashed all the time, and I had to make some bizarre automation sequence to restart it based on windows error event ID.
The Demodulator plugin works well enough on its own for me, I can make a priority of the few talkgroups I like to monitor and ignore the rest, and it doesnt seem to suffer from the issue of not switching to other active time slots.
I appreciate that on its own, because the Russian plugin crashed all the time, and I had to make some bizarre automation sequence to restart it based on windows error event ID.
thewraith2008
Member
- Joined
- Nov 22, 2016
- Messages
- 1,845
As I said, I would need an IQ sample so I could see what you see. I can't do much otherwise.
Latest version (v1.7.1.0) can be found here: Release post
Latest version (v1.7.1.0) can be found here: Release post
I would have to read up on how to do that...
thewraith2008
Member
- Joined
- Nov 22, 2016
- Messages
- 1,845
The setup and usage of the IF Recoder plug-in can be seen here.
You don't have to follow instruction in that post to the letter but it should help.
Latest version (v1.7.1.0) can be found here: Release post
You don't have to follow instruction in that post to the letter but it should help.
Latest version (v1.7.1.0) can be found here: Release post
thewraith2008
Member
- Joined
- Nov 22, 2016
- Messages
- 1,845
If all your traffic occurs on the main carrier then this will make recording easier.
In this case you can record with TTT (which the instructions say not to use)
Just record until you see the problem you see plus a little extra.
The more times the observed problem is recorded the better.
I have made a program that can trim an IQ file to make it smaller and I can make it available if it is needed.
Latest version (v1.7.1.0) can be found here: Release post
In this case you can record with TTT (which the instructions say not to use)
Just record until you see the problem you see plus a little extra.
The more times the observed problem is recorded the better.
I have made a program that can trim an IQ file to make it smaller and I can make it available if it is needed.
Latest version (v1.7.1.0) can be found here: Release post
Hi,
I use lastest TTT version with SDR#.
All seems good with Tetra plugin and TTT (single mode), except this error during initialization...
==============
29/10/2020 09:06:39
Unknown ERROR[RAW]:
Last DATA: Result:Error,Type:Syntax error,Message:{\command\: \set\, \method\: \netinfowindowopen\, \value\: vrai}
==============
Syntax error in \method\: \netinfowindowopen\ invalid \value\: vrai}
==============
Call active: Faux
tmrSaveTimed: Vrai
==============
I have to open manually Net InfoWindow in SDR#.
My OS is Windows 10 Pro (latest version 2004 - French). I can see in application list .NET framework 4.5.2 and 4.6 installed.
When I launch .NET 4.7 or 4.7.2 setup Windows 10 refuses. A message indicates that .NET framework is up to date, and 4.7 or + is already installed.
Have you any advice ?
I use lastest TTT version with SDR#.
All seems good with Tetra plugin and TTT (single mode), except this error during initialization...
==============
29/10/2020 09:06:39
Unknown ERROR[RAW]:
Last DATA: Result:Error,Type:Syntax error,Message:{\command\: \set\, \method\: \netinfowindowopen\, \value\: vrai}
==============
Syntax error in \method\: \netinfowindowopen\ invalid \value\: vrai}
==============
Call active: Faux
tmrSaveTimed: Vrai
==============
I have to open manually Net InfoWindow in SDR#.
My OS is Windows 10 Pro (latest version 2004 - French). I can see in application list .NET framework 4.5.2 and 4.6 installed.
When I launch .NET 4.7 or 4.7.2 setup Windows 10 refuses. A message indicates that .NET framework is up to date, and 4.7 or + is already installed.
Have you any advice ?
Last edited:
thewraith2008
Member
- Joined
- Nov 22, 2016
- Messages
- 1,845
Not sure if this is a language problem.
Are there any other French users out there, do you see this problem?
Latest version (v1.7.1.0) can be found here: Release post
french user and didn't saw this problem with latest TTT and SDR#1760 and no problems.
thewraith2008
Member
- Joined
- Nov 22, 2016
- Messages
- 1,845
OK thanks.
@jlmarc33
I switched display language here on Windows 10 to French and run SDR# (1700 and 1732) + plug-in and TTT in single mode and could not repeat problem. I'm not sure what problem you have and how to help.
Latest version (v1.7.1.0) can be found here: Release post
Similar threads
