Re: [Discuss-gnuradio] Gnuradio DCS Module

On 10/07/2014 07:16 PM, Jeff Long wrote:
> Martin,
>
> 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
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio