Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Oddity in E1xx FPGA (Almohanad Fayez)
2. Re: What is the largest data transfer rate between the PC &
USRP2/USRP N Series through a GB ethernet cable? (Josh Blum)
3. IP address and benchmark (Weixian Zhou)
4. Re: what is the largest data transfer rate between fpga and
overo in e100 (Philip Balister)
5. Re: IP address and benchmark (Josh Blum)
6. Re: What is the largest data transfer rate between the PC &
USRP2/USRP N Series through a GB ethernet cable? (Nazmul Islam)
7. Fwd: LFSR SEQUENCE GNURADIO_USRP2 (JAY PRAKASH)
8. Re: GPSDO on usrp2 (Dario Lombardo)
9. Re: problem using LO offset with USRP1 (Patrik Tast)
----------------------------------------------------------------------
Message: 1
Date: Wed, 30 May 2012 09:42:26 -0700
From: Almohanad Fayez <[email protected]>
To: John Buetefuer <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Oddity in E1xx FPGA
Message-ID:
<CABv+bNWJ-CKpHx45Kzi-cfzot7s82D2rf=t9bwJW=fev4ka...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
To answer your FPGA/GPS/serial question, the FPGA image doesn't read
in the RS232 values it just takes PPS and the 10 MHz reference signal.
On Tue, May 29, 2012 at 10:10 PM, John Buetefuer
<[email protected]> wrote:
> It appears I may have spoken too soon. If I remove these signals the port
> stops working, which suggests that I have outdated schematics for the E100.
>
> Are the latest E100/E110 schematics available? (Rev4?)
>
> Cheers
>
> John
>
>
> On 30/05/2012 1:15 PM, John Buetefuer wrote:
>>
>> I've just commenced integrating a 3rd party GPS unit (ie, not a GPSDO)
>> with an E100 and have noticed the following odd things with the E100 FPGA
>> and schematics.
>>
>> * The FPGA appears to be driving the overo_rxd1 net (and uart Rx input pin
>> on the overo) with a signal from the FPGA input pin "fpga_rxd1" (ball AB8) -
>> which according to my schematics is not connected on the PCB at all (presume
>> this is pulled high by the FPGA I/O pull-ups). ?[fpga/usrp2/top/E1x0/u1e.v]
>>
>> ? //
>> /////////////////////////////////////////////////////////////////////////
>> ? // UART level conversion
>> ? assign fpga_txd1 = overo_txd1;
>> ? assign overo_rxd1 = fpga_rxd1;
>>
>> overo_rxd1 is defined as an output pin, which sees it driving against the
>> MAX232 driving this line - surely this is not correct or intended.?
>>
>> It looks to me that this code may have had some historical purpose on an
>> earlier rev of the board, but perhaps with the current version of the
>> hardware, is not correct?
>>
>> On a somewhat related note, can someone confirm that on the E1x0 series
>> units, the FPGA firmware does not communicate with the GPSDO unit at all
>> (via RS232), and that the UHD accesses the GPS via the Overo serial port
>> (ttyO0)?
>>
>> Cheers
>>
>> John
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Almohanad (Al) Fayez
------------------------------
Message: 2
Date: Wed, 30 May 2012 09:58:23 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] What is the largest data transfer rate
between the PC & USRP2/USRP N Series through a GB ethernet cable?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 05/30/2012 07:11 AM, Nazmul Islam wrote:
> Hello,
>
> I found a tutorial on GNUradio (
> http://www.snowymtn.ca/gnuradio/gnuradiodoc-4.pdf) that mentions that USRP
> downconverts the signal to 8 Mega Sample per second before passing it to
> the USB cable. They do it due to the 32 Mega byte data transfer rate of USB
> cable and 16 bit I & Q samples. I assume that this information applies to
> USRP1 with USB cable.
>
> I am planning to use USRP2 & USRP N series along with GB ethernet cables in
> my experiments. Do these USRP's downconvert the signal before passing on to
> the computer? If my computer is fast enough, can I transmit and receive (in
> seperate USRP's) a signal with 20 MHz bandwidth?
>
There is a downconversion and upconversion chain in the USRP. The
practical rate limitations are 25 Msps at 32 bits per complex sample or
50 Msps at 16 bits per complex sample.
Is your computer fast enough? Thats an open ended question, but if you
can test your processing IP without a USRP pretty easily: send samples
from another computer over GigE and benchmark performance to see if your
application can process the samples fast enough.
-josh
------------------------------
Message: 3
Date: Wed, 30 May 2012 13:15:38 -0400
From: Weixian Zhou <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] IP address and benchmark
Message-ID:
<CAHeRwcTz_akntPQTbvE-TxTv8esLOGekbJpE6xi=xKrp_Ti=m...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
1) I setup the IP of a PC as 192.168.10.1 via
*ifconfig eth0 192.168.10.1*
Then I ping 192.168.10.2, the USRP responses. My question is that which IP
address does USRP use when we broadcast, 192.168.10.1 or 192.168.10.2?
2) My two PCs and USRPs has completely same setup, include the same IP
addresses. So does it matters if I try to send a file from one to another
through benchmark_tx and benchmark_rx?
--
Regards,
Weixian Zhou
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120530/e2fce320/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 30 May 2012 13:19:29 -0400
From: Philip Balister <[email protected]>
To: Ian Buckley <[email protected]>
Cc: discuss-gnuradio <[email protected]>,
[email protected]
Subject: Re: [USRP-users] what is the largest data transfer rate
between fpga and overo in e100
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 05/30/2012 11:46 AM, Ian Buckley wrote:
> There is a mictor connector (J301 on both USRP2 and N2x0) that has 32 signal
> and 2 clock pins all free to be used in the FPGA. Searching for "mictor" in
> the archive of this forum will find other posts about this.
>
> However I do want to drive home the point that you are unlikely to find an
> ARM processor currently that is capable of doing anything useful directly
> with RF data at bandwidths greater than which the E100 is capable or indeed
> one with a flexible physical interface that can support 60MB/s....you're
> clearly in the realm of high-end DSP processors at those rates.
If you need to do the processing on an ARM, you should research this
company:
http://www.calxeda.com/products/energycards/quadnode
Philip
>
>
> On May 30, 2012, at 8:02 AM, Almohanad Fayez wrote:
>
>> I don't believe there's a document for this it's more of an exercise left
>> for the motivated user.
>>
>> On May 30, 2012 6:27 AM, "Page Jack" <[email protected]> wrote:
>> Hi Almohanad ,
>> thanks for this information, can you provide more detail or is there any doc?
>>
>> On 5/30/12, Almohanad Fayez <[email protected]> wrote:
>>> If memory serves correctly the n200 or the usrp 2 has an fpga expansion
>>> interface to some xilinx development platform which you might be able to
>>> use to create a custom solution to serve your needs.
>>>
>>> Al
>>> On May 29, 2012 6:17 PM, "Page Jack" <[email protected]> wrote:
>>>
>>>> I don't want to using a ethernet wire to connect N series to an ARM
>>>> board.
>>>> anyone have tried
>>>> build N series with ARM or DSP in one board which means the ethernet line
>>>> between N and
>>>> the processor is on PCB.
>>>>
>>>> On Wed, May 30, 2012 at 6:24 AM, Philip Balister
>>>> <[email protected]>wrote:
>>>>
>>>>> On 05/25/2012 09:18 PM, Page Jack wrote:
>>>>>> Hi Philip,
>>>>>> How does the conclusion be made that ARM can not swallow the current
>>>>>> max data transfer rate? I need to build a project that need to process
>>>>>> 60MB/s data, so any way to achieve my goal. Use a more powerful CPU or
>>>>>> use dsp on the omap?
>>>>>
>>>>> 60 MB/s is far more data than the OMAP3 can transfer from the FPGA. We
>>>>> have worked hard on configuring the GPMC interface and this figure is
>>>>> basically an order of magnitude more then the hardware will support.
>>>>>
>>>>> You need to look at the N series with Gig-E, or do the high rate
>>>>> processing in the FPGA.
>>>>>
>>>>> Philip
>>>>>
>>>>>
>>>>>>
>>>>>> On 5/25/12, Philip Balister <[email protected]> wrote:
>>>>>>> On 05/24/2012 09:46 PM, Page Jack wrote:
>>>>>>>> Thanks Ben,
>>>>>>>> does e100 use EMIF to transfer sample data between FPGA and ARM? If
>>>>>>>> so
>>>>>>>> the
>>>>>>>> data rate should be able to improved.
>>>>>>>> Anyone have tried to improve the data rate?
>>>>>>>
>>>>>>> EMIF is basically identical to GPMC. The interface uses DMA to move
>>>>> data
>>>>>>> in 2K chunks between the FPGA and memory. This is the largest
>>>>>>> transfer
>>>>>>> possible due to how we connected the address and data lines
>>>>>>>
>>>>>>> My impression of the current limiting factor is interrupt response
>>>>> time.
>>>>>>> There is probably some room for small improvements, but as Ben notes,
>>>>> we
>>>>>>> are already collecting data faster than the ARM can swallow it.
>>>>>>>
>>>>>>> Philip
>>>>>>>
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> On Thu, May 24, 2012 at 9:01 AM, Ben Hilburn <[email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> The CPU sets up the initial DMA parameters, but from then on, it's
>>>>> pure
>>>>>>>>> DMA. No CPU is required.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Ben
>>>>>>>>> ----------------------------
>>>>>>>>> Ben Hilburn <http://goo.gl/5DdZ3> @ Ettus Research,
>>>>>>>>> LLC<http://www.ettus.com/>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, May 23, 2012 at 5:55 PM, Page Jack <[email protected]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Thanks, does the ARM memory bus use DMA or it eat cpu?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, May 24, 2012 at 5:06 AM, Ben Hilburn
>>>>>>>>>> <[email protected]>wrote:
>>>>>>>>>>
>>>>>>>>>>> Page -
>>>>>>>>>>>
>>>>>>>>>>> The memory bus to the ARM provides 40 MBytes / second. This is
>>>>> used
>>>>>>>>>>> for
>>>>>>>>>>> streaming samples, as controlled via software. Currently, UHD
>>>>> supports
>>>>>>>>>>> 16
>>>>>>>>>>> bit and 8 bit samples for TX & RX. The GPMC can only going to
>>>>> talk to
>>>>>>>>>>> one
>>>>>>>>>>> slave at a time; the possible slaves are TX, RX, and ethernet.
>>>>>>>>>>> So
>>>>> you
>>>>>>>>>>> can
>>>>>>>>>>> only be sending TX samples, receiving RX samples, or
>>>>>>>>>>> communicating
>>>>> via
>>>>>>>>>>> ethernet.
>>>>>>>>>>>
>>>>>>>>>>> Thus, doing the math with the numbers above, you can stream:
>>>>>>>>>>> 16 bit I, 16 bit Q -- Total: 32-bit samples -- @ 10 MSps
>>>>>>>>>>> 8 bit I, 8 bit Q -- Total: 16-bit samples -- @ 20 MSps
>>>>>>>>>>>
>>>>>>>>>>> What you choose to do with this data is obviously up to you. It
>>>>>>>>>>> is
>>>>>>>>>>> very
>>>>>>>>>>> easy to try to do more processing than the ARM can handle, in
>>>>>>>>>>> which
>>>>>>>>>>> case
>>>>>>>>>>> samples will start getting thrown out by UHD. Thus, you can
>>>>> typically
>>>>>>>>>>> process between 4 and 8 MHz of baseband bandwidth, depending on
>>>>> your
>>>>>>>>>>> application. If you are willing to dig deep into the code to
>>>>>>>>>>> make
>>>>> NEON
>>>>>>>>>>> and
>>>>>>>>>>> C64 optimizations, you can improve the performance dramatically.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Ben
>>>>>>>>>>> ----------------------------
>>>>>>>>>>> Ben Hilburn <http://goo.gl/5DdZ3> @ Ettus Research,
>>>>>>>>>>> LLC<http://www.ettus.com/>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, May 22, 2012 at 7:47 PM, Page Jack
>>>>>>>>>>> <[email protected]>wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> I want to know the overo model used in e100 and the largest data
>>>>>>>>>>>> transfer rate between fpga and overo in e100.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards!
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> USRP-users mailing list
>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> USRP-users mailing list
>>>>>>>> [email protected]
>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> [email protected]
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
------------------------------
Message: 5
Date: Wed, 30 May 2012 10:40:36 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] IP address and benchmark
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 05/30/2012 10:15 AM, Weixian Zhou wrote:
> 1) I setup the IP of a PC as 192.168.10.1 via
> *ifconfig eth0 192.168.10.1*
> Then I ping 192.168.10.2, the USRP responses. My question is that which IP
> address does USRP use when we broadcast, 192.168.10.1 or 192.168.10.2?
>
> 2) My two PCs and USRPs has completely same setup, include the same IP
> addresses. So does it matters if I try to send a file from one to another
> through benchmark_tx and benchmark_rx?
>
>
The IP address of the USRP is not related to the functionality of the
gnuradio examples benchmark_tx and benchmark_rx. They both implement
network stacks, but are entirely unrelated things.
-josh
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 6
Date: Thu, 31 May 2012 00:54:30 -0400
From: Nazmul Islam <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] What is the largest data transfer rate
between the PC & USRP2/USRP N Series through a GB ethernet cable?
Message-ID:
<CAFtrfEasf0TK3gofTvzCUuwJ=strv=-JwY_WXa=ynmb1o3c...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Thanks a lot, Josh.
Does overrun/underrun issues depend on the no. of bits per sample? Or is it
entirely dependent on the sampling rate?
I am currently using gnuradio-companion to transmit a bpsk signal and
receive the I&Q baseband samples. The computers are showing
overrun/underrun after 12 MS/s. If I can reduce the no. of bits/complex
sample (and I don't know how), can I transmit at 24 MS/s?
Thanks,
Nazmul
On Wed, May 30, 2012 at 12:58 PM, Josh Blum <[email protected]> wrote:
>
>
> On 05/30/2012 07:11 AM, Nazmul Islam wrote:
> > Hello,
> >
> > I found a tutorial on GNUradio (
> > http://www.snowymtn.ca/gnuradio/gnuradiodoc-4.pdf) that mentions that
> USRP
> > downconverts the signal to 8 Mega Sample per second before passing it to
> > the USB cable. They do it due to the 32 Mega byte data transfer rate of
> USB
> > cable and 16 bit I & Q samples. I assume that this information applies to
> > USRP1 with USB cable.
> >
> > I am planning to use USRP2 & USRP N series along with GB ethernet cables
> in
> > my experiments. Do these USRP's downconvert the signal before passing on
> to
> > the computer? If my computer is fast enough, can I transmit and receive
> (in
> > seperate USRP's) a signal with 20 MHz bandwidth?
> >
>
> There is a downconversion and upconversion chain in the USRP. The
> practical rate limitations are 25 Msps at 32 bits per complex sample or
> 50 Msps at 16 bits per complex sample.
>
> Is your computer fast enough? Thats an open ended question, but if you
> can test your processing IP without a USRP pretty easily: send samples
> from another computer over GigE and benchmark performance to see if your
> application can process the samples fast enough.
>
> -josh
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
Muhammad Nazmul Islam
Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120531/160248b0/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 31 May 2012 16:56:22 +0800
From: JAY PRAKASH <[email protected]>
To: [email protected]
Subject: [USRP-users] Fwd: LFSR SEQUENCE GNURADIO_USRP2
Message-ID:
<CADVr-4wk4wge29VhiedSocfzrJ6Vb9zR1SJSGvm=ce_1tQT=7...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Sir, Actually I have to measure channel impulse response.I am using
gnuradio for the purpose. As per the theory I can do so by sending the BPSK
modulated PN sequence.But like your doubt I need to know the rate of PN
sequence transmission and control it too.But the big doubt is the output of
GLFSR.It should be 1 and 0 sequence but here it appears to be 1 and -1
and the edges are not sharp too.The output is triangular in cases.I have
attached the image of my output.
one more thing how to get the desired output ie for x^4 + x^3 + x^0 = 0x19
but where this 0x19 came from? I am not able to get it.
Please help me out in the concerned doubts. I shall be obliged for your
support.
Thanks
Actually
Jay Prakash
B.Tech Part III
Electronics Engineering
IIT BHU
VARANASI
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120531/ef03f044/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot.png
Type: image/png
Size: 208030 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120531/ef03f044/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot-1.png
Type: image/png
Size: 159500 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120531/ef03f044/attachment-0003.png>
------------------------------
Message: 8
Date: Thu, 31 May 2012 12:31:33 +0200
From: Dario Lombardo <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] GPSDO on usrp2
Message-ID:
<caoyjjfsufkksvukhghagt50pdtuoomvoyqnz2agvxu8oxbx...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I've read in this post
http://sourceforge.net/mailarchive/forum.php?thread_name=CALALHJXbdq%3D6TRC-Md5poCFv%2BaEx8imqPZWVoUkYrqTnJLEhaw%40mail.gmail.com&forum_name=openbts-discuss
that the gpsdo unit should be left for a while in order to self-calibrate.
Is it true? How long should it be left?
I'm looking at the error from kal, and I'm observing that it's increasing
instead of decreasing.
It started from 2kHz and now is oscillating around 14.5kHz.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120531/598e8a4c/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 31 May 2012 16:33:12 +0300
From: "Patrik Tast" <[email protected]>
To: "Stefano Speretta" <[email protected]>,
<[email protected]>
Subject: Re: [USRP-users] problem using LO offset with USRP1
Message-ID: <4299856A367742D588128819FAFE0F0B@hp>
Content-Type: text/plain; format=flowed; charset="ISO-8859-15";
reply-type=original
Hi Stefano,
>I am using a USRP1 and I attached 2 50ohm terminators to the two antenna
Ok, as I understand from your post, you don't want to receive anything, just
cry?
Remove that 50 ohm thing. Try to connect an antenna and perhaps an amplifier
in-between then point at a source, then you wont see that spike...
....
P
----- Original Message -----
From: "Stefano Speretta" <[email protected]>
To: <[email protected]>
Sent: Wednesday, May 30, 2012 16:55
Subject: [USRP-users] problem using LO offset with USRP1
> Hello,
>
> I am seeing a spurious component at DC using a USRP1 and WBX board.
> Similar problems were already reported several times in the mailing list
> and
> the suggestion was to use an offset in tuning to move this DC component
> out of band.
>
> I am trying to do this but I keep seeing the same result (so that DC
> component in band). I am using a USRP1 and I attached 2 50ohm
> terminators to the two antenna
> ports to eliminate signals coming from outside but the DC component is
> still there, even if I change the RX tuning frequency.
>
> If I do not use the LO offset, in my application I set the RX frequency
> like this:
>
> uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
> ....
> double freq = 200e6;
> uhd::tune_result_t tuned = usrp->set_rx_freq(freq);
>
> and if I print tuned.to_string I get this:
> Tune Result:
> Target RF Freq: 200.000000 (MHz)
> Actual RF Freq: 199.999723 (MHz)
> Target DSP Freq: -0.000277 (MHz)
> Actual DSP Freq: -0.000277 (MHz)
>
> If I do an FFT of the received signal it looks like in the
> no_lo_offset.png that is attached (span is 20 kHz centered around 200
> MHz and the spike is 15 dB above noise floor).
>
> If I set the offset (5 kHz in this case, I tried with other values too
> and the result is the same) in the tune function, like this:
>
> uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
> ....
> double freq = 200e6;
> uhd::tune_result_t tuned = usrp->set_rx_freq(freq, 5000);
>
> printing tuned.to_string gives:
> Tune Result:
> Target RF Freq: 200.005000 (MHz)
> Actual RF Freq: 200.004932 (MHz)
> Target DSP Freq: 0.004932 (MHz)
> Actual DSP Freq: 0.004932 (MHz)
>
> But the FFT shows again that strong DC peak (check lo_offset.png
> attached). If you look carefully you will see that there is a Gaussian
> shaped noise around +5 khz
> which is exactly the noise around DC, so the offset tuning is working
> fine (you see the same noise around DC in the other picture).
> The problem is that the peak around DC is always there.
>
> I also tried enabling and disabling the rx_dc_offset (using
> set_rx_dc_offset) but with no luck.
>
> The spurious signal that I see is still there if I tune the the receiver
> to other frequencies (so I do not think this is an harmonic of the
> internal oscillator). The same peak can also be seen
> by using rx_ascii_art.
>
> Is it possible that there is some rounding error in the cordic or
> decimation stages leading to this DC error? Or in the conversions in the
> PC?
>
> Does anybody have ideas on what could be the source and how to eliminate
> this problem?
>
> Thanks a lot,
> Stefano
>
--------------------------------------------------------------------------------
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 21, Issue 30
******************************************
