Question about Unitrunker and tracking time...

[br0adband]

I'm doing my best to catalog and ID every radio here in the Vegas area on several systems, and one thing I've noted is that sometimes, especially when I'm really trying to ID a specific radio, it seems like Unitrunker doesn't show the actual RID of the specific radio that's doing the transmitting - and by that I mean when multiple comms are occurring in quick succession.

I realized the best time to acquire a significant chunk of RIDs is during the morning roll call/radio check done on our SNACC system here. They'll bring up maybe 4 or 5 of the channels and do a relatively lengthy radio check on each - the downside is they tend to do them on at least 2 or sometimes 3 or 4 of the channels at the same time instead of staggered times.

When Dispatch calls out a unit ID (like "Mobile 16") and Mobile 16 responds, it's almost like the "repeater tail" showing the DISPATCH RID that I have already identified is still there - when Mobile 16 keys up their mic Unitunker doesn't show the actual RID, it continues to show the RID of the Dispatch console RID.

So my question is, is this normal behavior, or is there a setting I can change that would cause Unitrunker to "let go" of the RID that's not actually transmitting and show the ID of the unit that actually is transmitting?

Or is this just some quirk of the trunking system in use where it won't ID the radio effectively transmitting. It's almost as if when a unit responds that the system will just let it "ride on the coattails" of the RID that started the communication in the first place.

I know I'm not explaining this very acccurately, but in the morning when the roll call is taking place, they call out nearly every single unit in this entire city and that's the fastest way for me to acquire a ton of the RIDs to plug into Unitrunker. The problem is, even when the Dispatcher is quiet and the unit being called actually does respond, I'm still seeing the RID of the Dispatcher and not the unit I'm trying to ID.

Bleh... if anyone has any tips on how to improve the tracking time or whatever, or force Unintrunker to let go of an RID as soon as the unit stops transmitting, I'd appreciate it. Of course, this could all be an exercise in futility but, I keep trying to ID these radios during roll call and I swear, over 75% of the time the RID never changes from DISPATCH to the actual radio ID I want to identify.

Thanks...

 

[FlashSWT]

br0adband, I've seen the same thing down here and always assumed it was an issue with my setup. I have no help to offer other than saying I've seen the same thing and you explained it well.

.

 

[br0adband]

I have noticed that here in Vegas when the EMS units are calling into the hospitals they're using different radios entirely; it's not just a question of them simply switching talkgroups on their handhelds, it's a totally different radio circuit, more or less. That sometimes gets frustrating also because the RIDs come up the same but lately I've been able to discern a difference depending on time of day and who's involved, so it's kinda weird.

But every time I try to grab a bunch of RIDs during that morning radio check/roll call I get really irritated when the RID remains stuck on the Dispatch console RID and never changes even though there's a huge number of units that are responding. Bleh... just my luck.

It'll happen over time, obviously, but it would be a lot easier if the RID changed as I think it should. Obviously they're different radios transmitting so each has a unique RID, now if only the software would show it. Maybe I'm just missing something or it's a "feature" of the particular system Clark County is using, I really can't say. Doing this kind of "monitoring" is new to me, meaning using Unitrunker to see what's really going on in trunked systems.

 

[SCPD]

But every time I try to grab a bunch of RIDs during that morning radio check/roll call I get really irritated when the RID remains stuck on the Dispatch console RID and never changes even though there's a huge number of units that are responding. Bleh... just my luck.

That's transmission trunking vs. message trunking.
(thank you Wayne!)

 

[br0adband]

So I take it that means the chance of doing anything about it means Jack you-know-who.

I have noted that at times I'll see MS listed in the CT column on the far right; I'm assuming that means Multi-Site or... anyone able to clue me in? That usually appears when Dispatch is doing the radio check/roll call in the mornings, as I'll sometimes here Dispatch call out for a unit that never seems to respond, only to discover they were responding on a different talkgroup altogether (i.e. Dispatch calls out on Zone 1 Ch 1 and gets a response from the unit they're calling for on Zone 3 Ch 2).

It's a bit odd to me but, I guess I still have a lot to learn about monitoring such a large trunked "zone" system as this one, and the others here in my area.

Thanks...

 

[SCPD]

So I take it that means the chance of doing anything about it means Jack you-know-who.

Sorry, don't know that person.

I have noted that at times I'll see MS listed in the CT column on the far right; I'm assuming that means Multi-Site or... anyone able to clue me in?

Multi-Select. It's a form of patched call that temporarily ties multiple talkgroups together. The other form is "XP" or cross-patch.

That usually appears when Dispatch is doing the radio check/roll call in the mornings, as I'll sometimes here Dispatch call out for a unit that never seems to respond, only to discover they were responding on a different talkgroup altogether (i.e. Dispatch calls out on Zone 1 Ch 1 and gets a response from the unit they're calling for on Zone 3 Ch 2).

Which is perfect for multi-select. If you - as the dispatcher - don't know "where" the unit is (ie. which talkgroup they've selected) - you can hit all of 'em at once (or at least the groups where you might expect to find the specific user or users).

 

[br0adband]

That's what I figured about the MS - I actually found something that said it was Multi-Select earlier but I was thinking Multi-Site when I made that post above, DOH!

And yeah, it's perfect for that sort of thing because after 3 calls for a unit with no response, I'll hit Scan to grab the next TG that shows active on Unitrunker and when the unit does respond on another different TG, when Dispatch keys up they'll be heard on that TG as well - and that's a different one meaning they're broadcasting over several at once sooo... yeah, yeah... that's the ticket... yeah

 

[FlashSWT]

That's transmission trunking vs. message trunking.

Thanks for the link Rick. I guess this explains another question I had about why a group would still be "active" in Unitrunker after a transmission even though it wasn't on my scanner.

.

 

[slicerwizard]

That's transmission trunking vs. message trunking.
(thank you Wayne!)

I don't think so. If the system was using message trunking, the OP would also be reporting regular users tailgating each other all day long. I'd say the dispatcher is merely keeping the talkgroup active and waiting for the replies (users can talk over a console). When doing radio checks with dozens of units, the dispatcher isn't going key/unkey for each one. I know I wouldn't.

 

[SCPD]

I don't think so. If the system was using message trunking, the OP would also be reporting regular users tailgating each other all day long. I'd say the dispatcher is merely keeping the talkgroup active and waiting for the replies (users can talk over a console).

If the user can talk over dispatch - they must be getting a channel grant - which br0adband says isn't happening - at least that's how I read it.

When doing radio checks with dozens of units, the dispatcher isn't going key/unkey for each one. I know I wouldn't.

I thought it was the other way around - the console can talk over the mobiles in which case they'd want to unkey so as to hear each reply [or is this configurable?] If dispatch is working from a base/mobile instead of a real console ... obviously this wouldn't work.

In any case, I'd need a log to see.

Br0adband - are you using voice following at all? If so, is it dual radio (listening radio separate from decoding radio) or single radio (same radio does both) ? If yours is a single radio setup then you're going to miss a lot info each time the radio leaves the control channel to chase the next call.

 

[SCPD]

I guess this explains another question I had about why a group would still be "active" in Unitrunker after a transmission even though it wasn't on my scanner.

More trivia - the control channel does not explicitly announce when a voice call ends (with some exceptions). There's no point - the radios that need to know this information are parked on the voice channel so announcing that fact over the control channel would be useless. Nearly all trunking protocols have some sort of "end of call" message (eg. a Motorola disconnect tone , EDACS "dotting", P25 terminator, or MPT1327 GTC message) sent over the voice channel instructing the radios to return to the control channel.

 

[DiGiTaLD]

Ptt-id?

That's transmission trunking vs. message trunking.
(thank you Wayne!)

Wouldn't it be PTT-ID trunking vs. message trunking? I notice this happening on system 0F06. The radio that originated the call will remain in the calling party column (and it's respective ID column) even if another user is talking, as long as the talkgroup is active. Once the hangtime is over and the talkgroup drops, whichever radio initiates the next call on the talkgroup shows up, and as long as the hangtime is active, their ID shows up.

The reason I say I think it is PTT-ID trunking versus message trunking is that according to Wayne's write-up, with transmission trunking there is no hang time and all radios return to the control channel as soon as a transmission is completed. This is not what is happening with system 0F06 and I'm betting is not what br0adband is seeing either. There is still a carrier present from the system transmitting on the voice channel, and when the next user transmits, the initial user's ID is still shown because they initiated the call.

BTW, on the other systems I monitor that use PTT-ID trunking (7829 for instance) such is not the case. The radio ID changes with every subscriber radio, or console, that transmits. I think what we're seeing has to do with the way the system is set up (message trunking vs. PTT-ID trunking) and not a flaw in our setups or Unitrunker.

 

[SCPD]

Wouldn't it be PTT-ID trunking vs. message trunking?

Good point. IIRC, the last time I read that page - Wayne only distinguished between message and transmission so he must have refined the distinctions even further.

From a control channel monitoring perspective - PTT ID trunking and transmission trunking behave the same. You'll see a call grant for each PTT. This implies that the TX'ing radio must leave the voice channel to issue a PTT request and wait for a call grant, before returning to the voice channel. The presence or lack of idle carrier on the voice channel between callers speaking in turn won't affect catching the radio IDs from the call grants on the control channel.

To put it another way, you can consider strict transmission trunking to be the same as PTT ID trunking with a hang time of zero ie. one is special case of the other.

From a decoding / logging perspective - my concern is whether the call grants mark the start of a call or the start of a transmission.

After re-reading br0adband's comments, I'm wondering if the issue is more like this ... the replies during roll call are so short that the dispatcher's radio ID quickly replaces them. In other words - the call grants with the unit IDs are there - but they go by so fast and are each followed by the dispatcher's voice (and call grant) so quickly that that it is hard for the user to see them.

The Windows GUI version of Unitrunker fixes this BTW.

We'll see what br0adband has to say ...

 

[br0adband]

I'm using Unitrunker off the control channel being received by a BC-700A; the voice monitoring is done with the 246T. So I sit here around 8AM each morning with the intent of grabbing as many "new" RIDs as I can. As Dispatch calls out (most of the time I know which channel is being used because it'll show that MS in the CT column) I hear the unit being called out to, write that name down, then hopefully catch the RID as it hopefully appears on Unitrunker on the same TG when the called unit replies. For the most part, that doesn't happen and the RID shows DISPATCH and the relevant RID stays the same even when the replying unit calls in.

If the hangtime ends (2 seconds I think) and the channel is released, when the Dispatcher keys up again, it's a new channel/frequency of course, and the process starts again. It's not a 100% hit or 100% miss thing, it's just kinda random how it works. Sometimes when a replying unit xmits, wham, there they are, and their RID replaces the DISPATCH one even when they respond within about 1 second of DISPATCH obviously unkeying the mic, I can hear it happen and then see the change in RID from DISPATCH to whatever the RID is for the unit replying.

I have DISPATCH as the standard format for all the labels for all Dispatch RIDs , in Light Cyan color, regardless of what group or use it is - makes things easier. Non-labeled or non-ID'ed RIDs still show in the default green color, so when the DISPATCH label appears, the hope is that it'll change to the default green color - bam, that means a "new" non-ID'ed RID for me to write down quick. If it's in red then it's already labeled - all my fire activity is red (light red, actually), police is light blue, etc.

DISPATCH is very easy to distinguish between the two because of the color. I think I've got pretty much every Dispatch RID covered so far, but I'm sure there are still many others I haven't actually noted voice activity on so far. They tend to be grouped together in terms of the RID numbering, but there are still many gaps - with over 5,000 RIDs in the RID file, there's a ton of stuff I most likely will never get identified unless I happen upon a codeplug for the entire SNACC system - and that ain't likely.

What I've been trying to do for some time now is actually do a recording of Unitrunker in operation along with the actual broadcast audio in a video file. I'm still having a helluva time doing that because of how Windows works - it'll only see one "recording" input at a time, and that one recording input is channeled into Unitrunker even though I have two soundcards: one actual PCI card - the Audigy - and onboard Realtek sound as well. No matter what I do with Windows, I can't get the audio from the 246T coming into the Realtek to be recorded with Windows Media Encoder even when I choose the correct "pin" assignment and make the Realtek the default audio device.

Ugh... after all these years, still these stupid limitations of computers. I do have a laptop here with a mic input, I was going to do the audio on that this morning and then try to mark the time using SoundForge so I know precisely where to match up the audio stream with the video stream from the video encoding. We'll see if I can manage that, and if I'm able to make it happen, then I can provide actual video footage with the audio component so you can see (and hear) what I'm having issues with.

I guess in the long run it's not that big of a deal for most of us. Sometimes the RID change is instant, regardless of who's talking to whom. I've had instances where DISPATCH was talking to a given unit and every time either side keys up, the RID changes to reflect who's actually talking - that's how I thought all this would work in the first place, but apparently it does, sometimes, and most times it doesn't. Weird...

I'll do what I can to get a video (which is easy) with audio (that's the tough part) this morning so you all have something to see.

 

[br0adband]

w00t!!! I got it working, I got it working... and it does, finally. So yeah, I'll be able to record the entire roll call/radio check thing this morning (at least one channel at at time), and I even have the actual 246T display overlaid on top of Unitrunker so you can see exactly what it's tuned to as well. Here's a sample clip of what I mean:

http://members.cox.net/br0adband/Test.wmv (438KB - 1 min 14 seconds)

Took me long enough to get the damned thing working right but, there it is. So... And wow... does this make catching RIDs so much easier, good lord. Already added like 75 of 'em just from a 10 minute recording I made. w00t!!! Highly recommended for gathering RIDs and whatever if you're serious about this. I can provide instructions for setting all this up the way I've got it working now if anyone is interested.

 

[br0adband]

Ok, there are more channels to check in on but this is the primary channel roll call/radio check done this morning. I haven't matched the tags just yet so Unitrunker lists the channel that I'll be holding on as LVFD 1 E Zone 1; the 246T equivalent is Las Vegas FD E Zone 1 Ch 1 so you can keep track.

http://members.cox.net/bbzghost/East_Zone_1_Ch_1.wmv (4.19MB - 10 mins 16 seconds)

The RID for that Dispatcher is 44158, as noted throughout the video, but you can see at :47 that Dispatch calls for Mobile 201 - Mobile 201 responds, but the RID doesn't change. However, as soon as the Dispatcher speaks again at about :51 note the RID changes to 44102. That's the part that's confusing me somewhat, as there is a really long hangtime on that particular transmission, nearly 6 seconds for it to release at :57. I've got 44102 as a DISPATCH RID already sooo... hmmm.

Yeah, I'm nitpicking somewhat. And there are times where no response is heard and I'm not sure why. Multiple sites, perhaps, and I'm not picking up the replies, or... ? I really don't know since this city is fairly well blanketed with coverage - surrounded by mountains on all sides and the towers are mounted all around us on those peaks.

It works, don't get me wrong, I'd just like to learn more about trunking systems and the who-what-when-why-where sorta stuff. Fascinating, to say the least... and yes I did gather a bunch of new RIDs just from this one recording, so now that this "system" of audio/video recording works, I fully expect the number of properly ID'ed units to skyrocket here shortly.

Thanks...

ps
After watching it a few more times it seems that the Dispatcher's RID fluctuates between 44102 and 44158 at several points; same Dispatcher but the RID kept switching around. Anyone able to explain that so it makes more sense?

 

[SCPD]

this is the primary channel roll call/radio check done this morning.

I'm so sorry you have to go through this hassle. The History tab in the new program will make short work of this.

After watching it a few more times it seems that the Dispatcher's RID fluctuates between 44102 and 44158 at several points; same Dispatcher but the RID kept switching around. Anyone able to explain that so it makes more sense?

Something's not right. I also see 44158 appear on other calls. If you think you can re-produce this with logging turned on, please send me a log - with or without video.