Use Hex instead of Decimal for Talkgroup input

[robotastic]

The listings for the a system's talkgroups on Radio Reference is provided in both a decimal and hexadecimal format. For P25 systems, hexadecimal and decimal values are the same. On SmartNet II, they are different. The decimal representation of the talkgroup address includes 4 status bits (all set to zero) appended to the end of the address. The hexadecimal representation does not include the status bit and is simply the address.

Off the top of my head, the following would be needed:

• change the CSV input to parse the HEX column and convert that into an integer that would be used to set the Talkgroup.num
• change the SmartNet message parsing so that the talkgroup address pulled from SmartNet Control Channel messages is simply the talkgroup address. Currently we are using the talkgroup+status bits internally for SmartNet talkgroups
• create a function that allows for Talkgroup Numbers to be printed in different formats: hex, decimal, and decimal shifted left 4 times (this will give you the same decimal value as what is on Radio Reference). This formatting should probably be set at the system level instead of the instance level.
• update OpenMhz CSV parsing. Right now a HEX column is not allowed on OpenMHz. We can switch to just using the same CSV as used for Trunk Recorder. This could make life better for people. It would use the HEX value from the value instead of the DEC value to get the talkgroup value.

Impacts: Doing this would require some work from people using OpenMHz. With people using P25, there is no change to talkgroup number so they can just change the CSV format at some point. For people with SmartNet systems, the numbering will be changing so they need to make sure TR and OpenMHz both get changed at the same time.

If this is something you would be excited to see, give it some thumbs up or leave a comment.

[HarrisonWilson]

It's always been a little annoying that the scanner companies have been using the wrong decimal TGID/UID number format for years on Type II systems, but it seems like this is a lot of effort considering the bulk of these systems have plans to migrate to P25 (or something else) if they aren't already in progress for doing so.