End Code Setting?

[werinshades]

I've been trying to figure out an issue here with a P25/Phase 2 800 mhz system. On this past Tuesday, their was some modification to the consoles which made the voices very loud which isn't an issue. The one thing I've been missing is the "simulcast transmissions" that they do during an EMS or some other important incident. I recalled some years back I inadvertently made a change to my End Code settings on an older model scanner. This system is "patching" both the UHF older system and newer P25/Phase 2 800 Mhz system.

My search has me looking for the End Code setting which I could not find in Sentinel or Pro Scan. However, I was able to find it in an older ARC 536 version and I made the change and uploaded to the scanner. Where is it hiding ? I'm still waiting to see if this did the trick, but if it did any changes I make via ARC, then upload from Sentinel, I'll have to go back to ARC to change the End Code?

 

[UPMan]

It is a system option for Motorola systems. It is not an option for P25.

 

[werinshades]

It is a system option for Motorola systems. It is not an option for P25.

Glad I'm not crazy then...well, maybe a little. Is there a reason for this or any possibility to add it later? I don't know if this resolved the issue yet, but if I had the option it might be a good idea? If I'm uploading from ARC to the scanner, is there a change taking place or is it defaulting back to Ignore?

 

[UPMan]

There is really no good reason to turn off End Code detect. I was never really clear on why the option to turn it off is available at all.

 

[werinshades]

There is really no good reason to turn off End Code detect. I was never really clear on why the option to turn it off is available at all.

I think in P25/Phase 2 systems it defaults to Ignore. I originally programmed this system via Sentinel, but when I uploaded it to ARC, it showed as Ignore under the System setting. I changed to to Analog & Digital, put the system in ID Search mode in the event they changed the Talk group, then uploaded it back to the scanner. I have it recording too.

 

[UPMan]

It doesn't default to anything. There is no such setting. ARC provides the option but it only actually applies the option to system types that support it. On the one hand, it simplifies the user interface of ARC, but on the other hand, it can cause confusion just like this.

 

[werinshades]

It doesn't default to anything. There is no such setting. ARC provides the option but it only actually applies the option to system types that support it. On the one hand, it simplifies the user interface of ARC, but on the other hand, it can cause confusion just like this.

Still some confusion, but my understanding now is their is no End Code Setting in Phase2/P25 systems. What brought me here was I no longer can monitor their simulcast transmissions. No other issue with decoding etc. I remembered about the End Code setting I think in the 796D and simulcasts. I'm baffled as to what changed and even put the scanner in ID Search mode to see if they reconfigured the talk groups when they simulcasted. So far, that's not it either but thanks for the explanation. I have determined by using three different scanners that the dispatch is no longer transmitting a Radio ID.

 

[Ubbe]

It's always a radio id involved to be able to set parameters and to properly log calls and much more.
Even with patched systems the patch in itself must have an ID in both systems.

/Ubbe

 

[jonwienke]

Radio ID is mandatory to keep unauthorized radios off the system.

 

[kruser]

Radio ID is mandatory to keep unauthorized radios off the system.

Two of the sites here do not use RIDs on the TG setup for Point to Point. There is a patch radio setup on the sites that allows the many users without P25 radios to get on the system for the old analog Point to Point comms.
The patch does use a talkgroup of course and if a P25 user responds to an analog user, their radios do show their RID but the analog VHF users show a blank RID.
When you see the blank UIDs, you can hear them on the old VHF 155.370 analog frequency with an old crystal scanner if you wish. This is used very often here.
If they could ever get everyone on digital radios, this analog patch would go away

 

[jonwienke]

The patch has an ID on the P25 side, even if the radios on the analog side of the patch don't.

 

[troymail]

Patches are "exceptions" to support legacy radios/systems. I'll see the "patch" radio Id as a zero, or sometimes a "fixed" id regardless of the radio talking "in" via the patch.

Sounds like if the system/site in question recently switched to simulcast (and/or you haven't experienced that type of system before) -- you've been entered into simulcast hell with the rest of us.

EDIT: Also - with your 536, you can receive simulcast systems perfectly clear one day and it goes to hell the next...

 

[kruser]

The patch has an ID on the P25 side, even if the radios on the analog side of the patch don't.

Even when watching the CC with Pro96com, there is no UID or RID when this patch is used.
I know this is different than how patches are done on most P25 systems. I'm just saying it is possible it can be done with no RID.
I doubt they can keep rogue radios off this TG when going in through the analog patch. Someone would need to take down the patch radio if someone were to get on the system with ill intents.

And yes, these pure analog patches sound like crud compared to those using digital on the patch.

If you are monitoring the P25 voice channels with something like an Icom R8600, it will show the TG when the patch TG comes alive but the RID info will never populate with any info for true analog users.
The analog receivers setup at each site do not transmit 45 MHz lower, they seem to be hardwired into the controllers at each site.
For those going into this TG that are digital users, they can be heard on the input frequency 45 MHz lower and they do show a RID. Analog users can only be heard in analog and on 155.370 but are simulcast in P25 so all agencies can hear. Same goes for the P25 users, their chatter is simulcast from an analog transmitter on 155.370 so the areas with analog only can hear.

edit: I've also seen some smarts in use on this patch. Not sure how it works but there are times where a P25 user will call another P25 user and the analog patch radio is not keyed up. If that same user needs to make a broadcast that everyone, analog and digital, needs to hear, then the analog radio is keyed up. I have no idea how this works but it almost has to be at the users discretion. I could see this causing problems if everyone should hear an areawide bolo for example and the initiator of the broadcast does not tell it to broadcast to analog users.
Maybe by default, it broadcasts to all unless the originator hits a button to select digital users only.
Now sure why they need this but I've heard it many times where there will not be an analog broadcast.

 

[werinshades]

It's always a radio id involved to be able to set parameters and to properly log calls and much more.
Even with patched systems the patch in itself must have an ID in both systems.

/Ubbe

Radio ID is mandatory to keep unauthorized radios off the system.

The patch has an ID on the P25 side, even if the radios on the analog side of the patch don't.

Patches are "exceptions" to support legacy radios/systems. I'll see the "patch" radio Id as a zero, or sometimes a "fixed" id regardless of the radio talking "in" via the patch.

Sounds like if the system/site in question recently switched to simulcast (and/or you haven't experienced that type of system before) -- you've been entered into simulcast hell with the rest of us.

EDIT: Also - with your 536, you can receive simulcast systems perfectly clear one day and it goes to hell the next...

I would agree with all of you normally, however I've been monitoring this system since it was a newborn 5 months ago. The 2 systems in question are a legacy UHF-T Digital System and a young whipper snapper P25/Phase 2 800 Mhz digital system. Before Tuesday, the Dispatch side was transmitting Radio ID's. Tuesday morning, they "modified" the consoles and not only did the ID's stop transmitting on the dispatch side, but the audio was increased and they're now louder than the mobiles and portables.

My 536 is my primary scanner for this system and noticed I wasn't seeing their Radio ID anymore. I checked my 436 and the same result. I also have this system in my TRX-2 as back up and if you're familiar with the display, when the dispatch transmits, in place of the Radio ID on the bottom the frequencies display. Control channel followed by Voice Channel. I've never seen this behavior before on the system prior to Tuesday.

My thought was possibly an End Code setting which brought me to this post. Prior to Tuesday when an "event" occurred, the dispatch would make an announcement which went across a few talk groups. That I haven't heard since Tuesday. So I suspect this is all related.

The system is tracking great, as i'm only a few blocks away, so range is not an issue.

 

[jonwienke]

Does P25 have anything equivalent to RAS? If so, that could interfere with a scanner seeing the radio ID.

 

[werinshades]

Problem Solved!

After all this "discovery" I spoke a user of the system who tells me they haven't heard the Multi-Select broadcasts (Simulcast) either. The dispatch was wondering why no one was acknowledging these transmissions as per their protocol, but must not have thought to investigate.

I just got a call from the user who told me the dispatch just attempted a Multi-Select Dispatch (Simulcast) and have confirmed their is an issue. You see, scanner geeks can play a productive role if we're allowed to and not shut us out with encryption.

Now that they "officially" know they have a problem, let the techs do their job. Ok. I'm done! (Mic drop!!)