From apco25_scanner@hotmail.com Mon Dec 14 14:06:45 1998
Path: news-f.iadfw.net!cabal1.airnews.net!news.airnews.net!cabal12.airnews.net!newspump.monmouth.com!newspeer.monmouth.com!nntp2.dejanews.com!nnrp1.dejanews.com!not-for-mail
From: apco25_scanner@hotmail.com
Newsgroups: rec.radio.scanner
Subject: APCO25 Digital Scanner Project
Date: Mon, 14 Dec 1998 20:06:45 GMT
Organization: Deja News - The Leader in Internet Discussion
Lines: 180
Message-ID: <753r4k$h2i$1@nnrp1.dejanews.com>
NNTP-Posting-Host: 208.194.201.183
X-Article-Creation-Date: Mon Dec 14 20:06:45 1998 GMT
X-Http-User-Agent: Mozilla/4.02 [en] (WinNT; I)
X-Http-Proxy: 1.0 x2.dejanews.com:80 (Squid/1.1.22) for client 208.194.201.183
Xref: news-f.iadfw.net rec.radio.scanner:159893

My senior design project is to build a APCO-25 Digital Scanner that is
capable of decoding the APCO-25 digital bitstream. I have gathered the
necessary documents from PUBLIC sources. Since I am working off of public
documents I should be safe. The only problem I have ran into is actually
playing back the digital audio(IMBE Voice Coder), I can get everything
else(Unit ID's, Talkgroup ID's, Infrastructure Signalling, Low Speed Data,
Link Control Data, Data Packets, ...).

I got all my info from public TIA (Telecommunications Industry Association,
www.tiaonline.org) Project 25 / APCO-25 documents from my university library.
Actually you have to pay a fee for copies of these standards but since my
university library does that for me, its free....

First off Here's what I have found out.

- APCO25 modulation is a 4-level FM QPSK signal. If you tune your scanner to
an APCO/Astro channel and hook up the discriminator out to a scope it looks
like 4 sine waves that are constantly bouncing around. One thing I have
noticed is that during the beginning and end of calls there looks like its a
fixed pattern or at least a repeating pattern. It turns out that the pattern
is link control frames that are repeated at the end of a call, you can even
hear it, sounds like a buzzing pattern, normally it sounds like a random
noise.

- Does anyone know if there is a off the shelf IC that does this, I heard a
professor mention a company called MXCOMM? For now I will stick with the
DSP/Sound card method.

- What needs to be done is to build a circuit that can reliably decode those
4-level FM signals. The 4 levels are called di-bits (01, 00, 10, 11). Once
you can decode those di-bits its a matter of assembling that data and parsing
that protocol. (simple isn't it?). I am trying to use the FLEX decoder
circuit that was released to the public (the FLEX modulation method is also
4-level FM, dont ask me for a FLEX scanner since its already done and
publically available).

- To reliably decode the 4-level signal you need to do some pretty complex
math on the data. The modulation sends 4800 symbols/sec (each di-bit symbol
is 2 bits thus APCO-25 has a raw 9600bps data rate. First you need to send
the scanner discriminator signal to a A/D converter then the digital data is
sent to a Intergration and Dump filter routine followed by a Stochastic Clock
recovery routine (sounds simple...) once that is done you get di-bits (the
raw 4-level FM data). This can be done using a high quality A/D converter and
then processing the data. I am thinking about using the Turtle Beach
Pinacle/Fiji sound card since it have very clean A/D's and also has a
Motorola 56000 DSP onboard that can run my code that does the precise 4-level
FM QPSK bit recovery.

From what I have heard, future public safely radio systems world-wide will be
based on APCO-25, in europe its called the Tetra standard. The protocol was
designed by Motorola back in the early 90's and released as a public standard
in 1995 (very unusual for Motorola to make a public standard, they are
usually proprietary). Since then quite a few manufactures are building
APCO-25 radios (Motorola, Transcript, GE/Ericcson ...) The APCO25 system is
used for both conventional and trunked systems. I believe the trunked systems
are still partially analog and the rest is digital. What I mean is that the
control channel is analog (can be decoded by the trunking tracker) but the
voice and data channels are all digital. Maybe someone will interface my
APCO-25 digital decoder to a trunking tracker, that way we will be able to
follow trunking systems that are APCO-25 but still use the old analog control
channel standard. But when the control channel goes digital I will be able to
do all of it in my setup.

To make my project simple I am not going to build a digital scanner that can
work on trunking systems, since the control channel is currently analog. But
that may change in the near future. And also because the calls will bounce
around so much it will be hard for me to debug. For now I will monitor and
try to decipher a conventional APCO-25 system. If I really wanted to monitor
a APCO25 trunked system I would just program my scanner with all the digital
voice channels and listen to those. Although the calls will bounce around..

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.

I guess all we are interested in is to hear the Audio. Thats what I dont
have. IMBE stands for Improved MultiBand Excitation. It is basically a Voice
Coder. It is designed to take 20ms of 8Khz samples with 8 bit resolution
voice and turn that into 144 bits with decent voice reproduction. Now thats
pretty dam good compression (8Khz * 8bits / 1000bps * 20ms = 1280bits/20ms,
for IMBE its only 144bits, that about a 9x compression).

Note IMBE is designed for Voice, not Music or Tones. Its modeled after the
english speaking male human vocal track. IMBE was developed by DVSI
(www.dvsinc.com). The IMBE vocoder used in APCO-25 is a rate 4800bps vocoder.

In APCO-25 all of the data is highly protected by forward error correction
routines (hamming, reed-solomon, golay, trellis). I wont go into any detail
here. But one must understand these error correction encoding methods to
extract the raw elements. They are all there (the raw data), you dont really
need to forward error correct the data. To do forward error correction codes
would require alot of CPU power.

Now DVSI sells a DSP board called the VC-20 that can decode/encode IMBE. It
costs big bucks (between $1000-$2000). Its basically a TI DSP board with
their IMBE vocoder onboard. You feed it IMBE frames and it generates analog
audio, it can go the other way.

Now if someone kindly donates one of these boards to me I will have a fully
functional APCO25 scanner. please... please... please... :-) I might even get
my other college associates to try and port the IMBE algorithm to a Windows
95/NT multimedia audio codec. DVSI, were just kidding...... hate to image
doing something illegal.... :-(

Now if the IMBE voice is encrypted we are out of luck, sort of... APCO-25
calls for a the DES encryption method with 56bit keys. I guess there are
public domain DES rotines out there, anyone what to try and decode a DES
encrypted call, might take years. I have a theory, since I have noticed that
IMBE voice calls always begin and end with a fixed pattern we have
information that makes it tons easier to decrypt. We can try different keys
on the data until it matches this fixed pattern at the begining and end of
the IMBE voice call... once we have the key its simple to run the DES decoder
and get the raw unencrypted IMBE voice data.

Image this, hook up your scanner to my 4-level FM recovery circuit, the PC
will process the signal and produce di-bits, my parser program will display
all the APCO-25 signaling data, and the IMBE will be routed to a Windows
Multimedia Codec to be played out on the speaker... What a dream... Its
possible, I am almost there...

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....

Any comments or suggestions?

Image if we build on this project, we could write this as a Active X
component, that will let any windows programmer write around these routines.
We could log all public safety calls, scan for radio Id's in our programs,
record and playback audio for a specific unit id. Listen for emergency alarm
signalling packets......

More to follow..

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own