Unitrunker MPT1327 call drops out after 20 seconds

[thewraith2008]

I'm noticing when a call is active, after 20 seconds Unitrunker ends listening to a call while it is still in progress. I can confirm this because I have a scanner on same frequency and the call can still be heard. I'm not hearing any end of call tones unless they're sub-audible.

Some calls I can only hear one side of the call, other calls I hear both. This still happens in any case.

Not sure if there is a setting for this. Is there a timer or something?

How is Unitrunker deciding to end the call. My understanding is the CC does not announce this and MS just return to CC at end of call with some tones sounding then repeater drop out. But the call hasn't end anyway.

The call is received with a RSSI of 68

Anyone come across this issue and a solution.

Cheers

 

[SCPD]

Hello;

This is a known problem with MPT1327 networks.

Many such systems do not issue late entry or call-in-progress messages so there's no easy way to know when a call has ended. Fixing this is on the TODO list but there are higher priority issues ahead of it.

 

[thewraith2008]

Thanks for the reply.

I fired up SDRTrunk to view traffic channel messages during a call and noticed that the 'MAINT' message seems to be sent as each caller completes their 'over'. And the 'CLEAR' message is been sent to return radio to control channel. Does Unitrunker not monitor the traffic channel for these messages and does it only use a 20 second timeout?

Could this 'MAINT' be used as some sort of watchdog timer reset so if they're not sent then after the allotted time it returns to the control channel. And have this timeout value exposed to the user.

I don't normally use SDRTrunk as the latest alpha/beta is not working that well with MPT1327, but 0.2.0 is following OK it seems. I haven't worked out the priority system on it yet so all active calls come through at once. I think Unitrunker is better in this regard.

Cheers

 

[SCPD]

Hello;

Generally speaking, Denny does good work.

The problem is the design you see originated from having a separate receiver for voice following (eg. pre-SDR). Since the computer controlled receiver has it's own speaker, the host PC does not participate in the traffic channel other than to tell the receiver which traffic channel to follow.

The 20 second value was a hackish compromise. Many MPT networks have 90 second timeouts (eg. the maximum to hold PTT and talk). The ability to change this value would only change the compromise, not really solve the problem.

In an SDR context, it is much more practical to sense carrier loss on the followed voice channel. I have a fix for this in version 2 of the program, but that is still under development and won't be ready for a while.

 

[thewraith2008]

Thanks for the explanation.

After looking through some different standards (mainly DMR and MPT1327) I can appreciate the effort that has been undertaken by yourself and other SDR software developers. One standard is complicated enough let alone 5 or more. And that's not including all the other aspects of the program that is also researched and developed.

Again I thank you guys. I'm not gushing I'm I.

Cheers.

 

[DSheirer]

I don't normally use SDRTrunk as the latest alpha/beta is not working that well with MPT1327

There was an issue with the MPT decoder, but it's resolved in current master branch now.

Denny

 

[thewraith2008]

Hi Denny.

Issue is related to the displaying of IDs in 'To' and 'From' in 'Audio Panel' and 'Decoding Channels' panes.

I still plan on write a bug report for you on your support forum about it. The networks are only active during the day and between Monday and Friday.

Cheers