Batboard

Hi there...

I've got a VHF Astro Saber II that seems to have a funny bug in it. I set up a zone to look like this:
1) Toronto (5F)
2) 1GTR
3) 1HWY02
4) 1OPS42
5) PCOM
6) PTAC
7) OPC
OFM

Channel 1 is pointing to a conventional channel that is set for auto scan on scanlist 1. Scanlist 1 contains the other 7 channels in the zone. Channels 2, 3 and 4 are digital (IMBE) talkgroups. Channels 5, 6, 7 and 8 are analog conventional channels.

It stops on the analog channels no problem at all. When a transmission comes over one of the digital talkgroups, the radio stops on the channel, displays the ID, but it doesn't actually RX anything. When the talkgroup goes silent, the radio starts scanning again.

I have the scanlist setup as a talkgroup list, so that can't be it. In another zone, I have it set up the exact same way, except that there are 2 analog talkgroups (on the same system as the digital ones). It stops on the analog talkgroups just fine, and I can RX no problem - but again, the digital ones are a no-go.

Another problem, not sure if it's related. 1OPS42 and 1HWY02 talkgroups are patched together. If I manually select 1HWY02, I hear traffic no problem, but turning to 1OPS42 doesn't RX at all. I've verified with my digital scanner that there IS traffic on that talkgroup - I just don't hear it.

Any ideas?

Thanks!

Did you set up those digital channels for "Digital CSQ" under the RX Unmute rule? This is found under the "Astro Options" for under the personality screen. The radio will not unmute digital unless you have the proper Astro code (sorta like a PL). If its set for Digtal CSQ, it will unmute all unencypted IMBE signals.

Negative.

All of the conventional channels are analog. All of the digital stuff are trunking talkgroups, so no adjustment of Digital Squelch settings are required.

Since you didn't meanting trunking before..

What kind of trunking system is it?

Do you know if encyption is used on those talkgroups?

It is possible that you are too far away from the TRS as well. One that is in my scan list from a very distant system will decode the CC, show the talkgroup being active, but does not unmute the voice as the BER is way too high.

Other than that, as long as you have the scan set to talkgroup, life should be good.

And of course...

Model, HOST/DSP and Flashcode please...

Do you have the talkgroup channels setup for AMSS WAC, or no coverage type at all? I have noticed a bit of a problem with that in the past. It also could be a firmware issue. Pj is right, it would be nice to see the host/dsp and flash, just to make sure.

Thanks for the replies! I said earlier in my first post it's a talkgroup, but I didn't specify if it's trunking or astro - it's Type II VHF Trunking.

I'm located about 2km from the tower, I can hear the control channel without an antenna, and the radio doesn't go out of range without an antenna on.

There's no encryption on them. I can hear them on my digital scanner no problem at all.

As for coverage type, I've tried with AMSS, SmartZone and Smartnet (disabled), and it does it for all 3.

My info:

Model: H04KDH9PW7AN
Host: R07.11.00
DSP: N08.02.06
F/C: 599108-1C5E00-1

F/C decodes to:
Q806/G806 IMBE / APCO-25 Digital Operation
H14/G114 Digital ID Display
H101,G101,H169 Conventional Repeater Access (Analog Operation Only)(MDC1200 or Singletone)
H868/W298 Conventional Multikey and Analog Conventional MDC OTAR
G170/H43 Remote Monitor and Radio Trace
H46 One-Touch Operation
H39 Selective Radio Inhibit
H38/G51 Smartzone Operation
Q181 Add StatAlert (MDC1200) Features
Q352 Soft ID
Q351 MODAT Operation
W947/Q947 APCO Packet Data
H270/H738 MDC Status Message
Q387 Conventional voting scan
Q173/G173 Smartzone OmniLink Operation
G182 Enhanced Radio Call Protocol

If you don't have an authorized ID for the system, my guess is that your radio affialated to the system and got inhibited.

Inhbited radio's with that flash has been know to do exactly what you said it does.

Unless you have authorization (which I dobut) never NEVER never EVER set the radio to SmartZone. It will automatically attempt to affiate to the system the moment you get to that personality.

And, if you programmed the radio with new enough CPS, you cannot do anything about unhibiting the radio, included reloading a saved codeplug. I believe once its programmed with CPS4, your screwed.

Sorry dude.

As for talkgroups, a feature of of IMBE digital is that you can have conventional based ASTRO "talkgroups". Sorta like MPL in a way...

From the CPS What's New file as a FYI:

'CPS allows programming an INHIBITED radio'. This new version of the CPS will no longer allow programming a system INHIBITED radio. Please note that in order to UN-INHIBIT a radio, it must be done through the system or by the Depot tool.

If the radio was inhibited, it wouldn't receive on any talkgroup on the system, right?

I'm using Astro 9.05 so that's not a problem, but I'm quite sure that's not the problem.

I'm not using SmartZone like you'd think. I have all of the control channel TX frequencies set on a default commercial channel (that I'm licensed to), and the TX range for the voice channels is such that it will TX on my commercial channel only (the TX range is 151.xxxx to 151.xxxx - both of them being the same frequency). The reason I use this is for RX...there's 41 sites on this smartzone system, so doing it this way allows me to select what tower I want. I do this instead of AMSS, as AMSS only displays site numbers according to control channel positions, instead of SmartZone, which displays the ACTUAL site number that the site transmits.

Edit: I have the secure switch rocker set to one site being blank and the other side TX inhibit, so my radio doesn't waste it's battery trying to affiliate to a site it'll never reach...

There's absolutely NO way the radio can TX on the system, as it doesn't know anything about the TX frequencies.

Just an update to this, I seem to have it working now. I don't know what I did, but it works now (I just dumped the codeplug back into the radio without changing anything), so it's quite weird.

For curosity's sake - why would my flash be more likely to be inhibited than say, a "Nick" flashcode? If there's a flash option that makes it more likely, which is it?

Thanks again for your help Pj!

if it's set to SZ or SN, and CC are programmed into it, the site can talk to the radio, as can the sys watch terminal, TX inhibit turned on or not. If your not an authorized user, stay off and use a scanner. If you are authorized, great, your sys administrator will be glad to help you out.

More info to your exact problem is required to determine what is actually going on, but at this point I suspect you are not supposed to be on the system, which, is part of the problem itself.

SG

If the radio is programmed for a trunked system, the radio CAN and WILL tx on a command from the control channel, reguardless of the TX Inhibit setting. This is especially true when the radio is set for SmartZone as SZ only has an option for Automatically Affilate with SZ is selected.

The Nick Jr and Nick flashcodes are not valid flashcodes (as with the options it contains that confilct with each other) and does strange things.

I had at one time a trunking radio with that same flashcode. At the time, I was authorized to use a TRS. We played around with the radio and the system. When the inhibt command to the radio was sent, it didn't shut down the radio as it was suppose to. It would do what you did, but also it was TX Inhibt conventional channels at times. Sometimes it worked, sometimes it didn't.

When we sent the uninhibit command back to the radio, it didn't take until about the 4th time.

Again, we hate to sound like a broken record here, but there is no value in using trunked radio's as a scanner, especially if you do not know how to properly program them. You end up in a situation like you are in now, and also you can adversly effect the performace of that system without knowning it.

I am going to come down to two consolutions...

1-You don't have the system programmed correctly
2-The radio being a Nick radio

spectragod wrote:if it's set to SZ or SN, and CC are programmed into it, the site can talk to the radio, as can the sys watch terminal, TX inhibit turned on or not.

If you read my post above, you'd see that's impossible.

It's a VHF system, so you program the control channel TX and RX, as well as the TX and RX voice channel ranges.

All of my control channels have a TX frequency of 151.xxxx and the TX range is 15kHz spacing, base 151.xxxx, end 151.xxxx. I have confirmed that when it tries to affiliate, it's TXing on my 151.xxxx frequency. I've run Treport for hours while my radio has been sitting on a system, and my radio's ID has never come up as trying to affiliate or anything, so it's quite obviously NOT affiliating to the system - it doesn't have any of the correct system TX frequencies in it.

If, suppose, my RID was sent a command to TX back to the control channel, my radio would respond on the TX frequency which I programmed in, which isn't the correct one for the system, so that command would never be received by the controller, therefore there's zero chance of anything happening on the system.

I have a digital scanner, but the reason I'm using this thing is because I don't really feel like carrying a scanner AND a VHF radio (I use it for ham stuff and the like all the time), when this one radio can take care of both. I agree, if it was an 800/900 radio, it'd be a pretty bad idea as there's no way to change the TX frequencies, but on a VHF/UHF, you can tell it what channels to TX back to the system on. I'm sure SG and PJ both know that when the controller transmits the voice channel, it sends out a hex channel which my radio calculates the actual frequency based on what I have for base and spacing...but if those values are incorrect for the system, it won't TX back to the system on a frequency that the system is listening to.

Anyways, as I said, my problem seems to have gone away.

FWIW, the radio itself isn't a "Nick" radio, it had a totally different flashcode in it when I got it (Digital, conventional only, pretty much), but the flash itself is a Nick flash. I'd like to put a "legit" flash into it, if I could

The flashcode makes it a "Nick Radio" with Nick problems.

The radio also does not need to affiate to the sytem to get zapped. If the system does a poll, it can send out zap commands to all radios that are not within the database.

The bottom line, if the radio can "hear" and is on a SZ system, it can be killed..... period.

If you need this radio for your job, why not a legit ID # on the sys?

SG

bellersley wrote:

spectragod wrote:if it's set to SZ or SN, and CC are programmed into it, the site can talk to the radio, as can the sys watch terminal, TX inhibit turned on or not.

If you read my post above, you'd see that's impossible.

If you knew Spectragod, you would be heeding his advice.

Just because your radio can't respond, doesn't mean the controller can't have a one way conversation with it. A kill command doesn't need to be ack'd by your radio to succeed.

I also believe that the controller also sends out the input channels as well as the output channels for the system (I'll have to fire up Treport later and check).

Your radio could very well ignore the bogus information you've entered when it encounters a kill or other system command.

The only people with a need to have that specific set of talkgroups and conventional channels would be Bell Mobility Radio.

To reiterate PJ and SpectraGod, If you are a legitimate user of the system, get the admin to give you an ID. Get a properly flashed/featured radio and you are good to go.

If you are not a legit user, might I suggest a digital trunking scanner? Wanting to listen is all well and good, but if you aren't a user of the system and you want to save yourself some potential headaches, get the scanner.

While I appreciate all the advice, I'm not worried about the radio getting zapped or anything like that, as it's not a big deal to re-enable the thing.

Sorry to get this way, but how many of you on here aren't authorized users of a trunking system but have trunking radios set up to RX on a trunking system? I suspect it's a HECK of a lot more than you'd want to admit.

As for my use for the radio, I don't need it to ever transmit on those digital talkgroups, only on some analog conventional frequencies.

A VHF trunking system DOES send out the TX as well as RX frequencies, but it sends them out as hex values. Your radio takes those hex values and calculates the actual frequency. For example, you program your radio with a base frequency of 141.015, with a spacing of 15kHz. If your radio gets a channel of 1A3 for example, it'll calculate 1A3 channels above 141.015MHz with a spacing of 15kHz for each channel. RX works the same way - you have a base frequency of 138.015 and a spacing of 15kHz. Same deal.

So there's no way my radio can "ignore" the bogus information I've put in it. Nothing from the control channel says "go to 143.340", instead, it'll say "go to channel 1A5" which the radio interprets as 1A5 channels above your base frequency. So, if I have the base frequency set to 144.000 and the end frequency as 144.000 for example, the radio will only EVER transmit on 144.000. This I have verified with a frequency counter several times, and I've talked to Mot. techs and they've told me that's exactly what happens.

It's not like 800/900MHz radios where the firmware has it hardcoded that channel 1A5 is 867.5625 or whatever, without a way of making it TX elsewhere (unless you feel like hacking the firmware...).

Again, thank you very much for all your input and advice, even though I might not agree with all of it, it's DEFINATLY appreciated! This is why people keep coming back here...there's a lot of very smart "cookies" on here. I appreciate Spectragod's advice, and I hold it in exceptionaly high regard considering the source, so it's not as though I'm ignoring anybody, I'm simply stating my concerns/information.

Thanks again!!!