webpage AFS-DEC-BIN-HEX conversions

[Pro-95]

Ok so I'm pretty new at this stuff. I keep finding myself looking for a converter for HEX/DEC/BIN/AFS and the ones I've found come bundled in programs. I used the RR pages here to figure out how things are converted when it comes to AFS talkgroups. I then took my limited JavaScript programming experiance with my even less math skills to come up with a conversion webpage.

Please take a vist and let me know what you think.

http://www.mjw.com/scanner/convert.htm

 

[kikito]

Hey that's pretty cool, I like it.

I usually do these type of conversions manually but with your webpage, it's much nicer and quicker.

Thanks for your efforts!

 

[SCPD]

Cool idea! The "Convert from HEX" button does not seem to do anything.
-rick

 

[Pro-95]

Cool idea! The "Convert from HEX" button does not seem to do anything.
-rick

Thanks Rick! It seems I have a problem with 4 or more hex digits. I should have it fixed before to long.

 

[loumaag]

Cool idea! The "Convert from HEX" button does not seem to do anything.
-rick

It does, but all of the functions are limited by the max number that can be used in AFS format. Or at least that is what is seems to me.

Good job, have now stuck it in the "favorites" folder.

 

[Pro-95]

Cool idea! The "Convert from HEX" button does not seem to do anything.
-rick

It does, but all of the functions are limited by the max number that can be used in AFS format. Or at least that is what is seems to me.

Good job, have now stuck it in the "favorites" folder.

Yep on the limitations. Had a goal in mind, acheived it now I can expand it.

The 4 places hex conversion is fixed. I am now working on expanding the conversions for dec to hex and hex to dec to be up to 65535(dec). I am also working on validating the input and possibly allowing AFS to be entered as 00000 as acceptable as 00-000.

After that, who knows.

Let me know if you encounter any other problems.

 

[scannerfreak]

Cool idea! The "Convert from HEX" button does not seem to do anything.
-rick

It does, but all of the functions are limited by the max number that can be used in AFS format. Or at least that is what is seems to me.

Good job, have now stuck it in the "favorites" folder.

Yep, pretty cool. I as well have stuck it in my fav's "scanner stuff" folder! 8)

 

[Pro-95]

Ok, I think I'm done with that page. I elected not to include input validation, at least for now. So the GIGO rules apply.

Now to find something else to convert.

 

[Pro-95]

Ok I found something else to add to the page.....

:arrow: Motorola 6 <> Motorola 3 <> Uniden conversions.

I can't think of anything else. Guess I'm done for now. 8)

 

[kikito]

I can't think of anything else. Guess I'm done for now. 8)

Maybe one more thing....

APCO-25 talkgroups like 29919 or 29983 don't convert properly due to the new talkgroup convention used on those systems.

 

[Pro-95]

APCO-25 talkgroups like 29919 or 29983 don't convert properly due to the new talkgroup convention used on those systems.

Where is there some info on APCO-25 talkgroups? My cursory search revealed more about various APCO-25 training and education programs than guts.

 

[kikito]

Where is there some info on APCO-25 talkgroups? My cursory search revealed more about various APCO-25 training and education programs than guts.

Unfortunately, I don't have the expertise to guide you in the right direction. What I do know is that talkgroups are consecutive in P25 systems, they don't adhere to the same rules of divisible by 16 or 32 like the older systems, plus they don't have "status bits" either and so on....

Maybe the trunked experts in the forum have a better insight on this.

 

[Pro-95]

I've been doing a little reading. Seems as though the APCO-25 digital signal is sent in packets with headers, core and footers. Part of the header includes information pertaining to the type of communication from private calls, talkgroup calls, emergency calls and telephone interconnect. Which as a humorous sidenote.. everything was reffered to as a call except the telephone one. :lol:

So basically the director section of the signal carries the packet of information that contains the talkgroup info, if in fact the signal is a talkgroup type of signal. I have however had no luck in finding any specific information on packet structure.

Also like ACK/NAK APCO-25 signals are error-corrected with an ERC type of information that confirms that the entire packet was received. I also found it quite interesting that (I think this is duplexing signals, although I didn't actually see it refferd to as such) not only can the voice part of the transmission be compressed 16 times the original but that you can also piggy back data along with the signal at the same time without a noticable drop in voice quality. All within a minimal bandwidth. Pretty cool stuff maynard.

Sorry if this is old news to the rest of you, I am just learning this stuff. :wink:

Still, If anyone can provide some insight into the APCO-25 talkgroups I'd like to read some more.

 

[SCPD]

P25 basics (perhaps more than you ever wanted to know)

Talkgroups are 16 bits, that's $0000 to $FFFF in hex or 0 to 65535 in decimal.

Radio ids are 24 bits, that's $000000 to $FFFFFF in hex (some values are reserved) or 0 to 16 million ( no, don't ask me to type that one out - that's what JavaScript is for! ).

System identifiers are 32 bits long - but are composed of two parts - a 20 bit WACN or wide-area C number (yeah, I forgot what the "C" stands for), and a 12 bit Sysid.

WACNs are $00000 to $FFFFF in hex or 0 to 1 million plus in decimal.
Sysids are $000 to $FFF in hex or 0 to 4095 in decimal.

To support roaming, P25 packets come in two forms. Short packets for local users on a "home" site or system and extended packets that include the roaming user's 32 bit system identifier.

In other words, it takes a total of 56 bits (32 + 24) to identify a roaming user on a P25 network.

Channels are 16 bits - but are actually composed of two parts, a 4 bit identifier and a 12 bit channel number.

Channel identifiers are $0 to $F hex or 0 to 15 decimal.
Channel numbers are $000 to $FFF hex of 0 to 4095 decimal.

What's a channel identifier? It's a number that identifies which channel map to use. Each map has a base frequency, channel spacing, and TX offset. P25 supports up to 16 of these identifiers. I *think* identifiers are system-wide but I have not been able to confirm this. They might be site-specific. The identifier selects the channel function. The channel number is plugged into the function/formula to produce an actual frequency.

It's convenient to display the channel in hyphenated form, ie. I-NNN where "I" is the channel identifier digit (or digits) and "NNN" represents the channel number.

Using P25 terminology, the control channel is composed of OSPs or outbound signalling packets. Eack packet is composed of one or more blocks or TSBKs (trunk signalling blocks). These blocks are 12 bytes long. [ The PRO-96 provides the ability to dump these TSBKs over the data cable. ] There are other types of TSBKs but those are for data services, not trunking.

In Motorola call types are a 4 bit value appended to the talkgroup. P25 does something similar but I believe the call type is 5 or 6 bits long. It includes relative priority, emergency, and so on.

-rick

 

[Pro-95]

Actually Rick I'm glad your sharing.

Ok here's some tidbits I found...

Ok to the protocol. If you have a clean capture of the 4-level fm signal the
one thing you will see often is a frame synchronization pattern. According to
the documents its 48bits in length and is hexidecimal (0x55, 0x75, 0xf5,
0xff, 0x77, 0xff). Those frame sync's seperate the frames of data. This is a
key element since if you have detected that pattern it means your 4-level FM
recovery routines are functioning properly.

- each APCO-25 voice call is composed of a series of data units: 1 Header
unit followed by Logical Data Unit 1 and Logical Data Unit 2. Those LDU's
repeat until the end of the voice call. At the end of the voice call there is
something called a terminator data unit.

- what distinguishes a voice frame from a data frame or a terminator frame is
something called a network ID. This network id is 64 bits in length and is the
very first piece of data after frame sync. It basically tells you what type of
packet it is (Header, LDU1, LDU2, Terminator, Data).

- within each LDU packet is the actual IMBE voice data, link control data
(source ID, destination ID, manufacture ID, talkgroup ID, ..), Low speed data
(dont know what this is for), and encryption sync(key ID, algorithm ID). I can
basically get all this data with my parsing routine. I can tell what radio is
keyed up, who they are talking to, and the various signalling messages sent
(emergency, pages, messages,...). I have the raw IMBE voice data but dont know
how to turn the IMBE packets into audio.

- Each LDU contains 9 IMBE packets, each IMBE packet is 144 bits in length,
88 of those bits are raw IMBE voice data. Each IMBE frame represents 20ms of
audio. It seems like during the beginning and end of a call the IMBE frame is
fixed.

- There is only one header packet during the beginning of any APCO25 voice
call. This header unit contains a encryption synchronization pattern,
manufacture ID, encryption algorithm ID, Encryption Key ID, and Trunking
talkgroup ID. It seems like the encryption related data is fixed where the
call is not encrypted (the encryption sync pattern appears fixed and does not
look random).

- Data frames are trellis encoded, I have a TIA APCO-25 document that saids
something about future trunking control packet being based on Data frames. I
guess they encapsulate trunking signalling into data frames. There are
basically 2 types of data frames 1/2 rate and 1/3 rate trellis encoded
packets. The first data frame and all standalone data frames are always 1/2
rate trellis encoded. Subsequent data frames can be 1/2 or 1/3 rate trellis
encoded depending on what type of data call it is. The types are confirmed
(acknowledged) or unconfirmed (unacknowledged). You see with 1/2 rate
encoding 1/2 or your data is forward error correction data. With 1/3 rate 2/3
is data and 1/3 is forward error correction. You loose alot of efficiency
with 1/2 rate, but it is more reliable.

Ok, on to the bits;

16 bits Talkgroup ID
24 bits Radio ID
32 bits SyS ID (20 WACN, 12 Sys ID)

So far I'm at 72 bits unless I'm misunderstanding and Talkgroup is part of Radio ID.

16 bits Channel ID (4 ID, 12 Ch ID) I'm again assuming this is the breakdown for Talkgroup ID????

12 bits OSP's consisting of TSBK's
5-6 bits for call type (Private,Talking,Emergency,Telephone)

That's a lot of bits! 106 according to my math. I am assuming that this is actually transmited in one 128bit stream?

 

[Pro-95]

I think it's beginning to sink in after some more reading.

Header: 648 bits, which contain:
Message Indicator (Encryption technique) (86 bits ??)
Manufacturer's ID (8 bits ??)
Algorithum ID (8 bits ??) (80 = no encryption)
Key ID (16 bits ???)
Talkgroup ID( 16 bits ???)
note: header is ALWAYS broadcast open/clear.

LDU1: 180ms (including header) of 240 bits of which 72 bits contain:
Talkgroup ID
Source ID
Destination ID
Emergency Indicator
Manufacturer ID

LDU2: 20ms of IMBE frame which contains:
88 bits of information(voice/data)
56 bits ERC

240 bits of Encryption which contains:
96 bits of:
Message Indicator
Algorithum ID for Encryption
Key ID for encryption key

note: LDU2 has lots of "extra" room in it. Potentially could contain geographic coordinates or ?????

LDUx: Continuation of transmission information

Terminator: ERC and modified word format.

Also information derived from screen shots: (I can only assume what some of this is)

ISP - upload
SRC - 24 bits
SVC - 8 bits
GRP - 16 bits

OSP - download
RFSS - 8 bits
Site ID - 8 bits
WG ID - 16 bits
WU ID - 24 bits
LRA - 8 bits
P - 4 bits
A - 4 bits
LG - 4 bits
GAU - 4 bits
RV - 4 bits
SVC - 8 bits
SVC Opt - 8 bits
GRP ADD - 16 bits

If anyone can help me with what the above is... TIA

 

[SCPD]

Actually Rick I'm glad your sharing.

Ok here's some tidbits I found...

Ok to the protocol. If you have a clean capture of the 4-level fm signal the

Cool. Wonder where that came from!

12 bits OSP's consisting of TSBK's

Nope, you've missquoted me. Let me try to elaborate a bit more.

A TSBK is a block. It's 12 BYTES, not bits. An OSP is a packet. It's a whole message. It is composed of 1 or more TSBKs. In other works, an OSP is a multiple length of 12 bytes (12, 24, 36, etc.). If that packet should happen to contain a talkgroup (which depends upon the type of message involved), there would be a 16 bit field somewhere inside that packet designated as such. Ditto for channels, radio ids, and so on.

If you take a look at the output from the pro96dmp program, you'll see the TSBKs in raw hex along side the annotated meanings of the various bit fields.

-rick

 

[SCPD]

I have the raw IMBE voice data but dont know how to turn the IMBE packets into audio.

Have this person contact me. We've got this one (raw IMBE to voice) covered I think.

Regards,
Rick

 

[SCPD]

Maybe Bearcat will hire me when I graduate and buy my senior design project.... or maybe I will give it away for free to the public....

Nevermind. This was from December of 1998. The control channel specs weren't done yet. Maybe Uniden or GRE hired this person. Ya think?

-rick