Manually Decoding a DCS Tone

Here I have a recording of FM decoded audio from a certain Motorola
radio. In it you can see a continuous series of level changes, even
when there is no audio (the fuzzy bits). This is the DCS (or
generically CDCSS) used as a requirement to keep the squelch open. You
can also see a continuous tone at the end of the transmission, just
before the noise burst. This continuous tone is the squelch tail
elimination (STE) which when the receiving radio hears, it silences
the speaker output before the noise burst that happens just before the
squelch cuts off.

Cutting the audio file down to a portion of just DCS tone looks like
this. From here you can see that the bitstream is offset from zero so
we want to use Audacity to normalize this, as well as amplify the
signal a bit. After applying the Normalize effect with remove DC
offset and normalize maximum aplitude, we get a signal which looks
like this.

Now we want to extract the actual bits from the stream so we can
decode them into a DCS code for radio operation. In order to make sure
we get the bit spacing correct, we want to add a second channel with a
continuous square wave at 134.4Hz. We add a new track with a square
wave by using Generate->Tone, set the waveform to square, and set the
frequency to 134.4Hz. We’ll also zoom in again, as DCS only uses a
repeated bitstream 23 bits long.

From here you want to pick a transition of the square wave and
transcribe whether the sampled audio is above or below the zero
line. Taking the low to high transition, we get the bit series:

10000001110001101111100100000011100011011111001 ...

Before continuing we need a bit more information about how DCS’s
bitstream is decoded and encoded. DCS is encoded in a Golay code,
which is an error correcting data encoding. A particular DCS code is
represented as a 3 digit octal code, which translates to 9 bits of
data. This data is encoded in a Golay(23,12) code, which contains 12
bits of data and 11 check bits used for error correcting. Since only 9
bits are actually used for DCS, the first 3 bits are the fixed
sequence 100. However DCS actually transmits the Golay code in
LSB order, which means that this, and the data must be reversed. With
this information we can reverse the bistream, split it into words, and
split it into data and check bits. This gives us a Golay word that
looks like this:

100111110110 00111000000
----data---- ---check---

Stripping the initial 100 we get the data to be 111110110
or in octal, 766. But wait! That isn’t a valid DCS tone. Well it
turns out that Golay codes have interesting properties, meaning that a
single Golay code can be decoded into multiple different data values
depending on where the start bit is considered. DCS doesn’t have these
alternative rotations as possible options to help prevent inadvertent
conflicts. You can also invert the code and rotate it again to get
different values (this is where ‘inverted’ DCS comes from). I’m not
going to go into this in too much detail, but
this site goes into much
more detail (and has very helpful tables so you don’t actually have to
do the next step).

In order to find the real code, we now have to rotate the entire code
(including the check bits) to find other instances of the bit sequence
100. We find

100011100000 01001111101
----data---- ---check---

and

100000010011 11101100011
----data---- ---check---

The first of which is 340 in octal, again not a valid DCS
option, but the second is 023, one of the most common DCS
choices (easiest to scroll to). I recommend just trying this one
before manually decoding it like I did…

I’m not going to cover the check bits in this post, but I found
this
very helpful.