>> I would try this with the regular (non-PLL) FM demod. I think the
>> rolloff of the PLL tracking loop is what is giving you the lower gain.
>>
> Yes, that seems to be the problem.
> For now I switched to using the non-PLL FM-demod.
>
> Do you know if/how I can make a PLL which does not ha
On Thursday 21 June 2007 12:06, Adam Skelton wrote:
> I'm trying to build gnu radio on FreeBSD. It will go through the
> basic configure but dies when I force it to build usrp, because
> it says it can't find the library containing usb_bulk_write. But
> I have libusb in /usr/local/lib and strings s
First time here so be gentle.
I'm trying to build gnu radio on FreeBSD. It will go through the
basic configure but dies when I force it to build usrp, because
it says it can't find the library containing usb_bulk_write. But
I have libusb in /usr/local/lib and strings says it has
usb_bulk_write
Matt Ettus wrote:
> Martin Dvh wrote:
>
>>Hi,
>>I found a nasty bug in the wfm_rcv_pll.py code.
>>
>>The pilot tone pll should return the recovered carrier,
>>For this you should use gr.pll_refout_cc, not gr.pll_carriertracking_cc.
>>pll_carriertracking returns the input transformed to baseband us
Thank you all, this solved my problem.
On 6/20/07, Jiri Pittner <[EMAIL PROTECTED]> wrote:
I had the same problem, latest SVN version of gnuradio definitely solved
it.
Jiri
On Tue, 19 Jun 2007, Matt Ettus wrote:
> Ian Larsen wrote:
>> Hello,
>>
>> I'm trying to figure out what's going on here
Hello,
In receive_path.py, there is this code:
# Design filter to get actual channel we want
sw_decim = 1
chan_coeffs = gr.firdes.low_pass (1.0, # gain
sw_decim * self._samples_per_symbol,
# sampling rate
The problem was in the gain level- I hadn't realized the default gain in
the mult_ versions is at 20 compared to midvalue for the standard
versions. My signal was saturating the A/D's at this value of gain.
Reducing the gain eliminated the problem.
eric
E
- Original Message -
From: "Alaelddin Mohammed" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, June 20, 2007 11:17 AM
Subject: Re: [Discuss-gnuradio] Error in my first USRP test
I found that I am using libusb-win32 version 0.1.12.0-1, I change it to
version 0.1.10.1-3. I plugged TX and
Hi all-
I'm trying to build a multi-reciever program modelled on the stuff in the
multi_antenna directory, however there seems to be a problem with the
multi_fft and multi_scope programs. I have 2 LF daughterboards, and I'm
using a function generator to send a 1 kHz sine wave with .1 V p-p le
I'm working on a Flex400 card, and noticed that when calling the
subdev.set_gain() method, nothing is returned (or, rather "None" is
always returned). I hadn't seen this before, so I looked through the
Python code and found that in "db_flexrf", the "set_gain()" method
tries to return the v
im still new to python , i just found that the class usrp.source_c needs some
parameters as stated
usrp1_source_c ( int which_board,
unsigned intdecim_rate,
int nchan,
int mux,
int mode,
I found that I am using libusb-win32 version 0.1.12.0-1, I change it
to version 0.1.10.1-3. I plugged TX and RX in my USRP device. but I got
this error.
$ python test_counting.py
found 5 busses
found 5 busses
usrp_open_interface:usb_claim_interface: failed interface 2
could not claim interfa
this should be on discuss-gnuradio, not commit-gnuradio
--- Begin Message ---
Hi All,
I tried to 'make' the GNU Radio 3.0.3 after
successful ./configure, But encountering some problems in building
swig_python_xx.cc in GnuRadio_core Folder. The systems slows down in a
vast way
I had the same problem, latest SVN version of gnuradio definitely solved
it.
Jiri
On Tue, 19 Jun 2007, Matt Ettus wrote:
Ian Larsen wrote:
Hello,
I'm trying to figure out what's going on here. I have a USRP that
works just fine when tested with the test_usrp_standard_rx test
program, but s
14 matches
Mail list logo
