On 2014-10-08 01:16, 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.
>
I've now switched back into a sink, which output to stdout. It bugs me a
bit that I haven't found any suitable UI-widget to just display some
info - it seems like a very simple component to have - or maybe a few:
* 'console-like' component with configurable buffer size
* label-like component where a key and value can be set dynamically
But maybe the existing labels can be used but I haven't figured out how?
>>
>> 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.
I failed to mention that my source was already lp-filtered.
> 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.
Thanks, I'm experimenting with that now. I've found how to implement LPF
using fir-filters, but don't quite know how to do DC-blocking. It seems
to me it would require a bandpass-filter. Any docs floating around on
that?
>
> 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).
I think what made my solution work was that I thresholded with several
higher frequencies still there, which made it kind of stable - as long
as low-frequency audio disturbance was not there. In order to make it
more robust, I need to filter more harshly, which will make the ones and
zeroes less pronounced, and I will need a synchronizer.
I've looked at the docs for the MM_clock_recovery, and I understand the
parameter settings - but I don't understand what it actually does - how
does it convey the synchronization/clock info to the next component in
the flow-graph?
Thanks!
/Martin
ps. When I write a flowgraph, I get more and more complicated
expressiosn for parameters. e.g samplerate becomes
sample_rate/lp_decimation1*interp_1/decim_2.... and so on. It would be
nice to be able to refer to another component earlier in the flowgraph.
For example, as sample_rate be able to write:
this.source['sample_rate']
or
source("rr_resampler")['sample_rate'] /
source("rr_resampler")['decimation'] *
source("rr_resampler)['interpolation']
The second example would search the source-chain for a component called
"rr_resampler" and determine the outgoing sample_rate based on that
component's parameters.
>
>>
>> 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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
