Phase 1 and Phase 2

[Air490]

Can someone please explain the difference between APCO 25 Phase 1 and Phase 2.

Thanks

 

[SCPD]

Phase 1 is a narrow band FM signal called "C4FM" that fits in a 12.5 khz spaced channel.

Phase 2 includes several proposed methods for improving bandwidth efficiency over phase 1. The most common is CQPSK - the signal is very similar to C4FM but fits inside a 6.25 khz spaced channel. There are other proposals including TDMA but CQPSK is the only form of Phase II actually implemented out in the field (that I know of).

If your FCC license resides in a portion of the RF spectrum that is expected to be re-farmed or re-spaced to 6.25 khz wide channels then you want Phase 2, otherwise you can get by with Phase I equipment.

-rick

 

[N_Jay]

Phase 1 is a narrow band FM signal called "C4FM" that fits in a 12.5 khz spaced channel.

Phase 2 includes several proposed methods for improving bandwidth efficiency over phase 1. The most common is CQPSK - the signal is very similar to C4FM but fits inside a 6.25 khz spaced channel. There are other proposals including TDMA but CQPSK is the only form of Phase II actually implemented out in the field (that I know of).

If your FCC license resides in a portion of the RF spectrum that is expected to be re-farmed or re-spaced to 6.25 khz wide channels then you want Phase 2, otherwise you can get by with Phase I equipment.

-rick

Most of tghe Phase 2 standrds (mostly concerned with teh TDMA solution) are not even finished.

I do not know of any 6.25 FDMA solutions on the market.

CQPSK is used to enhance the separation of simulcast site at 12.5 kHz.

 

[UPMan]

Just to add another $.02:

CQPSK is not exclusively (or even definitely in) Phase II. It is in the Phase I specification. Early reports incorrectly called CQPSK Phase II, a mistake that lives on...

 

[SCPD]

I do not know of any 6.25 FDMA solutions on the market.

You must be right ... I just looked ... I can't find any. The radios say CQPSK compatible but the TX specs say 12.5 khz BW.

CQPSK is used to enhance the separation of simulcast site at 12.5 kHz.

According to this Aeroflex document ... CQPSK fits in a 6.25 khz channel. It also mentions "LSM" which appears to be designed for simulcast as is 12.5 khz wide.

http://www.aeroflex.com/products/commtest/pmr/appnotes/lsm.pdf

So now I'm wondering if Motorola's Intellirepeaters are CQPSK or this wide "LSM" format. Hmm ...

-rick

 

[chrisjz]

Out of the radio business. Deleted...

 

[N_Jay]

M/A-COM OpenSky is currently the only APCO 25 Phase-II compliant system available on the market.

http://www.opensky.com/

Whoa!!!!! :x :x :x

M/A-COM OpenSky is NOT P25 (Phase 1 or 2) :evil: :evil:

Might be nice if the standards went that way, but as far as I know, it has not even been submitted for consideration. :wink:

 

[loumaag]

M/A-COM OpenSky is currently the only APCO 25 Phase-II compliant system available on the market.

Consider the following in regard to OpenSky:
1. A propriatary radio solution, not an open standard as demanded by APCO Project 25.
2. OpenSky uses the AMBE vocoder not the IMBE specified by P25.
3. No where on the M/A-COM site, on the provided a link, is a claim made thet OpenSky is APCO-25 compatible.

Just where do you get this idea? :?

 

[safetyobc]

I have a question about phase 1 and 2. Will the new BCD396T be able to track phase II if it is put in place in my area. My area is going digital at the end of 2005 or 2006. I plan on getting the 396. I have seen some scanners say phase 1 only?

 

[AZScanner]

I have a question about phase 1 and 2. Will the new BCD346T be able to track phase II if it is put in place in my area. My area is going digital at the end of 2005 or 2006. I plan on getting the 346. I have seen some scanners say phase 1 only?

I assume you mean 396....

The answer is maybe. Sorry, but until one actually is installed somewhere and people can try it, there's no way to know. It's kinda like faster-than-light travel. Some say it can be done, others say no, but until someone actually attempts it, we'll never know.

I have both a PRO-96 and a 796D that, in theory, might also work on a Phase II system, because it can decode CQPSK and accepts 6.25KHz channel spacing (that is, IF the finished Phase II standard calls for CQPSK and not TDMA!). But, since there are no true Phase 2 systems in use yet, no one knows for sure. Kinda hard to sell a "Phase II" compliant scanner when the standard has not even been completed yet!

-AZ

 

[safetyobc]

i agree you couldn't sell the scanner. But is there a way to update the scanner with a download that would keep it current so we could get at least for a couple of years of use out of it before it is outdated. It is going to get expensive for us po folk to keep up.

 

[crayon]

M/A-COM OpenSky is currently the only APCO 25 Phase-II compliant system available on the market.

Holy smokes!
They torpedoed ya on that one .. now tell 'em your working on a scanner that does Provoice and see if that ship still floats.

 

[N_Jay]

i agree you couldn't sell the scanner. But is there a way to update the scanner with a download that would keep it current so we could get at least for a couple of years of use out of it before it is outdated. It is going to get expensive for us po folk to keep up.

This method would be even more expensive, as they would have build in a lot of hardware and extra procesing power, since they would not know what job it would need to do when the standard cames out.

THEN, they could still be wrong and it would all go to waste!

 

[SCPD]

This method would be even more expensive, as they would have build in a lot of hardware and extra procesing power, since they would not know what job it would need to do when the standard cames out.

Actually ... for receivers that support multiple modes ... like AM, wide-FM, narrow FM, USB, LSW ... this could result in a design simplication and cost savings in production. They'd have to make some assumptions or compromises in terms of maximum bandwidth of the type of signal to receive.

Instead of having an AM detector, narrow and wide FM discriminators, and SBB detectors ... all of this circuitry could be replaced with a IQ receiver that down-converts to baseband plus a pair of A/D converters to feed the raw "I" and "Q" signals in digital form into a small processor. From that point on its just a matter of having the right firmware running inside the radio.

-rick

 

[N_Jay]

This method would be even more expensive, as they would have build in a lot of hardware and extra procesing power, since they would not know what job it would need to do when the standard cames out.

Actually ... for receivers that support multiple modes ... like AM, wide-FM, narrow FM, USB, LSW ... this could result in a design simplication and cost savings in production. They'd have to make some assumptions or compromises in terms of maximum bandwidth of the type of signal to receive.

Instead of having an AM detector, narrow and wide FM discriminators, and SBB detectors ... all of this circuitry could be replaced with a IQ receiver that down-converts to baseband plus a pair of A/D converters to feed the raw "I" and "Q" signals in digital form into a small processor. From that point on its just a matter of having the right firmware running inside the radio.

-rick

Today they don't have all these circuits UNLESS that is the least expensive wauy to do the job.

The circuits there are designed to do the job in the most efficiant manner. Adding ANy costs to a product on the hope that it will meet a future undefined requirment is somthing that is rarely to NEVER done in product design.

If you have EXPERIANCE that disagrees with this, I would love to hear about it!

 

[SCPD]

Today they don't have all these circuits UNLESS that is the least expensive wauy to do the job.

Which was the case ... until a few years ago. Today, if you want a single mode (like NFM) then a simple FM discriminator will do the job. However, if you want to support multiple modes, you're better off letting a microcontroller or DSP do the work for you. Part of the "silicon economy" comes from chipsets intended for cellular phone designs.

Adding any costs to a product on the hope that it will meet a future undefined requirement is somthing that is rarely to NEVER done in product design.

Strictly speaking ... that's not true. Some devices are built using an open-ended architecture. Back in the day, higher end oscilloscopes were built around a common chassis and display tube. You make your choice of pluggable modules to get the speed and features you wanted today while having the option of upgrading to newer modules as they became available. You could save costs by eliminating the pluggable architecture but that's not what the consumer wanted.

Getting back to scanning receivers ... we've already seen the benefits of flash-programmable firmware for several radios. For (1) fixing outright bugs in the firmware and (2) adding small enhancements - like the CQPSK fix for the PRO-96. I think there are enough folks on this forum that have had some sort of experience with this type of upgrade.

It's not that big of a leap from these minor upgrades to adding an entirely new modulation or signal format - provided that the new signal fits within the bandwidth of the existing receiver design.

Some radios already incorporate an SDR (software defined radio) architecture in their design. I'm pretty sure some of the WinRadio models fit into this category. No, they aren't building them this way in anticipation of supporting future signal formats. They've chosen such a design to get the most performance at the lowest cost.

As long as the radio supports a means for firmware upgrades - there is no technical reason for not being able to do an upgrade once the new signal format is known. On marketing side, the manufacturer may prefer to just sell you a whole new radio instead of offering a software upgrade.

If you have EXPERIANCE that disagrees with this, I would love to hear about it!

The choice of supporting firmware updates has been an option available to the manufacturers for quite a few years now. Take the BC245XLT for example. That radio came out in like ... 1998? Speaking from my personal experience, if you take the radio apart ... you will find (1) an on-board flash programmable microcontroller and (2) a set of 6 gold plated contact points on the circuit board to accomodate a JTAG programming pod. In other words, this radio is re-programmable (though not easily *field* programmable - you needed a programming pod and software).

How hard would it be to make small software enhancements (like support 6.25 or 5 hkz channel spacing) on this and other older models? How hard would it be to add one of the more well know trunking protocols - like LTR or MPT1327? IIRC, this radio only supports a single base/offset of VHF/UHF Motorola trunking. How hard would it be to support at least two more base/offset entries? For the manufacturer ... all of these could be done with very little effort - with a potential for after-the-sale revenue in the form of upgrades. I think this is a feature already present in many of the radios we own ... that is getting ignored or overlooked for marketing reasons.

-rick

 

[N_Jay]

Making small improvements is very posible with any software/firmware based product.

But trying to plan enough expandabilty into a product to "flash" a yet developed protocol would be very risky.

In the end you would just as likely end up with a product carrying excessive costs that never are leveraged.

From the consumer viewpoint it is hard to uindertsand these product design issues.

As I said, "If you have EXPERIANCE that disagrees with this, I would love to hear about it!" Meaning, if YOU have any PRODUCT DESIGN/DEFINITION experiance that is different, lets hear about it.

 

[SCPD]

Before I dive in, let me say that Jay is a sharp guy that has given sound advice on this forum. Our disagreement is over some very specific details. That said, let me lay out my side of the arguement ...

But trying to plan enough expandabilty into a product to "flash" a yet developed protocol would be very risky.

Jay ... you keep harping on one point which isn't event the one I'm addressing. Okay, fine ... then let's go there. Just what exactly is the risk?

The risk ... in the case of SDR ... is likely to be in the choice of which microcontroller or signal processor that does all the dirty work.

The manufacturer does not need to intentionally design their product to accomodate every as yet unforeseen protocol that might some day come into play. What they can do is take an SDR approach which will ...

(1) give them a short term term gain by reducing costs and parts count.
(2) this same architecture is inherently adaptable & expandable so there is a good chance that future protocols can be accomodated.

For most designers, #1 is reason enough to adopt SDR. #2 might not even be a deliberate goal. In that case, the risk is ZERO but the potential that lies in #2 above remains.

Expanding on the risk issue, if the designer takes #2 into consideration, the designer can choose a DSP that is good enough for the job at hand ... or ... choose another part with a higher clock speed or more memory ... or both. To place a price tag on this future capacity, I'll suggest an extra 30 cents, maybe an extra $3. In some cases, there may be no cost savings by choosing a slower part so the designer uses a faster one.

In any case, the risk is likely to be an amount in the range of a dollar or two. Sure, in large quantities ... that adds up quick. The same arguement can be made for every component, every circuit. Are 1% tolerance resistors necessary when 5% resistors will do? ... and so on. Every design has a certain amount of "over" engineering to help insure its success. Civil engineers are fond of using more concrete and steel than is strictly necessary (unless they work for the DOT - ouch! Just kidding).

In the end you would just as likely end up with a product carrying excessive costs that never are leveraged.

What you say is generally true; common sense even. What I am pointing out here is a specific situation where costs are reduced while expandability is enhanced. The purpose of adopting SDR is cost reduction. The benefit - whether the manufacturer intends to "leverage" it or not, is a framework easily upgraded.

As I said, "If you have EXPERIANCE that disagrees with this, I would love to hear about it!" Meaning, if YOU have any PRODUCT DESIGN/DEFINITION experiance that is different, lets hear about it.

As a matter of fact, I do. Without pissing off any clients or breaking an NDA, let me say this.

In one case - the customer was driving the need to accomodate an open-ended architecture. We did so by designing around a backplane. Normal use left extra backplane slots. Software upgrades were a given, it was mainly the hardware and DSP firmware that needed provisions to support future updates.

There were some basic assumptions, that, if met would accomodate most any protocol. Those assumptions were bandwidth and DSP horsepower. The bandwidth was set by the backplane. A faster DSP could be substituted if needed. The customer understood not to expect the ability to support something like HDTV, for example. This would have exceeded the IO throughput of some parts of the system.

In other cases, the manufacturer (not the customer) wanted to simplify their product line by using one common, configurable framework. It was easier for them to have one base product with multiple configurations instead of many products ... each targeting a specific combination of features. For the customer, this has the secondary benefit of an upgrade path that does not require a complete replacement of their existing hardware.

Regards,
Rick

 

[N_Jay]

I guess you should go to work for a scanner company and "straiten then out"

(I am guessing your products were not in the consumer market)

 

[studgeman]

P25 Phase 2 is years away from approval, in fact only about 1/2 to 3/4 of Phase I is actually approved. Still work to be done there. The product that closely resembles what is in draft for phase 2 is Opensky or Tetra (perhaps iDEN). you will probably go through a couple generations of scanners before you have to worry about that.

A quick note on SDR. The discussion that is happening directly above my post is the same discussion happening all over the world. They are trying to addess the harware and software connection with standard software coding techiniques. DoD's JTRS project is one of the largest developement efforts to date. It will be interesting to see how it all plays out in the end.