Batboard

I have a W9 and W7 programmed identically. Both with fairly similar flashcodes and firmware.

The radio in question, the W7 (512k board)
I06.04.09/08.15.xx.xx (or by the radio - 08.01.05)

On a non-priorty scan channel, the radio will stop, but not unmute traffic with the improper PL (which is half of what its suppose to do). So essentially, the radio will sit there and be tied up for something it shouldn't be stopping on to begin with.

On the W9, this does not happen (don't have the firmware revision handy). If there is the wrong PL, it does not stop and sit on the channel.

HUB Suspends Scan is not checked, carrier detect required is not checked and priorty marking is not checked on both radios.

So why would one stop on a channel, and not the other?

Check "priority marking."

It was a quirk of the scan logic hard coded into Spectras that, if it detected co-channel on the scan priority channel, it would sit on that channel, muted, so long as there was carrier.

"Priority marking" is designed to eliminate (or at least reduce) this problem as follows:

Once the radio detects carrier w/o tone or carrier w/wrong tone on the priority channel, it sets a flag. So long as that flag is set, the priority channel is temporarily deleted from the scan list, but the freq is tested for activity periodically. The flag is reset when the radio detects either no carrier or carrier w/proper tone, at which point the radio resumes normal priority scan operation.

Not a perfect solution, but it does seem to work.

Forgot to add....tried that. No-go. I am wondering if its a firmware issue.

That I cannot answer. I will say that, with XTS5000 and XTS2500 (basically the same architecture) unchecking "Carrier Detect Required" and checking "Priority Marking" seems to cure the problem. Ditto the XTL5000.

Pj wrote:Forgot to add....tried that. No-go. I am wondering if its a firmware issue.

That would be my first thought, especially since the problem radio is an ancient 512K.