[Discuss-gnuradio] Control loop in GNURadio
Hello, I need to implement some control loops as GNURadio blocks, I had a look at the code base and I found the gr::blocks::control_loop class which, despite his name is specialized for phase lock loops. Am I missing something or a general PID control loop implementation does not exist in GNURadio? Thanks. Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Hilbert transform
Hi Tom, As hilbert transform is a high-pass filter which only allows the positive frequency components.And we know that only a complex signal can have a single sided spectrum,not a real signal.So, i am still confused that why the signal isn't showing any imaginary part??May b i am not understanding fully.. On Sun, Aug 17, 2014 at 10:45 PM, Ali wrote: > Thanx Marcus and Tom fr ur explanations. I will read further and ask any > questions if i have. > > > > > Tom Rondeau wrote: > > > On Sun, Aug 17, 2014 at 11:04 AM, jason sam wrote: >> >> Hi, >> I have made a simple flowgraph as attached.I have on query that when i >> observe the signal coming out of the 'Hilbert transform' block using a >> time sink then its imaginary part is shown to be zero.According to the >> theory the hilbert transform of a signal x(t) is: >> x(t)+jx~(t) >> where x~(t) is the quadrature phase component of x(t).Then why is the >> signal from the hilbert block has zero imaginary part?? >> Regards, >> Ali > > > > The Hilbert transforms a real signal into an analytic signal. Think about > your case this way: you start with a real sine wave, so in the frequency > domain, you have a delta function at +f and -f. But if you have that same > sine way as a complex number, then you'll only have a delta at +f. A sine > wave travels along the unit circle, but in which direction? A complex > (analytic) signal gives you the value and the direction, like a vector > instead of a scalar. So we've reduce the ambiguity of the solution by > providing the direction: clockwise or counter clockwise. > > The Hilbert transforms the signal from real to complex by removing the values > in the negative frequency. In fact, most HIlbert transforms (like the one > here in GR) are just high-pass filters with the passband starting at 0 Hz > that provide this conversion process. > > I wrote a post showing the Hilbert transform effects without actually > explaining it. Still, it might be helpful to understand it: > > http://www.trondeau.com/blog/2013/9/26/hilbert-transform-and-windowing.html > > Tom > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Hilbert transform
On Mon, Aug 18, 2014 at 11:22 AM, jason sam wrote: > Hi Tom, > As hilbert transform is a high-pass filter which only allows the > positive frequency components.And we know that only a complex signal > can have a single sided spectrum,not a real signal.So, i am still > confused that why the signal isn't showing any imaginary part??May b i > am not understanding fully.. Not sure. I think you definitely understand the concept. By removing the negative frequencies, you /must/ add an imaginary part to the complex signal. Basically, the Hilbert, as you understand, essentially just adds the appropriate imaginary part. I just tried your example, and things looked fine for me: http://imgur.com/z305wlS Tom > On Sun, Aug 17, 2014 at 10:45 PM, Ali wrote: > > Thanx Marcus and Tom fr ur explanations. I will read further and ask any > questions if i have. > > > > > > > > > > Tom Rondeau wrote: > > > > > > On Sun, Aug 17, 2014 at 11:04 AM, jason sam wrote: > >> > >> Hi, > >> I have made a simple flowgraph as attached.I have on query that when i > >> observe the signal coming out of the 'Hilbert transform' block using a > >> time sink then its imaginary part is shown to be zero.According to the > >> theory the hilbert transform of a signal x(t) is: > >> x(t)+jx~(t) > >> where x~(t) is the quadrature phase component of x(t).Then why is the > >> signal from the hilbert block has zero imaginary part?? > >> Regards, > >> Ali > > > > > > > > The Hilbert transforms a real signal into an analytic signal. Think > about your case this way: you start with a real sine wave, so in the > frequency domain, you have a delta function at +f and -f. But if you have > that same sine way as a complex number, then you'll only have a delta at > +f. A sine wave travels along the unit circle, but in which direction? A > complex (analytic) signal gives you the value and the direction, like a > vector instead of a scalar. So we've reduce the ambiguity of the solution > by providing the direction: clockwise or counter clockwise. > > > > The Hilbert transforms the signal from real to complex by removing the > values in the negative frequency. In fact, most HIlbert transforms (like > the one here in GR) are just high-pass filters with the passband starting > at 0 Hz that provide this conversion process. > > > > I wrote a post showing the Hilbert transform effects without actually > explaining it. Still, it might be helpful to understand it: > > > > > http://www.trondeau.com/blog/2013/9/26/hilbert-transform-and-windowing.html > > > > Tom > > > > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Tracking PLL phase error
Hello, I'm using the gr::analog::pll_carriertracking_cc() block to track a very stable signal of which I don't know the exact frequency and of which I want to detect (small!) phase oscillations. In my tests I discovered that the tracked signal has a residual phase modulation that I would not expect to find. I tried a simple test, very similar to the qa test for the block, and indeed I found that even for a constant frequency input signal the output has some residual phase oscillations. The amplitude of the oscillations depends on the pll bandwidth and on the frequency of the input signal, of the order of mrad for this examples (qa_pll_carriertracking.py). I need to get rid of those oscillations because they mask the phase signal I want to measure. I'm going to investigate the issue further, but does anyone have an idea about where those may come from? I suspect the digital oscillator may introduce some numeric error that may explain them, but they seem quite big... Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [GSoC] Co-Processors Update #10
Hello all, Logistical: - Pencils down is upon us so the rest of the week will be spent on getting all my documentation in order. This includes cleaning the code on github, keystone2 wiki page http://gnuradio.org/redmine/projects/gnuradio/wiki/Keystone2 runtime wiki page http://gnuradio.org/redmine/projects/gnuradio/wiki/runtime - Final Evaluations due this Friday Progress: - I have pushed the tcp3d test that passes the llrs from the arm and the dsp processes them on the tcp3d then the arm checks whether they match the expected result. https://github.com/muniza/tcp3d_dsp_test - I have some code that modifies GNU Radio runtime to isolate blocks based on flags we set in the blocks constructor. This will enable us to treat certain blocks differently such as putting the buffer in a different location in memory. Also is code that exposes the buffer object to the work function so that we can get the start address and size of the buffer in bytes. https://github.com/muniza/gnuradio - I have an OOT module that passes a struct with the gnuradio buffer start address and size to a kernel module using ioctl. https://github.com/muniza/gr-buffertest - Lastly the kernel module that runs get_user_pages on the gnuradio buffer struct. https://github.com/muniza/gsoc_2014 Plan: I did more research on the contigous memory allocation method and I now see that it is not a good zero-copy solution for ALL the devices we want to support. A good discussion is available on the linux kernel news site that discusses the reasons for NOT integrating ION, another contigous memory allocator, into the linux kernel: http://lwn.net/Articles/565469/. I'm still going to get a minimal CMEM GPLv3 integrated into GNU Radio as a stepping stone for modifying runtime and using zero copy with the keystone. This shouldn't take long at all since I just need ioctl. For part of my talk at the conference, I am going to discuss this method of contigous memory along with positives and negatives as it relates to GNU Radio and a couple of devices. I'm also hoping to make more progress so I can show the integration of the get_user_pages dma method but we'll have to see what happens when I'm back at Penn. I think a discussion of various methods this will bring up good conversation for the coproc working group. Expect one more update to mark the finishing of documentation on Friday. I'll also cry a little and give thanks to those that helped but thats in a couple of days. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Branch for Testing Parallel Build Issue
< https://github.com/jmcorgan/gnuradio/tree/fix-parallel-build > The goal of this branch is to fix the parallel build issue that's been plaguing GNU Radio's CMake build system pretty much since day 1. The shortest explanation of this fix is that CMake has a bug in it when handling multiple generated files in a single command. This bug has been known for years in various versions, and is on the back burner for them to fix as time allows someday. My fix is to explicitly spell out to CMake the dependencies and commands to execute in order, rather than trusting CMake to do it itself. The issue manifests itself in the following way: After performing a "make -j#" to completion with #>1, doing another "make" results in a small number of SWIG-generated .cxx files being recompiled. This issue happens more reliably with higher "#"s -- about 25% of the time when using "-j8" on my Mac OS X box. I encourage anybody interested to check out this branch and give it a test using "make -j" or "make -j8" or whatever works on your system with #>1. In testing thus far, this change actually allows for -more- parallelism in builds than without it; and, it has thus far functioned flawlessly using CMake 2.6, 2.8, and 3.0. If you do testing, feel free to reply to the group or email me directly with your successes or failures. Try touching headers (.h and .i) and sources to see if rebuilding happens correctly. Thanks in advance for any feedback on this change. - MLD -- Michael Dickens, OSX Programmer Ettus Research Technical Support Email: supp...@ettus.com Web: http://www.ettus.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] fcdproplus (Funcube Pro Plus) Module?
Greetings Marcus, Thank you for your prompt response and assistance! Once I knew that it was looking for a software module I realized I probably specified the wrong location for the fcdproplus module installation. The instructions on GitHub state to specify the path "". I initially specified the /usr/share/gnuradio path. However the path that was actually needed in my case was just "/usr" as the make file specified the rest of the path which was actually within Python distribution packages branch of the directory tree. Thanks again for your help. Best Regards, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
