RE: [Discuss-gnuradio] Can't get input from sound card.
> > But I don't seem to me able to get any data from the audio card using such > programs as audio_to_file.py or audio_fft.py. > I still can't get any input from the sound card. I have installed GNU Radio on a completely different computer. The dial_tone.py program works. I get a flat line (it bounces around between -8e-5 and +4e-5) when I run audio_fft.py in the oscilloscope mode. In the hopes of perhaps, possibly getting some kind of a response, I'll try to ask very specific questions. 1) Is the signal source for audio_fft.py supposed to default to the sound card microphone? 2) If not, what is the default? 3) If not, can I tell it to use the sound card microphone? 4) If yes, how? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRC pre release screening
Hello, I want to begin working on hierarchical flow graphs in GRC. Before I do this, I want to encompass my most recent work in a 0.65 version release. Would some volunteers mind trying out my snap shot? Try to run a few things, build a flow graph... Let me know if there are any glaring bugs or problems. I have one warning: Importing older flow graphs from version 0.6 will produce rearranged parameters for the graphical sinks. http://www.joshknows.com/download/grc/grc_snap_shot.tar.gz Also, GRC needs some new screen shots. If you do something cool with GRC, send me a screen shot or post the image on the wiki (http://gnuradio.org/trac/wiki/GNURadioCompanion). If you can, send/post the grc.xml file as well. Try to take those "active window only" screen shots. Thank You, -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A medley of questions
On Fri, Mar 16, 2007 at 08:07:33PM -0700, Mike Garcia wrote: > Hi Eric, > > I just joined the gnuradio discussion but I found your question about the > GMSK amplitude distortion interesting. My guess is that it's aliasing. GMSK > has good spectral efficiency but it still has spectral sidelobes that get > folding into your desired passband when you decimate. I would suggest > filtering before decimating. Even better, since your decimating by factors > of 2, you can use a half band filter that reduces the sample rate by 2 each > time. Or you could consider downsampling via a polyphase filter. I'd be > interesting in seeing the phase distortion too. Phase distortion is more of > a concern for GMSK demodulation since it's a phase modulation. Take the > phase of the input signal and the phase of the output signal and difference > the two to get the phase error. You should see higher phase distortion as > you decimate more especially if you don't filter. > > Mike Hi Mike, thanks for your comments. We do filter when decimating, otherwise nothing would work. The first N/2 decimation is handled with a 4th-order CIC, the final decimation by two is done with a halfband. The Cylone doesn't have any h/w multipliers, so using a halfband at each stage is not feasible. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] A medley of questions
Hi Eric, I just joined the gnuradio discussion but I found your question about the GMSK amplitude distortion interesting. My guess is that it's aliasing. GMSK has good spectral efficiency but it still has spectral sidelobes that get folding into your desired passband when you decimate. I would suggest filtering before decimating. Even better, since your decimating by factors of 2, you can use a half band filter that reduces the sample rate by 2 each time. Or you could consider downsampling via a polyphase filter. I'd be interesting in seeing the phase distortion too. Phase distortion is more of a concern for GMSK demodulation since it's a phase modulation. Take the phase of the input signal and the phase of the output signal and difference the two to get the phase error. You should see higher phase distortion as you decimate more especially if you don't filter. Mike You're right, I was normalizing for the purposes of plotting. Here's what the raw complex samples look like: http://img490.imageshack.us/img490/3225/rawbasebandvv9.jpg +/- 2400 or so. and here's that other plot regenerated: http://img249.imageshack.us/img249/9520/d256unnormalizedkd4.jpg signal is going in to RX at -10dBm, default gain setting. On 3/14/07, Eric Blossom <[EMAIL PROTECTED]> wrote: On Wed, Mar 14, 2007 at 09:47:20PM -0400, Steven Clark wrote: > Plots of USRP decimation woes: > input is GMSK waveform @ ~30ksym/sec, BT = 0.35, no noise added > using decimation rate of 16: > http://img339.imageshack.us/img339/4467/d16cz9.jpg > top plot is complex baseband, bottom plot is amplitude of top plot > some amplitude variations noticeable, but fairly minor. > > using decimation rate of 256: > http://img256.imageshack.us/img256/2850/d256qh2.jpg > heavy amplitude variations. > zoomed in version of previous plots: > http://img490.imageshack.us/img490/6528/d256zoomedku7.jpg > > Still confused as to what is going on here... Steve, what's the real amplitude of the received baseband signal? I suspect that you are normalizing to 1. Can you regenerate the plots without normalizing so that we've got an idea of the values coming across the USB. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] window sizing issue
On Fri, Mar 16, 2007 at 06:29:42PM -0400, [EMAIL PROTECTED] wrote: > Ok, I can accept that this device was not intended to be used as a > calibrated measurement device, but maybe I can give it a shot. If I keep > the decimation constant, and stabilize the temperature, what other > considerations do I need to take into account (other than the obvious one, > ie gain) for the basic am-demodulation routine I am using? Can I consider > the FPGA as a "black box" and just calibrate the output vs the input at > the physical connector? > > thanks, > eric Yes, you should be able to make this work. You'll want to apply a known stimulus at several frequencies and amplitudes, measure what you get for each of those, then determine your calibration coefficients. If you haven't already, I suggest reading up on "two-point calibration". Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Segmentation Fault in rx_voice.py
On Fri, Mar 16, 2007 at 12:39:44AM -0500, Tarun Tiwari wrote: > Hi, > > I was trying to use rx_voice and tx_voice examples, but I found following > errors on different Fedora PCs. > > I have one computer (Pentium 4 Xeon 3.40GHz processor speed) with Kernel > 2.6.11-1.1369_FC4smp, and another computer (Centrino Core Duo T2300 > 1.66GHzprocessor speed) with Kernel > 2.6.18-1.2200.fc5smp. > > When I run rx_voice.py I recieve following errors: > a) on FC4 : Segmentation Fault > b) on FC5 : terminate called after throwing an instance of > 'std::runtime_error' > what(): msg length is not a multiple of d_itemsize > Aborted > > Then, I tried installing fftw from source code with following options: > 1) ./configure --enable-sse --enable-single --enable-shared > 2) ./configure --enable-single --enable-shared > 3) ./configure --disable-sse --enable-single --enable-shared > > but there was no improvement in the program, though all the make check > worked perfect. Although GNU Radio works pretty well with the current setup, > but I am not able to understand the WHY behind this problem. > > Between the time, I am also not able to listen anything on receiver side. I > am using RFX2400 boards with following commands: > > For TX: ./tx_voice.py --freq 2.41G -M 1 -I plughw:0,0 -v -m gmsk > For RX: ./rx_voice.py --freq 2.41G -O plughw:0,0 -v -m gmsk > > I need help on this issue. > > Thanks in advance. > > Regards, > Tarun No clue. It works for me. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] window sizing issue
Ok, I can accept that this device was not intended to be used as a calibrated measurement device, but maybe I can give it a shot. If I keep the decimation constant, and stabilize the temperature, what other considerations do I need to take into account (other than the obvious one, ie gain) for the basic am-demodulation routine I am using? Can I consider the FPGA as a "black box" and just calibrate the output vs the input at the physical connector? thanks, eric On Fri, 16 Mar 2007, Eric Blossom wrote: On Fri, Mar 16, 2007 at 05:30:44PM -0400, [EMAIL PROTECTED] wrote: Thanks- I'm using the DC-30 MHz basic RX board. So by recording the input signal, recording the value displayed on my "time series" window, and knowing the gain (0-20db if memory serves) I can calibrate the hardware so that I can back out the original voltage levels at the input? What impact does the signal processing have on the absolute magnitudes? If there is some magnitude attenuation caused by the FIR filters, is it frequency independent? thanks, eric Not to discourage you, but the USRP was designed as a software radio peripheral, not a precision calibrated measurement device. You will have to calibrate _everything_ in the path, and of course that includes the signal processing in the FPGA as well as anything in the host-based signal processing path. And yes, pretty much all of this varies depending on a large variety of settings. E.g., you'd want to calibrate for each possible FPGA decimation rate that you're interested in. Also, any calibration you make is going to be temperature dependent. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] window sizing issue
Thanks again! That worked great. As for who wrote the script, well, I adapted it (with much help from people on the discussion list) from a pre-existing wfm-based script, if I recall correctly. eric On Fri, 16 Mar 2007, Michael Dickens wrote: On Mar 16, 2007, at 12:01 PM, [EMAIL PROTECTED] wrote: 1) do you happen to know where the default values for the control buttons are set? I'd like to change the time scale from 100us/div to 1ms/div and to set the Autorange to "on" by default. In your "am_..." file, change the "scope_sink_f" call to inside "_build_gui", "if plot3:": self.scope = scopesink.scope_sink_f(self, self.panel, title="AM Demodulated Time Series", sample_rate=demod_rate, size=(50,100), t_scale=1.0e-3, v_scale=None) the last 2 items set the time scale and autorange as you want. 2) do you know how to convert the integer values on the third window (time-series) to actual voltage values as measured by the adc? It must be a function of the internal gain and offset. I need to know these eventually; this application is supposed to measure physical voltages, not just produce sounds. Not sure of this. Maybe whoever wrote the script knows? - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] window sizing issue
On Fri, Mar 16, 2007 at 05:30:44PM -0400, [EMAIL PROTECTED] wrote: > Thanks- > > I'm using the DC-30 MHz basic RX board. So by recording the input signal, > recording the value displayed on my "time series" window, and knowing the > gain (0-20db if memory serves) I can calibrate the hardware so that I can > back out the original voltage levels at the input? What impact does the > signal processing have on the absolute magnitudes? If there is some > magnitude attenuation caused by the FIR filters, is it frequency > independent? > > thanks, > eric Not to discourage you, but the USRP was designed as a software radio peripheral, not a precision calibrated measurement device. You will have to calibrate _everything_ in the path, and of course that includes the signal processing in the FPGA as well as anything in the host-based signal processing path. And yes, pretty much all of this varies depending on a large variety of settings. E.g., you'd want to calibrate for each possible FPGA decimation rate that you're interested in. Also, any calibration you make is going to be temperature dependent. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] external 1pps pulse
I currently have four complex input signals coming in through USB and I have a 1pps timing pulse coming from a gps source that I need to synchronize the 64MHz clock to and also pass on to the PC so that I know exactly which sample it occurred on. Can someone give me some guidance as to how I might accomplish this? Thank you, Hans Hi Hans, In the good news / bad news department, the good news is that this shouldn't be hard to do with the "inband signaling" work that's currently underway. The bad news is that this work probably won't be ready for a couple of months. In the interim, if you're willing to steal an LSB, you could modify the verilog such that it reported the presence or absence of the 1pps in the LSB of say, the I component of the first channel. Eric Hi Eric, Thanks for the reply. I could use an LSB on one signal, although I hate to lose a whole bit when I only have 12 to start with. I was hoping there might be a way to interleave another signal in with the four complex ones I'm receiving in the PC. My data rate is fairly low, so another signal would not hurt much. I haven't looked at the Verilog code yet. Would a fifth interleaved signal even be implement in the context of the verilog code? Also, what method would you use to receive the 1pps signal so the verilog code could stick it into an LSB, or another signal? The other issue is synchronizing the 64MHz clock to the 1pps. Is there any way to do this synch with the usrp's onboard clock, or will I have to make an external clock? Thanks, Hans ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] external 1pps pulse
Hans Glitsch wrote: Hello, I currently have four complex input signals coming in through USB and I have a 1pps timing pulse coming from a gps source that I need to synchronize the 64MHz clock to and also pass on to the PC so that I know exactly which sample it occurred on. Can someone give me some guidance as to how I might accomplish this? Thank you, Hans Why not use an external clock and sync with your 1pps ? This takes care of part of the problem anyway. Ryan _ 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
Re: [Discuss-gnuradio] window sizing issue
Thanks- I'm using the DC-30 MHz basic RX board. So by recording the input signal, recording the value displayed on my "time series" window, and knowing the gain (0-20db if memory serves) I can calibrate the hardware so that I can back out the original voltage levels at the input? What impact does the signal processing have on the absolute magnitudes? If there is some magnitude attenuation caused by the FIR filters, is it frequency independent? thanks, eric On Fri, 16 Mar 2007, Eric Blossom wrote: On Fri, Mar 16, 2007 at 12:43:01PM -0400, Michael Dickens wrote: 2) do you know how to convert the integer values on the third window (time-series) to actual voltage values as measured by the adc? It must be a function of the internal gain and offset. I need to know these eventually; this application is supposed to measure physical voltages, not just produce sounds. Not sure of this. Maybe whoever wrote the script knows? - MLD You would need to calibrate the complete signal path. Of course this is highly dependent on the particular daugtherboard in use as well as any gain setting in effect. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] external 1pps pulse
On Fri, Mar 16, 2007 at 01:08:27PM -0700, Hans Glitsch wrote: > Hello, > > I currently have four complex input signals coming in through USB > and I have a 1pps timing pulse coming from a gps source that I need > to synchronize the 64MHz clock to and also pass on to the PC so that > I know exactly which sample it occurred on. Can someone give me > some guidance as to how I might accomplish this? > > Thank you, > Hans Hi Hans, In the good news / bad news department, the good news is that this shouldn't be hard to do with the "inband signaling" work that's currently underway. The bad news is that this work probably won't be ready for a couple of months. In the interim, if you're willing to steal an LSB, you could modify the verilog such that it reported the presence or absence of the 1pps in the LSB of say, the I component of the first channel. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Commodore is Back ...
Il giorno ven, 16/03/2007 alle 16.16 -0400, Michael Dickens ha scritto: > < http://www.commodoregaming.com/pcshop/Game+PC/Commodore+xx.aspx > They seems to be only a IPER-provided standard Intel-based PC. -- Davide Anastasia web: http://www.davideanastasia.com/ email: [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] window sizing issue
On Fri, Mar 16, 2007 at 12:43:01PM -0400, Michael Dickens wrote: > > >2) do you know how to convert the integer values on the third > >window (time-series) to actual voltage values as measured by the > >adc? It must be a function of the internal gain and offset. I > >need to know these eventually; this application is supposed to > >measure physical voltages, not just produce sounds. > > Not sure of this. Maybe whoever wrote the script knows? - MLD > You would need to calibrate the complete signal path. Of course this is highly dependent on the particular daugtherboard in use as well as any gain setting in effect. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] installation error
On Fri, Mar 16, 2007 at 09:02:17AM -0700, bellzii wrote: > > hey everyone, > Im using a ubuntu 6.10 ,ive tried compiling the gnuradio but when i tried > the configuring gnuradio but i got the error : > gr_block.cc:41: error: 'gr_io_signature_sptr' has not been declared > gr_block.cc:42: error: 'gr_io_signature_sptr' has not been declared > gr_block.cc: In constructor 'gr_block::gr_block(const std::string&, int, > int)': > gr_block.cc:44: error: class 'gr_block' does not have any field named > 'd_input_signature' > gr_block.cc:45: error: class 'gr_block' does not have any field named > 'd_output_signature' > gr_block.cc: In member function 'void gr_block::consume(int, int)': > gr_block.cc:112: error: 'd_detail' was not declared in this scope > gr_block.cc: In member function 'void gr_block::consume_each(int)': > gr_block.cc:118: error: 'd_detail' was not declared in this scope > make[4]: *** [gr_block.lo] Error 1 > make[4]: Leaving directory > `/home/ziad/Desktop/gnuradio-3.0.3/gnuradio-core/src/lib/runtime' > make[3]: *** [install-recursive] Error 1 > make[3]: Leaving directory > `/home/ziad/Desktop/gnuradio-3.0.3/gnuradio-core/src/lib' > make[2]: *** [install-recursive] Error 1 > make[2]: Leaving directory > `/home/ziad/Desktop/gnuradio-3.0.3/gnuradio-core/src' > make[1]: *** [install-recursive] Error 1 > make[1]: Leaving directory `/home/ziad/Desktop/gnuradio-3.0.3/gnuradio-core' > make: *** [install-recursive] Error 1 > > Can some1 help > thanks for your time > ziad Did the "configure" step complete successfully? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MSB
On Fri, Mar 16, 2007 at 01:26:08PM +0100, Davide Anastasia wrote: > Il giorno gio, 15/03/2007 alle 12.17 -0700, Eric Blossom ha scritto: > > I think you'll find it easier to do the unpacking in a separate block > > downstream from the usrp1_source_s. Modifying usrp1_source* to handle > > samples smaller than 1 byte is going to take quite a bit of work. > > Part of the problem is that the code is written in terms of functions > > such as sizeof_basic_sample() which returns a size in bytes. In your > > case, your basic sample is smaller than a byte. The current code > > doesn't know how to deal with that. > > I'm think about this question since I turn on my PC today. :) > Ok, I receive from USRP a stream of samples. They are raw, not packed. > So, if I use a 1 bit quantization, I have 8 samples in a byte; with 2 > bit, 4 samples... and so on! But any module in GNU radio uses only char, > short, gr_complex (std::complex, is the same?). If I change > usrp1_source* to return always * samples, I reach my purpose. And then, > after usrp1_source*, I can use every module in the library I need. > > What's my fault(s) in this reasoning? > -- > Davide Anastasia > > web: http://www.davideanastasia.com/ > email: [EMAIL PROTECTED] No particular fault. However, the outputs from the USRP are almost always some kind of complex values. They may be encoded as 16-bit I & Q, or 8-bit I & Q or 4-bit or 2-bit or 1-bit. The question is how do we want to deal with them downstream from the USRP? The existing usrp.source_s could be considered broken (although there are users of it.) The data is really interleaved 16-bit I & Q, though it's presented as if each sample was only 16-bits wide. In fact a "sample" is really composed of 2 16-bit values. One way to approach this is to modify usrp.source_c so that it internally handles the format conversion, and always produces gr_complex as its output type. When dealing with 1 bit samples, there is the question of whether you want to treat them as -1, +1 or 0, +1. I suspect that -1, +1 makes more sense, but on the other hand, treating them as -32767, 32767 would be consistent with how the 8-bit samples are handled. That is, they are multiplied by 256 so that they fill the same range as the "normal" 16-bit I & Q. Another thought is to define a new complex interface that always returns values normalized to [-1.0, +1.0]. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about Basic TX/RX boards, the I, Q
On Fri, Mar 16, 2007 at 09:49:47AM -0400, [EMAIL PROTECTED] wrote: > I am having the same problem of being able to receive on RX_A but > not RX_B and I don't know why. Any help would be much appreciated. > Thanks > Nick Assuming the Basic Rx is on the "A" side, use -R a:1 to access the RX_B input. The Basic Rx is treated as having two distinct subdevices. Matt, *please* re-label the inputs on the Basic Rx with less ambiguous names. Perhaps something like "Input 0", "Input 1". Likewise for the Basic Tx. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Qwt packages for Fedora
Trond Danielsen wrote: > When packaging stuff I try to remain compatible with upstream, but the > qwt package contains _alot_ of header files, and I think it would be > better to store them in a separate subfolder. I'll discuss this with > the upstream devs too. It's fine and I encourage having the qwt headers installed into their own subdirectory. That's how it's packaged for Debian/Ubuntu, and when you compile from the source tarball, it does it too. (Though the directory is not named qwt). The qwt configuration script looks to be working finally. If you want to compile the gr-qtgui component to test, do the following: 1) Uncomment the #GRC_GR_QTGUI line in configure.ac, and re-run bootstrap. (Right now the component is disabled for everybody.) 2) Add the two following lines to your ./configure script command line: ./configure --with-qwt-incdir=... --with-qwt-libdir=... Replace the dots with the actual directory path that the include files are installed into and the path the qwt library is installed into. It's unfortunate, but every distribution is putting these files into a different place, and there is no way for the configure script to find them automatically. For example, if you install qwt from the sourceforge tarball, you'd have to do: $ ./configure --with-qwt-incdir=/usr/local/qwt/include \ --with-qwt-libdir=/usr/local/qwt/lib All this being said, gr-qtgui doesn't do anything useful yet :-) so don't go looking for QT versions of all the wxPython stuff we already have. However, the QWT library has a very rich set of widgets and eventually we'll be using these to display GNU Radio flow-graph generated output. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about Basic TX/RX boards, the I, Q
On Fri, Mar 16, 2007 at 05:33:36PM +0800, hanwen wrote: > Hi, all. > > Today I try an old QPSK transmission program on Basic TX/RX and failed. > However, it does work well on rfx2400. > I just simply connect TX 1 of Basic TX on transmitter to RX 1 of Basic RX on > receiver. The receiver program failed to synchronize with pilot sequence. > The carrier frequency is 100Mhz. That's too high for the Basic_Tx / Basic_Rx unless you really know what you're doing. Try using 10MHz. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tx Signal time
On Fri, Mar 16, 2007 at 10:10:28AM +0100, anmar wrote: > hi, > > How can i set the time of the signal between sin and cos. > in the file test_usrp_standard_tx.cc when i change the ampl the ampl > changes. > pattern[2*i+1] = host_to_usrp_short ((short) (ampl * sin (2*M_PI*i > /PERIOD))); > but when i change it to > pattern[2*i+1] = host_to_usrp_short ((short) (ampl * sin (2*M_PI*i > /PERIOD+or- X))); nothing happens, the signal stay normal Sin. > > if this is not the place to change the signale output where should i > look at. > in python we can chose sin, cos or const. but nothing in between . > > how can i do that? > > Thanks, > > Anmar First off I suggest that you not use test_usrp_standard_tx.cc as an example to emulate. It doesn't handle daughterboards, and was originally written to test the USRP before the rest of the GNU Radio framework was written. You can generate pretty much anything from python. I'm not sure what you are looking for. If you want to independently genereate the real and imaginary components of the complex baseband signal, you are free to do that. You can then combine the two float streams into a complex stream using u = usrp.sink_c(...) i = q = f2c = gr.float_to_complex() fg.connect(i, (f2c, 0)) fg.connect(q, (f2c, 1)) fg.connect(f2c, u) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DBSRX: Tune the LO from python
On Fri, Mar 16, 2007 at 01:17:27AM -0700, Chris Stankevitz wrote: > Is it possible to set the DBSRX's LO frequency and the FPGA DDC > independently? Yes it is. > Currently you can set the single quantity (LO - DCC) > using the USRP's "tune" member function. > > When f = 1.57542GHz, I do not like GNURadio's choice of > LO = 1.5755 GHz > DDC = 80KHz > > The board seems to put out a signal at 1.5760 GHz when the LO is tuned > to 1.5755 GHz which is not present when the LO is tuned to slightly > higher freqs. I would like to tune the LO to the higher freq and use a > larger DDC. > > Thanks, > Chris You have all the source available to you. The source to "tune" is in gr-usrp/src/usrp.py gr-usrp/src/db_dbs_rx.py may also be relevant. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Commodore is Back ...
And it's a rockin' computer under the hood. While it's meant for gaming, it should make an awesome SDR box too! I just wonder how much this particular model costs ... can't be cheap ;( < http://www.commodoregaming.com/pcshop/Game+PC/Commodore+xx.aspx > Features: This is the starting point of what's inside the Commodore xx. Most parts are customizable. * Intel® Core™2 Extreme Quad-Core processor QX6700: 2.66GHz 8M Cache * ASUS® P5N32-E nForce 680i SLI motherboard * 2x 150GB 1 RPM SATA Raid 0 and 1x 500GB 7200 RPM SATA Raid 1 hard drives * 4GB Corsair® Dominator 2xTwin2x2048-8500C5D memory: 1066MHz * Philips® DVDRW optical drive * 1000W ICE Cube power supply * Creative® SoundBlaster X-Fi Xtreme Gamer * 2x NVIDIA® 8800 GTX 768MB graphics cards ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] external 1pps pulse
Hello, I currently have four complex input signals coming in through USB and I have a 1pps timing pulse coming from a gps source that I need to synchronize the 64MHz clock to and also pass on to the PC so that I know exactly which sample it occurred on. Can someone give me some guidance as to how I might accomplish this? Thank you, Hans___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: installation error
hey everyone, Hi Ziad, Im using a ubuntu 6.10 ,ive tried compiling the gnuradio but when i tried the configuring gnuradio but i got the error : gr_block.cc:41: error: 'gr_io_signature_sptr' has not been declared gr_block.cc:42: error: 'gr_io_signature_sptr' has not been declared gr_block.cc: In constructor 'gr_block::gr_block(const std::string&, int, int)': gr_block.cc:44: error: class 'gr_block' does not have any field named 'd_input_signature' gr_block.cc:45: error: class 'gr_block' does not have any field named 'd_output_signature' gr_block.cc: In member function 'void gr_block::consume(int, int)': gr_block.cc:112: error: 'd_detail' was not declared in this scope gr_block.cc: In member function 'void gr_block::consume_each(int)': gr_block.cc:118: error: 'd_detail' was not declared in this scope make[4]: *** [gr_block.lo] Error 1 make[4]: Leaving directory `/home/ziad/Desktop/gnuradio-3.0.3/gnuradio-core/src/lib/runtime' make[3]: *** [install-recursive] Error 1 make[3]: Leaving directory `/home/ziad/Desktop/gnuradio- 3.0.3/gnuradio-core/src/lib' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/home/ziad/Desktop/gnuradio-3.0.3/gnuradio-core/src' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/ziad/Desktop/gnuradio- 3.0.3 /gnuradio-core' make: *** [install-recursive] Error 1 I believe dependencies for gnuradio are not configured properly and you are doing make. well, before doing make you need to be sure about the dependencies of GNURadio. You can do that by following commands: $ script config.check $ ./configure --enable-maintainer-mode $ exit this way you will generate a file called script.config in the same directory of ./configure file. Open the file and then at the end you will find what blocks could be installed and what not. Remember following blocks are must for gnuradio to work: 1) gr-core 2) gr-usrp 3) gr-wxgui 4) gr-alsa 5) usrp If these blocks can be installed then I dont think you will be in trouble, well its better to install all the possible blocks. Say if blosk gr-xxx is under Not-Install category, you search for xxx in the file and then you can find the reason why is that block not being installed. Well, you will find the dependency there (say it yyy), and then try installing the packages from repository byt using following command: $ yum install yyy if this does not work then try $ yum install yyy* and even this does not work then try $ yum install *yyy* and if this also does not work then you need to find the source code of yyy and install from that. It may happen that you need other dependent components for yyy while using source code, again you can use the script saving technique and try to install that dependency using repository (or source). Can some1 help I hope this may help you, even you are unable to do so, its better you send the file called config.check and then we can be in better situation to help you further. thanks for your time welcome ziad Tarun ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] compiling error
does any1 know what does the error make[4]: *** [gr_block.lo] Error 1 make[4]: Leaving directory `/home/ziad/Desktop/gnuradio-3.0.3/gnuradio-core/src/lib/runtime' make[3]: *** [install-recursive] Error 1 make[3]: Leaving directory `/home/ziad/Desktop/gnuradio-3.0.3/gnuradio-core/src/lib' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/home/ziad/Desktop/gnuradio-3.0.3/gnuradio-core/src' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/ziad/Desktop/gnuradio-3.0.3/gnuradio-core' make: *** [install-recursive] Error 1 can some help please -- View this message in context: http://www.nabble.com/compiling-error-tf3415725.html#a9518798 Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] window sizing issue
On Mar 16, 2007, at 12:01 PM, [EMAIL PROTECTED] wrote: 1) do you happen to know where the default values for the control buttons are set? I'd like to change the time scale from 100us/div to 1ms/div and to set the Autorange to "on" by default. In your "am_..." file, change the "scope_sink_f" call to inside "_build_gui", "if plot3:": self.scope = scopesink.scope_sink_f(self, self.panel, title="AM Demodulated Time Series", sample_rate=demod_rate, size= (50,100), t_scale=1.0e-3, v_scale=None) the last 2 items set the time scale and autorange as you want. 2) do you know how to convert the integer values on the third window (time-series) to actual voltage values as measured by the adc? It must be a function of the internal gain and offset. I need to know these eventually; this application is supposed to measure physical voltages, not just produce sounds. Not sure of this. Maybe whoever wrote the script knows? - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] installation error
hey everyone, Im using a ubuntu 6.10 ,ive tried compiling the gnuradio but when i tried the configuring gnuradio but i got the error : gr_block.cc:41: error: 'gr_io_signature_sptr' has not been declared gr_block.cc:42: error: 'gr_io_signature_sptr' has not been declared gr_block.cc: In constructor 'gr_block::gr_block(const std::string&, int, int)': gr_block.cc:44: error: class 'gr_block' does not have any field named 'd_input_signature' gr_block.cc:45: error: class 'gr_block' does not have any field named 'd_output_signature' gr_block.cc: In member function 'void gr_block::consume(int, int)': gr_block.cc:112: error: 'd_detail' was not declared in this scope gr_block.cc: In member function 'void gr_block::consume_each(int)': gr_block.cc:118: error: 'd_detail' was not declared in this scope make[4]: *** [gr_block.lo] Error 1 make[4]: Leaving directory `/home/ziad/Desktop/gnuradio-3.0.3/gnuradio-core/src/lib/runtime' make[3]: *** [install-recursive] Error 1 make[3]: Leaving directory `/home/ziad/Desktop/gnuradio-3.0.3/gnuradio-core/src/lib' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/home/ziad/Desktop/gnuradio-3.0.3/gnuradio-core/src' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/ziad/Desktop/gnuradio-3.0.3/gnuradio-core' make: *** [install-recursive] Error 1 Can some1 help thanks for your time ziad -- View this message in context: http://www.nabble.com/installation-error-tf3415350.html#a9517453 Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] window sizing issue
Michael- thanks very much for your help! Your changes have fixed the "control buttons covered" issue. I'll have to study what you did; I don't know any wxPython at all and as you've mentioned it's not easy to wade through existing documentation. Two other questions- 1) do you happen to know where the default values for the control buttons are set? I'd like to change the time scale from 100us/div to 1ms/div and to set the Autorange to "on" by default. 2) do you know how to convert the integer values on the third window (time-series) to actual voltage values as measured by the adc? It must be a function of the internal gain and offset. I need to know these eventually; this application is supposed to measure physical voltages, not just produce sounds. thanks again, eric Eric H. Matlis, Ph.D. Aerospace & Mechanical Engineering Dept. 120 Hessert Center for Aerospace Research University of Notre Dame Notre Dame, IN 46556-5684 Phone: (574) 631-6054 Fax: (574) 631-8355 On Thu, 15 Mar 2007, Michael Dickens wrote: On Mar 15, 2007, at 5:15 PM, [EMAIL PROTECTED] wrote: I've got an application with 3 plot windows and a control area in the bottom. Depending on the screen resolution, the control area on the bottom is "covered" by the lowest of the 3 plot windows. The applicatoin works fine at 1600x1200 but less well at 1440x900, and certainly at lower resolutions the control boxes are getting covered. What can I do so that even at lower resolutions I can see the entire application? I've tried adjusting the middle numeric field (vbox.add(self.scope.win, 4, wx.EXPAND)) in the vbox.add entry from 4 to 0, which helps for 1440x900 but this doesn't work for all resolutions and I don't know what this value represents anyway. Is there a recommendation for making my application resolution-independent? I've attached the python-code. Any advice is appreciated! I've been studying GUI design recently, and I can tell you that it's not simple learning WX or wxPython as documentation really isn't very good (IMHO). Does folks have particular references (online tutorial, book, PDF) that they really like? I could use some pointers ... I've seen those provided by the WX and wxPython projects, and Google'd various others, but none really do justice to all the methods and variables for even such "simple" things as a BoxSizer. I think this is correct: The "0" or "4" you're referring to is a "weight" of the particular added object. The "weight" is taking into account when the BoxSizer [0] determines how big an object should be; "0" weight (I think) means to not consider this object in the sizing but rather instead to just allocate its actual size (in pixels). Tweaking this value helps only so much, as objects can get only so small and screens only so large. Each object has a property, something like "minimum size"; some of these are straight forward to set while others seem to be less so if not impossible. In the case of the "fftsink" GUI, the default frame size is (X,Y) = (640, 240), as found in gr-wxgui/src/python/fftsink.py , and you can change this in the call to "fftsink.fft_sink_c" with "size=(50,50)" or whatever you want. Ditto for fftsink2.py. Then you'll want to change the "weight" in the "vbox.Add" call to 1 for each of these. That for "scopesink" is also (640, 240) [gr-wxgui/src/python/scopesink.py], except that this value doesn't actually get used for anything (oops, bug alert). The "scopesink" also has some extra GUI stuff below it that doesn't seem to be set to EXPAND; nor is "size" passed around to any of the classes that actually create the GUI objects. Thus some work needs to be done on the scopesink classes stuff in order to get "size" to work. Once the scopesink is corrected (as appended [1]), then you'll probably want (in your am_rcv_plasma.py) to vbox.Add them with a weight of 1, and everything else with a weight of 0. At least for me, this looks OK at down to around (X,Y) = (750,525) ... nothing special that small, but it does work. [0] The BoxSizer 'vbox' to which you refer is a means for placing objects into a GUI with minimal user defined parameters; this particular one is a "vertical box" only, which means that items are added from the top of a window towards the bottom, in rows. Each row can have a different number of columns, each of which is generally a BoxSizer in its own right (a "horizontal" one). [1] I've appended updated files, with corrections for these issues. Place them in the same directory before trying to execute your "am_.." script since it now depends on the fftsink_mod script being in that same directory. I'll think about what should really be done to scopesink to get it working properly, since this is just a quick fix for an obvious problem but it's not "ideal" I don't believe. ___ Discuss-gnuradio mailing list
[Discuss-gnuradio] window sizing issue
In gr-wxgui/src/python/scopesink.py (and ...2.py), is it a bug or feature that the "size" isn't passed through to the actual objects being created (like it is in fftsink.py)? If a bug, I can fix it quickly; if a feature, then can someone offer an explanation? Thanks! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about Basic TX/RX boards, the I, Q
I am having the same problem of being able to receive on RX_A but not RX_B and I don't know why. Any help would be much appreciated. Thanks Nick Content-Type: multipart/alternative; boundary="=_Part_43578_14158760.1174037616509" --=_Part_43578_14158760.1174037616509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, all. Today I try an old QPSK transmission program on Basic TX/RX and failed. However, it does work well on rfx2400. I just simply connect TX 1 of Basic TX on transmitter to RX 1 of Basic RX on receiver. The receiver program failed to synchronize with pilot sequence. The carrier frequency is 100Mhz. Is the signal from TX 1 is just I or Q path of the complex signal? I saw signal come out from both TX1 and TX2. BTW, I could only receive signal from RX1 of Basic RX and nothing from RX2. Very confusing. ^_^ --=_Part_43578_14158760.1174037616509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, all. Today I try an old QPSK transmission program on Basic TX/RX and failed. However, it does work well on rfx2400. I just simply connect TX 1 of Basic TX on transmitter to RX 1 of Basic RX on receiver. The receiver program failed to synchronize with pilot sequence. The carrier frequency is 100Mhz. Is the signal from TX 1 is just I or Q path of the complex signal? I saw signal come out from both TX1 and TX2. BTW, I could only receive signal from RX1 of Basic RX and nothing from RX2. Very confusing. ^_^ --=_Part_43578_14158760.1174037616509-- ___ 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: gr_noise_source_X( ) only negative seeds?
I have submitted a patch to patch-gnuradio@ for gr_noise_source and qa code
The patch is to gr_noise_source_X rather than gr_random::ran1()
I am not sure why but most implementations from ran1() set all positive
values of seeds to 1. Rather then mess with what may be convention I
thought it might be better to fix in gr_noise_source.
Index: gnuradio-core/src/lib/gengen/gr_noise_source_X.cc.t
===
--- gnuradio-core/src/lib/gengen/gr_noise_source_X.cc.t (revision 4763)
+++ gnuradio-core/src/lib/gengen/gr_noise_source_X.cc.t (working copy)
@@ -43,7 +43,8 @@
gr_make_io_signature (1, 1, sizeof (@TYPE@))),
d_type (type),
d_ampl (ampl),
-d_rng (seed)
+// for ran1() positive values for seed all return same sequence
+d_rng ((seed < 0)?seed:-seed)
{
}
On 3/8/07, Tim Meehan <[EMAIL PROTECTED]> wrote:
Hi All
When seeded with a positive number gr_noise_source_X seems to always
return the same sequence.
i.e.
call gr_noise_source_f(gr.GAUSSIAN,1,Z) where Z > 0 the sequence is
always the same. Called with a negative seed (Z < 0 ) it behaves as I
would expect.
Am I missing something?
I think this is from lines below in gr_random, but the comment
made me scared to touch it :-)
/*
* This looks like it returns a uniform random deviate between 0.0 and 1.0
* It looks similar to code from "Numerical Recipes in C".
*/
float gr_random::ran1()
{
int j;
long k;
float temp;
if (d_seed <= 0 || !d_iy) {
if (-d_seed < 1)<< HERE
d_seed=1; << and HERE
else
d_seed = -d_seed;
for (j=NTAB+7;j>=0;j--) {
k=d_seed/IQ;
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MSB
Il giorno gio, 15/03/2007 alle 12.17 -0700, Eric Blossom ha scritto: > I think you'll find it easier to do the unpacking in a separate block > downstream from the usrp1_source_s. Modifying usrp1_source* to handle > samples smaller than 1 byte is going to take quite a bit of work. > Part of the problem is that the code is written in terms of functions > such as sizeof_basic_sample() which returns a size in bytes. In your > case, your basic sample is smaller than a byte. The current code > doesn't know how to deal with that. I'm think about this question since I turn on my PC today. :) Ok, I receive from USRP a stream of samples. They are raw, not packed. So, if I use a 1 bit quantization, I have 8 samples in a byte; with 2 bit, 4 samples... and so on! But any module in GNU radio uses only char, short, gr_complex (std::complex, is the same?). If I change usrp1_source* to return always * samples, I reach my purpose. And then, after usrp1_source*, I can use every module in the library I need. What's my fault(s) in this reasoning? -- Davide Anastasia web: http://www.davideanastasia.com/ email: [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MSB
Il giorno gio, 15/03/2007 alle 12.17 -0700, Eric Blossom ha scritto:
> I think you'll find it easier to do the unpacking in a separate block
> downstream from the usrp1_source_s. Modifying usrp1_source* to handle
> samples smaller than 1 byte is going to take quite a bit of work.
> Part of the problem is that the code is written in terms of functions
> such as sizeof_basic_sample() which returns a size in bytes. In your
> case,your basic sample is smaller than a byte. The current code
> doesn't know how to deal with that.
I can use the "format()" function to obtain the width of the sample.
Actually I'm using this way:
case 1:
for (int i = 0; i < nitems; i++){
switch ( format() ) {
case 1:
out[i] = usrp_to_host_short(s16[i]);
// temp = 0 | s8[i] << 8;
// i++;
// out[i] = temp | s8[i]; // Si può fare?
break;
case 2:
out[i] = s8[i] << 14;
break;
case 4:
out[i] = s8[i] << 12;
break;
case 8:
default:
out[i] = s8[i] << 8;
}
}
break;
I change sizeof_basic_sample() in order to return 1 with samples smaller
than a byte. I written a little C++ program to obtain from a 1 bit
stream a table (#, value{0 or 1}). I think it can been reused to create
a module, which take a stream and return a 16 bit sample per bit.
>
> After unpacking, what representation do you want for your samples?
I guess a simple continuos stream of bit is enough.
>
> If bytes containing 1-bit per byte are OK, then perhaps the easiest
> approach is to create a gr_packed_to_unpacked_sb.*
>
> You should be able to do this by changing:
>
> # other blocks
> others = (
> ('gr_chunks_to_symbols_XX', ('bf', 'bc', 'sf', 'sc', 'if',
> 'ic')),
> ('gr_unpacked_to_packed_XX',('bb','ss','ii')),
> ('gr_packed_to_unpacked_XX',('bb','ss','ii'))
> )
>
>
> to
>
> # other blocks
> others = (
> ('gr_chunks_to_symbols_XX', ('bf', 'bc', 'sf', 'sc', 'if',
> 'ic')),
> ('gr_unpacked_to_packed_XX',('bb','ss','ii')),
> ('gr_packed_to_unpacked_XX',('bb','ss','ii', 'sb'))
> )
>
> in gnuradio-core/src/lib/gengen/generate_common.py
"b" stays for byte or bit?
>
> On the other hand, I assume that ultimately these end up as some kind
> of complex data type, so perhaps some other kind of mapping to
> gr_complex would be useful.
--
Davide Anastasia
web: http://www.davideanastasia.com/
email: [EMAIL PROTECTED]
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP schematic..
Hello Sir I have bought the USRP board, basically i am doing a project. So for that purpose i need to have the detail schematic of USRP board. for example if i have programmed FPGA by my own RBF files, which i have generated by quartus 2 software. In that i did pin assignment of input and output so how can i use those pins of cyclone FPGA now from Daughterboard, because i guess the same pins of FPGA must be available on daughter board. If i am wrong please correct me. i hope for detailed schematic and more information about this. thank you pankaj - Don't pick lemons. See all the new 2007 cars at Yahoo! Autos.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question about Basic TX/RX boards, the I, Q
Hi, all. Today I try an old QPSK transmission program on Basic TX/RX and failed. However, it does work well on rfx2400. I just simply connect TX 1 of Basic TX on transmitter to RX 1 of Basic RX on receiver. The receiver program failed to synchronize with pilot sequence. The carrier frequency is 100Mhz. Is the signal from TX 1 is just I or Q path of the complex signal? I saw signal come out from both TX1 and TX2. BTW, I could only receive signal from RX1 of Basic RX and nothing from RX2. Very confusing. ^_^ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Tx Signal time
hi, How can i set the time of the signal between sin and cos. in the file test_usrp_standard_tx.cc when i change the ampl the ampl changes. pattern[2*i+1] = host_to_usrp_short ((short) (ampl * sin (2*M_PI*i /PERIOD))); but when i change it to pattern[2*i+1] = host_to_usrp_short ((short) (ampl * sin (2*M_PI*i /PERIOD+or- X))); nothing happens, the signal stay normal Sin. if this is not the place to change the signale output where should i look at. in python we can chose sin, cos or const. but nothing in between . how can i do that? Thanks, Anmar -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Qwt packages for Fedora
2007/3/16, Johnathan Corgan <[EMAIL PROTECTED]>: Jason Coy wrote: > Yeah, I agree that the .pc file is the best way to handle providing this > info. In the qwt tar file on the n4hy.org web site there is a version of > the qwt library that has the .pc file in it. It is similar to the qt-mt.pc > file that is installed by qt. I will send an email to the upstream developer regarding the pkg-config file. Well, I've since reverted a portion of the gr_qwt.m4 file to remove the need for the qwt subdirectory. The reason--the canonical tarball from [...] It's really up to the distribution packagers to standardize these according to the LSB, so Trond, you could create a .pc file with the right info for where you're putting them with your RPM. But my configuration script needs to work whether there is a .pc file or not, so I can't take advantage of it until even the canonical upstream source has one. When packaging stuff I try to remain compatible with upstream, but the qwt package contains _alot_ of header files, and I think it would be better to store them in a separate subfolder. I'll discuss this with the upstream devs too. -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] DBSRX: Tune the LO from python
Is it possible to set the DBSRX's LO frequency and the FPGA DDC independently? Currently you can set the single quantity (LO - DCC) using the USRP's "tune" member function. When f = 1.57542GHz, I do not like GNURadio's choice of LO = 1.5755 GHz DDC = 80KHz The board seems to put out a signal at 1.5760 GHz when the LO is tuned to 1.5755 GHz which is not present when the LO is tuned to slightly higher freqs. I would like to tune the LO to the higher freq and use a larger DDC. Thanks, Chris ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
