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: Cannot remove X310 image (David Miller)
2. Re: Cannot remove X310 image (Marcus M?ller)
3. Re: API that clears recv buffer? (Marcus M?ller)
4. Re: API that clears recv buffer? (Dario Fertonani)
5. Re: FPGA RAW ADC values on N210 (Marcus M?ller)
6. Daughterboard difference between 120/160MHz and 40MHz version
(hanwen)
7. Re: Daughterboard difference between 120/160MHz and 40MHz
version (Marcus D. Leech)
8. Re: Daughterboard difference between 120/160MHz and 40MHz
version (hanwen)
9. Re: Daughterboard difference between 120/160MHz and 40MHz
version (Marcus D. Leech)
10. Strange behavior when receiving a DC signal (Frank Liu)
11. Re: Strange behavior when receiving a DC signal (Marcus D. Leech)
----------------------------------------------------------------------
Message: 1
Date: Sat, 1 Oct 2016 16:02:16 +0100
From: David Miller <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Cannot remove X310 image
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Thanks Marcus,
Yeah, I must have remembered incorrectly about the version, the FPGA
versioning makes sense, thanks.
It's a fresh install of UHD 3.9.4 on a new install of Centos7. No other
version of UHD has been installed.
Thanks,
Dave
On 01/10/2016 16:51, Marcus M?ller wrote:
> Hi David,
>
> 003.009.004 is the host-side UHD library version, not the version of
> the FPGA image (these do have to be compatible, but FPGA versioning
> follows a different scheme). Loading a different FPGA image onto the
> USRP can't change that string.
>
> Since you're using images from a path that indicates you want to use
> UHD 3.9.4, you must make sure that at runtime, no different version of
> UHD is accidentally loaded.
>
> Best regards
> Marcus
>
> Am 1. Oktober 2016 02:29:37 GMT-07:00, schrieb David Miller via
> USRP-users <[email protected]>:
>
> Thank-you for replying...
>
> Using Vivado hardware manager, program FPGA with...
> uhd-images_003.009.004-release/share/uhd/images/usrp_x310_fpga_HGS.bit
> From what I remember uhd_usrp_probe states the loaded version is
> now 003.009.004... and not 003.008.002
> then do:
> uhd_image_loader --args addr=192.168.10.2,type=x300 --fpga-path
> uhd-images_003.009.004-release/share/uhd/images/usrp_x310_fpga_HGS.bit
> which returns the error.
>
> Thanks,
> Dave
>
>
>
> On 30/09/2016 19:12, Paul David wrote:
>> Also, could you provide the arguments you're supplying to
>> uhd_image_loader?
>>
>> On Fri, Sep 30, 2016 at 11:10 AM, Paul David
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> Hi David,
>>
>> Are you certain you're on the same version of UHD as the FPGA
>> image?
>>
>> On Fri, Sep 30, 2016 at 3:42 AM, David Miller
>> <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hi Paul and usrp-users,
>>
>> So, I used Vivado hardware manager to program the FPGA
>> with 3.9.4 bitfile (I'm stuck with 3.9.4 for the moment)
>> and confirmed with uhd_usrp_probe that all appears OK.
>> I did not power cycle the X310.
>> But then trying to use uhd_image_loader with the 3.9.4
>> bitfile fails with the same "Error: RunTimeError: Device
>> reported an error during initialization".
>>
>> Maybe I should re-program the 3.8.2 image back first?
>>
>> Any ideas?
>>
>> Thanks,
>> Dave
>>
>>
>> On 20/09/2016 19:07, Paul David wrote:
>>> Hi David,
>>>
>>> To answer your question: you do need Vivado in order to
>>> configure the FPGA over JTAG using the command:
>>> viv_jtag_program <bitfile path> .
>>>
>>> Or you can use the hardware manager in Vivado. After you
>>> do that, you'll need to use uhd_image_loader to burn the
>>> same FPGA image so that it persists after a power cycle.
>>>
>>> I would recommend upgrading UHD to a more recent tagged
>>> release as well.
>>>
>>> -- Paul
>>>
>>> On Tue, Sep 20, 2016 at 9:08 AM, David Miller via
>>> USRP-users <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Hi,
>>>
>>> I have acquired an X310 with an image based on the
>>> original uhd 3.8.2 image, not sure what it does but
>>> doing a uhd_usrp_probe with uhd 3.8.2 it works as
>>> expected, however no samples are emitted with the
>>> utilities, it's hosed!
>>>
>>> Anyways, I have tried the 3.8.2 burn program
>>> (usrp_x3xx_fpga_burner) which fails, and currently
>>> tried the 3.9.4 uhd_image_loader.
>>>
>>> uhd_image_loader fails (and similarly
>>> usrp_x3xx_fpga_burner) with:
>>>
>>> Error: RunTimeError: Device reported an error during
>>> initialization.
>>>
>>> I hacked the code in the x310_send_and_receive()
>>> function, somewhere in the code, to see if there is
>>> any kind of status message generated that might
>>> help, the recv function returns a len of 4 (0 being
>>> a timeout), which fails a subsequent check function
>>> that masks this len value (with 0x04, or whatever
>>> the def is) to determine that this is a failure.
>>> Sorry to be a bit vague, I don't have the setup in
>>> front of me at the moment.
>>>
>>> So, the real question is: How do I recover the unit
>>> and burn back a working image, is it now only
>>> possible using Vivado/ISE/JTAG?
>>>
>>> Hope you can help?
>>>
>>> Thanks,
>>> Dave
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> <mailto:[email protected]>
>>>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>>
>>>
>>
>>
>>
>>
>> --
>> #/Paul David/
>> # /Staff Software Design Engineer/
>> #/Ettus Research - A National Instruments Company/
>>
>>
>>
>>
>> --
>> #/Paul David/
>> # /Staff Software Design Engineer/
>> #/Ettus Research - A National Instruments Company/
>
>
> ------------------------------------------------------------------------
>
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161001/c21fbcec/attachment-0001.html>
------------------------------
Message: 2
Date: Sat, 1 Oct 2016 09:19:54 -0700
From: Marcus M?ller <[email protected]>
To: David Miller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Cannot remove X310 image
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi David,
ah, well. I was hoping we could quickly solve this, but let me contact
you off-list in a minute, and we'll sort this out.
Thanks for your patience!
Marcus
On 10/01/2016 08:02 AM, David Miller wrote:
> Thanks Marcus,
>
> Yeah, I must have remembered incorrectly about the version, the FPGA
> versioning makes sense, thanks.
>
> It's a fresh install of UHD 3.9.4 on a new install of Centos7. No
> other version of UHD has been installed.
>
> Thanks,
> Dave
>
>
> On 01/10/2016 16:51, Marcus M?ller wrote:
>> Hi David,
>>
>> 003.009.004 is the host-side UHD library version, not the version of
>> the FPGA image (these do have to be compatible, but FPGA versioning
>> follows a different scheme). Loading a different FPGA image onto the
>> USRP can't change that string.
>>
>> Since you're using images from a path that indicates you want to use
>> UHD 3.9.4, you must make sure that at runtime, no different version
>> of UHD is accidentally loaded.
>>
>> Best regards
>> Marcus
>>
>> Am 1. Oktober 2016 02:29:37 GMT-07:00, schrieb David Miller via
>> USRP-users <[email protected]>:
>>
>> Thank-you for replying...
>>
>> Using Vivado hardware manager, program FPGA with...
>> uhd-images_003.009.004-release/share/uhd/images/usrp_x310_fpga_HGS.bit
>> From what I remember uhd_usrp_probe states the loaded version is
>> now 003.009.004... and not 003.008.002
>> then do:
>> uhd_image_loader --args addr=192.168.10.2,type=x300 --fpga-path
>> uhd-images_003.009.004-release/share/uhd/images/usrp_x310_fpga_HGS.bit
>> which returns the error.
>>
>> Thanks,
>> Dave
>>
>>
>>
>> On 30/09/2016 19:12, Paul David wrote:
>>> Also, could you provide the arguments you're supplying to
>>> uhd_image_loader?
>>>
>>> On Fri, Sep 30, 2016 at 11:10 AM, Paul David
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> Hi David,
>>>
>>> Are you certain you're on the same version of UHD as the
>>> FPGA image?
>>>
>>> On Fri, Sep 30, 2016 at 3:42 AM, David Miller
>>> <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Hi Paul and usrp-users,
>>>
>>> So, I used Vivado hardware manager to program the FPGA
>>> with 3.9.4 bitfile (I'm stuck with 3.9.4 for the moment)
>>> and confirmed with uhd_usrp_probe that all appears OK.
>>> I did not power cycle the X310.
>>> But then trying to use uhd_image_loader with the 3.9.4
>>> bitfile fails with the same "Error: RunTimeError: Device
>>> reported an error during initialization".
>>>
>>> Maybe I should re-program the 3.8.2 image back first?
>>>
>>> Any ideas?
>>>
>>> Thanks,
>>> Dave
>>>
>>>
>>> On 20/09/2016 19:07, Paul David wrote:
>>>> Hi David,
>>>>
>>>> To answer your question: you do need Vivado in order to
>>>> configure the FPGA over JTAG using the command:
>>>> viv_jtag_program <bitfile path> .
>>>>
>>>> Or you can use the hardware manager in Vivado. After
>>>> you do that, you'll need to use uhd_image_loader to
>>>> burn the same FPGA image so that it persists after a
>>>> power cycle.
>>>>
>>>> I would recommend upgrading UHD to a more recent tagged
>>>> release as well.
>>>>
>>>> -- Paul
>>>>
>>>> On Tue, Sep 20, 2016 at 9:08 AM, David Miller via
>>>> USRP-users <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have acquired an X310 with an image based on the
>>>> original uhd 3.8.2 image, not sure what it does but
>>>> doing a uhd_usrp_probe with uhd 3.8.2 it works as
>>>> expected, however no samples are emitted with the
>>>> utilities, it's hosed!
>>>>
>>>> Anyways, I have tried the 3.8.2 burn program
>>>> (usrp_x3xx_fpga_burner) which fails, and currently
>>>> tried the 3.9.4 uhd_image_loader.
>>>>
>>>> uhd_image_loader fails (and similarly
>>>> usrp_x3xx_fpga_burner) with:
>>>>
>>>> Error: RunTimeError: Device reported an error
>>>> during initialization.
>>>>
>>>> I hacked the code in the x310_send_and_receive()
>>>> function, somewhere in the code, to see if there
>>>> is any kind of status message generated that might
>>>> help, the recv function returns a len of 4 (0 being
>>>> a timeout), which fails a subsequent check function
>>>> that masks this len value (with 0x04, or whatever
>>>> the def is) to determine that this is a failure.
>>>> Sorry to be a bit vague, I don't have the setup in
>>>> front of me at the moment.
>>>>
>>>> So, the real question is: How do I recover the unit
>>>> and burn back a working image, is it now only
>>>> possible using Vivado/ISE/JTAG?
>>>>
>>>> Hope you can help?
>>>>
>>>> Thanks,
>>>> Dave
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> <mailto:[email protected]>
>>>>
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> #/Paul David/
>>> # /Staff Software Design Engineer/
>>> #/Ettus Research - A National Instruments Company/
>>>
>>>
>>>
>>>
>>> --
>>> #/Paul David/
>>> # /Staff Software Design Engineer/
>>> #/Ettus Research - A National Instruments Company/
>>
>>
>> ------------------------------------------------------------------------
>>
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161001/5039d74b/attachment-0001.html>
------------------------------
Message: 3
Date: Sat, 1 Oct 2016 09:31:15 -0700
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] API that clears recv buffer?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
you could just loop until recv() fills your metadata with an
end_of_burst flag:
while(not md.end_of_burst) {
recv(buffer, md);
}
On 09/30/2016 10:57 PM, Dario Fertonani via USRP-users wrote:
> Is it possible to clear the recv buffer in the "some code" part of the
> example below? I was assuming that stopping the rxStreamPtr stream and
> starting a new one would clear the buffer, but the time stamps of the
> RX meta data say otherwise.
>
> Thanks,
> Dario
>
> {
> uhd::stream_cmd_t rxStreamCmd(
> uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS );
> rxStreamCmd.stream_now = true;
> rxStreamPtr->issue_stream_cmd( rxStreamCmd );
> }
> {
> //some code
> }
> {
> uhd::stream_cmd_t rxStreamCmd(
> uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS );
> rxStreamCmd.stream_now = false;
> rxStreamCmd.time_spec = newStreamStartTime;
> rxStreamPtr->issue_stream_cmd( rxStreamCmd );
> }
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161001/55b07cb6/attachment-0001.html>
------------------------------
Message: 4
Date: Sat, 1 Oct 2016 10:13:38 -0700
From: Dario Fertonani <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] API that clears recv buffer?
Message-ID:
<cajgedah33cnrsurnyxdtueqyhdmgjjdhws6+vmqgtuxn-zk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thank you, that works. I ended up with the following code (same as yours,
except for the need of a timeout in my architecture).
while ( rxMetaData.end_of_burst == false )
{
rxStreamPtr->recv( rxSamplePtr_d1 , ChunkSamples , rxMetaData ,
RxTimeout_s );
}
On Sat, Oct 1, 2016 at 9:31 AM, Marcus M?ller via USRP-users <
[email protected]> wrote:
> you could just loop until recv() fills your metadata with an end_of_burst
> flag:
>
> while(not md.end_of_burst) {
> recv(buffer, md);
> }
>
> On 09/30/2016 10:57 PM, Dario Fertonani via USRP-users wrote:
>
> Is it possible to clear the recv buffer in the "some code" part of the
> example below? I was assuming that stopping the rxStreamPtr stream and
> starting a new one would clear the buffer, but the time stamps of the RX
> meta data say otherwise.
>
> Thanks,
> Dario
>
> {
> uhd::stream_cmd_t rxStreamCmd(
> uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS
> );
> rxStreamCmd.stream_now = true;
> rxStreamPtr->issue_stream_cmd( rxStreamCmd );
> }
> {
> //some code
> }
> {
> uhd::stream_cmd_t rxStreamCmd(
> uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS
> );
> rxStreamCmd.stream_now = false;
> rxStreamCmd.time_spec = newStreamStartTime;
> rxStreamPtr->issue_stream_cmd( rxStreamCmd );
> }
>
>
>
>
> _______________________________________________
> USRP-users mailing
> [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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161001/8b6a1c16/attachment-0001.html>
------------------------------
Message: 5
Date: Sat, 1 Oct 2016 11:32:43 -0700
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] FPGA RAW ADC values on N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Matthias!
> I want to bypass the DDC, because I work directly with IF because I
> have an external I-Q mixer. I want to use the FFT block instead of the
> DDC block.
Well, that's fine. You should basically be able to bypass the ddc_chain
module with a set of wires.
> As far as I see it, each ADC channel of the dual ADC has only a
> resolution of 14 bit
Well, have a look into rx_frontend.v. DC offset correction, and more
importantly, IQ imbalance correction take place in there, which are
bit-widening operations. In fact, those are 18x18 bit multiplications,
and the result is shortened to 24 bit.
Regarding your ADC setup question: I like to consider the N210's ADC to
be a single device. It gives two samples simultaneously. This complex
sampling case is the default, you don't have to do anything special.
Best regards,
Marcus
On 09/20/2016 02:17 PM, Matthias M?ller via USRP-users wrote:
>
> Dear USRP users
>
> I?m currently working on my master thesis where I will calculate a FFT
> on a N210. I make my own I-Q mixer and filter in HW and I use the ADC
> of my N210 only to sample the already mixed signals.
> I?m now a little bit confused where to insert the FFT block in the
> FPGA. As it is written in the description, I need to modify the
> ?custom_dsp_rx.v? and put my FFT block directly there.
> I want to bypass the DDC, because I work directly with IF because I
> have an external I-Q mixer. I want to use the FFT block instead of the
> DDC block.
>
> I have following issues:
>
> 1: I?m a little bit confused about the width of the frontend_i and
> frontend_q signals. According to several internet resources,
> frontend_i corresponds to the samples directly sampled from the ADC1
> of the HW and frontend_q to the ADC2. As far as I see it, each ADC
> channel of the dual ADC has only a resolution of 14 bits. So why are
> frontend_i and frontend_q 24 bits wide? Or do I need to get the raw
> ADC values from elsewhere?
>
> 2: by using the makro in the makefile, I can specify two separate
> channels, RX_DSP0_MODULE and RX_DSP1_MODULE. It is correct, that
> those channels are two parallel, independant DDC channels which have
> nothing to do with each other and both use the same frontend_i and
> frontend_q samples from the ADC? Is it correct that I need only one
> (e.g. RX_DSP0_MODULE), put my FFT block in it and I could forget about
> the other?
>
> 3: Do I also need to specify a special frontend in the driver to make
> sure that the ADC1 samples are on frontend_i and the ADC2 samples are
> on frontend_q? Like A:AB? Are more driver settings needed?
>
> I hope you could clear up a little bit of my confusion J
> Thank you in advance
> Cheers,
> Matthias
>
>
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161001/b499bf05/attachment-0001.html>
------------------------------
Message: 6
Date: Sat, 1 Oct 2016 22:14:06 +0200
From: hanwen <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Daughterboard difference between 120/160MHz and
40MHz version
Message-ID:
<cabjuse3whtflmazz9ynh4vuybs787hf5xbvbcz7rlqrp++k...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I'd like to know the exact difference between the same daughterboard type
which comes with two bandwidth versions.
For applcations only needing relatively narrower bandwidth (<20MHz), will
the 40MHz version provide better anti-aliasing against the interference
from adjacent band?
Br, Hanwen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161001/21b8268c/attachment-0001.html>
------------------------------
Message: 7
Date: Sat, 01 Oct 2016 16:24:10 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Daughterboard difference between 120/160MHz
and 40MHz version
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 10/01/2016 04:14 PM, hanwen via USRP-users wrote:
> Hi,
>
> I'd like to know the exact difference between the same daughterboard
> type which comes with two bandwidth versions.
>
> For applcations only needing relatively narrower bandwidth (<20MHz),
> will the 40MHz version provide better anti-aliasing against the
> interference from adjacent band?
>
> Br, Hanwen
>
>
The 40Mhz version is intended for base platforms that sample at lower
rates---USRP1, N210. Put one on an X3xx, for example, likely won't
improve anti-alias response very much, since a lot of the filtering
is done digitally. The filter roll-offs are designed to be roughly 60-80%
of the appropriate Nyquist frequency for the preferred platform.
The low-pass filters on these devices (WBX, SBX, CBX) are
7-order elliptic filters (as I recall), and have excellent roll-off
characteristics.
------------------------------
Message: 8
Date: Sat, 1 Oct 2016 22:47:22 +0200
From: hanwen <[email protected]>
To: "Marcus D. Leech" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Daughterboard difference between 120/160MHz
and 40MHz version
Message-ID:
<cabjuse2n2t58uogg2uwg0mvcj8ygmsn6nfa5yrvofrjdnyn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks, Markus.
Then it seems that I need a RF bandpass filter to reject the strong
interference from neighbouring band. If you have further suggestion on
this, please share with me.
Is the offset tuning affecting the anti-aliasing? Say, if I have a strong
neighbour at the right side of my signal. Then is it better to make the Rx
offset tuning a minus value, since in this way the actual carrier frequency
is more far away from the neighbour interference.
I can experiment this next week, but better to know earlier.
BR, Hanwen
2016-10-01 22:24 GMT+02:00 Marcus D. Leech via USRP-users <
[email protected]>:
> On 10/01/2016 04:14 PM, hanwen via USRP-users wrote:
>
>> Hi,
>>
>> I'd like to know the exact difference between the same daughterboard type
>> which comes with two bandwidth versions.
>>
>> For applcations only needing relatively narrower bandwidth (<20MHz), will
>> the 40MHz version provide better anti-aliasing against the interference
>> from adjacent band?
>>
>> Br, Hanwen
>>
>>
>> The 40Mhz version is intended for base platforms that sample at lower
> rates---USRP1, N210. Put one on an X3xx, for example, likely won't
> improve anti-alias response very much, since a lot of the filtering is
> done digitally. The filter roll-offs are designed to be roughly 60-80%
> of the appropriate Nyquist frequency for the preferred platform. The
> low-pass filters on these devices (WBX, SBX, CBX) are
> 7-order elliptic filters (as I recall), and have excellent roll-off
> characteristics.
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161001/e95df51b/attachment-0001.html>
------------------------------
Message: 9
Date: Sat, 01 Oct 2016 16:53:12 -0400
From: "Marcus D. Leech" <[email protected]>
To: hanwen <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Daughterboard difference between 120/160MHz
and 40MHz version
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 10/01/2016 04:47 PM, hanwen wrote:
> Thanks, Markus.
>
> Then it seems that I need a RF bandpass filter to reject the strong
> interference from neighbouring band. If you have further suggestion on
> this, please share with me.
>
> Is the offset tuning affecting the anti-aliasing? Say, if I have a
> strong neighbour at the right side of my signal. Then is it better to
> make the Rx offset tuning a minus value, since in this way the actual
> carrier frequency is more far away from the neighbour interference.
>
> I can experiment this next week, but better to know earlier.
>
> BR, Hanwen
>
I'd experiment. It depends on how closely-spaced the interferer is to
your passband. But you can tweak the offset tuning a bit to keep
the inteferer outside of your analog passband. This works provided
that the signal isn't so strong that it is driving the first gain stages
and mixer into non-linear operation--in which case, pretty much
nothing you do after that point will help much.
------------------------------
Message: 10
Date: Sun, 2 Oct 2016 00:00:17 -0700
From: Frank Liu <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Strange behavior when receiving a DC signal
Message-ID:
<camzy46yz8brj8jjvewulaz+srn4mgb9onov2mq3uc6kvqp-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
We've been debugging our application and have run across some strange
behavior when receiving a pure DC signal transmitted with carrier
frequencies in the 2.45GHz ISM band (image attached). We notice a similar
amount of I/Q modulation weirdness when transmitting a variety of other
signals as well.
The same thing occurs when we use the 5.8GHz band as carrier. I'm no signal
processing expert, but I imagine this should not be happening, especially
since we don't observe this when using a different SDR unit as the receiver.
Currently using an X310 running UHD 3.9.5, along with the latest version of
GNURadio.
--Frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161002/d424e912/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: weirdness.png
Type: image/png
Size: 349857 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161002/d424e912/attachment-0001.png>
------------------------------
Message: 11
Date: Sun, 02 Oct 2016 09:58:09 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Strange behavior when receiving a DC signal
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 10/02/2016 03:00 AM, Frank Liu via USRP-users wrote:
>
> Hi all,
>
> We've been debugging our application and have run across some strange
> behavior when receiving a pure DC signal transmitted with carrier
> frequencies in the 2.45GHz ISM band (image attached). We notice a
> similar amount of I/Q modulation weirdness when transmitting a variety
> of other signals as well.
>
> The same thing occurs when we use the 5.8GHz band as carrier. I'm no
> signal processing expert, but I imagine this should not be happening,
> especially since we don't observe this when using a different SDR unit
> as the receiver.
>
> Currently using an X310 running UHD 3.9.5, along with the latest
> version of GNURadio.
>
> --Frank
>
>
It looks like you have two issues there. One is, you're clipping.
Back-off on the RX gain -- how are TX and RX connected? Via antenna
or directly? If directly, how much attenuation do you have in-line?
Also, if you're operating very close to DC, the DC-offset-removal will
interfere with your signal. Use offset tuning on the RX side to
move the DC anomaly out of your pass-band:
http://files.ettus.com/manual/page_general.html
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 74, Issue 2
*****************************************
