Forum: GNU Radio EDACS Control Channel

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
4ab77a35413c818c142d38dd1026080f?d=identicon&s=25 Ryan Pape (Guest)
on 2006-04-15 23:35
(Received via mailing list)
Finally having all the pieces in place I need, I want to use the new
GMSK code to decode an EDACS trunked radio control channel.


Given my rudimentary knowledge on the topic (and gnuradio in general)
which (if any) of the examples present would be my best starting point
given that I'm hoping to do this, even initially, right off the air
with the TV RX?

Some details at
http://users.netropolis.net/maverick/scanners/edacs.htm for anyone
interested.

Most relevant snippet for the uninitiated:
~~~~

Modulation: It looks like GMSK (Gaussian Minimum Shift Keying) which
is basically the same thing as two level FSK keying except that the
data stream is passed through a low pass filter before modulating the
carrier. This reduces the high frequency components allowing the
control channel to fit within a 12.5KHz channel. Accordingly, a simple
data-slicer circuit can be used to receive the control channel
information.

Baud Rate
    9600 Baud
Frame Sync
    Frame synchronization is achieved by sending the following 48 bit
sequence:
    000101010101010101010111000100100101010101010101
    or
    0x155557125555 Hexadecimal
Data Frames
    After transmission of the frame synchronization sequence TWO data
frames will be transmitted and then the whole cycle repeats ad
infinitum. Each data frame is 120 bits long; this means 288 bits are
transmitted in each cycle (2x120 bits for the data frames and 48 bits
for frame sync).
432f63ac90470dc61f8b2610987ce0b5?d=identicon&s=25 Frank Brickle (Guest)
on 2006-04-16 01:37
(Received via mailing list)
If you poke around the net, you will probably be able to find the source
for an old DOS program that decodes EDACS control channel. It's called
"Trunk Tracker."

I also have original source for an EDACS control channel decoder of my
own from a number of years ago. Unfortunately all that remains is a
hardcopy, but if you want, I can scan and provide that, probably.

Both of these assume that the demod and bitsync have been performed
already and are being fed to their inputs as binary streams.

Frank
4ab77a35413c818c142d38dd1026080f?d=identicon&s=25 Ryan Pape (Guest)
on 2006-04-16 02:01
(Received via mailing list)
I am comforatable with my prospects once I have that bit stream...it
is plugging the pieces together  to get to that point that I am having
trouble with.
D3cc279f8f85b552f33033efbfb296e8?d=identicon&s=25 Rick Parrish (Guest)
on 2006-04-16 02:20
(Received via mailing list)
Frank Brickle wrote:

>If you poke around the net, you will probably be able to find the
>source for an old DOS program that decodes EDACS control channel. It's
>called "Trunk Tracker."
>
>
I think "Trunk Tracker" is a trademark of Uniden. See
http://www.trunktracker.com/ ...

Ryan wrote:

>Some details at
>http://users.netropolis.net/maverick/scanners/edacs.htm for anyone
>interested.
>
>
The URL provided by Ryan is from a December 1997 rec.radio.scanner
newsgroup posting. That code evolved into a program called E-trunk.

Things to be wary of the code: It was written for Borland's Turbo-C
compiler as a 16 bit DOS program. The size of a C "int" is 16 bits here.
The program assumes direct access to an 8250 compatible UART. It
installs it's own interrupt service routine. It uses the progammable
timer-counter as a time-reference.

You can find information about E-trunk on the Trunker Yahoo! groups
mailing list.

-rick
432f63ac90470dc61f8b2610987ce0b5?d=identicon&s=25 Frank Brickle (Guest)
on 2006-04-16 02:35
(Received via mailing list)
Rick Parrish wrote:

> I think "Trunk Tracker" is a trademark of Uniden. See
> http://www.trunktracker.com/ ...

Yes, right, sorry. It's been awhile.

> Things to be wary of the code: It was written for Borland's Turbo-C
> compiler as a 16 bit DOS program. The size of a C "int" is 16 bits here.
> The program assumes direct access to an 8250 compatible UART. It
> installs it's own interrupt service routine. It uses the progammable
> timer-counter as a time-reference.

IIRC the bitslicing code is separable from the decoding functions, and
the 16-bit-itude isn't a huge obstacle. The hardest thing to get your
mind around is the fact that the decoding algorithm uses the sync vector
as a terminator, not a header. That is, it uses the sync vector of the
(logically) upcoming frame to cue the decoding of the data from the
current frame.

There's a lot of UI goo also, but not too hard to ignore. The guts are
pretty straightforward.

Frank
D3cc279f8f85b552f33033efbfb296e8?d=identicon&s=25 Rick Parrish (Guest)
on 2006-04-16 05:47
(Received via mailing list)
Ryan Pape wrote:

>Given my rudimentary knowledge on the topic (and gnuradio in general)
>which (if any) of the examples present would be my best starting point
>given that I'm hoping to do this, even initially, right off the air
>with the TV RX?
>
>
To follow-up on Ryan's original question ... I've looked at the examples
and documentation. A few grumbles ...

1. I can't find straightforward examples.
2. there are no comments (no, the GPL preamble doesn't count)

Part of the problem (for me at least) is that I don't write Python. It's
just not my choice for scripting.

Let me see if I can translate what Ryan wants into the types of building
blocks found in GNU radio.

1. something to convert the USRP into a NBFM receiver. I've seen an NBFM
example but again, it's all python so I can't tell where to modify it
for this application. I'd like to break this out into two peices.
1a. "how-to" example that downconverts an RF signal into an IF or
baseband signal
1b. "how-to" example that builds on the above to produce AM, FM, or NBFM
audio from the baseband or IF samples; this includes various bandwidths
ie. 100 khz, 30khz, 15khz and 8 khz.
2. in the above NBFM block-chain there needs to be a source that
produces demodulated audio samples at a decent "hi fi" sample rate;
there should be no de-emphasis or low/high pass filtering of this audio
(functionally equivalent to unfiltered FM discriminator audio).

If we can get audio samples at something like 44100, 48000 or even 96000
samples per second ... we're almost home. It doesn't take much more work
to handle clock recovery and crunch the audio samples into a 9600 baud
bitstream.

Some other nice-to-have how-tos are:

1. read data from an audio file (with the audio chunks delivered in
"real" time) and/or record to an audio file.
2. a sample processing block that adds some sort of audio effect along
with example plumbing that uses the audio.in and audio.out (PC
microphone and speakers).

Someone like Ryan could use #1 or #2 as a way to test his code without
an actual USRP.

-rick
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2006-04-16 06:30
(Received via mailing list)
On Sat, Apr 15, 2006 at 10:43:40PM -0500, Rick Parrish wrote:
>
> 1. I can't find straightforward examples.

Start here:
  http://www.gnu.org/software/gnuradio/doc/exploring...


The non-GUI examples are considerable more simple than the GUI
examples.   Try usrp_wfm_rcv_nogui.py (Yes, it's wideband, not
narrowband, but it's pretty simple).

For narrow band rx, try usrp_nbfm_rcv.py

> 2. there are no comments (no, the GPL preamble doesn't count)

Several of the examples contain comments, as does the majority of the
guts of the implementation.  We generally don't comment stuff that's
obvious.  We do assume a working knowledge of python.

> Part of the problem (for me at least) is that I don't write Python. It's
> just not my choice for scripting.


Nice tutorial here: http://docs.python.org/tut/tut.html
Or if you prefer PDF, try this: http://docs.python.org/download.html


> Let me see if I can translate what Ryan wants into the types of building
> blocks found in GNU radio.
>
> 1. something to convert the USRP into a NBFM receiver. I've seen an NBFM
> example but again, it's all python so I can't tell where to modify it
> for this application. I'd like to break this out into two peices.

Extract receive_path from usrp_nbfm_rcv.py

> 1a. "how-to" example that downconverts an RF signal into an IF or
> baseband signal

Take a look at gnuradio-examples/python/usrp/usrp_rx_cfile.py.
It tunes the front end and DDC, decimates and writes the resulting
complex baseband data to a file.

> 1b. "how-to" example that builds on the above to produce AM, FM, or NBFM
> audio from the baseband or IF samples; this includes various bandwidths
> ie. 100 khz, 30khz, 15khz and 8 khz.

http://www.nd.edu/~dshen/GNU/Tutorial/7.html
http://www.nd.edu/~dshen/GNU/


> Some other nice-to-have how-tos are:
>
> 1. read data from an audio file (with the audio chunks delivered in
> "real" time) and/or record to an audio file.

In gnuradio-examples/python/audio:

   audio_play.py
   audio_to_file.py
   audio_copy.py

> 2. a sample processing block that adds some sort of audio effect along
> with example plumbing that uses the audio.in and audio.out (PC
> microphone and speakers).

  spectrum_inversion.py


Eric
D3cc279f8f85b552f33033efbfb296e8?d=identicon&s=25 Rick Parrish (Guest)
on 2006-04-16 08:38
(Received via mailing list)
Eric Blossom wrote:

>>1. I can't find straightforward examples.
>>
>>
>
>Start here:
>  http://www.gnu.org/software/gnuradio/doc/exploring...
>
>
I did. Will look again after I get some sleep.

>>2. there are no comments (no, the GPL preamble doesn't count)
>>
>>
>
>Several of the examples contain comments, as does the majority of the
>guts of the implementation.  We generally don't comment stuff that's
>obvious.  We do assume a working knowledge of python.
>
>
Okay, I can see one reason why some of the C++ source files don't have
comments.

// WARNING: this file is machine generated.  Edits will be over written

Browsing through other C++ source files ... I don't see much. A LOT of
files have zero comments (aside from the GPL preamble).

-rick
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2006-04-16 23:15
(Received via mailing list)
On Sun, Apr 16, 2006 at 01:32:18AM -0500, Rick Parrish wrote:
> Eric Blossom wrote:
>
> >>1. I can't find straightforward examples.
> >>
> >Start here:
> > http://www.gnu.org/software/gnuradio/doc/exploring...
> >
> >
> I did. Will look again after I get some sleep.

OK.

> // WARNING: this file is machine generated.  Edits will be over written
>
> Browsing through other C++ source files ... I don't see much. A LOT of
> files have zero comments (aside from the GPL preamble).

Generally the comments are in the .h files, where they can be
extracted by doxygen.  One can consider this a bug or a feature.

Eric
This topic is locked and can not be replied to.