search

DSheirer / sdrtrunk

A cross-platform java application for decoding, monitoring, recording and streaming trunked mobile and related radio protocols using Software Defined Radios (SDR). Website:
GNU General Public License v3.0
1.6k stars 256 forks source link

LTR-Standard talkgroup 255 problem #42

Closed WilliamTR closed 8 years ago

WilliamTR commented 8 years ago

I am using sdrtrunk V0.2.0 beta to receive LTR-Standard using soundcard Line In. Operating system is Windows 7 Home Premium Service Pack 1 64-bit and java version 1.7.0_71. The speaker icon To: shows the LTR Talkgroup while the call is in progress and clears when call ends and audio is output while the call is in progress. The LTR-Standard window below it lights up blue while the call is in progress and shows the word CALL. The Events tab shows the Call Event. However, periodically the repeater sends a CALL word to group ID 255, such as 0-05-255 or 1-01-255, with a list of free LCNs. For a normal CALL there appears to be three END transmissions but for this 255 talkgroup CALL transmission some of the repeaters only transmit one END transmission and some of the repeaters do not send any END transmission outbound signaling message word. Whenever the one END transmission is received sdrtrunk continues to work normally. However, if there is no END transmission word then the messages tab will still show call signals but the LTR-Standard window on the left does not show the word CALL nor does it light up blue and nor does anything show in the speaker icon TO: field nor is any audio output. Also, the Events tab has stopped showing these Call Events even though they are showing in the Messages tab. Also, closing sdrtrunk and restarting it fixes the problem until the next 255 talkgroup transmission without an END transmission occurs.

DSheirer commented 8 years ago

After monitoring one of the local systems, it appears that there are two issues with the LTR Standard decoder state component:

1) When there is an ongoing call on the LCN and the repeater sends status messaging for an ongoing call on another LCN on the repeater, both sets of messages say CALL, but only the messages for the monitored LCN should say CALL. The status messages for the other LCN should say CALL DETECT.

2) The channel state inactivity monitor is randomly not squelching a call when the decoded signalling stops. When the call end event is not decoded/missed, the channel state monitor should kick in and squelch the audio once a period (~2 seconds) of inactivity has elapsed.