Can SmartZone IMBE be monitored via P25 conventional?

[Elroy Jetson]

There's a UHF low band Astro Smartzone near me. I don't have a radio that can be programmed to monitor that system in trunking mode (and it would be risky even
if I could) but I do have a UHF low split XTS5000 that has P25 conventional operation in it.

The system I want to listen to is really not very active. I think that if it could be monitored by this XTS5000 by just scanning it and decoding the IMBE/P25 voice information,
it would suffice for scanning purposes.


Does anyone know if this will work, and if so, are there any special configuration tricks I need to use?


Elroy

[d119]

Just program in the voice channels as ASTRO Conventional channels, set the NAC to 293 and set the personality to Digital CSQ and enjoy. If it's UHF-Low (G-Band) SmartZone, don't cry if it turns out that most/all of it is encrypted.

Additionally, you'll want to set your scan hang time to 0 seconds, and make sure you have priority scan turned off.

[Elroy Jetson]

Yep, it works. I tried that but heard nothing. It turns out that the system is just used so little that it can go HOURS without ANY activity.

I may need to tweak the hang time, etc. but I'm hearing voices. Good enough!


Elroy

[d119]

You'll want the scan hang time set to zero so that when the repeater hang time runs out and the system assigns an in-progress call to another voice channel, the radio will immediately switch to it instead of sitting there waiting for a reply on that channel until the scan hang time runs out.

Just create another scanlist and put all of the voice channels in that one scanlist so that you can configure the scan hang time properly and not affect any of your other personalities in the radio, and any of your other scanlists.

I've never actually set a radio up like this, I just took a wild guess at it but you said it works, so I'm glad my theory was correct.

[Tom in D.C.]

I monitor the DC MPD on 460 mHz by simply scanning its eight or so P25
channels. For whatever reason the back-and-forth on short exchanges
seems to stay on the same channel, which makes it a lot easier to follow
what's going on. This is a 460/800 mHz simultaneous trunked digital system
with no dispatch encryption. It works fine, though not nearly as well as
a setup where you're monitoring the actual trunked system with a trunking
scanner, for instance.

[Wowbagger]

For whatever reason the back-and-forth on short exchanges
seems to stay on the same channel, which makes it a lot easier to follow
what's going on.

That's by design: in P25 (and in Smartzone as well) there is a hang time when the transmitting radio has unkeyed during which the system will leave the resources associated with the call allocated (allocating the resources is expensive). If another radio in the same talk group keys up, the system can immediately hand the call off to the already allocated traffic channel, rather than having to spend time re-allocating a channel.

[immelmen28]

For whatever reason the back-and-forth on short exchanges
seems to stay on the same channel, which makes it a lot easier to follow
what's going on.

If I recall correctly, I think this is referred to as the "Conversation Type" in CPS. "Transmission" drops the channel immediately upon end of transmission. "Message", and "PTT-ID" conversation types provide for a hang time where another user can reply within a set time without releasing the channel(PTT-ID also requires Subscriber authentication to hold the channel for the TG).

MPDC's UHF system uses the PTT-ID conversation type.

[d119]

For whatever reason the back-and-forth on short exchanges
seems to stay on the same channel, which makes it a lot easier to follow
what's going on.

If I recall correctly, I think this is referred to as the "Conversation Type" in CPS. "Transmission" drops the channel immediately upon end of transmission. "Message", and "PTT-ID" conversation types provide for a hang time where another user can reply within a set time without releasing the channel(PTT-ID also requires Subscriber authentication to hold the channel for the TG).

MPDC's UHF system uses the PTT-ID conversation type.

PTT-ID is what a majority of systems use because it requires that the subscriber send it's PTT ID every time it keys up. This allows dispatchers to see which unit is talking "on-the-fly", whereas Message type trunking uses the PTT ID of the initiating radio so long as the resources allocated to the call (voice-channel) remain up (hang time).

From the CPS Help Screen:

Message: After the initiator dekeys the radio, the voice channel stays active (hang time) so other members of the talk-group can respond on the same channel. If a radio in the talkgroup transmits during another user's transmission, it will talk over the other transmission.

Transmission: No hang time and no talk over. When a radio is dekeyed, the channel is immediately deallocated and reassigned. If a user tries to talk over an active channel, the radio will not key until the channel is clear.

PTT ID: PTT-ID systems are similar to Message conversation type.

Obviously this doesn't say much about PTT-ID, and the author of the help file evidently didn't know much about it, but see my comments on PTT-ID vs. Message above. I'm 99.9% sure that Message trunking and PTT-ID differ only in the fact that Message trunking does not require the subscriber to re-send it's PTT-ID each transmission unless it's the initiating radio on a new voice channel. This is undesirable for console equipped systems as you cannot reliably tell who's talking.

[RKG]

In its day, Message Trunking (and today, PTT-ID Trunking) is considered the norm for public safety, because it enables "barge in" in the event of an emergency.

[wavetar]

Obviously this doesn't say much about PTT-ID, and the author of the help file evidently didn't know much about it, but see my comments on PTT-ID vs. Message above. I'm 99.9% sure that Message trunking and PTT-ID differ only in the fact that Message trunking does not require the subscriber to re-send it's PTT-ID each transmission unless it's the initiating radio on a new voice channel. This is undesirable for console equipped systems as you cannot reliably tell who's talking.

Yep, you are correct sir, with one important addition:

Beyond the console ID issue, it's primary function is to successfully maintain the conversation over the entire SmartZone system. If you accidentally set the radio to 'message trunking', it will successfully initiate a call over the system, as it's ID is verified by the Zone Controller which then allocates the applicable repeaters. However, if it responds during the hang-time, since it does not send it's ID to the Zone Controller, the controller believes the conversation to be over, and will release all the sites. The conversation will only continue at the single site the message trunked radio is transmitting, as the connect tone (or NAC in digital) keeps that particular repeater active. PTT-ID is required every transmission in order for the Zone Controller to know to keep all sites keyed up.

The above might be a nice tip for people having issues hearing conversations across multiple sites, as that particular programming error is easy to make.

[Elroy Jetson]

It would seem to me, then, that a logical change to the CPS would be to eliminate message and transmission
trunking types from the list of available selections when SmartZone is selected. PTT-ID should be forced on.

Elroy

[d119]

Unless you're using an older system that doesn't support PTT-ID. Some folks like the Transmission method of trunking - you cannot key over someone else, and the repeaters don't stay up for "hang time", so the conversation is ALWAYS trunked around the system.

[MattSR]

Is it just me or are we getting alittle off topic

[Elroy Jetson]

So let's get right back on topic!


My radio is working fine, for the most part, but sometimes I wonder if I've really got all the system channels programmed in, as I sometimes hear
just one side of a conversation when things are totally dead. The system is hardly ever carrying more than one conversation, so far.

Figure this out: I've also got a fully P25-enabled (P25 conventional AND P25 trunking) M/A-Com 7100IP in the same band range, and while I can go to
p25 conventional mode and talk between this radio and the XTS5000 just fine, with the XTS set to the SAME Astro settings that allows it to hear the
local Astro trunked system, the M/A-Com radio doesn't hear (or at least decode) the digital voices from the same system.

Both radios have P25 conventional capability and both talk to each other just fine in P25 conventional mode. One hears the Astro SmartZone system,
the other does not, with equivalent programming.

I wonder why that is?

Elroy

[MattSR]

Does the MA/COM have a Digital CSQ setting?

With Smartzone IMBE the first 2 digits of the NAC is set to the last 2 digits of the System ID, and the last digit of the NAC is derived from the connect tone... so on my local SZOL system (3A0D with 90.0Hz connect) the NAC is 03D - perhaps this might help?

Cheers,
Matt

[Elroy Jetson]

I'm using the NAC value that is the digital carrier squelch value. And the RX rule is set to monitor.


Elroy

[d119]

With Smartzone IMBE the first 2 digits of the NAC is set to the last 2 digits of the System ID, and the last digit of the NAC is derived from the connect tone... so on my local SZOL system (3A0D with 90.0Hz connect) the NAC is 03D

That doesn't make any sense. Wouldn't that mean the NAC should be 0Dn with n being the derivative of the connect tone?

[515]

You should be able to conventionally scan the trunked system traffic just fine...

NAC 293 does NOT provide digital CSQ functionality--its just the 'default NAC'. NAC F7E would be more what you want, as it's essentially a 'wildcard NAC'. Unfortunately, only the newer P25 radios treat F7E as a wildcard. The XTS2500 and XTS5000 should do this, but the XTS3000 won't. I'm not sure on the M/A-COM stuff--maybe if it's got new firmware, F7E as the RX NAC might work for you. The P25 standard currently states that F7E shouldn't be transmitted, so if your radio lets you enter F7E in the TX NAC field, that probably means the wildcard NAC functionality isn't supported.

I'm not sure if the M/A-COM radios have any other digital CSQ functionality that can be enabled aside from the special reserved NAC of F7E.

If the M/A-COM radio doesn't treat F7E as a wildcard NAC, you should still be able to conventionally scan the system if you can figure out the NAC used on the voice channels. If it's a 3600 bps system, I'd try the last two digit's of the system ID as the first two digits of the NAC, and then try 0 thru 7 as the last digit. If it's a 9600 bps CC P25 system, I'd try the system ID as the NAC, or those values around it. If it's a single site P25 9600 CC system, the voice channel NAC is probably the system ID, as shown on most P25 capable scanners.

You might also try a GRE PSR-500/600 scanner or the kNAC software utility to determine the NAC in use on the voice channels, or a P25 service monitor ...

If you can determine the NAC, you should be able to use any P25 radio to monitor all the unencrypted voice traffic. With Moto radios, you can even enable Talkgroup "Display on Receive" under Radio Wide Display Settings to determine which TG's are in use, and then program the radio with the correct NAC and TG's you want to monitor using "Selective Squelch". This works pretty good on systems that aren't very busy, and you can filter out the boring TG's if you want to...

The "Selective Squelch" trick is more of a crapshoot on non-Moto radios, though. Unlike P25 conventional transmissions, the TG ID is not present in every frame on the trunked voice transmissions. The Motorola radios cope with this well, but it often throws other manufacturer's radios for a loop if you try and conventionally monitor the trunked voice channels in "selective squelch" mode. Often they'll always mute or unmute on the frames that don't have the TG ID in them, so you'll hear intermittent audio.

Of course if you want to listen to ALL talkgroups, just program up any radio with the correct NAC and normal squelch, and it should work just fine...

[GEMOTO]

The NAC for a P25 system (3600) is set using the last 2 digits of the System ID anf the Connect Tone Number.

The Connect Tone numbers are as follows:

0 = 105.9
1 = 76.6
2 = 83.7
3 = 90.0
4 = 97.3
5 = 116.1
6 = 128.6
7 = 138.5

For example a System ID of 1234 with a connect tone of 97.3 (4) would be NAC = 344

[Elroy Jetson]

I've done everything and it's apparent to me that the problem has to be in the RX alignments of the 7100IP radio in digital mode,
because the info is correct. Setting the XTS5K to TX on the same channels it's scanning successfully, in P25 IMBE mode, the 7100
hears SOME but not ALL of those channels though the programming is triple verified correct.

First things first: How's the reference oscillator set? P25 has a pretty narrow acceptable frequency shift spec.

I'll have to do digital alignments, I think, and that can be problematic as my service monitor doesn't really support that.

Elroy

[GEMOTO]

On a Motorola radio you read the radio in with Tuner and click on the reference oscillator tab. It will list a frequency that is pre-programmed and is within the band split of the particular radio you have. You connect the radio's antenna port to the input of the Service monitor or Frequency counter, its important that either of these two devices are calibrated.

If you are using a service monitor set it up to receive on the test frequency listed in CPS and then key the radio by clicking on the TX radio button in Tuner. The frequency error should show up on the service monitor. I usually like it to be no more than +/- 150Hz for a portable or a mobile. I think somewhere 1300 or 1500Hz is the legal limit.

[MattSR]

With Smartzone IMBE the first 2 digits of the NAC is set to the last 2 digits of the System ID, and the last digit of the NAC is derived from the connect tone... so on my local SZOL system (3A0D with 90.0Hz connect) the NAC is 03D

That doesn't make any sense. Wouldn't that mean the NAC should be 0Dn with n being the derivative of the connect tone?

You're right - its 0D3 - that was a typo on my behalf..

[Wowbagger]

I think somewhere 1300 or 1500Hz is the legal limit.

From TIA-102.CAAB-B, the limits are:
Below 100MHz: 5.0 PPM (500 Hz)
138-174MHz: 2.5 PPM (435 Hz)
406-512MHz: 2.0 PPM (1024 Hz)
764-806MHz: 1.5 PPM when not locked to the base station (1612 Hz)
806-869MHz: 1.5 PPM (1303 Hz)
896-941MHz: 1.5 PPM (1411 Hz)

That's for mobiles, bases are 0.1 or 0.2 PPM (it's assumed they are locked to a real reference like a GPS disciplined oscillator).

[immelmen28]

Unfortunately, only the newer P25 radios treat F7E as a wildcard. The XTS2500 and XTS5000 should do this, but the XTS3000 won't.

FWIW, for those who might want to try it with XTS3000's, F7E does work as a wildcard NAC when programed with later versions of CPS 5.x.

[Wowbagger]

The NAC for a P25 system (3600) is set using the last 2 digits of the System ID anf the Connect Tone Number.

The Connect Tone numbers are as follows:

0 = 105.9
1 = 76.6
2 = 83.7
3 = 90.0
4 = 97.3
5 = 116.1
6 = 128.6
7 = 138.5

For example a System ID of 1234 with a connect tone of 97.3 (4) would be NAC = 344

(That I have to ask this question should tell you how nasty the *official* documentation on Smartnet is).

You wouldn't happen to know what message on the control channel the radio gets the current connect tone from? The XTS5000 I have doesn't seem to be listening to the Status opcode=1 messages to pick up the connect tone data from the CC, and is using a NAC with a final digit of "0" rather than what I am sending out.

[Twisted_Pear]

You wouldn't happen to know what message on the control channel the radio gets the current connect tone from?

It's contained in the system background messages. With a networked site there are two, one local and the other wide. Regardless of the system type that's where it's always located. With SmartZone systems there are one or two other places.

[Wowbagger]

It's contained in the system background messages.

I need the specific message(s) it's in. I've looked over Motorola's "documentation" on the Smartnet protocol but the only place I see the connect tone is in the System Status messages, opcode 1. However, the XTS5000 I am testing against is NOT picking up the connect tone from that message in the overhead I am generating and using that to generate the correct NAC on a CAI traffic channel - it is generating a NAC with a final 4 bits of 0 rather than the (non-zero) connect tone I am specifying.

With a networked site there are two, one local and the other wide. Regardless of the system type that's where it's always located. With SmartZone systems there are one or two other places.

Like I said: WHERE? Specifics, please.

In case I didn't make it clear: I am IMPLEMENTING a Smartzone base radio simulator, but the documentation I got from Motorola is, let us say, less than complete, less than coherent, and less than helpful (and that also often describes the responses I get from the Motorola engineers as well).

[GEMOTO]

I have noticed that even if I program in the incorrect connect tone I still am able to key up on a Talk group and it will go over multiple zones.

This is on a 4.1 SmartZone both ASTRO and analog, mostly ASTRO. 800.

[wavetar]

Like I said: WHERE? Specifics, please.
In case I didn't make it clear: I am IMPLEMENTING a Smartzone base radio simulator, but the documentation I got from Motorola is, let us say, less than complete, less than coherent, and less than helpful (and that also often describes the responses I get from the Motorola engineers as well).

Well, unless a completely helpful & coherent Motorola engineer is reading this, your chances of success here aren't very good.

[d119]

I have noticed that even if I program in the incorrect connect tone I still am able to key up on a Talk group and it will go over multiple zones.

This is on a 4.1 SmartZone both ASTRO and analog, mostly ASTRO. 800.

Well fine, but does it pass audio, and if so, for how long? Digital mode, or analog?

[GEMOTO]

I have not tried it in digital but in analog it will pass audio for 15-20 seconds at least. Th audio went over at least 2 zones of the SmartZone.

If you program the wrong trunking type i.e Message instead of PTT-ID, it will key up but the audio will not go over any Zones but the one you are on, as there is no ID sent with your transmission for the Zone Controller to verify which sites to route the audio over.

[wavetar]

If you program the wrong trunking type i.e Message instead of PTT-ID, it will key up but the audio will not go over any Zones but the one you are on, as there is no ID sent with your transmission for the Zone Controller to verify which sites to route the audio over.

Actually it will work properly if it initiates the conversation, as the ID is sent at that time with a message trunked radio, so all sites will come up. However, as soon as you release the PTT & subsequently try to answer, all sites but the one you are on will drop. Same thing will happen if you are simply responding to a call during the hangtime...no ID means to wide area audio.

[Twisted_Pear]

Well, unless a completely helpful & coherent Motorola engineer is reading this, your chances of success here aren't very good.

Sometimes you never know what you'll find on here.

Wowbagger, I'll PM you.

[EindhovenOne]

Sorry...maybe I should have clarified a bit...the system I want to monitor is an APCO25 CAI...do the same procedures and what not still apply for monitoring that system?

[Pj]

Conventional or trunked?

If trunked, VHF, UHF or 800, and 3600 or 9600 system?

What model radio are you using?

[EindhovenOne]

Trunked UHF-High 3600 i believe. I have an XTS2500 with all the necessary options flashed.

[EindhovenOne]

Okay...forget the SmartZone for a second, what should I make the settings if I want to make a conventional receive only P25 CAI channel? Should it be an ASTRO personality or not? Should I set a NAC or anything or leave it all default and CSQ even if there is a PL listed? When I make it an ASTRO personality, the PL/DPL/CSQ option disappears in the CPS. Thanks for your time.

[motorola_otaku]

XTS2500, right?

Under "Receive Options" for the personality you have assigned to that channel/mode/whatever, you can set "Receive Type" to "Mixed Mode" and get the option for both analog PL and P25 NAC. The first menu tab has the option for receive-only; check that and it'll gray out the transmit frequency and tone/NAC boxes.

[EindhovenOne]

Okay...so it seems that I have everything squared away and working, I can hear everything. The only time I cannot is when a unit switches up to what I am assuming is a private channel or something...the odd thing is that when they are talking to each other, their IDs still pop up on the radio as if they radio is picking up the conversation and the radio definitely stops scanning and holds on that channel until their conversation is done, but I DO NOT receive any audio, not even the garbled "i don't have a secure card" digital crap sound. I know that none of the units are encrypted so why the lack of any audio whatsoever? Any suggestions are appreciated.

[Pj]

What system is this? I'll look it up.

[redbeard]

Okay...so it seems that I have everything squared away and working, I can hear everything. The only time I cannot is when a unit switches up to what I am assuming is a private channel or something...the odd thing is that when they are talking to each other, their IDs still pop up on the radio as if they radio is picking up the conversation and the radio definitely stops scanning and holds on that channel until their conversation is done, but I DO NOT receive any audio, not even the garbled "i don't have a secure card" digital crap sound. I know that none of the units are encrypted so why the lack of any audio whatsoever? Any suggestions are appreciated.

Sounds like they just went to an I-call. Unless your radio mirrored one of their radio IDs it wouldn't let you hear the conversation since it is radio-to-radio and supposed to be private. This is where the "buy a scanner" mantra could be applied.

[123]

Finally got some radio traffic. M techs are field testing and the above method is working great. I was even sitting on the control channel. Radio never unmuted to the c/c and switched to the voice traffic right away with no delay.

Hope to do more testing as the system gets busier.