Binary logic error within the 16 bit TGID field/Pro-96

[royalzapper]

Hamilton County TRS (APCO-P25 9600 baud)
System Type: Project 25 Standard
System Voice: APCO-25 Common Air Interface Exclusive

The Digital Scanner Team located in Hamilton County, Ohio.
Has observed a problem with some Radio Shack PRO-96 &
PRO-2096 Radios.

That I first called "Closed Mode MOT: bleed over".

When the Banks are set up in the "Closed Mode".
The problem is receiving transmissions of talkgoups that
haven't been programmed in the Radio's ID list.
The Radio will display the MOT: ID #.
Also if you lockout this MOT: ID # that was displayed, the
Radio will lockout a different talkgroup that is stored in the
Radio's ID list.

Example # 1:
Bank 01 is set up in the “Closed Mode” to only receive the
transmissions of the Hamilton County Police.
Talkgroup # 00051 is programed in the Radio's ID list with the
alpha tag of LE EAST DISP.
When you receive Hamilton County East Dispatch transmission
the Radio will Display the associated alpha tag LE EAST DISP.

Then you receive the transmission of Cincinnati Police Dist. 2
This talkgroup is HAS NOT BEEN programed in the Radio's ID list!
MOT: 32819 will show on the Radios display & you hear the transmission.
If you press L/OUT the Radio will lock out # 00051 alpha tag LE EAST DISP.

The revise action will occur in Bank 04 that is set up in “Closed Mode”
for Cincinnati Police. MOT: 00051 will show on the Radios display and
you hear the transmission. If you press L/OUT the Radio will lock out
talkgroup 32819 DIST 2 Disp.

Example # 2:
Bank 01 is set up in the “Closed Mode” to only receive the transmissions of the
Hamilton County Police.
You have programed in # 00081 & the alpha tag AW 19
When you receive a encrypted transmission.
MOT: 32849 will show on the Radios display {This is Cincinnati PD C2C 1}
If you press L/OUT the Radio will lock out # 00081 & the alpha tag AW 19

Consistently the same talkgroup ID will be locked out when the Radio
receive the transmission the opposing talkgroup!

What we have discovered is within the Talkgroup ID 16 bit TGID field.
That some Radio Shack PRO-96 & PRO -2096 Radios are neglecting
the high bit. When the Radios are receiving transmissions of talkgoups
there could be a translation table error at bit 0x8000 within the 16 bit TGID field.

The Hamilton County / Cincinnati TRS system has 105 talkgroups
that with the exception of bit 0x8000, that are "IDENTICAL".

Here is a example of 10 talkgroups:

TGID
Digital 16 bit field Alpha Tag
00001 0000 0000 0000 0001 FD DISP 1
32769 1000 0000 0000 0001 MAIN AUX

00051 0000 0000 0011 0011 LE EAST DISP
32819 1000 0000 0011 0011 C PD DIST 2

00052 0000 0000 0011 0100 LE WEST DISP
32820 1000 0000 0011 0100 C PD DIST 3

00053 0000 0000 0011 0101 LE CENT DISP
32821 1000 0000 0011 0101 C PD DIST 4

00054 0000 0000 0011 0110 LE SPARE
32822 1000 0000 0011 0110 C PD DIST 5

00395 0000 0001 1000 1011 JAIL 3
33163 1000 0001 1000 1011 SPARE 11

All Radio Shack PRO-96 & PRO -2096 Scanners here in Hamilton County, Ohio
are not effected which leads us believe that the problem is not in the firmware.
We have confirmed this problem with CPU: 1.1 , 1.3 & 1.4

Our goal is to bring this problem to the attention of GRE & Radio Shack.
We would like to know with this information is there a way that you can
bench test the binary logic translation table and detect the error at
bit 0x8000 within the 16 bit TGID field.

Thanks
royalzapper
Billy Zapf

 

[royalzapper]

“MOT: Closed Mode leak”?

As I think about the problem more the Radio can differentiate
the difference of the high bit.

00051 0000 0000 0011 0011 LE EAST DISP
32819 1000 0000 0011 0011 C PD DIST 2

00052 0000 0000 0011 0100 LE WEST DISP
32820 1000 0000 0011 0100 C PD DIST 3

The Radio can recognize the bit 0x8000 because the opposing talkgroup
MOT: that shows in the display is the proper digital ID number.
Plus the right transmissions are always hear on the proper associated
digital ID number.

The problem is with what I first called the “Closed Mode MOT: bleed over”.
Maybe I should have called “MOT: Closed Mode leak”?

Perhaps something within the binary logic that should prevent talkgroups
from passing through the "Closed Mode" translation table?

What I have observed is ONLY the opposing talkgroups are passing through
the Banks that are set up in Closed Mode.
No other MOT: ID # has passed through or been displayed.

I do not know how the Radios logic circuit works. I am only trying
to give the information the best that I can. With the hope that this
may assist in finding a way to resolve this problem.

Thanks
royalzapper
Billy Zapf

 

[AireRoscoe]

Any Luck in Getting a Fix for the Logic Error?

The description of the problem that's given here is exactly what I've begun to experience on the Minneapolis-St. Paul system with one of my Pro-96s. The other one seems to be okay.

This only happens with one of the systems, but it may be that the mix of IDs I have in that system causes the "leak", which seems to be a good word to describe the problem.

The question is...has there been any luck in addressing it? Has anyone sent their radio back to the Shack for a fix and if so, could it be fixed? This isn't a terrible situation, but it's annoying.

 

[rdale]

The older CPU had a firmware problem with lockouts, if you used Win96 the problem wasn't there.

 

[royalzapper]

The description of the problem that's given here is exactly what I've begun to experience on the Minneapolis-St. Paul system with one of my Pro-96s. The other one seems to be okay.

This only happens with one of the systems, but it may be that the mix of IDs I have in that system causes the "leak", which seems to be a good word to describe the problem.

The question is...has there been any luck in addressing it? Has anyone sent their radio back to the Shack for a fix and if so, could it be fixed? This isn't a terrible situation, but it's annoying.

AireRoscoe "has there been any luck in addressing it?"
...........Cannot say.....

AireRoscoe "Has anyone sent their radio back to the Shack for a fix"
...........YES......The Radio will be returned to you with a Note that reads
.......... NO PROBLEM FOUND

At this time RadioShack CANNOT fix this PROBLEM !!!!

AireRoscoe you should try to exchange your Radio.
Some Radios will have the problem & Some Radios will not.

Thanks
royalzapper

PS.... This IS annoying if the Talkgroup you really like to listen to has
a "leak" with an Encrypted Talkgroup !!!!

 

[royalzapper]

The older CPU had a firmware problem with lockouts, if you used Win96 the problem wasn't there.

This has nothing to do with that problem !!

royalzapper

 

[Thayne]

I have noticed this a few times on the Colorado system. Sometimes the a few of DCSO groups will be heard and identified by # even when the bank is closed and those groups are identified by name and locked out in the TG list.
It seems to me to have something to do with different CC reception as it goes between towers that simultaneously transmit the offending group.
I have seen it on both 96 and 2096.
Most of the time it is not a problem, but some of the News guys ***** about it.

 

[AireRoscoe]

Thanks For the Help With the Phantom Talkgroups

RoyalZapper,

Thanks...you answered my questions.

After thinking about this a bit I experimented and found (as I think you already know) that the Phantom problem occurs when the talkgroups are separated by 2,048 (decimal). In our case in the Twin Cities, this causes the following Phantoms among talkgroups that are actually in use:

Talkgroup in radio........Talkgroup received
52........2100
64........2112
82........2130
84........2132
88........2136
94........2142

You are correct in that by locking out the lower-numbered talkgroup, the phantom (the higher numbered group) will not be received. The reception can also be stopped by turning the bank that has the lower numbered groups off. No news to you, I'd suspect.

Contrary to what I said before, I can make this happen with any talkgroup on any system, so it's clearly the radio misinterpreting the talkgroup data. It just took a clue as to what to look for in addressing this issue and your earlier posts gave me that. Thanks!! As you've indictated, if the related talkgroup happens to be in the bank, and has a text tag, the radio will show that group and its associated text tag. If the talkgroup is not in the bank, it will show up as a "new" group.

There doesn't seem to be any limit to the range of talkgroups through which this will happen. I've gone up into the 10,000s and found the exact same behavior.

As far as I can tell, this seems to only happen in one direction...that is, up. A higher talkgroup does not seem to generate a phantom of a lower numbered group. Another thing I've not tried is multiples of 2,048, such as groups 4,096 apart.

You are also on track with regard to this varying by radio. My other 96 does not exhibit this behavior. Interesting that the one that does has a higher serial number than the one that doesn't. I'd flashed the lower numbered one to add the CQPSK upgrade, but the newer one was already okay with CQPSK, so didn't need the flash. Makes me wonder if that made a differerence, but probably not.

RDale's comments made me wonder about one other thing. I do use Win96, but the last time I did a load from there (just a few weeks ago) I directly loaded one radio, but cloned the other (don't recall the sequence now). Just for fun, I'll redo a load to the affected radio from Win96 and see if that makes a difference. Just maybe it's the way the talkgroup data is loaded into the radio that is the source of the error. A long shot, but worth a try.

A shame the Shack can't figure this one out. But, thanks for letting me know that it's not worth the bother of trying to get a fix from them.

Sorry the the length here...I really appreciate your help and that of others.

 

[royalzapper]

Thank you for the additional info !!

The first time I seen the "leak" was at Bit 08 (0x8000) within the TGID Digital 16 bit field
This was before the Cincinnati TRS come online....

[00053] 0000 0000 0011 0101 [LE CENT DISP]
[00309] 0000 0001 0011 0101 [RADIO SVC 1]

[00138] 0000 0000 1000 1010 [BLUE ASH FD]
[00394] 0000 0001 1000 1010 [JAIL 2]

[00006] 0000 0000 0000 0110 [ HC FG 01]
[00262] 0000 0001 0000 0110 [MSD STA 4]

[00121] 0000 0000 0111 1001 [ RED CROSS 3]
[00377] 0000 0001 0111 1001 [VALLEY FD]

[00013] 0000 0000 0000 1101 [HC FG 08]
[00269] 0000 0001 0000 1101 [MSD STA 10]

The Hamilton County TRS system has 75 talkgroups that with the exception at
Bit 08 (0x8000), that are "IDENTICAL"

Your problem is at bit 12

0000 0000 0101 0010
0000 1000 0101 0010

0000 0000 0101 0100
0000 1000 0101 0100

0000 0000 0101 1000
0000 1000 0101 1000

0000 0000 0101 1110
0000 1000 0101 1110

FYI..If you use a problem radio to clone another radio the problem does not go with the
clone, it stays in the bad radio, full reset and re-flash of the CPU does not remove the
problem.

AireRoscoe wrote :
"A higher talkgroup does not seem to generate a phantom of a lower numbered group"

The "leak" goes both ways !!

This is an extraordinary problem it does not show on "ALL radios" &
the system that you are monitoring has to use the "opposing talkgroup numbers."

Plus that opposing talkgroup has to be transmitting at the same time your radio
is scanning the ID bank that you have the opposing talkgroup programed into your radio !!

Hope that this make sense ! Clear as mud ??

The Digital Scanner Team located in Hamilton County, Ohio.
royalzapper

 

[AireRoscoe]

Thanks Again for Your Insight

RoyalZapper,

Interesting. I see that the problem you are having is with talkgroups separated by decimal 256. Your explanation is very thorough...far from being "clear as mud"...and most helpful.

It would seem logical that the "leak" would go both ways, so I'll do some more research to confirm that condition here if possible. I'll need to sift through the talkgroups in order to find a set where the "down" aspect can be tested. In the cases I listed the lower numbered groups aren't very active, so it may be hard to catch an actual "down" event. But, maybe after doing some math on the groups that are here I'll find some prospects. We have somewhere around 1,600 groups on the Minnesota system, but in most cases the groups are in batches that are less than 2,000 (decimal) in scope.

As to the cloning question, I wasn't thinking that the problem might go with the clone (quite frankly, that idea hadn't occurred to me), although I can see your line of thought. Rather, I was wondering if the way in which data might be loaded during a clone, as compared to the way it might be loaded directly from Win96, could make a difference. Unlikely, it would seem, but it seemed worth a test. For the testing done at this end so far, the extra groups I examined were entered using the keypad on the radio.

I see now that Thane has reported seeing the same thing on the Colorado system. That report indicates that the groups come through even if the offending ones are locked out, which seems contrary to what both you and I have experienced. In my case, locking out either the group or the bank will work...as long as those locked out are (in my case) the lower numbers.

Have you heard of any similar problems with Unidens? I've not and my Uniden is fine. This would further suggest it's a Pro-96/2096 problem.

Again, thanks for all of the help.

 

[royalzapper]

Have you heard of any similar problems with Unidens? I've not and my Uniden is fine. This would further suggest it's a Pro-96/2096 problem.

No problems that I am aware of with the Unidens.
Except here in Hamilton County the PRO's SOUND BETTER!
{But that is another story}


I do not think that most people that read this post realize how important this decision is?

They could have a problem Radio....and there is NO WAY TO TEST IT.

royalzapper

 

[AireRoscoe]

Getting the Word Out...

Yes, I think you are correct in that this isn't getting the attention it probably should. You'd think Radio Shack would be interested if for no other reason than to address the issue in any further models it might develop. They also have the potential "time-bomb" issue as systems grow and this problem materializes to a greater extent. Upset users can be a noisy pain that most businesses would prefer to avoid.

Few may realize the problem they have...I didn't until happening to program some low-use groups that hadn't previously been in the radio but turned out to be the ones that caused the problem to show up. Most of the systems here have a range of talkgroup IDs that are less than the 2,048 difference it takes on my radio to show up. If I had the smaller range problem that you are experiencing (difference of 256) it might well have shown up sooner.

As to getting the word out, I see that you originally posted this issue on the Yahoo GRE group last July, but didn't get much response. Supposedly, there are RS people who watch that group so I wonder if it might be worth reposting? If you agree and would find it to be okay, I'd be happy to do that, referencing your original post and investigative efforts, of course.

 

[hobbyhoser175]

I'm glad I'm not the only one with this problem. I tried to ask about this on my local message board (http://scanfan.hoff.org/cgi-bin/yabb/YaBB.pl?num=1134947474) with no luck. I too am in Minneapolis/St Paul, however, my scanner isn't doing the exact same thing. My bleeding occurs with lower talkgroups bleeding through.

Talkgroup in radio......Talkgroup recieved
3024......2512
3026......2514
3036......2524
3022......2510
3030......2518
3034......2522
There are more, but I didn't write them down.
My talkgroups are separated by 512 (not 2,048 like AireRoscoe, also in the Twin Cities)

I monitor 2100 (Allina North) almost all day and have never had 52 bleed through like AireRoscoe does.
Could it be that different radios have different bleed through? Royalzapper, do all your friends in Ohio have the same talkgroup bleedover or are they different?

You are both right, I hope GRE/Radio Shack take this seriously. I won't buy another Pro96 when the East Metro goes digital. As more talkgroups are added, this problem will only get worse.

 

[royalzapper]

This was the first time that I posted this information to this forum

http://www.radioreference.com/forums/showthread.php?t=18067

/////////////////////////////////////////////////////////////////////////////////////

I do not count the separation of the talkgroups.

download this "Unit Converter"

http://www.pmasoft.net/englisch/pmabinary.htm

You can enter the Decimal talkgroup ID #
and it will convert to the Binary number

I am not learned in this I can only share what I
have found out.

I took all the talkgroups that Hamilton County &
Cincinnait has. Then I Converted each talkgroup
looking for something similar within 16 bit ID field.

Attached is a photo of the "HEADER DATA UNIT"
look at red square "TGID 16 bits"

The TGID is within the data pack from
the Control Tower.

Binary arithmetic is a "0" or "1"
in place 15 thru 0 [I think?]

NOTE: only bit 9 is different in your examples
..........15..........9................0
[3024]=0000 1011 1101 0000
[2512]=0000 1001 1101 0000

[3026]=0000 1011 1101 0010
[2514]=0000 1001 1101 0010

[3036]=0000 1011 1101 1100
[2524]=0000 1001 1101 1100

[3022]=0000 1011 1100 1110
[2510]=0000 1001 1100 1110

[3030]=0000 1011 1101 0110
[2518]=0000 1001 1101 0110

[3034]=0000 1011 1101 1010
[2522]=0000 1001 1101 1010

What is interesting is:
The "leak" here in Hamilton County is at the
most significant bit or the high bit.

Here in Hamilton County "All" the problem radios
that I have seen have the "SAME" bit leak problem.

The Hamilton County/Cincinnati TRS is one
OMNILINK Smartzone System..

Interesting that you have more that one system
in a bank and have seen this problem.

So far I believe that this may only be a
P-25 9600 Baud Exclusive problem.

I do not know how the Minneapolis/St Paul System
is set up. I will take the time to check it out.

When I read some of the spec...
I am amazed this this Scanner works !!!

Can you return your PRO-96?

Like I have said
ALL THE RADIOS DO NOT HAVE THIS PROBLEM...
At this time I have a PRO-96 & PRO-2096 "PROBLEM FREE!!"

royalzapper

edited for typo !!!

Then I Converter each talkgroup = Then I Converted each talkgroup

"Converter to Converted"

P25 Training Guide (pdf) can be download from

http://www.danelec.com/library/english/whitepapers.asp

© 2004 Daniels Electronics Ltd.
All Rights Reserved.

 

[hobbyhoser175]

Thanks for the reply & the binary converter. I have a few more bleed overs since last night & they are at the same bit number (10 or 9 depending if far right is 1 or 0)

Its interesing that AireRoscoe's bleed is at bit 12 and mine is at 10. We're looking at the same system, so it's obvioulsy is the scanner that is the problem. You'd think there would be a fix then.

I bought my scanner in early December so I'll have to see if I can exchange it. Who's to say I won't have the same issue with a new scanner (at a different bit location)?

 

[AireRoscoe]

Further Testing on Phantom, or Leaking Talkgroups

Most interesting.

HH176...have to say I'm sorry in that I saw your post on ScanFan but didn't quite follow it at the time. I see JohnM saw it too and responded. Since then I've been in touch with him and he's as mystified as are we. My Pro-96 is too old to exchange, but yours is not, so the plan to take it back is probably a good one. Most 96s seem to be okay, so the odds are that you'll probably get a good one if you exchange it. On the other hand, I've heard nothing but good things about the Uniden 396 and the price difference is minimal, so you might want to consider that. Your call, of course.

RoyalZapper...your posts continue to be most informative. Thanks especially for the link to Daniels. What a nice explanation of the P25 system! First I've been able to get a clear look at the differences between C4FM and CQPSK. Great.

Now to our problem.

We know that there are people in Colorado, Ohio, and Minnesota with this problem so it would seem our presumption that the radio is the issue is probably correct.

The only difference seems to be the bit that is misunderstood. RoyalZapper's is at decimal 256, HH176's is at 512, and mine is at 2,048. It's probably the case that the broader the spread, the less the issue.

What is common is that the error occurs in the third quad (from the low-order end) of the bitstream.

My problem is at the high-order character of this set, RoyalZapper's is at the low-order position, while HH176's is at the second character from the low-order position. This translates to decimal talkgroup differences of 256, 512, and 2,048 respectively, as we already know. We've not heard of a problem at the third character from the low end (decimal talkgroup difference of 1,024), but it may exist there as well.

In an effort to get a better understanding of this, I tested my radio for problems across the range of decimal talkgroup differences from 8 to 4,096, in both directions.

I picked 10808 at the "base" group. HH176 will recognize this as Bloomington PD dispatch. In an empty bank, I plugged in groups decrementing by 8, 16, 32, 64, and so on (respective groups were: 10800, 10792, 10776, 10744, and downward), all the way down to -4,096. Did the same thing going up, incrementing by 8, 16, 32, 64, and up (groups 10816, 10824, 10840, 10872 and upward), to 4,096 going in this direction. Then, I scanned on this bank. Since few, if any of these groups are actually in use, this was pretty easy. The result was that the only hit I got was on 8,760, which received group 10808, demonstrating the problem. The bottom line is that on MY radio, the only problem is when a talkgroup is in the radio that is 2,048 less than the "target" group.

It might be interesting for others to try a similar thing...some may already have.

This now leads to my next question, which is what is actually going on here?

In the case above, and in all others I've tried, the talkgroup number that shows up in the radio's display is the target group's, not the entered group's. Perhaps more clearly, when talkgroup 10808 shows up on the entry of 8760, the number that shows up in the display is 10808, not 8760.

It would seem to me that if the radio were misreading the talkgroup number during transmission that the number showing up in the display would be the misread one: in my case, 8760, since group 10808 would be being mistranslated as 8760. But that's not what happens.

On the other hand, if the entry of the talkgroup data into the radio resulted in an error, then the entry of talkgroup 8760 would "look" to the radio as if it were 10808. Then, when the radio received talkgroup 10808 it would display as 10808, but be received because group 8760 was in the radio, but misinterpreted by the radio as group 10808.

I'm not sure where the Pro-96 gets its talkgroup ID number information, whether it's from the control channel or the message data header. If it comes from the control channel, the scenario above seems to make sense, but it if comes from the data header, then it could be seen how the radio would display the "target" talkgroup number even if it were receiving that group as a result of an error in calculating the group number.

May be way off track here. It would be interesting to find out what's actually going on. It would also be good if the Shack could develop a fix. As mentioned before, this problem is very consistent and will not heal itself.

 

[royalzapper]

Something more to think about.

Need to redirect your thinking or something more to think about.

I believe that the Radios CAN differentiate the difference of the opposing talkgroups.

Read Reply #2 {again}

(This in not in stone just me thinking)

I do not know how the Radios logic circuit works !!

But I believe that the "LEAK" is in the “Closed Mode”.

In the close mode the radio should only be reading the
ID list that is programed in the radio.

But the radio has to sample (?) what data is coming from the Control Channel
looking for the TGID that is in programed in your Radio.(ie=16 bit TGID)

Something in the circuit that should "Block off the passage through" (ie=LEAK)
of a talkgroup when in “Closed Mode” is where I think to problem is.

That is where someone that KNOWS how the logic circuit works needs to LOOK !

Remember ALL RADIOS DO NOT HAVE THE PROBLEM.

Is this in the IC Chip #???(I do not think so.)
Could it be a FILTER ??? (Maybe!)
Do some Radios have a leak to ground ??? (Maybe!)
Do some Radios have a power leak ??? (Maybe!)

Thats the Million Dollar question. Where is the LEAK ??

AireRoscoe wrote:

They also have the potential "time-bomb" issue as systems grow
and this problem materializes to a greater extent.
Upset users can be a noisy pain that most businesses would
prefer to avoid.

I like your comment about the "time-bomb".
Will be interesting if a fix comes or like
yourself warranty is expired.

What will the Shack do ?

Will RadioShack fix the Radio at no-charge ?
Was not your Radio defective before your warranty expired ?

From the Pro96 Manual
"If your scanner is not performing as it should,
take it to your local RadioShack store for assistance."

I am willing to bet that after you own your PRO-96/2096 you know
more about it then MOST of the employes at RadioShack.

I wonder how many of the "OLD" guys will "SQUAWK"
about it when time-bomb goes BOOM on their system ?

Us NEW guys know a PROBLEM when we see one !

royalzapper

LEAK score card Pin # & the value

08=256
09=512
11=2048
15=32768

 

[royalzapper]

Maybe this is a way for everyone to test....

Binary logic error within the 16 bit TGID field
"Closed Mode MOT: ID # Leak"

When the scanner is in scan mode (scanning)

On the Display of the PRO-96 or PRO-2096
You see the numbers
0 1 2 3 4 5 6 7 8 9
This is the Banks you are scanning

Under the numbers you will see (+) or (-)
(+)= Open mode
(-)= Closed mode

In Banks set to (-) Closed mode
You should never see a number after MOT: show up on the Display.

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

Maybe this is a way for everyone to test their
PRO-96 or PRO-2096 for the "Closed Mode MOT: ID # Leak".

Pick the top 10 talkgroups that you listen to on your Trunking System.

Then enter the decimal TGID number and convert
that number to binary number.(16 bit TGID)

If you need a decimal/binary bit converter you
can download one at this Link.

http://www.pmasoft.net/englisch/pmabinary.htm

Almost all computer users understand the concept of a bit (that is, a 1 or 0 value encoded
by the setting of a switch of some kind). A single bit can represent two states:

0 1

A 16-bit binary value uses bit positions zero through fifteen:from "right to left"

bit positions...15.....14....13....12....11....10....9....8....7...6...5...4..3..2..1..0
bit values...32768..16384..8192..4096..2048..1024..512..256..128..64..32..16..8..4..2..1

So far the known problem bits.

bit #08 & value 00256
bit #09 & value 00512
bit #11 & value 02048
bit #15 & value 32768

Lets say this is the decimal TGID that you have picked from your
Trunking System that you listen to.

TGID......binary number
[00034] = 0000 0000 0010 0010
[00052] = 0000 0000 0011 0100
[00086] = 0000 0000 0101 0110
[00146] = 0000 0000 1001 0010
[00896] = 0000 0011 1000 0000
[01016] = 0000 0011 1111 1000
[02264] = 0000 1000 1101 1000
[03424] = 0000 1101 0110 0000
[10272] = 0010 1000 0010 0000
[24450] = 0101 1111 1000 0010

Now lets take [00034] in the binary number

0000 0000 0010 0010

change bit # 08 from "0" to "1"

0000 0001 0010 0010

The new decimal number is [00290]
this will be the SIMULATED TGID that you will enter in your Radio ID List

Note: If you only add the value of problem bit to the TGID IT MAY NOT ALWAYS WORK
TGID........value......simulated TGID..binary number
[00034] + 00256 = [00290].............0000 0001 0010 0010
[00034] + 00512 = [00550].............0000 0010 0010 0110 (Note wrong #)
[00034] + 02048 = [02084].............0000 1000 0010 0100 (Note wrong #)
[00034] + 32768 = [32802].............1000 0000 0010 0010

But if you change the problem bit from "0" to "1" you will get the proper decimal number
that "WILL LEAK" if you have the problem
[00034] 0000 0000 0010 0010 CHANGE bit #08 from "0" to "1"= 0000 0001 0010 0010 SIMULATED TGID [00290]
[00034] 0000 0000 0010 0010 CHANGE bit #09 from "0" to "1"= 0000 0010 0010 0010 SIMULATED TGID [00546]
[00034] 0000 0000 0010 0010 CHANGE bit #11 from "0" to "1"= 0000 1000 0010 0010 SIMULATED TGID [02082]
[00034] 0000 0000 0010 0010 CHANGE bit #15 from "0" to "1"= 1000 0000 0010 0010 SIMULATED TGID [32802]

Do this to all the talkgroups that you have picked at EACH problem bit position.

Now you will have 40 SIMULATED TALKGROUPS.
Put this SIMULATED list in your PRO-96 and CLOSE THE BANK

With your bank in CLOSE MODE you SHOULD NOT get a "MOT: #####" on your Display

Example

00290\
00546 \ MOT:00034
02082 /
32802/

If you have "MOT: #####" show up on the Display you have a problem Radio and
should contact 1-800-THE-SHACK

Hopefully you understand what I am suggesting.
I am NOT aware of any REPAIR for this problem.

royalzapper

********************************************

If you have this PROBLEM please post your info here.
Please list.

System that you are listening to.

Battery Compartment date code

Serial #

Turn your Radio on & During Welcome screen display
press the 3 button.
What is your CPU, DSP application and DSP vocoder versions

Display will show
CPU: F1.3
DSP-App: F1.2
DSP-Voc: F1.0

thanks
royalzapper

********************************************

 

[Al42]

I do not know how the Radios logic circuit works !!

The "circuit" is programming (the firmware) and data (your input).

In the close mode the radio should only be reading the ID list that is programed in the radio.

It is - it's comparing what's coming down the control channel with what's in the list in the radio.

But the radio has to sample (?) what data is coming from the Control Channel looking for the TGID that is in programed in your Radio.(ie=16 bit TGID)

It looks to see if each TGID that comes in is on the list. If one is, it goes to the channel that TG was granted and receives the transmission.

Something in the circuit that should "Block off the passage through" (ie=LEAK) of a talkgroup when in “Closed Mode” is where I think to problem is.

The radio simply stays on the control channel if there's no grant for a TG in the list.

It would appear that the problem is either in decoding the data stream coming from the control channel, or looking up TGIDs in the list. (Or storing them in the list.)

Is this in the IC Chip #???(I do not think so.)
Could it be a FILTER ??? (Maybe!)
Do some Radios have a leak to ground ??? (Maybe!)
Do some Radios have a power leak ??? (Maybe!)

None of those would be causing the problem. It's not like the radio is receiving all transmissions on the system at all times and blocking (or filtering) out the ones not in the list. It's receiving the control channel, comparing DATA (not voice transmissions) to a list of talkgroups. In order for you to hear the transmission the radio has to change frequency to the channel the talkgroup is on.

Thats the Million Dollar question. Where is the LEAK ??

It's either in the logic - in software - or the "decoder" isn't working right.

 

[hobbyhoser175]

I have the leak, and sometimes it itches, but that's another story. Here's my vitals:

System that I am listening to: Minnesota ARMER
Battery Compartment date code: 08A05
Serial #C037551
CPU: F1.4
DSP-App: F1.2
DSP-Voc: F1.0

AireRoscoe helped me with developing a leak test to program into Win96 & upload to the scanner. First pick a control channel and talkgroup that is very active. (I picked a police talkgroup since they always seem to be talking, Bloomington MN to be exact) Then, using Excel I created a spreadsheet with that talkgroup in the middle. Then add/subtract 8, 16, 32, 64, 128... until you get to 8192. Here's what mine looks like:

2616 8192
6712 4096
8760 2048
9784 1024
10296 512
10552 256
10680 128
10744 64
10776 32
10792 16
10800 8
10808 0 Bloomington MN PD
10816 -8
10824 -16
10840 -32
10872 -64
10936 -128
11064 -256
11320 -512
11832 -1024
12856 -2048
14904 -4096
19000 -8192

I then created a new Win96 file with the first column as the talkgroups and a control channel that you recieve in your area. You must either lockout or do not enter the known talkgroup (10808 in my case). Keep the bank closed and upload the file to your Pro96/2096. Scan away & if the display shows MOT: #####, you have the leak. If you press L/OUT, then MAN, then FUNC, then TRUNK, it will display the talkgroup where the leak is. Use the binary program from royalzapper's post to find out where your leak is, if you wnat/need that info.

Like I said, my scanner has the leak & I was going to take it back to the Shack, but maybe I'll try the 1-800 number first?