Hi all, I run two usrp apps on two usrp, each set the which usrp correctly,
but meet usrp_standard_common: failed to read FPGA cap register when I run
the second app.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/
On Thu, Sep 2, 2010 at 2:14 PM, Matt Ettus wrote:
> On 09/02/2010 10:47 AM, Dan Harasty wrote:
>>
>> Hello, all.
>>
>> OK, I know I'm just the "new guy" here, and it may be poor form to
>> suggest that a well established forum should change its ways
>>
>> But I find the email-based discussion
Hi,
i'm traying to add an FFT module to the the "base" design of the usrp2.
I've found, in my opinion, where is the best place to add it. Between
the module dsp_core_rx_old and the module rx_control.
If i am right, the dsp_core_rx_old takes the input from the adc and
takes out (doing decimation a
Hi Matteo,
It sounds like you are using one of the BLOCK I/O xilinx FFT cores. As you
said, the core loads the
input i & q values, performs computation, then outputs the i & q FFT
results. And yes, during the load
and computation latency periods, there will be the lack of useable output
samples
> I am using the following code snippet to view a 100kHz sinewave on a
> virtual oscilloscope:
>
> self.interface_rate = 1e9
> self.src = gr.sig_source_c(self.interface_rate, gr.GR_SIN_WAVE, 1e3,
> 1)
> self.scope = scopesink2.scope_sink_c(panel,
> sample_rate=self.interface_rate)
> self.connect(s
Hi Matt,
I have connected the RF tuner that provides (nominal) a gain of 30 dB. So
the chain is (SIGGEN)--->(TUNER)--->(USRP2).
The tuner itself introduces spurious signal (below -70dBm).
The output spectrum is:
a) without tuner (description is above the picture)
http://imagebin.ca/view/ZTARvXd.h
On Fri, Sep 3, 2010 at 5:07 PM, Suleja, Lukasz wrote:
> I am using the following code snippet to view a 100kHz sinewave on a virtual
> oscilloscope:
>
> self.interface_rate = 1e9
> self.src = gr.sig_source_c(self.interface_rate, gr.GR_SIN_WAVE, 1e3, 1)
> self.scope = scopesink2.scope_sink_c(panel,
Thanks to Alex for pointing out a mistake in the code snippet, it should
read:
self.interface_rate = 1e6 # i.e. 1 MS/s
--
Roke Manor Research Ltd, Romsey,
Hampshire, SO51 0ZN, United Kingdom
A Siemens company
Registered in England & Wales at:
Siemens plc, Faraday House, Sir William Siemens Squa
You'll need to read the datasheet for the ADC. It's a AD9862. From there
you'll know the full range. I suspect is south of 3.3v as that's the boards
power supply.
An easier solution is to use a precision function generator and calibrate.
Send in a known signal and see what the graph displays. Chan
Well, you haven't really provided enough information here. Assuming
that your "RF Tuner" consists of some sort of frequency conversion and
an LO, you should know that you will always have leakage between the LO
input into the mixer and the IF output. Perhaps that is what you are
seeing? Does
I'm a puzzled by some UHD behavior and wondering if I need a new host system.
I'm not doing any signal processing in the host -- just transmitting from a
buffer and/or receiving from a buffer. Later, we'll be wanting to do more
processing with two USRP2s both transmitting and receiving at the sa
Sorry to reply to myself, but we just got the new Ethernet NIC so both USRP2s
report WE_TX flow control. Nothing changed.
And I have a correction for the types of ethernet cards. The onboard NIC is the
Broadcom. Ethernet 2 (and now 3) appear to be Realtek RTL8111/8168B.
On Sep 3, 2010, at 3:10
On 09/03/2010 04:52 PM, Marc Epard wrote:
> Sorry to reply to myself, but we just got the new Ethernet NIC so both USRP2s
> report WE_TX flow control. Nothing changed.
>
> And I have a correction for the types of ethernet cards. The onboard NIC is
> the Broadcom. Ethernet 2 (and now 3) appear to
Matt Ettus wrote:
>
> On 09/02/2010 07:09 AM, Jack Ott wrote:
>>
>> The strange thing is that when the fft's sample rate is at 25Msps which
>> equals the USRP's bandwidth at a decimation of 4 everything works fine
>> with
>> the regular fft sink yet not with the OpenGL one. However when I increa
OK, so I'm wetting my collective feet (all two of them) in the Tx side
of the world, with a comms/telecom application, no less.
I'm playing with the OP25 project, which is an open-source initiative to
produce tools to deal with the so-called
"Project 25" digital radio standard that is emerging a
I've got a flow-graph with a throttled random byte source, which is a
test input for a modulator:
http://www.sbrac.org/files/fm4_test_modulator.grc
http://www.sbrac.org/files/fm4_test_modulator.py
The source is throttled to the byte rate required to produce the correct
number of symbols/second (
On Fri, Sep 03, 2010 at 10:09:01PM -0400, Marcus D. Leech wrote:
> I've got a flow-graph with a throttled random byte source, which is a
> test input for a modulator:
>
> http://www.sbrac.org/files/fm4_test_modulator.grc
>
> http://www.sbrac.org/files/fm4_test_modulator.py
>
> The source is thro
On Fri, Sep 03, 2010 at 04:21:53PM -0700, Jack Ott wrote:
>
>
> Matt Ettus wrote:
> >
> > On 09/02/2010 07:09 AM, Jack Ott wrote:
> >>
> >> The strange thing is that when the fft's sample rate is at 25Msps which
> >> equals the USRP's bandwidth at a decimation of 4 everything works fine
> >> wit
On 09/03/2010 11:52 PM, Eric Blossom wrote:
> The throttle block was written so that the GUI elements could be
> tested without an inherently rate limiting source being in the graph.
> It is not designed to precisely rate limit anything. For any use
> other than that, you're asking for trouble. T
On 09/04/2010 12:01 AM, Eric Blossom wrote:
> FWIW, independent of GNU Radio, I've found that OpenGL support in
> Linux still leaves a lot to be desired in the performance and
> reliability departments. (Spoken as someone who's recently tried high
> performance cards from both Nvidia and ATI, tryi
20 matches
Mail list logo
