WOW! - I have spotted a massive ERROR in the RR DATABASE

[4phun]

Apparently I am the only person in the whole country other than Don Starr that is interested in using HEX values to program the PRO-96 trunking scanner. One reason to use HEX is that you are able to easily spot the incorrect talkgroups submitted by others to a public database.

I first noticed that the HEX values on RR.COM extended to only three alpha digits while a trunking system uses HEX values to four alpha digits. You can pull out the trusty Microsoft Windows Calculator, set it to SCIENTIFIC, and double check by entering FFF (HEX) and then switching the view to DECIMAL. Yep, the largest value that can exist is 4095 (DEC) when you use only three HEX digits!

What that means for those using Win96 to program the PRO-96, you can not use HEX values from RR.COM until the matter is fixed. In many cases all it will take is to add a trailing zero to the RR.COM value.


You could of course add data to Win 96 in DEC format and then switch to HEX and view the data. It is a ‘radio button’ in the PRO-96 software. Remember the last or low order hex digit represents the various status bits to any talkgroup. The PRO-96 ignores these as far as you are concerned. The PRO-96 does avoid bothering you with digital encryption by moving past any TG with encryption turned on so it clearly reads all the data in the incoming stream and takes notice of it.


Vic

 

[4phun]

Other web sites get the HEX CODES right -not RR

Mike Martin who hosts ScanAtlanta.com gets HEX codes right!

Compare the ScanAtlanta web page for the Cobb county Trunking system
http://www.scanatlanta.com/CobbTRS.htm

to the web page served by radioreference.com
http://snipurl.com/71rk

Notice the use of anything from 2 HEX digits to four HEX digits where appropriate in the ScanAtlanta list under Motorla Codes.

Mike drops the leading HEX digits if they are ZERO which is OK.
The bottom line is no trunking system can be described with only three HEX digits unless it is very small and uses only low number talkgroups.

 

[bear105]

Just a quick observation but aren' t all the 'trailing' zeros left off on the RR database??

I.e. Cobb county Animal control
RR talkgroup 0x077
ScanAtlanta talkgroup 0x770

 

[FPO703]

Just a quick observation but aren' t all the 'trailing' zeros left off on the RR database??

I.e. Cobb county Anaimal control
RR talkgroup 0x077
ScanAtlanta talkgroup 0x770

That is correct. They were removed way back when we were TrunkedRadio.net

 

[loumaag]

... One reason to use HEX is that you are able to easily spot the incorrect talkgroups submitted by others to a public database.

I first noticed that the HEX values on RR.COM extended to only three alpha digits while a trunking system uses HEX values to four alpha digits. ...

The incorrect talkgroup check is partially right, assuming you are not talking about APCO-25 systems. Your statement about trunking systems using HEX values of 4 digits is incorrect. The reason the trailing "status" bit was dropped on the RR database (and previously on TrunkedRadio Net) was the Motorola does not use the 4 digits, only the most significant 3.

What that means for those using Win96 to program the PRO-96, you can not use HEX values from RR.COM until the matter is fixed. In many cases all it will take is to add a trailing zero to the RR.COM value.

The "matter" as you refer to it will never be fixed, at least for non-9600 baud APCO-25 systems, because it was done on purpose. In all cases all it takes is to multiply the HEX value provided by decimal 16 to get the correct HEX value for programing your Pro-96 (or of course you can just plug in a zero in the end of the displayed HEX number).

You could of course add data to Win 96 in DEC format and then switch to HEX and view the data. It is a ‘radio button’ in the PRO-96 software. Remember the last or low order hex digit represents the various status bits to any talkgroup. The PRO-96 ignores these as far as you are concerned. The PRO-96 does avoid bothering you with digital encryption by moving past any TG with encryption turned on so it clearly reads all the data in the incoming stream and takes notice of it.

This is so wrong, I am not sure where to start. The Pro-96 when receiving non-digital audio will ignore all status bits, not just the encryption bit. This means you will hear all transmissions, but just not know what you are hearing as long as it is a group call. When receiving a digital audio stream, it will decode the correct TG number (for example TG 121 will display "MOT 00121") and not the SmartNet rounded to the next lowest 16 multiple. Where do you get the idea the the Pro-96 does not "bother you" with encryption? I guess nobody where you are uses encryption because the Pro-96 will pass it right through on Motorola systems and you get to hear a lot of noise.

By the way, I am not sure where you get the idea Don prefers HEX to Decimal. I don't know one way or the other, but you will note that when you open a "new" template in Win96 the default is set to Decimal for ID groups; to change to HEX you must press the HEX "push button" (a "radio button" is a small circle which is high lighted when chosen like the ID bank choice in Win96).

 

[AngelFire91]

It's already been said by Lou but I wanted to reinforce it. A talkgroup of say 5A1 is in correct Hex format for a Motorola system. The Last hex character on the end of a talkgroup is called the "status bit" In short it tells the radio's on that talkgroup if it is being used as a group, Individual, Encrypted, or Patched talkgroup. There is no problem with the database when using hex. When a Motorola radio is programed you only put in 3 hex characters because it doesn't matter about the last bit for the talkgroup Id. Also I believe that in Win 96 the default is Decimal, How is it easier to find problems in hex? If you can count in Hex then you can count Decimal also and the talkgroups are always going to be the same Hex and Decimal numbers so if a patteren is there in Decimal then it's going to be in Hex. It's just a matter of which you prefer to operate in. But if your going to work in Hex make sure you know how to work in hex first.

 

[DonS]

the talkgroups are always going to be the same Hex and Decimal numbers so if a patteren is there in Decimal then it's going to be in Hex. It's just a matter of which you prefer to operate in.

I think the OP's concern is that the numbers shown by the RR database are not the same between the HEX and DEC columns. For example, in the Santa Clara, CA city system, it lists for the Fire Dispatch group 272 DEC and 011 HEX. The HEX value has the low 4 bits removed, but the DEC value does not (272 DEC == 110 HEX, while 011 HEX == 17 DEC). Also, this convention is not used for 9600 APCO-25 systems (it can't be, as there are no status bits and all bits are significant).

I guess the question is: why does RR throw away the low 4 bits only for HEX values, and not for DEC values? Is this a convention used by some radio manufacturers? If not, then DEC vs. HEX is just a human-readable representation, and it seems (to me) that the same value should be displayed in both columns. Either throw the status bits away in both, or include them in both.

 

[loumaag]

I guess the question is: why does RR throw away the low 4 bits only for HEX values, and not for DEC values? Is this a convention used by some radio manufacturers? If not, then DEC vs. HEX is just a human-readable representation, and it seems (to me) that the same value should be displayed in both columns. Either throw the status bits away in both, or include them in both.

Well, the reason, as I understand it, is the HEX was there to be used to match against Moto channel lists, which you may ... err... happen across. The decimal is there to match the Uniden style of data entry for groups (read that as us humans). Naturally the fully APCO-25, 9600 baud systems don't use this "drop the least significant figure" method and I believe that is one of the things Lindsay has on his "to do" list.

 

[INDY72]

And please remember this db is a constant growing entity (Always something new to work on )

 

[blantonl]

Couple notes here:

1. We don't throw away the last 4 bits for P25 systems (9600 baud control channel). They are preserved.

2. Hex is represented for those that program Motorola radios, where the last 4 bits don't mean jack to a Motorola radio. There isn't any scanner today that is programmed with HEX, so this is irrelevent for scanner listeners.

3. My objective in presenting in HEX format is for those folks who have/need to program a Motorola radio with a tg. There hasn't been any other need than that.

Programming scanners with hex values doesn't seem like a good direction to me. It's not the intention of the database.

Furthermore, Mike Martin has it all wrong, because those HEX values he posts are worthless to someone programming a scanner, and worthless to someone programming a Motorola radio.

I've implemented DEC tg's as a standard across the board for the rr database, and do some translations to Hex and AFS as a convienience to users (on the fly.) I'm not going to change the "standard" just because someone wants to use some special feature in scanner programming software. Use decimal. end of story.

 

[blantonl]

...and I love the thread title!

WOW! - I have spotted a massive ERROR in the RR DATABASE

Make sure you research before you jump to conclusions!