Hi,
Thank you. Tx/Rx on the old Flex2400 using the usrp2 is now working.
On 01/09/2010 21:41, Jason Abele wrote:
On Wed, Sep 01, 2010 at 03:08:53PM -0400, Marcus D. Leech wrote:
On 09/01/2010 12:51 PM, Jason Abele wrote:
I'll need to do some re-soldering and burn-db-eeprom with USR
Hi Alex,
> Can you actually get usable audio in and out when you use "pulse" for
> device?
Yes (OpenSuSe) -- this is the only way to get some audio operation with
GnuRadio on top of pulseaudio here.
> I use Ubuntu 9.10 and 10.04 and none of my computers are able
> to work with that setting.
I hav
Hi all,
I'm trying to modify the test bench provided with the standard USRP verilog
code
to work with the latest version of the usrp_std module. I'm using the 2rx 0tx
config.
My problem is that I don't think I'm initializing the usrp_std module properly;
I'm not sure of the order of even
Hi,
What could be the reason for this error?
"usrp2: channel 0 not receiving
usrp2::rx_samples() failed"
>From some previously post, Johnathan said that this should be fixed in
>releases after 3.2.2
I'm using the latest git trunk version, I've change the firmware (to
txrx_raw_eth_20100608.bin
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 increase
the fft's sample rate to 50Msps which is 2x the USRP's bandwidth both sinks
On 09/02/2010 10: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 increase
> the fft's sample rate to 50Ms
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 increase
the fft's sample rate to 50Msps wh
On 09/02/2010 11:39 AM, Matt Ettus wrote:
>
>
> If you have unaccelerated OpenGL, then the OpenGL version will be
> unacceptably slow.
>
> Matt
>
Any idea how you *tell* if your OpenGL is accelerated or not? How does
this relate to the Direct Rendering Manager
in the X server?
--
Marcus Leech
Sam,
Coming from a Windows user, I have to say that switching to Ubuntu was 1)
extremely easy and 2) greatly accelerated my understand and ability to use
GNURadio/USRP - mainly because I could use the GRC, which is a Labview-like
graphical interface to GNURadio and USRP.
I'd *highly* recommend giv
Hello!
I am doing some experiments using usrp_oscope.py. I am especially
interested in comparing the values obtained from the usrp devices and
those measured from a traditional oscope. Unfortunately one can't find any
hint which dimension (volts, etc.) is used for displaying the graph.
Thanks a l
On Thu, Sep 2, 2010 at 5:53 PM, Marcus D. Leech wrote:
> On 09/02/2010 11:39 AM, Matt Ettus wrote:
>>
>>
>> If you have unaccelerated OpenGL, then the OpenGL version will be
>> unacceptably slow.
>>
>> Matt
>>
> Any idea how you *tell* if your OpenGL is accelerated or not?
I know several ways tha
With UHD, how can I programmatically detect when transmit underruns have
occurred?
I see Us in the output both on the host and from the USRP2 serial port, but I
haven't spotted an API to test for this condition.
-Marc
___
Discuss-gnuradio mailing li
On Thu, Sep 2, 2010 at 08:39, Matt Ettus wrote:
> I think you are missing the point here. There is no need to lie to the
> program. If you are sending the FFT sink 25 MS/s, then tell it you are
> sending it 25 MS/s. If you give it a different rate you will have all sorts
> of other issues, lik
It will be completely dependent on your receiver chain. My understanding is
that the values you are seeing are the output of the ADC, so you'll need to
figure out what the voltages at that point are. Perhaps someone else can be
more helpful, but you'll need to do the legwork.
What receiver are you
See recv async message:
http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1device.html#afe4ec312d71c669fbd86ce9a7d350605
And the async metadata:
http://www.ettus.com/uhd_docs/doxygen/html/structuhd_1_1async__metadata__t.html
-Josh
On 09/02/2010 12:58 PM, Marc Epard wrote:
With UHD, how
Marcus D. Leech wrote:
>
> On 09/02/2010 11:39 AM, Matt Ettus wrote:
>>
>>
>> If you have unaccelerated OpenGL, then the OpenGL version will be
>> unacceptably slow.
>>
>> Matt
>>
> Any idea how you *tell* if your OpenGL is accelerated or not? How does
> this relate to the Direct Rendering Man
I'm using a USRP2 with UHD and starting a receive a short time in the future. I
have an external reference and PPS. Below is the pertinent code, slightly
simplified.
The timestamp returned in the metadata by recv is always off a little from the
time I requested in the stream command. The amount
Oh cool! When was that implemented? I missed it...
I assume there is no problem with timeout = 0?
Is the interface thread safe? read/write/recv_async?
--Eric
On Thu, 2010-09-02 at 13:23 -0400, Josh Blum wrote:
> See recv async message:
> http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1d
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 list VERY inefficient.
- any sense of "threading" of a conversation is lost (at least for me: I
receive the "d
On Sep 2, 2010, at 12:23 PM, Josh Blum wrote:
> See recv async message:
> http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1device.html#afe4ec312d71c669fbd86ce9a7d350605
>
> And the async metadata:
> http://www.ettus.com/uhd_docs/doxygen/html/structuhd_1_1async__metadata__t.html
Thanks, J
On 09/02/2010 10:39 AM, Marc Epard wrote:
I'm using a USRP2 with UHD and starting a receive a short time in the
future. I have an external reference and PPS. Below is the pertinent
code, slightly simplified.
The timestamp returned in the metadata by recv is always off a little
from the time I re
Dan,
Other than the difficulty of setting up and maintaining the site, I think
it's a fabulous idea!
Then again, I'm just as new as you are, but in general I think it would be
*way* better. Especially for new folks jumping in and learning all the past
body of knowledge.
-William
On Thu, Sep 2, 20
On Thu, Sep 02, 2010 at 01:47:34PM -0400, 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 list VERY inefficient.
> - any sense o
I would like to be able to send a continuous stream of tx packets, each
with a timestamp, such that if one is dropped, the next will be
transmitted at the correct time. My use case involves CDMA test signal
generation, and currently a dropped packet causes a total loss of sync
on the test devices (
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 list VERY inefficient.
A lot of people on here seem to use Nabble
On 09/02/2010 01:54 PM, Marc Epard wrote:
On Sep 2, 2010, at 12:23 PM, Josh Blum wrote:
See recv async message:
http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1device.html#afe4ec312d71c669fbd86ce9a7d350605
And the async metadata:
http://www.ettus.com/uhd_docs/doxygen/html/structuhd_
On 09/02/2010 01:46 PM, Eric Schneider wrote:
Oh cool! When was that implemented? I missed it...
http://old.nabble.com/UHD-Announcement---August-16th-2010-td29457066.html
I assume there is no problem with timeout = 0?
should be fine
Is the interface thread safe? read/write/recv_async?
Hi Eric, thanks for the insightful reply. I will be using these pins for
my design. what else is provided to the board through Ethernet? If I
understand correct, the configuration data for DAC (such as the IF
frequency, etc) is provided through Ethernet, but we don't really want
to change those
On Sep 2, 2010, at 1:02 PM, Matt Ettus wrote:
> [An excellent answer.]
Thanks!
-Marc
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On 09/02/2010 02:48 PM, Malihe Ahmadi wrote:
I need 5 mega bit per sec of bandwidth and if I understand correct the
rate of CMII_TX_CLK is 100 mega bit per second which is higher than
what I want. The first reason I don't like GiGe is that it chunks the
data and it can cause delay in its stream
I downloaded the ise12 branch of the fpga code. Compiled it using the
makefile, and ISE12.2 gui tool. Both did not work in the usrp2, giving the
same results...what a shame.
SteveChrepta wrote:
>
> I am preparing to make small changes to the fpga code. First I wanted to
> compile the latest f
Hi Nick,
Actually we are using the USRP2 not for a SDR application, but we are
using it to test our physical layer asynchronous backet based
communication. For that I have to change the FPGA code and remove the
interpolation/decimation and replace it with a spreading scheme. for
that I need t
FYI, I guess the linkedIn spam mail issue is solved.
Best regards,
Aaron.
Begin forwarded message:
>
> LinkedIn Customer Support Message
> Subject: problem with address book upload and mailing lists
> Hi Aaron,
>
> No, only the "discuss-gnuradio@gnu.org" was used on the member's account.
>
Hi Nick,
Actually we are using the USRP2 not for a SDR application, but we are
using it to test our physical layer asynchronous backet based
communication. For that I have to change the FPGA code and remove the
interpolation/decimation and replace it with a spreading scheme. for
that I need t
Malihe,
> Date: Thu, 2 Sep 2010 14:19:54 -0600
> From: ahmad...@ualberta.ca
> Actually we are using the USRP2 not for a SDR application, but we are
> using it to test our physical layer asynchronous backet based
> communication. For that I have to change the FPGA code and remove the
> interp
Hi MArcus,
Assuming I want to use Ethernet, let's say I want to send the stream
'011', and I pick DBPSK as the modulation. can you please explain
what is the relation of the DBPSK modulated data and "GMII_RXD" input to
the FPGA or "sample" input to the dsp_core_tx? is that FPGA receives 8
The BasicRX has no amplification. Its full scale amplitude is +10dBm.
The ADC in the USRP2 has a rated SFDR of 88dBFS. That means you may see
spurs at levels high as -78dBm equivalent when using a BasicRX. In the
plots you sent me, your signal is -50 dBm and the spur is more than 40
dB lo
Hello -
> It will be completely dependent on your receiver chain. My understanding
> is
> that the values you are seeing are the output of the ADC, so you'll need
> to
> figure out what the voltages at that point are. Perhaps someone else can
> be
> more helpful, but you'll need to do the legwork.
Works fine for everyone else, but we are using ISE 12.1. It shouldn't
be different, though. The most likely problem is programming the SD
card incorrectly.
Matt
On 09/02/2010 11:59 AM, SteveChrepta wrote:
I downloaded the ise12 branch of the fpga code. Compiled it using the
makefile, a
Hi Nick,
I think I should explain my project better. We are developing a physical
layer protocol for an asynchronous packet based transceiver all in
Verilog. The design has been simulated so far using ModelSim. The target
of the project is the VLSI fabrication of this design. Thus all the
sig
On 09/02/2010 05:11 PM, Malihe Ahmadi wrote:
> Hi MArcus,
> Assuming I want to use Ethernet, let's say I want to send the stream
> '011', and I pick DBPSK as the modulation. can you please explain
> what is the relation of the DBPSK modulated data and "GMII_RXD" input
> to the FPGA or "sample"
Malihe,
Your understanding is basically correct. I misunderstood your request -- I
didn't realize you had an existing FPGA design you were integrating with the
USRP2, and figured you were going about things the hard way.
Nothing happens to Ethernet packets between the host transmission and GMI
First mistake: the 2rx 0tx doesn't actually work (or I'm too stupid to make it
work :) I'm using the default 2rx 2tx config, and the usrp_std module is now
responding to input, although it's not showing me what I want yet.
Has anyone else had experience writing test benches for the full chip?
43 matches
Mail list logo
