SDR# TETRA Demodulator Trunk Tracking Demonstration

[digiman1]

The Thresh (dB) I leave at -62.
It compresses the audio, decreasing the difference between the higher and lower souns. This is very useful!
Because there are users of the radio who speak lower and others who speak screaming and it is very annoying to have to be constantly increasing and lowering the volume of sound!

With my -62 I do not have this problem! I get all voice volumes at the same sound volume level and all with quality! It greatly enhances the reception!

the Slope (dB) I leave at 0 and Decay (ms) I leave at 500.

Great, I have now set mines to be the same.

I have been having a lot of audio issues lately, almost like the audio is stuttering or being slightly echo'd, I was thinking it would have been this causing it but nothing has changed.

 

[thewraith2008]

thewraith2008, I would like to know what the function is for (BFI (Bad audio frame) and what changes when the Increase PDU element verbosity function is enabled

Data as it comes out of the lower MAC is passed to the audio decoder with checks to see if the full slot = 2 or half slot = 1 audio frame/s is OK.
If it failed CRC, then audio data is lost (and decoder does some concealing of error).
If option is enable, a beep is heard.
Two different beep frequencies can be heard to indicate is if was a full or half slot error.

1. Low frequency (523Hz) beep means a bad full slot audio frame was seen.
2. Higher frequency (723Hz) beep means a bad half slot audio frame was seen.

This was added for debugging purposes and not really meant to be used normally.

The Increase PDU element verbosity is mentioned in the current changelog for the plug-in for v1.0.14.3 (as is the BFI information)

 

[hassanila]

@thewraith2008, first of all thank you for the update, now everything is working without crashing!

I'm only having a problem that should be easy to fix somehow.
I'm filtering out all talkgroups and only allowing one that I want to listen to, the problem is that sometimes I can still hear other talkgroups at very low volume, in TTT it shows that the call is skipped but in SDR# I can see that the volume is at it's lowest (not muted).
I think I understand why it happens, basically when TTT switches Timeslot to listen to a wanted call it doesn't automatically revert back to Timeslot 1 (MCCH), so when an unwated call is placed on the last used Timeslot it gets trough. The problem can be fixed by automatically reverting to Timeslot 1 and muting SDR# when a skipped call takes place.

I hope you understand, if not, I can try to reformulate and attach screenshots etc.

 

[ferminSV]

Thank you for your new update.
I installed the new update but it doesn't work, it starts normally(without crashing)but I doesn't seems to work properly, it seems that it can't read the new calls from network info window.

I have win10 home 64bit

Στάλθηκε από το SM-A505FN μου χρησιμοποιώντας Tapatalk

 

[thewraith2008]

@thewraith2008, first of all thank you for the update, now everything is working without crashing!

I'm only having a problem that should be easy to fix somehow.
I'm filtering out all talkgroups and only allowing one that I want to listen to, the problem is that sometimes I can still hear other talkgroups at very low volume, in TTT it shows that the call is skipped but in SDR# I can see that the volume is at it's lowest (not muted).
I think I understand why it happens, basically when TTT switches Timeslot to listen to a wanted call it doesn't automatically revert back to Timeslot 1 (MCCH), so when an unwated call is placed on the last used Timeslot it gets trough. The problem can be fixed by automatically reverting to Timeslot 1 and muting SDR# when a skipped call takes place.

I hope you understand, if not, I can try to reformulate and attach screenshots etc.

Normally setting the lowest volume sets the mute in SDR#, but as you can see if a timeslot is active (while TTT is idle) the plug-in un-mutes SDR# automatically and you get bleed through. This is why TTT sets the lower lowest volume. For most people this doesn't seem to be noticed by the masses.

TTT only returns to the main carrier and does not set the plug-in back to MCCH as the plug-in processes all timeslots (unlike a real radio).
In the next release I will set it to MCCH (TS1).



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

 

[hassanila]

@thewraith2008 Thank you!
I will be watching out for the next version.

 

[digiman1]

Hey @thewraith2008, I have an issue, I am not sure it can be resolved though as I am almost sure I had this answered in the past (early stages of development) but cannot be sure, if so then apologies for asking again.

I have 5 Talkgroups, all of which carry traffic I am interested in, there seems to be ONE controller when she talks it goes out across all 5 Talkgroups at the same time but may only be talking to someone in Talkgroup 1 but TTT kicks into life as if she is talking to someone in Talkgroup 2, I hear no response so I end the call and only then does it switch to the correct Talkgroup group where I hear both ends of the conversation.

Any ideas? Is there a setting in place already maybe that I am missing?

 

[Ubbe]

It's a tetra system function. I think it's called multicall. The disptacher can link several TG's together to transmit simultaneous on them but the answer from one TG are not repeated out on the other TG's.

If the TG's instead belonged to a patch the dispatcher wouldn't see it any differently but then the conversations on one TG are always repeated out on other TG's and in most cases would be very annoying to the users.

/Ubbe

 

[digiman1]

It's a tetra system function. I think it's called multicall. The disptacher can link several TG's together to transmit simultaneous on them but the answer from one TG are not repeated out on the other TG's.

If the TG's instead belonged to a patch the dispatcher wouldn't see it any differently but then the conversations on one TG are always repeated out on other TG's and in most cases would be very annoying to the users.

/Ubbe

Yeah, this is exactly how it is working for me and can be a pain although it's not the end of the world pain but would be amazing if a workaround could be made for this.

 

[thewraith2008]

Hey @thewraith2008, I have an issue, I am not sure it can be resolved though as I am almost sure I had this answered in the past (early stages of development) but cannot be sure, if so then apologies for asking again.

I have 5 Talkgroups, all of which carry traffic I am interested in, there seems to be ONE controller when she talks it goes out across all 5 Talkgroups at the same time but may only be talking to someone in Talkgroup 1 but TTT kicks into life as if she is talking to someone in Talkgroup 2, I hear no response so I end the call and only then does it switch to the correct Talkgroup group where I hear both ends of the conversation.

Any ideas? Is there a setting in place already maybe that I am missing?

In the logs for the call, probably 'D_Setup'. What is "Basic_service:" ?
Is it 'Individual', 'Group_call', 'Point_to_multipoint_Acknowledged' or Broadcast?

 

[hamradionl]

Ubbe
digiman1
Thanks, both bring in a very good point, same situation.

 

[digiman1]

In the logs for the call, probably 'D_Setup'. What is "Basic_service:" ?
Is it 'Individual', 'Group_call', 'Point_to_multipoint_Acknowledged' or Broadcast?

I hope I have picked up the correct log:

Carrier:3677 TimeSlot:1 SSI:19000 Call ID:177 D_Setup Transmission Granted_to_another_user Party_SSI:108511 Mode_of_Operation:Simplex Hook_method:No hook signalling (direct through-connect) Basic_service:Group_call Clear Speech_TCH_S Call time-out:Infinite time Modify:Simplex requested

The user 108511 is the SSI of the Controller/Dispatcher, this SSI talks out across all TGs.

 

[thewraith2008]

Nothing in that output indicated anything special about the call, unless other PDUs exist that together show a bigger picture (like private calls).
I doubt there is must you can do.
Maybe blocking all calls started by the Controller/Dispatcher (Just and idea, TTT doesn't do this) . But I don't know if that would work in your case.



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

 

[digiman1]

Nothing in that output indicated anything special about the call, unless other PDUs exist that together show a bigger picture (like private calls).
I doubt there is must you can do.
Maybe blocking all calls started by the Controller/Dispatcher (Just and idea, TTT doesn't do this) . But I don't know if that would work in your case.

It is a strange one.

I don't think blocking all calls started by the Controller/Dispatcher would solve this as sometimes when I am listening on TG1(19000) she will call and get a response as I am listening on the correct TG and wouldn't want to miss her first call.

Would supplying an IQ file help? I could have a go at catching this.

 

[thewraith2008]

Would supplying an IQ file help? I could have a go at catching this.

Sure, couldn't hurt. Just make sure there is a decent lead-in just in case there is other parts to the call.

 

[digiman1]

Sure, couldn't hurt. Just make sure there is a decent lead-in just in case there is other parts to the call.

Yeah, I shall keep recording for say 10 seconds then stop and start a new recording so I can get a lead in.

I should mention also that Say I am listening on TG1(19000) and a caller initiates a call in TG2(19001), obviously I don't hear that unless I switch to TG2 but even though I am on TG1 the Controller/Dispatcher still comes through so it's not necessarily her initiating the call.

I will chime back in again once I have an IQ file you can check out for me.

 

[thewraith2008]

Just to clarify IQ.

 lead-in          lead-out
>--------> [Call] ------x

Ideally the lead-in should be atleast 30 seconds prior to call and lead-out about 10 seconds after call has ended.

 

[R3Natas]

Hi thewraith2008,

Downloaded your latest release, but the problem is SDR doesn't work with TTT, I tried playing with the check box parameter, but no luck. When I click start, it's starts as it should and I can see MCC/MNC and LA, but when someone talks I only see it in the SDR not in TTT

 

[thewraith2008]

Hi thewraith2008,

Downloaded your latest release, but the problem is SDR doesn't work with TTT, I tried playing with the check box parameter, but no luck. When I click start, it's starts as it should and I can see MCC/MNC and LA, but when someone talks I only see it in the SDR not in TTT

Did you install all files from package to the right folders?

To working SDR# folder:

• SDRSharp.Tetra.dll
• libtetradec.dll

To working TTT folder:

• tetra_trunk_tracker.exe

 

[R3Natas]

Did you install all files from package to the right folders?

To working SDR# folder:

• SDRSharp.Tetra.dll
• libtetradec.dll

To working TTT folder:

• tetra_trunk_tracker.exe

Yes, everything is installed correctly and double checked and as mentioned starting TTT I can see network info and when I switch between sites I see it in the TTT log, but no communication in TTT I only see that in TETRA Demodulator, previous version worked perfectly