N_Jay said:
So when another P25 document is finished (there are many in process) like the ISSI, then all the P25 systems in existence that don't has standardised ISSI will immediately stop being P25 systems? :roll: :roll: :roll:
Let me ask;
"Does a P25 System that does not include data services not qualify as a P25 system?"
"Must a P25 system implement encryption since it is in the standard?"
"Must an encrypted system support OTAR?"
This is a building block set of standards, not a monolithic standard. :wink:
All of what you mentioned are options that may or may not be used.
If it uses a control channel for a trunked system - it must be 9600 to be compliant.
Ever wonder why there are no 3600 ASTRO 25 systems? It's because to meet the '25' part, they need to use a 9600 control channel. That's why the other systems are not advertized as ASTRO 25, but just ASTRO. The 25 means that they FULLY meet APCO P-25 standards.
Let me ask you a question: If a system uses a 9600 CC and analog voice (I know there aren't any, but humor me), is it a P25 system because it does meet some of the P25 criteria? Would the committee say "Well, OK, you met some of our standards, so we will accept that you fully comply even though you clearly don't"?
NO - ANY of the options they choose to use must be compliant with P25 standards. That's why conventional systems are P25 compliant even though they don't use a 9600 control channel (or any control channel for that matter). If you use a control channel, it must be P25 compliant to maintain the system as being P25 compliant.
The P25 standard does allow for some custom options, but the control channel format is clearly spelled out. They were going to adopt 3600 for control channels, but they didn't. When they finalize and adopt Phase II, any existing systems will be P-25 phase I compliant, but NOT P25 Phase II compliant. Scanners will have to then add the Phase II specs to continue to be able to follow all P25 systems.
Joe M.