Unitrunker Third Public Beta

[NDRADIONUT]

Data

Rick, here is my other wish after logging affiliations.....when a radio signs off the system it leaves a "0" in the TG field of the .RID data file......could that be changed to just leave the last talkgroup it used ???

Thanx......I'm really enjoying the results of your hard work !!

 

[SCPD]

Rick, here is my other wish after logging affiliations.....when a radio signs off the system it leaves a "0" in the TG field of the .RID data file......could that be changed to just leave the last talkgroup it used ???

I can do that. I should distinguish between registered (present on the monitored site) and last-affiliated (possibly on a remote site).

-rick

 

[NDRADIONUT]

Data

Thanx Rick....either TG option is much more useful than a zero !!

 

[Jay911]

Rick,

I've been running on a couple of Motorola systems lately with positive results. No "unwanted" information being gathered; only freqs actually in use are being counted. However, I have another quirk to report.

I am getting 99 to 100 percent decoding on one site of a six-site Smartzone system. It's working flawlessly except for one thing: During specific, certain calls, the source ID is appearing on the screen only briefly, until the target ID pops up; then the source ID is blanked out on-screen and all that's seen is the target. I thought this was only happening with encryption/encoded ("Dig") talkgroups, but I saw one that I know isn't encrypted, and was actually more than likely a crosspatch. Wondering if the issue lies with all types of calls where a value of any kind is in the rightmost column (where "Dig", "XP" etc reside)?

 

[SCPD]

During specific, certain calls, the source ID is appearing on the screen only briefly, until the target ID pops up; then the source ID is blanked out on-screen and all that's seen is the target. I thought this was only happening with encryption/encoded ("Dig") talkgroups, but I saw one that I know isn't encrypted, and was actually more than likely a crosspatch. Wondering if the issue lies with all types of calls where a value of any kind is in the rightmost column (where "Dig", "XP" etc reside)?

Which system is this (eg. is it on 800 mhz) ? I'm a little concerned that the fleetmap logic might be coming into play when it shouldn't. I'll can run a regression test. Knowing if this is 800, 900 or UHF/VHF will help.

Two quick things to check:

Make sure that the system is recognized as a Type II system.
Make sure you do NOT have a fleet map defined.

If you can capture the unwanted behavior to a log file, please email or post here. I should be able to track it down from the log file.

On a side note, I have some EDACS improvements coming soon.

-rick

 

[Jay911]

It's an 800mhz Smartzone system, viewing site 3 of 6. (sysid 753f)

I'm not near the logging computer right now, but I'll grab the logs when I get home. I do believe it reported it as a Type II and I don't think I have a fleetmap defined. I'll send you some data later today.

 

[Jay911]

Yes, the properties display shows Type II 800, and profile 0.90 (though I think it showed something like 1.10 previously - didn't pay much attention to it). No fleetmap is programmed.

I'll email you with details of logs and current data files for this system.

 

[Steve]

Strange

Maybe someone can answer this question, running Unitrunker on the following system,http://www.radioreference.com/modules.php?name=RR&sid=635, Unitrunker shows the system as not a Type I. Reportedly the system is a Type I. I run the system a couple different ways when using old Trunker. One way with fleetmap of E1P8 and the other way with a size code of s-3 for block 5. Both since to work okay with Trunker.
So what gives with Unitrunker's decode?


Steve
KD4LCY

 

[DaveNF2G]

If users of a Type I system are replacing radios, they are probably replacing them with Type II equipment because Type I is no longer supported. If that is the case, then the radio system becomes Type IIi (Type I with some Type II radios). The newer radios are probably the source of Unitrunker's apparent "confusion" about the system.

If you leave the original Trunker running long enough for someone to transmit on a new radio, it will detect a Type II RID and change the system flavor to Type IIi.

 

[SCPD]

Unitrunker shows the system as not a Type I. Reportedly the system is a Type I.

"Not Type I" means the program hasn't seen anything suggesting a specific type of Motorola trunking. There isn't much listed in the RR DB in the way of talkgroups so either the system has low activity or lots of activity on a few talkgroups. If the other banks are never used, it's difficult to conclusively pin down the system as a purely Type II system.

Also, look for fleetmap support in the next release.

If you can, leave the program running for an extended periood of time. Please let me know if it stays stuck in "Not Type I". We'll get it figured out.

-rick

 

[SCPD]

Yes, the properties display shows Type II 800, and profile 0.90 (though I think it showed something like 1.10 previously - didn't pay much attention to it).

The profile number is an internal performance statistic. It's the relative number of CPU cycles consumed by that decoder. It's mostly for my benefit to make sure I don't create a resource hog.
-rick

 

[dbrown2]

Rick,
Have you had any luck controlling the BC895XLT yet? with unitrunker?

David

 

[slicerwizard]

I can do that. I should distinguish between registered (present on the monitored site) and last-affiliated (possibly on a remote site).

I don't see how you can know for sure that a subscriber is still affiliated to a given site for more than about five seconds after you see an affiliation.

 

[SCPD]

I don't see how you can know for sure that a subscriber is still affiliated to a given site for more than about five seconds after you see an affiliation.

Andrew - you'll have to elaborate on what you're saying.

 

[slicerwizard]

Andrew - you'll have to elaborate on what you're saying.

You had stated "I should distinguish between registered (present on the monitored site)..."

I am asking how you would know that a subscriber is registered on the current site?

 

[SCPD]

You had stated "I should distinguish between registered (present on the monitored site)..." I am asking how you would know that a subscriber is registered on the current site?

NDRADIONUT didn't want the radio's last-seen TG cleared out - which is what I was doing on the deaffiliation. Put another way ... I need two columns - radio's last used talkgroup and last used site. I can infer one or both columns from three messages (depending on protocol). Affiliation implies radio's active talkgroup and site. Channel grant only implies radio's active talkgroup. Registration implies active site.

-rick

 

[NDRADIONUT]

Last Used Site

The last used site is a wonderful idea to include !! Especially with some of the wide ranging systems around...I leave my Yaesu 2600 on scan on several South Dakota sites and gather data when I'm gone so it's nice to see what site they came from. The sites fade in and out over the hours as I am some distance away.

 

[SCPD]

The last used site is a wonderful idea to include !! Especially with some of the wide ranging systems around...I leave my Yaesu 2600 on scan on several South Dakota sites and gather data when I'm gone so it's nice to see what site they came from. The sites fade in and out over the hours as I am some distance away.

Just to clarify ... it can tell you if the radio logged onto "this" site - not any of the neighboring sites. If the user keys up on a talkgroup and you haven't seen an affiliation - you don't know what site they're using. In your example - that would work - though there is a good chance that the program hasn't figured out which site you're using (particularly when switch among sites on the same system). A more elegant route would be to have the program control the radio so that it knew - with some certainty - that the radio is about to switch channels (but hey, not this week).

I think TrunkView does something very much like this for MPT1327.

A more robust approach is to simultaneously monitor multiple control channels (assuming you've got the extra radios).

-rick

 

[slicerwizard]

Affiliation implies radio's active talkgroup and site.

Watched a radio affilation on my local Smartzone site (3C08 / zone 2) yesterday; meanwhile, the guy I was talking to on the phone watched the same affiliation show up at the exact same time on his local site (3C08 / zone 1).

 

[robbinsj2]

Watched a radio affilation on my local Smartzone site (3C08 / zone 2) yesterday; meanwhile, the guy I was talking to on the phone watched the same affiliation show up at the exact same time on his local site (3C08 / zone 1).

Likewise here, Smartzone 8a27. Many county (zone 1) radios show affiliations over the township (zone 2) control channel, but even moments after the affiliation that talkgroup's activity comes over only zone 1, not zone 2. Not all county radios show affiliations over the township zone, however -- certain sets of them, like DPW, don't ever appear.

Maybe it's different for P25 systems?

Would the radio's "last-seen talkgroup" be updated if it gets a channel grant for a talkgroup different than it previously affiliated to? From an untrained eye, it sometimes looks like a user changes channel and quickly keys up, preempting any affilition (which isn't logged by Trunker, even after the call). I don't know if UniTrunker behaves the same; I'm waiting for the forthcoming 895 support before switching completely over.

Jim