[Discuss-gnuradio] Re: GNU Stow and make install (DESTDIR)
schrieb Alexandru Csete on 2011-01-06 21:09: > Hi Patrick, > > I manage multiple versions of GNU Radio manually by simply installing > each under its own prefix and having a symbolic link "current" point > to whichever version I want to use. We should document both ways in the wiki. Patrick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM benchmark
Hello, I am trying to understand the design in benchmark OFDM code in Gnuradio. In the code, OFDM_RECEIVER use OFDM_SYNC_PN to do the timing and frequency offset synchronization, and then doing FFT_DEMOD to demodulate the signal. After that, SLICER and DEMAPPER in GR_OFDM_FRAME_SINK are used to output it in the message queue. But the questions are: Why there is PLL for carrier compensation in GR_OFDM_FRAME_SINK? Should PLL be used before FFT_DEMOD ? What is the difference between PLL here and timing and frequency synchronization in OFDM_SYNC_PN? -- Regards, Guanbo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How the valve block works
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! I'm trying to implement an application with GNU Radio Companion that incorporates different branches. For example I have a Wav source and a signal source and I want to switch between them. Or I want to hear the signal at socertain points in the flow graph. The old way was to use a variable chooser, const multipliers for muting of paths and adders. The downside of this system is that all the paths continue to run concurrently. I do not use the muted paths, but they still consume processing power. Now I found the valve block, and the doc says: Connect output to input when valve is closed (not open). I expected the valve to block when input is not connected to output. I thougth the flow graph would starve/block on that path. In consequence the path would not consume processing power. Now it seems - referring to Josh's message from 2010-05-06 [1] - that down the path from the valve indeed starving happens, but the null sink in the valve happily consumes, keeping the producers running. I thought about replacing the null sink with something blocking. This would for sure work with otherwise unconnected sources, like when choosing between different sources. But I'm not sure what happens if the path splits before the valve. Would the blocking be propagated back over the split or be limited to the path with the valve? Maybe I'm just on the wrong track and there is some other simple solution for this problem. Regards Patrick [1] http://article.gmane.org/gmane.comp.gnu.radio.general/26777 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0nrBYACgkQ/G6gHctkMa/WtQCfV6z15+BrBgPa12X/WCoCphXt jqUAn0fSxmm94i/OS/FXKa/cC1E0cX8e =Jn5p -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How the valve block works
The input blocks to the valve, when open, connect to null sinks. The idea was to drain any incoming data. This could be desirable if for example you had other blocks, like a file sink that also used this stream. You wouln't want to back-up indefinitely and then consume all the old data when closed again. It depends on the topology. So maybe the user should decide... I think the valve needs a user-set policy. Consume when open, or block when open. And while we are at it, for the outputs, produce zeros when open, or block when open. -Josh On 01/07/2011 04:13 PM, Patrick Strasser wrote: > Hello! > > I'm trying to implement an application with GNU Radio Companion that > incorporates different branches. For example I have a Wav source and a > signal source and I want to switch between them. Or I want to hear the > signal at socertain points in the flow graph. The old way was to use a > variable chooser, const multipliers for muting of paths and adders. The > downside of this system is that all the paths continue to run > concurrently. I do not use the muted paths, but they still consume > processing power. > > Now I found the valve block, and the doc says: Connect output to input > when valve is closed (not open). > I expected the valve to block when input is not connected to output. I > thougth the flow graph would starve/block on that path. In consequence > the path would not consume processing power. Now it seems - referring to > Josh's message from 2010-05-06 [1] - that down the path from the valve > indeed starving happens, but the null sink in the valve happily > consumes, keeping the producers running. > > I thought about replacing the null sink with something blocking. This > would for sure work with otherwise unconnected sources, like when > choosing between different sources. But I'm not sure what happens if the > path splits before the valve. Would the blocking be propagated back over > the split or be limited to the path with the valve? > > Maybe I'm just on the wrong track and there is some other simple > solution for this problem. > > Regards > > Patrick > > [1] http://article.gmane.org/gmane.comp.gnu.radio.general/26777 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: How the valve block works
schrieb Josh Blum on 2011-01-08 01:44: > The input blocks to the valve, when open, connect to null sinks. The > idea was to drain any incoming data. This could be desirable if for > example you had other blocks, like a file sink that also used this > stream. You wouln't want to back-up indefinitely and then consume all > the old data when closed again. It depends on the topology. So maybe the > user should decide... > > I think the valve needs a user-set policy. Consume when open, or block > when open. And while we are at it, for the outputs, produce zeros when > open, or block when open. Just found out that the selector block fits my requirements much better. But do I have the same behaviour here again? I replaced my const multipliers/adders with selectors, but now it uses much more cpu load :-( Regards Patrick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] D-Star with gnuradio?
Hi people, Have anyone successfully built a D-Star transmitter with gnuradio blocks? Best regards, Rafael Diniz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 Clock drift
Hi Mike/Nick, Thanks for your help, I tried offsetting the transmitter by a couple of kHz and it all came to life (isn't software radio great like that!) The error of 13kHz was only at 940.2MHz, which is definitely within spec. As Mike explained this correlates to an error of about 6kHz @ 435MHz. Seems that the ppm unit of measurement had caught me out - once I figured out that it is a *ratio* and not a specific value everything suddenly became clear. Cheers, Matt On 7/01/11 10:12 :13, Michael Ossmann wrote: > On Fri, Jan 07, 2011 at 10:01:18AM +1100, Matt Robert wrote: >> I ran Kalibrate against my pair of USRP1's using GSM900 towers >> (around 940MHz) and found my first unit to me 5kHz off and the >> second was 13kHz off. >> >> Is this within limits for the built in oscillator? > Yes, those are both within 20 parts per million. > >> Perhaps clocktamer or a secondhand GPSDO is needed for my Tx >> applications. > Have you tried adjusting the tuning of your USRP to compensate? > e.g. you could tune to 400.013 MHz instead of 400 MHz. In theory > you might also have to correct the symbol rate, but it is likely > that the receiver will be much more tolerant of symbol clock error > than carrier frequency error. > > mossmann ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: How the valve block works
> Just found out that the selector block fits my requirements much better. > But do I have the same behaviour here again? > The valve is implemented with the selector. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_qtgui, SWIG. QT Signals and such
Hi All, Just a quick update to say I've got the QT Signals part working (I can double click the FrequencyDisplayPlot and catch a signal in my python app with the frequency and amplitude at which I clicked). It turns out to be trivially easy. My code is very prototype-y at the moment, I'll tidy it up a bit and publish something tomorrow I expect. BR, Mike VK2XMC ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
