UT-Affiliation Display loosing sync

[Liverdog]

Rick, from time to time, I see my affliation display start to lag up to a minute behind the system clock of the PC. What's also interesting is that the actual calls being logged in the affiliation display are actually from a minute in the past. I've verified this by turning to different TGs using a system radio and waiting to see the TG affliation show up. I can key the system radio and see immediate response in the activity display and then a minute later, see the affiliation that took place (time stamped) in the past show up.

Now, if I move off of affiliation, and look at "props" for example and then back to affliation the display jumps over that minute to arrive at correct point in time (kind of reminds me of Back to the Future). So, what I end up with is a one minute gap in the affliation display.

This is a P25 site, fourteen channels, affliation activity every two seconds or so, and CPU loading of less than 2% and high 90's decode rate.

Thanks

 

[WayneH]

Maybe I'm reading this wrong but, you know an affiliation is unrelated to an actual call on the system, correct?

An affiliation is meant to only notify the system that the radio is on the network or has switched to channel X.

 

[Liverdog]

Ya Wayne, thanks. The issue's a bit deep, so I'm hoping Rick can help uncover the sync prob.

 

[SCPD]

Check the scroll on the affiliation display. It may be displaying past information because you've scrolled down to some time in the past.

 

[Liverdog]

That was one of the things I looked at. What I noticed, since there is activity every two seconds or so, is that after moving off of the affliation display, to view something else and then coming back, there is a one minute gap (loss of information during the lag time that existed).

Example:

Watching the display with no interaction:
Affliation System Clock
01:00:00 01:01:00
12:59:58 01:00:58
12:59:56 01:00:56

Moving away and then coming back:
Affliation System Clock
01:01:02 01:01:02 <-- Lost one minute of data from previous line to this one
01:00:00 01:01:00

Thanks

 

[Dewey]

Just an FYI... on the DC PD system (603d UHF), mine is instantaneous. The delay actually comes in due to system load. This is how I'm able to confirm mine: I'll fire up UT and navigate to the affiliation screen. Once it starts filling, I'll switch my radio to another channel. It will take up to two or three minutes, but once the change kicks in, I see it immediately in the affiliation screen. How do I know... because the radio's transmission to the system will cause the transmit led to flash very beriefly. Also, there will be a pop on the scanner that is tracking the control channel due to the short burst transmission of the radio notifying the system that the channel has changed. For the life of me, I can't figure out how the radio follows the channel change prior to the notification, but I do know that the radio notification is not sent right away unless the system is not active at the time (VERY VERY VERY rare for DC PD).

Hope this helps,
Dewey

EDIT: I forgot to mention that when I do see the channel change (to include on/off) in the affiliation log, it is normally grouped with several other radio changes as if the system may do a systematic poll of the radios.

 

[SCPD]

I think Liverdog may have found a kink in the way the program suppresses duplicates.

Affiliation messages are often sent in duplicate or triplicate. To avoid cluttering the display with redundant junk - a filter is applied. Duplicates from the last 60 seconds are discarded. That time window is probably too big. The event history is for the last 1000 or so events - enough to cover several hours of affiliations and registrations.

As a user on the system, if you turn on your radio and see it affiliate ... then switch to another group; you should see the second affiliation. If you quickly switch back to the first group - you won't see the affiliation because the program thinks it is a duplicate and discards it. However, repeat the process again a minute later and you'll see both groups.

During that one minute - you should continue to see events pertaining to other radios (assuming there is activity). I think Liverdog is saying he sees no activity during this one minute (not just his radio but all radios) and I don't have an explanation for that.

Since this is a P25 system, you should also see the registration or "logon" message when each radio is powered on or roams from another site.

 

[Liverdog]

Okay, Rick what you're saying is making perfect sense, and now I think I know what the problem is...

You see, there are several users on the system who's radios have been left on and sitting in chargers. They die then acquire enough charge to re-register and affiliate then die again. This happens over and over with only a few seconds between charge-affiliation-die-charge-affliation-die. Right now there are about 6 radios doing this on the one site I'm looking at.

However, based on your comments about the filter I do see the same radio(s) affiliating every couple of seconds. I would have thought those would have been filtered.

In any case, if we take six radios affiliating in the same way every two seconds, thats (6 radios x 3 affliations(maybe) x 2-second periods x 30 periods in a minute) = 1080 events. So, is my event history getting jammed up given this scenario?

If I can make a request, I'd prefer not to have the data filtered even if it is redundant. It's nice to have some of the programatic insight in this case too.

Thanks

 

[SCPD]

However, based on your comments about the filter I do see the same radio(s) affiliating every couple of seconds. I would have thought those would have been filtered.

That's because the filter is also limited to the last three messages in the history. It a new message matches one of the three most recent history messages and the time difference is less than 60 seconds - it is discarded.

Another reason for the behavior you see may be radios operating in fringe areas on the edge of or between two sites. The radio loses signal, reacquires the control channel and re-affiliates ... over and over ... until the user moves to an area with better reception.

In any case, if we take six radios affiliating in the same way every two seconds, thats (6 radios x 3 affliations(maybe) x 2-second periods x 30 periods in a minute) = 1080 events. So, is my event history getting jammed up given this scenario?

No. Take the first 2 second period. Let A be affiliation msg for radio A, B is an affiliation msg for radio B and so on for six radios. The control channel sends out "A A A B B B C C C D D D E E E F F F" inside of two seconds. Your history would look like "A B C D E F". That's only six entries every two seconds. At that rate it would take 5.7s hour to fill the history before it started discarding the oldest events to make room for the most recent.

If I can make a request, I'd prefer not to have the data filtered even if it is redundant. It's nice to have some of the programmatic insight in this case too.

I tried that ... on some systems it filled up too quickly and scrolled by too fast to be useable. For that level of detail ... you can always turn on logging to see every message sent on the control channel.

 

[Liverdog]

That's because the filter is also limited to the last three messages in the history. It a new message matches one of the three most recent history messages and the time difference is less than 60 seconds - it is discarded.

This is fascinating to me, so I hope you don't mind if I drill down on this a bit...

I see sometimes that the system radios will attempt several times to register over a programed period of time (if it wasn't sucessful at first). Is this where we get the cc redundancy that we are discussing (ie AAABBB being generated and resent as ack from the cc) or is it a function of the cc to always send a message three times even if the subscriber's radio only sent one request?

Is the decision in the quote above a logical AND? In otherwords, based on my question above, I am asking if one subscriber submits a request (radio A) and then another (radio B), then (radio A) submits the same request again does UT's filter process and display three events since there was break between A's request? Would A's request only be filtered if there were sucessive requests within a 60 second window with no breaks?

Thanks

 

[SCPD]

is it a function of the cc to always send a message three times even if the subscriber's radio only sent one request?

The mobile radio will continue to send affiliation requests until it sees an affiliation response. I don't know the exact timing ie. how long to wait between unsuccessfuly requests or how long to wait and N failed attempts before starting the whole process. The important thing is for the radio to not hinder other radios' access to the control channel.

Is the decision in the quote above a logical AND? In otherwords, based on my question above, I am asking if one subscriber submits a request (radio A) and then another (radio B), then (radio A) submits the same request again does UT's filter process and display three events since there was break between A's request?

Only if there were three filtered messages recorded in the last 60 seconds since the last time message A was first received.

There's actually a better way to do this ... but the mechanism described above was cheap and easy to implement.