[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Gnuradio DCS Module

From: Jeff Long
Subject: Re: [Discuss-gnuradio] Gnuradio DCS Module
Date: Wed, 08 Oct 2014 05:55:16 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1

On 10/07/2014 07:16 PM, Jeff Long wrote:

Some ideas inline ... hope some of this is useful.

On 10/07/2014 03:30 PM, Martin Holst Swende wrote:
Hi list,

I am pretty new to Gnuradio / SDR, experimenting with a HackRF. As a
startup experiment, I wanted to communicate with simple handheld radio
devices (toy radios). These radios used DCS, and in order for my
computer to bypass their squelch, I need to
1) Determine DCS-code
2) Add DCS to my transmissions

Since I didn't find any suitable tools for that (?), I have now
implemented a gnuradio module to decode DCS. The source code is at
bitbucket [1].

I started out by implementing the DCS decoder via a message block in
python. This seemed a bit hacky, so I decided to implement it in C++
instead following the "Out-of-tree modules" tutorial [2]. In the end, I
implemented it as a Stream Tag block. My thought was that it would add
tags to an audio stream, and a UI component somewhere would pick up the
tags and display to the user (needless to say, a DCS-squelch could be
built using the tagged stream).

I now have a few question, both regarding the digital signal processing
in general, and regarding gnuradio.

1. Currently, my block takes digital input. Here [3] you can see a
picture of how I go from 960 hz sampled audio stream via DC-blocker,
thresholding , interpolation and decimation into a digital signal (to
the 'old' message sink). In the next stage, I'd like to take an audio
source (with a few selectable common audion samplerates) instead, which
means that my block must do all those things within the block itself.
How is this normally done? Do I create a hierarchical block containing
these blocks "under the hood", plus my new digital-in-DCS-decode block?

There's no right way. You can make a hier block in GRC, Python, C++, or
leave it in the top level flow graph. GRC hier block is the easiest if
it works for you.

2. Does it make sense to have DCS as a tagged stream? Should I chose
some other type to communicate DCS ?

The choice of messages or tagged streams has to do with how you want to
process the data downstream. If a downstream block needs the info
associated with a sample (like a squelch) then tags are good. If it's
thought of more as data (like for logging) then messages are good. There
is also a tag-to-message block, so you can have it both ways.

Oh, tag-to-message is part of gr-baz, not gnuradio proper.

3. Are there better ways to extract the digital signal from the audio
source than my schematic above? Am I doing something stupid?

A low pass filter should be used to cut out voice. A rational resampler
can replace the interpolate and 1-in-N blocks. You could combine the LPF
and DC blocker into the taps for the resampler if you want to get fancy.
The threshold can go after the resampler.

I'm not familiar with DCS, but typically a synchronizer block of some
sort is used before the bits are processed. Otherwise, your bit
alignment is due to luck (or short sequences).

4. Are there any suitable UI-components I can use to display DCS
information - e.g. something which show information from streamed tags ,
or mechanisms to modify variables based on tag info?

The QT time sink will display tags.

Grateful for suggestions and ideas.
Martin Holst Swende

[1] https://bitbucket.org/holiman/gnuradio-dcs
[2] http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules
[3] http://martin.swende.se/graph_part.png

Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]