Hi all,
the usrp2 destructor can throw an exeption due the fact that while
destroying the
implementation ( usrp2::impl::~impl() ) a stop_bg() is performed.
The stop_bg implementation is:
void
usrp2::impl::stop_bg()
{
d_bg_running = false;
d_bg_pending_cond.notify_one(); // FIXME: ch
Martin, thanks for responding. See my follow ups below:
--- On Thu, 1/13/11, Marcus D. Leech wrote:
> From: Marcus D. Leech
> Subject: Re: [Discuss-gnuradio] grc amplitude demodulation questions
> To: discuss-gnuradio@gnu.org
> Date: Thursday, January 13, 2011, 4:26 PM
> > Hello-
> >
> > I am
Marcus:
You say that "the UHD provides a different API than "classic", and
usrp2_fft.py uses the "classic" API." I'm brand new to UHD and just getting
started with it. Could you explain in a little more detail about the two APIs
and the differences between them?
I'm using raw Ethernet now w
David:
How did you generate the YouTube
video from your Linux machine??
Did you use recordMyDesktop??
(http://recordmydesktop.sourceforge.net/)
Thanks.
Steve McMahon
--- On Thu, 1/13/11, David L wrote:
> From: David L
> Subject: [Discuss-gnuradio] transient when changing valve state
> To:
On 01/14/2011 02:56 PM, emat...@yahoo.com wrote:
> Martin, thanks for responding. See my follow ups below:
> --- On Thu, 1/13/11, Marcus D. Leech wrote:
>
>
>> From: Marcus D. Leech
>> Subject: Re: [Discuss-gnuradio] grc amplitude demodulation questions
>> To: discuss-gnuradio@gnu.org
>> Date
On Tue, Jan 4, 2011 at 6:49 AM, You Lizhao wrote:
> Hi all,
>
> Recently I want to implement a OFDM based multi-rate system, and I am using
> benchmark_ofdm_tx/benchmark_ofdm_rx programs in ofdm directory. I know I can
> use unlock/lock mechnism to disconenct/connect the exising blocks to change
>
On 01/14/2011 03:28 PM, Steve Mcmahon wrote:
> Marcus:
>
> You say that "the UHD provides a different API than "classic", and
> usrp2_fft.py uses the "classic" API." I'm brand new to UHD and just
> getting started with it. Could you explain in a little more detail
> about the two APIs and the diffe
Hello:
Why is the USRP2 is going End-Of-Life (EOL) in March 2011? My understanding is
that one of the parts will soon become unavailable. Which part is it?
I'm just curious, but wouldn't it have been easier to just design around the
obsoleted part, or find a drop-in replacement, rather than des
But I still don't understand what it is that has to change in GRC to use UHD.
Do you mean that the "USRP2 Sink" and "USRP2 Source" blocks are only for the
raw Ethernet interface, and to use UHD you would need to use a different block
in your GRC flowgraph?
Thanks again.
--- On Fri, 1/14/11, M
On 01/14/2011 03:43 PM, Steve Mcmahon wrote:
>
>
--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On 01/14/2011 03:43 PM, Steve Mcmahon wrote:
> But I still don't understand what it is that has to change in GRC to
> use UHD. Do you mean that the "USRP2 Sink" and "USRP2 Source" blocks
> are only for the raw Ethernet interface, and to use UHD you would need
> to use a different block in your GRC
On 01/14/2011 12:40 PM, Steve Mcmahon wrote:
Hello:
Why is the USRP2 is going End-Of-Life (EOL) in March 2011? My
understanding is that one of the parts will soon become unavailable.
Which part is it?
The SRAM
I'm just curious, but wouldn't it have been easier to just design
around the obsol
> I believe the code is already doing this. Here are code segments for
> 2 fft guis. The first shows the fft of the raw output of the USRP2.
> This gui responds correctly. Notice the line:
> "sample_rate=100e6/usrp2_decim", so I assume that as I dynamically
> adjust usrp2_decim, this value is b
--- On Fri, 1/14/11, Josh Blum wrote:
> From: Josh Blum
> Subject: Re: [Discuss-gnuradio] grc amplitude demodulation questions
> To: discuss-gnuradio@gnu.org
> Date: Friday, January 14, 2011, 2:14 PM
>
> > I believe the code is already doing this. Here
> are code segments for
> > 2 fft guis.
Jamie Morken shaw.ca> writes:
> USB 3.0 transceiver IC or USB 3.0 microcontroller
> Altera Cyclone3 FPGA
> highspeed DAC/ADC
What about using an ASIC instead of the FPGA for the DDC, for example AD6652
from Analog Devices, and connect that directly to the USB 3.0 Controller? Might
be cheaper?
On 01/14/2011 04:28 PM, Charly Lima wrote:
> What about using an ASIC instead of the FPGA for the DDC, for example AD6652
> from Analog Devices, and connect that directly to the USB 3.0 Controller?
> Might
> be cheaper?
>
>
The AD6652 isn't exactly cheap, at $45.00 apiece. But I had also
consi
Hi all
I have an usrp2 & xcvr2450 board and I wrote a simple python script
which I use to measure the signal strength and transmit a packet.
Since the xcvr2450 does not support full duplex it switches to
transmitting mode after sending the first packet. Is there a way to
switch back to receiving m
On 01/14/2011 02:09 PM, Stefan Schmid wrote:
Hi all
I have an usrp2& xcvr2450 board and I wrote a simple python script
which I use to measure the signal strength and transmit a packet.
Since the xcvr2450 does not support full duplex it switches to
transmitting mode after sending the first packe
I've posted my latest thoughts at:
http://www.sbrac.org/files/digital_receiver2.pdf
This version has some BOM cost estimates for most of the items, and
shows a new
PLL, the ADF4351, which is a new chip from AD, coming out later this
spring, which
is pin compatible with the ADF4350, and inc
Hi all,
What do people think of introducing a constellation object into gnuradio?
It would hold the constellation points and also a decision-making function.
New modulations could then be easily created by subclassing a constellation.
It would also mean that the decision-making function for a gi
20 matches
Mail list logo
