Re: [Discuss-gnuradio] Gnuradio DCS Module
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.
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
Re: [Discuss-gnuradio] Gnuradio DCS Module
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. 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
[Discuss-gnuradio] Gnuradio DCS Module
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? 2. Does it make sense to have DCS as a tagged stream? Should I chose some other type to communicate DCS ? 3. Are there better ways to extract the digital signal from the audio source than my schematic above? Am I doing something stupid? 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? 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
