I've been looking around a little bit to see what I could find out
about GE / Ericsson's EDACS trunked radio control channel protocol.
Although I didn't find enough information to allow one to decode
talkgroup and frequency assignments, I think I did come up with enough
to allow someone to receive outbound control channel messages. Perhaps
someone else can then figure out how to interpret these control channel
messages and be nice enough to post their findings and perhaps even
design and market something like a "Trunktracker" board for EDACS
systems (and while you're at it please make it do Motorola trunked
systems too, and also act as an decoder for Motorola and Mobitex mobile
data terminal transmissions, POCSAG/GOLAY/FLEX paging, CTCSS, ACARS,
subaudible signalling, digitally coded speech, et cetera).


     The control channel data is transmitted over the air at 9600 baud
using Gaussian Minimum Shift Keying (GMSK). The upshot of this is I
think it should be possible to receive the control channel using
something as simple as the clipping circuit used to receive Motorola's
trunked radio control channel or mobile data terminal transmissions. It
would probably be a good idea to use Dejanews or Altavista to find
postings giving more information on those Motorola systems since they
explain some of the same things I'm going to talk about here. It might
even be possible to rewrite one of the posted Motorola programs even
though the coding and commenting style of the original writer will
probably make you slowly rip all your hair out of your scalp.


     Like any other digital system, there has to be some way of letting
the receiver synchronize with the start of a transmitted message. This
is done by regularly sending the following 48 bit synchronization
sequence:

      Sync Sequence :  000101010101010101010111000100100101010101010101
                       (or 155557125555 in hexadecimal notation)

Every time one sees this sequence in the received bit stream one knows
that the following 120 bits form a transmitted message. In order to
increase the number of messages transmitted each second GE decided to
send the sync sequence before only every second message. So the
transmitted data stream looks something like:

               Frame sync, message slot 1, message slot 2,
               Frame sync, message slot 1, message slot 2,
                         and on and on it goes

Some important system status / information messages will be repeated in
both message slots.


     Now that one knows how to pick off the individual messages off the
air one must convert each 120 bit long message into the 40 information
bits. This turns out to be really easy: the 40 information bits are sent
in order repeated three times. The second time all the information bits
are inverted. Effectively one has a really primitive and wasteful error
correcting scheme - in the received message invert bits 41-80, then read
off the information bits given by bits (1,41,81), (2,42,82), (3,43,83)
and so on. If no receive errors occured then all three bits in each
position will be the same. If an error occured just ignore that bit that
doesn't match the other two. I'm not sure why the system designers
didn't use some sort of convolutional or block error correcting code
which would require much less overhead (maybe the designers had been
smoking a little too much of that wonderfully wierd wacky weed).


     One verifies that the received information bits are correct with a
cyclic redundancy check. There are 28 actual information bits while the
remaing 12 are the transmitted CRC code. One can calculate the CRC code
using the following procedure:

              1. Load a 12 bit register R with hex 7D7
              2. Zero the 12 bit CRC register
              3. If the information bit is 1 then
                 XOR the CRC register with R
              4. If the rightmost bit of register R is zero then
                 shift R right by 1 bit, otherwise
                 shift R right by 1 bit and then XOR with hex A9C
              5. Go back to step 3 until all 28 information bits
                 have been processed.

This calculated CRC should match bits 29-40 of the message or else the
received message must be considered invalid.


     At this point I've pretty much exhausted all of my information
sources. I don't have any information on how the 28 information bits are
formatted or translate into frequency and talk-group assignments. I
would imagine that anyone who gets a decoder up and running for an EDACS
system should be able to figure such things out in relatively short
order. I also don't know whether or what information an EDACS system
sends to mobile data terminals over a trunked system control channel -
some literature seems to imply that the trunked control channel
signalling can be used for more than just handling the trunked radio
system.