Batboard

We sold some xts3000 and xts3500s a while back, and put some astro channels in them. Now the customer has bought some xts5000s with astro 25. Can someone tell me if they'll be compatible with the existing radios, and just what is the difference between astro and astro 25?

Astro = VSELP vocoder
Astro25 = IMBE [i.e. P25]

xmo wrote:Astro = VSELP vocoder
Astro25 = IMBE [i.e. P25]

I thought ASTRO25 was their branding for the P25 trunking solution (9600bps control).

tvsjr wrote:I thought ASTRO25 was their branding for the P25 trunking solution (9600bps control).

Me too

jackhackett wrote:We sold some xts3000 and xts3500s a while back, and put some astro channels in them. Now the customer has bought some xts5000s with astro 25. Can someone tell me if they'll be compatible with the existing radios, and just what is the difference between astro and astro 25?

I presume you're running on a trunked system? Probably a Moto Type II (3600bps control) with ASTRO digital voice?

Yes, the ASTRO25 radios should work (you'll have to set the trunking type to Type II, not ASTRO25). Be aware that the XTS5000 *requires* affiliation, even on a Type II/3600bps system.

tvsjr wrote:

xmo wrote:Astro = VSELP vocoder
Astro25 = IMBE [i.e. P25]

I thought ASTRO25 was their branding for the P25 trunking solution (9600bps control).

APCO 25 specifies the IMBE Vocoder as well as the 9600 baudrate, both of which ASTRO25 uses. But, as tvsjr noted, the XTS-5000's are backwards compatible with Type II

[quote="tvsjr"]
I presume you're running on a trunked system? Probably a Moto Type II (3600bps control) with ASTRO digital voice?

Yes, the ASTRO25 radios should work (you'll have to set the trunking type to Type II, not ASTRO25). Be aware that the XTS5000 *requires* affiliation, even on a Type II/3600bps system.[/quote]

Actually they're not trunking, all conventional, some simplex, one repeated.
They have voice type set to Astro.
I'm not the one doing the actual programming, kind of acting as a middle man.. the question came up and I figured if anyone would know you guys would.

It won't matter, then. In conventional mode, having ASTRO25 in the flashcode is meaningless. Should work perfectly (assuming they're running the IMBE vocoder - don't think they made XTS3500s in VSELP).

Ok, thanks.. got some programmed, working fine.

ASTRO means the radio is either VSELP or IMBE capable or equipped.

Take a look at the control head on an ASTRO Spectra. Notice it says "ASTRO." Same thing for an ASTRO Saber, XTS-3000, and XTS-5000. They ALL have "ASTRO" painted on their control head, or on their case (involves an "ASTRO" escutcheon on the portables). It has nothing to do with being VSELP, as it simply means digital as opposed to analog.

ASTRO 25 is IMBE, by definition, since VSELP was long since discontinued when ASTRO 25 was introduced. Also, ASTRO 25 entails 9600 baud.

Hope this helps.

ASTROMODAT wrote:Also, ASTRO 25 entails 9600 baud.

I've said it before, and should the mistake continue to be made, I shall say it again.

P25 is NOT, I repeat NOT, 9600 *baud*.

It is 4800 baud (4800 symbols/second), at 2 bits per symbol.

Please, *don't* perpetuate this error.

If you want to say that P25 is 9600bps, I shan't say a word.

But it IS NOT 9600 baud.

This may seem very nit-picky to you, but it really DOES cause us problems!

Motorola calls it 9600 baud. Perception IS reality. Sorry to burst your bubble...

ASTROMODAT wrote:Motorola calls it 9600 baud. Perception IS reality. Sorry to burst your bubble...

Show me one link from Motorola where they call it 9600 BAUD, not 9600 bps.

Yes, the data links from the radios to external devices may be 9600 baud as they are 2 level RS-232 (and thus 1 bit per symbol), but show me one link that describes the air interface as 9600 baud.

Sorry, but if everybody perceives the world as flat, that does not change the fact that it is round - and if you look up the definition of BAUD and the definition of the APCO-25 air interface standard you will see that it is 4800 baud.

Well, think about it --

Motorola probably calls it baud since most people in this world have modems, and they can relate baud to data and speed. However, most people when you go, it's 9600bps, then, well, what is bps....

I bet it's simply refered to as baud in their sales literature, however, I'd be inclined to go with the person who works hand in hand with a publicly avaliable service monitor that is ment to work with this stuff - i'm sure he knows more about some of the aspects of using the protocol than some of us will ever be in our lifetimes.

Not saying one of you is more correct than the other, just saying I'd be more inclined to agree with Wowbagger based on his experience on the raw technicality of it all.

-Alex

Agreement should be based on the fact that the original poster is using a word incorrectly. The bad part is, even the dictionaries are starting to get it wrong.

<rant type="religious">
One baud is, always has, and always will be the number of state- or level-transitions per second. Baud == bps if and only if the signalling method being used is two-level modulation with no framing or stop bits.

P25, in it's 4-level FSK implementation (C4FM), uses a 4800-baud transmission rate. 4800 times a second, the levels change. There are combinations of levels to form 00, 01, 10, 11 (sometimes referred to as dibits, especially in things like the FLEX implementation). Hence, 2 bits are delivered every 1/4800 sec., for 9600 bits per second.

It may seem like haggling over nothing to some people, but for us engineering types, it makes a lot of difference. And, yes, it's a confusion that makes me cringe!
</rant>

It gets even worse when you factor in the confusion Motorola has created by using "Astro" to mean several different things:

Smartnet/Smartzone with 3600 baud control channel (and 3600 bps as well - 2 level signaling) and NBFM analog traffic channels.

Smartnet/Smartzone with 3600 baud control channels and (IIRC) 7200 baud 2 level signaling VSELP digital voice channels (I am not as familiar with this mode as we don't do it (too much $$$$$ from Motorola for the licenses) and I may be getting the specifics wrong.)

Smartnet/Smartzone with 3600 baud control channel and P25 CAI (4800 baud 4 level IMBE) digital traffic channels.

Full-boat APCO-25 trunking with 4800 baud 4 level control channel and 4800 baud 4 level traffic channel.

Now, somebody calls us and wants an "Astro" test solution. Try to figure out what he needs - does he need APCO-25 trunking, Smartnet, or both? Sometimes the only thing you can go on is when he says "Naw, it's Astro - with a 9600 baud control channel" and then you can say to yourself "OK, he's full APCO-25 and just doesn't know it."

But %DEITY% help you if you guess wrong, and he has to buy another option! "You ripped me off! You are trying to screw me!" (never mind that all he needs to do is apply the option file and it will switch off the one option and switch the other on, and he wasn't down for weeks while he ships his unit back in....)

And *thats* why I get fussy over the terminology used.

The solution: When a customer asks for ASTRO test capabilities, give 'em ALL of the digital options in the Motorola kitchen, since the customer may have several ASTRO implementations, and he may change/expand his system(s) later, etc. Don't short change the customer.

Just some friendly advice...

ASTROMODAT wrote:The solution: When a customer asks for ASTRO test capabilities, give 'em ALL of the digital options in the Motorola kitchen, since the customer may have several ASTRO implementations, and he may change/expand his system(s) later, etc. Don't short change the customer.

Just some friendly advice...

Since those options are a per-option cost, I don't think most customers would like that. And no, I have no problem with the per-option cost... gotta pay people like Wowbagger to build the stuff in its various permutations.

"Motorola calls it 9600 baud. Perception IS reality. Sorry to burst your bubble"

You're wrong. Wowbagger is correct. As a trained Network/Comms engineer, I know the difference - baud is signaling rate, which is entirely different from bits per second (or throughput)

tvsjr wrote:

ASTROMODAT wrote:The solution: When a customer asks for ASTRO test capabilities, give 'em ALL of the digital options in the Motorola kitchen, since the customer may have several ASTRO implementations, and he may change/expand his system(s) later, etc. Don't short change the customer.

Just some friendly advice...

Since those options are a per-option cost, I don't think most customers would like that. And no, I have no problem with the per-option cost... gotta pay people like Wowbagger to build the stuff in its various permutations.

Not just that - some options cost US in license fees (or rather, they cost the customer but we have to collect them) - so if we give you the ASN Keyfill option, you have to pay Motorola for that option, so we have to charge you.

Astromodat - if we were to enable all options, that would raise the cost of the box to about US$80K - and then folks like you will :o about the cost.

Even if we use the time-limited options mode - give you everything for N weeks then make you buy what you need - then folks like you :o about "taking away" "your" options (nevermind that you haven't paid for them).

tvsjr - thanks for understanding the nature of the business.

"...Show me one link from Motorola where they call it 9600 BAUD, not 9600 bps...."
__________________________________________________________

They use "9600 Baud" everywhere. For example, the XTS price pages say: "ENH: SOFTWARE, TRUNKING, 9600 BAUD, Q574, $XXXX.XX" and "Software package includes: 9600 Baud, Wide Area Smartzone, Astro Digital CAI, and PTT-ID Display"

Service manual example: 6881095C21. "This upgrade allows the existing Astro Digital Spectra mobile radio to be upgraded to the Astro Digital Spectra Plus mobile radio, which enables the 9600-baud feature set of P25 trunking systems."

You're fighting a loosing battle. I don't disagree with the accuracy of your interpretation - but if we are going to nitpick the accuracy of the use of industry standard terminology - how about the term "NORMALIZE" ???

Ooh, another religious war. Cool!

I'll toss my definition in the ring... normalization is a process you perform on a database schema to make it compliant with the various normal forms.

Regardless what Mother says, they're still wrong...

Mixing up of baud/bps is not nitpicking - it's a very serious error. It's like confusing miles and pounds.

"...It's like confusing miles and pounds..."
____________________________________

More like miles and mile markers. If the mile markers are placed every mile then miles = mile markers just as bps = baud in two-level formats, whereas if mile markers are placed at some other increment you can count the markers but you don't know how many miles you have gone unless you know the increment [obviously in the real world we read the numbers].

Just like 4800 baud doesn't tell you the bps by itself but 4800 baud P25 tells you 9600 bps by definition because it is a defined four level protocol.

OK, so Motorola marcomms gets it wrong. While that may excuse people making the mistake, it does not change the fact that it is a mistake.

Nor does the assertion that "it's a losing battle, why fight it?" justify accepting the situation - after all, there will always be crime, it's a losing battle, why fight it, right?

Wrong.

It is precisely because so many people get it wrong that it is important to correct it where-ever possible.

Just as I will correct somebody for the standard /. "loosing/losing" confusion.

"...it's a losing battle, why fight it, right?..."
__________________________________

Now if NORMALIZE just worked on a 2975 like it does on test equipment from HP, Agilent, Advantest, Anritsu,etc. .....

xmo wrote: Now if NORMALIZE just worked on a 2975 like it does on test equipment from HP, Agilent, Advantest, Anritsu,etc. .....

OK, so - define how we are different.

When making a stimulus-response measurement - such as a transmission measurement of a filter device or a return loss measurement with a directional coupler or bridge - the user is interested in the response characteristics of the Device Under Test [DUT]. A spectrum analyzer tracking generator combination displays an absolute amplitude trace representation of the complete measurement system including the display amplitude uncertainty and generator unflatness, cable and adapter losses, etc. as well as the contribution of the DUT.

Normalization is an instrument feature which allows the system frequency response to be stored and subtracted from the test result data - thereby providing a trace containing only the contribution of the DUT, i.e. a "Normalized" or relative trace. Markers applied to this trace data display relative readings rather than absolute readings so that you have an exact insertion loss [or gain if applicable] at any trace point without the user doing the math.

This feature has been available in many manufacturer's equipment for at least 30 years or so in such instruments as the Tek 492 [option 2] + TR503, HP 853A/8558B/8444A, HP 8755S frequency response system with 8750A Storage Normalizer, HP 8920 series RF Communications Test Sets, Advantest R4131, Agilent ESA, etc.....

As far as I can tell you can't normalize a swept response test on the 2975 - the manual simply advises you to adjust the generator amplitude until the trace is at the top of the screen - not the same thing at all.

There is a "Normalize" soft key on the 2975 but what it appears to do is an internal spectrum analyzer self calibration.

That's my point about being accurate with terminology. If a button does a 'self-cal' then call it that. If you have a button that says: "Normalize" it ought to do the same thing that "Normalize" has been doing as an industry standard.

Allow me to address your points in reverse order:

As to the "normalize" vs. "self cal" terminology - I personally agree, but there is a problem with some shops: if you use the "C" word (calibration) they get all funny in the head - they treat anything with the "C" word associated with it like a full-blown, NIST traceable, paperwork required in quadruplicate, send it in to the factory and put a cal sticker on it calibration. They insist that "We don't want our techs doing calibrations! We only want our Metrology staff doing calibrations!"

So we avoid using that term for things where we are performing an internal check.

As to the first issue - what you are wanting is relative measurements - you want to be able to take a snapshot of the system without the DUT, then say "call that reference", and then make measurements relative that. That was in my design plan for the project, but I was never given the time/resources to complete that. Believe me, there are a LOT of features I had called out in the engineering plan that have not been implemented because, while *I* think they are important, the Marketing manager does not - and guess who sets the priorities.

All I can say is, write Aeroflex and complain (nicely!) - tell the sales reps why you want these features. Then, when they come back to me and say "We have this new requirement!" I can bring up the bugs that have been in the tracking system for years and say "No, this is NOT a *new* requirement - I told you we needed to do this from day ONE, but *you* didn't listen to me. Now, here's the time/manpower estimates for that."

Believe me, there's a lot of things I feel are missing - remember, "I'm not just the designer, I'm also a client" to paraphrase the Hairclub for Men ads - I do use the gear to service radios, and things like the relative measurements, offset tracking generator, and split-screen analyzer that the COM-120B has that the 2975 does not were NOT oversights on my part - I had them spec'ed in from the beginning. But the Power That Be set the priorities, and making features like that work (i.e. doing the low level code, defining the remote command set for them, proving that works, designing the user interface for them, making sure that works, designing the test plan for them, making sure that works, ....) takes time - and if the PtB don't let me have the time, they don't get done.