Rid sort question

[dave3825]

How does the 436 look up radio id info when there is an active transmission? I am asking because the scanner is not always displaying the rid when there is an active transmission of 4 seconds or more. I am not speaking of transmissions that are 3 seconds or less.

I have 3200 rid's stored and have tried both numerically and alphabetically and don't see a difference..

Thanks


.

 

[ofd8001]

I've been watching my 536 for the past few minutes. The P25 system I monitor has some 1,200 Radio IDs stored. That's not all, just those I can relate a Unit Number to a Radio ID number.

At any rate, I'm seeing the appropriate alpha tags for radio IDs being displayed regardless of transmission duration and some of them have been lengthy.

As I understand it, the scanner receives data on the control channel. Included in this data is the voice frequency, Talkgroup ID Number and Radio ID number.

When there is a channel grant (voice transmission) the scanner looks in two places. One is the list of talkgroups you wish to monitor (assuming your are in ID Scan). The other is in the list of Radio IDs.

If the talkgroup should be monitored (as in not locked out), the scanner will tune to the appropriate voice frequency and broadcasts the audio. It will also display the talkgroup alpha tag it found in the list of TGIDs and the alpha tag associated with the Radio ID number. If there is not Radio ID alpha tag found, the scanner displays the radio ID number (in my case it is 6 digits).

 

[marksmith]

If your radio picks up a transmission in the middle, or the second user keys up before the system drops the first one, it is likely to display nothing, or continue showing the first one.

The radios do a fair job of pulling radio id's, but if you run Unitrunker at the same time you watch what a radio pulls, you will find none of the radios that display RID can do it as well as that free piece of software.

So the data is there, it's just that none of the radios can display it as efficiently as software, whether the system is digital, analog, or both.

PS - Sorting the data will make no difference. Same as sorting talkgroups. The radio gets the data from CC, and goes direct to TG or RID file records.

Mark
WS1095/536/436/996P2/HP1e/HP2e/996XT/325P2/396XT/PRO668/PSR800/PRO652

 

[tglendye]

I also think it has to do with the radio system you are monitoring. I monitor 2 different systems. On my statewide system, my 436 will miss RID's sometimes. And sometimes a RID is displayed while a user is speaking, and the ID is actually of the user transmitting prior to him/ her. My local system- from what I have seen- does not miss any ID's.

The state system is a Motorola VHF P25 Phase 1 system. My local system is an 800 ProVoice system.

 

[Jay911]

There are several reasons why you might not see a radio ID on a transmission.

The biggest issue is with analog users on Motorola Type II systems. Radio IDs are not carried over the voice channel on those systems, so once you leave the control channel to follow the voice message, you won't get any further IDs. That is why programs like Unitrunker appear to work better on that type of system - they don't ever leave the control channel. You get the first RID in a conversation from the info sent over the CC, and then, if the conversation is carried on quickly enough that you stay on the voice channel for the whole conversation (never going back to the CC), you will not get another RID.

P25 systems, unlike Mot II systems, carry the RID on the digital voice "data packet", so you will see the RID when a digital user is speaking. This also applies to digital users on a Mot II system.

I don't have any EDACS systems in my neighborhood so I can't rightly say if LIDs (logical ID, the EDACS term for a RID) are carried over the voice path.

The other issue is what someone mentioned above - coming into a conversation after it has started. This is called "late entry" and you may not get the RID (at least for the duration of the current person speaking in the conversation) showing up in this case, for the same reason - you may have gotten to the conversation too late to see the RID when it was mentioned either on the control channel or in the voice data, if the voice data supports it.

As mentioned above, the "sorting" of RIDs (or TGs, for that matter) has no bearing on the success or failure of looking up either piece of data. In a trunking environment, the TG and RID are directly provided by the control channel (or, again, voice data) and can be looked up directly, unlike an analog signal, where you only know it is, for example, 413.8375, and have to listen for a bit to determine what its squelch code (if any) is, etc.