Re: [Discuss-gnuradio] [SOLVED] Clock Recovery MM
Ooops. Good catch Bastian.
On Fri, Sep 26, 2014 at 2:29 PM, Tom Rondeau t...@trondeau.com wrote:
On Tue, Sep 9, 2014 at 3:21 PM, Bastian Bloessl bloe...@ccs-labs.org
wrote:
On 09 Sep 2014, at 15:42, Tom Rondeau t...@trondeau.com wrote:
On Mon, Sep 8, 2014 at 5:49 PM, Bastian Bloessl bloe...@ccs-labs.org
wrote:
Hi all,
looking at the clock recovery MM code, I wonder if
d_omega_relative_limit is a relative or absolute deviation from d_omega.
Here it looks like absolute
https://github.com/gnuradio/gnuradio/blob/next/gr-digital/lib/clock_recovery_mm_ff_impl.cc#L107
Here it is relative
https://github.com/gnuradio/gnuradio/blob/next/gr-digital/lib/clock_recovery_mm_ff_impl.h#L57
(even though this code has no impact since d_{min,max}_omega is not
used.)
I don’t have access to the book linked in the docs atm.
Best,
Bastian
It is supposed to be relative. I'd have to verify the math on that line
107 in the .cc file, but it's supposed to adjust the center position of the
current omega estimate and then apply the clipping. Then it adds the mid
point back to get it back to where it's centered. Try walking through that
line one more time to verify that it's doing that properly. But yes, it's
supposed to be relative to the original setting of omega.
So this line asserts that the current (absolute) deviation (d_mega -
d_omega_mid) is smaller than the maximum allowed absolute deviation
(d_omega_mid * d_omega_relative_limit). AFAIS, the second argument is
missing “* d_omega_mid”.
I will create a patch, then you can check if I got you right.
Bastian
Just to follow up, Bastian was correct and we merged his patch in this
week.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
Bob McGwier
Co-Owner and Technical Director, Federated Wireless, LLC
Professor Virginia Tech
Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY
Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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. 4. Are there any suitable UI-components I can use to display DCS information - e.g. something which show
[Discuss-gnuradio] Why is fft output complex?
I can't wrap my head around why fft transform of complex signal produces a complex output. After all the output reflects the amount of energy per frequency bin and frequency bins and energy are both real numbers, no?I'm trying to write a python script to analyze the energy across frequency bins but I don't know where to insert a complex to mag block. I think if I can understand the fft I will know to put the complex to mag. ThanksBrad.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why is fft output complex?
On 10/11/2014 05:38 PM, k1...@comcast.net wrote: I can't wrap my head around why fft transform of complex signal produces a complex output. After all the output reflects the amount of energy per frequency bin and frequency bins and energy are both real numbers, no? I'm trying to write a python script to analyze the energy across frequency bins but I don't know where to insert a complex to mag block. I think if I can understand the fft I will know to put the complex to mag. The output of an FFT is complex because it contains magnitude _and_ phase. If the output is I,Q (cartesian coordinates) then the magnitude is the length of the vector from 0,0 to I,Q or sqrt(i^2 + q^2). The phase of the signal is atan2(Q,I). Note that the FFT transforms Voltage samples into Voltages per frequency bin. When you say energy you may mean power which is the magnitude squared or (i^2 + q^2). jeff, wa1hco Thanks Brad. ___ 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] Why is fft output complex?
On Oct 11, 2014, at 5:38 PM, k1...@comcast.net k1...@comcast.net wrote: I can't wrap my head around why fft transform of complex signal produces a complex output. After all the output reflects the amount of energy per frequency bin and frequency bins and energy are both real numbers, no? I'm trying to write a python script to analyze the energy across frequency bins but I don't know where to insert a complex to mag block. I think if I can understand the fft I will know to put the complex to mag. Thanks Brad. _ Dear Brad, What you write is mostly correct. But you are thinking of the power spectrum, which is the modulus of the FFT and thus entirely real. An FFT contains more information. For example, a Fourier Transform (the continuous version of an FFT) can be inverted using an Inverse Fourier Transform to exactly reproduce the original time-domain waveform.That would not be possible using the power spectrum alone, since information is lost in going from the complex Fourier Transform to the power spectrum. --Dan Marlow ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why is fft output complex?
Thank you this helps a lot. I'll place my complex to mag block directly at the fft output. Then I can send that to a vector sink and review my bin data. [Brad Hein]-Original Message-From: wa1...@wa1hco.netTo: discuss-gnuradio@gnu.orgCc: Sent: 2014-10-11 17:59:24 GMTSubject: Re: [Discuss-gnuradio] Why is fft output complex? On 10/11/2014 05:38 PM, k1...@comcast.net wrote: I cant wrap my head around why fft transform of complex signal produces a complex output. After all the output reflects the amount of energy per frequency bin and frequency bins and energy are both real numbers, no? Im trying to write a python script to analyze the energy across frequency bins but I dont know where to insert a complex to mag block. I think if I can understand the fft I will know to put the complex to mag. The output of an FFT is complex because it contains magnitude _and_ phase. If the output is I,Q (cartesian coordinates) then the magnitude is the length of the vector from 0,0 to I,Q or sqrt(i^2 + q^2). The phase of the signal is atan2(Q,I). Note that the FFT transforms Voltage samples into Voltages per frequency bin. When you say energy you may mean power which is the magnitude squared or (i^2 + q^2). jeff, wa1hco Thanks Brad. ___ 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
