Unitrunker 10th Public beta

[SCPD]

Other times, when multiple TG are active on a site the voice scanner will be directed to a frequency and TG, but once that conversation ends, the voice scanner will not be directed to another frequency and TG even though there are many active ones - it will just go to the park channel until the entire site has no activity, then it will start directing the voice scanner again.

Selection is event driven. If the program didn't switch to one of the other active groups - those groups weren't getting any new events (call grants or continuations - some protocols call these "GTCs" to go-to-channel messages). The program will continue to display them as active for the "hang time" interval. It won't select one of them because the call may in fact be over. You could be switching to dead air.

On top of that ... if the decode rate is less than 100% ... you're missing some of the events needed to make the selection. This makes the behavior you've described more apparent.

 

[troymail]

Hey Rick - what's the story on the View -> Affiliations? I see affiliations appearing but they don't seem to go away - I recall the used to show "active" and then a "goodbye" (or was that on non-P25 systems?). I also have some radios on the system talking but they don't show up in the affiliations list on the screen....

 

[SCPD]

You should see the "goodbye's" (which are actually de-registration acks).
-rick

 

[SCPD]

Other times, when multiple TG are active on a site the voice scanner will be directed to a frequency and TG, but once that conversation ends, the voice scanner will not be directed to another frequency and TG even though there are many active ones - it will just go to the park channel until the entire site has no activity, then it will start directing the voice scanner again.

I may have a fix for this that will attempt to cope with a less than perfect decode. It will select the most recently active call that matches the listening criteria instead of waiting for an event to confirm the call is active (sheesh - I hope that made sense).
-rick

 

[troymail]

You should see the "goodbye's" (which are actually de-registration acks).
-rick

Not seeing them on this system... I see affiliations registering but they just stay active - no goodbyes

http://radioreference.com/modules.php?name=RR&sid=4790

 

[SCPD]

Not seeing them on this system... I see affiliations registering but they just stay active - no goodbyes.

Turn on logging ... after a spell ... search your log for "Deregistration" messages.

 

[troymail]

Turn on logging ... after a spell ... search your log for "Deregistration" messages.

I had the logging running - 132Mbytes - I see "registrations" but no "deregistrations" - I can send you a snippet if you'd like.

 

[nickburns]

I'll second troymail. I see registrations all day long but no deregs on a 9600 system. Didnt even know it was supposed to show that!

J

 

[troymail]

I see radios affiliate on a TG and switch to other TGs but no indication that they leave - although I think some may be "fading". I'm not sure if the deregistration is seen but not logged/displayed or this is just a "fade" feature while watch affiliations.

 

[SCPD]

I had the logging running - 132Mbytes - I see "registrations" but no "deregistrations" - I can send you a snippet if you'd like.

If you don't see "Deregistration Acknowledge" messages in your logs - the system isn't sending them. In which case there isn't an easy way to determine a radio has left the system. It may be that the system and/or radios are configured this way.

To verify that a subscriber unit is still lurking on the system - the controller can send out a unit registration command. This is a demand that the unit re-register. No response indicates the radio is no longer there - but isn't nearly as convenient to display as a plain de-registration message.

 

[nickburns]

Troy, looks like we have a little digging to do to see how they actually send a deregister message.....I'll gather a logfile as well Rick.

J

 

[Liverdog]

I may have a fix for this that will attempt to cope with a less than perfect decode. It will select the most recently active call that matches the listening criteria instead of waiting for an event to confirm the call is active (sheesh - I hope that made sense).
-rick

Yes, Rick... makes perfect sense. Again, we all love your work... I was just trying to tie a possible deviation that may have taken place from one revision to the next. Same equipment, different software rev, different performance between revs.

 

[Liverdog]

If you don't see "Deregistration Acknowledge" messages in your logs - the system isn't sending them.

I'm curious about this on our P25 systems too. When you say "logs" are you talking about the affliation viewer in UT or something else? Where would we see "goodbye" or deaffliation in UT if it were something over the CC?

 

[SCPD]

I'm curious about this on our P25 systems too. When you say "logs" are you talking about the affliation viewer in UT or something else? Where would we see "goodbye" or deaffliation in UT if it were something over the CC?

The "goodbye" appears in the [A]ffs view. The log is a text file created by the program when logging is enabled. Under the [O]ptions menu ... look for "Logging is [on/off]". The files can become huge - 100 megs or more per day. The program starts a new log file at midnight and applies GZIP compression to the previous day's log file - to conserve disk space.

The "Deregistration Acknowledge" messages appear the log file - not in a program display.

-rick

 

[Liverdog]

I would like to echo RandyK's comments. I thought I was having scanner issues too since using beta 10. I had been noticing that the voice radio, decoding P25 was only giving me every other transmission on the same TG and channel. Then I noticed that after the first transmission the radio would park on a blank memory channel and not go back to the same TG and channel when a voice response was sent.

Other times, when multiple TG are active on a site the voice scanner will be directed to a frequency and TG, but once that conversation ends, the voice scanner will not be directed to another frequency and TG even though there are many active ones - it will just go to the park channel until the entire site has no activity, then it will start directing the voice scanner again.

Rick, I've looked at this problem at bit more. Let me see if I can explain the problem a bit more.

I have a very good decode rate on the P25 system in question (high 90's). I see all the activity that I expect in the UT screen (i.e. dispatch makes a call, unit responds, dispatch calls again, unit responds, etc). However, when the voice scanner is being commanded, it is only commanded to the correct frequency/TG every other transmission. So, if dispatch calls first, I hear dispatch as the voice scanner is commanded to the correct frequency. However, as soon as the unit being called responds (same voice channel) the voice scanner automatically goes to the "park" channel and sits there until dispatch keys up again, then it goes back to the correct frequency. This occurs very fast, just as if:

Disp: "3A31 copy AOA"
3A31: "go ahead"
Disp: "3A31 respond to..."

In this example, all I hear is the dispatcher, not 3A31.

The opposite is true too, just in case you're thinking I've locked out everything but dispatch. If the unit starts first, then dispatch, then the unit, all I hear is the unit. The voice scanner is commanded to the park channel for every other transmission.

The voice scanner in this case is a BC250d.

This problem is very repeatable. The only time it works correctly is if the responding party waits long enough that the channel drops and then UT picks it up when the responding party's channel is assigned a frequency at a later time.

Thanks