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. Running RFNoC HDL Testbench (Muhammad, Siraj)
2. [GRCon17] Reminder of Deadlines this Week! (Ben Hilburn)
3. Re: Gnuradio wideband processing speed (Marcus M?ller)
4. Re: Running RFNoC HDL Testbench (Jonathon Pendlum)
5. E310 Internal Reference Frequency. (Walter Maguire)
6. Re: About Self calibration (liu Jong)
7. Re: E310 Internal Reference Frequency. (Marcus D. Leech)
8. [N210] AD9510 Configuration Issues (Galler Florian)
9. Re: About Self calibration (Marcus M?ller)
10. low frequency ADC flicker noise (Ettus x310)
(Hofer, Russell Dwayne)
11. Re: low frequency ADC flicker noise (Ettus x310)
([email protected])
----------------------------------------------------------------------
Message: 1
Date: Tue, 30 May 2017 19:30:48 +0000
From: "Muhammad, Siraj" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Running RFNoC HDL Testbench
Message-ID:
<by1pr03mb1338e63f835edb7b1534defccd...@by1pr03mb1338.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hi,
I have been following the RFNoC knowledge base to create custom RFNoC block and
its HDL testbenches.
Everything was going fine until I hit the point where I want to run the
simulation with the following command:
$ make noc_block_gain_tb
I receive this error:
siraj@rfnoc:~/rfnoc/src/rfnoc-tutorial/build$ make noc_block_gain_tb
Scanning dependencies of target noc_block_gain_tb
/bin/sh: 1: source: not found
CMakeFiles/noc_block_gain_tb.dir/build.make:57: recipe for target
'CMakeFiles/noc_block_gain_tb' failed
make[3]: *** [CMakeFiles/noc_block_gain_tb] Error 127
CMakeFiles/Makefile2:131: recipe for target
'CMakeFiles/noc_block_gain_tb.dir/all' failed
make[2]: *** [CMakeFiles/noc_block_gain_tb.dir/all] Error 2
CMakeFiles/Makefile2:138: recipe for target
'CMakeFiles/noc_block_gain_tb.dir/rule' failed
make[1]: *** [CMakeFiles/noc_block_gain_tb.dir/rule] Error 2
Makefile:199: recipe for target 'noc_block_gain_tb' failed
make: *** [noc_block_gain_tb] Error 2
I have sourced ~/rfnoc/setup_env.sh and generated the everything using
rfnocmodtool, according to the tutorial.
Any thoughts would be appreciated!
Thank you,
Siraj
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170530/2efd536f/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 30 May 2017 15:34:43 -0400
From: Ben Hilburn <[email protected]>
To: GNURadio Discussion List <[email protected]>, USRP-Users
<[email protected]>
Subject: [USRP-users] [GRCon17] Reminder of Deadlines this Week!
Message-ID:
<cajh_qmfez0toaodp3zs27qpmoroeesuj69mykugkaw+ox2e...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey all -
Just some reminders about a number of deadlines this week regarding GRCon17:
*Presentation Deadline*
The deadline for submitting your presentation abstract (talk, tutorial, or
poster) is in *2 days*, Thursday 1 June. Check out the website for more
info, and please let us know if you have any questions! https://www.
gnuradio.org/grcon-2017/submit/
*Paper Submission Opens*
Paper submission will open on EDAS on Thursday 1 June, and closes on
Saturday 1 July. Acceptance will be on a rolling basis. For more details,
please see the website: https://www.gnuradio.org/grcon-2017/submit/
*Registration*
The deadline for Early Bird Registration is this Thursday, *June 1st*!
To register for the conference, head to Eventbrite: https://grcon17.
eventbrite.com/
To book your hotel rooms, use this link for our negotiated rate:
http://bahiahotel.com/groups/GRCon17/
Don't forget that there is discounted registration available for students (
https://www.gnuradio.org/grcon-2017/students/).
*Questions*
If you have any questions or need help, don't hesitate to let us know. You
can reach the conference organizers at `[email protected]`.
Cheers,
The GRCon17 Organizing Committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170530/80f72a94/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 31 May 2017 00:25:10 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Gnuradio wideband processing speed
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Anik,
**Never** use a throttle block inside a hardware rate-limited flow
graph. You incur the two-clock problem [1], which is why I added the
explicit warning to GRC not to combine throttle and hardware. Throttle
is a tool for simulation/offline analysis only.
Your PC is the bottleneck if the USRP Source overflows, /not/ GNU Radio
or the USRP Source ? it does exactly the same what you do in your direct
interface: It gets samples from UHD and directly writes them into a
buffer in RAM [2]. You can resize that buffer using the
`max_output_buffer` option in the advanced options of your USRP Source
blcok.
You didn't include a flow graph, so it's hard to guess, but:
You don't want the polyphase arbitrary resampler for a resampling ration
of > 10. Use a rational resampler, or simply a decimating FIR.
Best regards,
Marcus
[1]
https://wiki.gnuradio.org/index.php/FAQ#When_do_I_use_a_throttle_block.3F
[2] https://www.gnuradio.org/blog/buffers/
On 30.05.2017 17:15, ?????? ???? via USRP-users wrote:
> Ahh, sorry, forgot about throttle block. It reduces the number of
> overflows, but does not get rid of them.
> As additional info:
> i used samples_per_buffer = 10000,
> wire_format = sc12,
> in /etc/security/limits.conf i added this line: @usrp - rtprio 99
>
> 2017-05-30 17:54 GMT+03:00 ?????? ???? <[email protected]
> <mailto:[email protected]>>:
>
> Hi,
>
> My goal is to cut out several channels (10-30, 100e3 each) from a
> wide band with a width of 40e6 and write them into files at
> real-time / or pass they immediately into another flowgraph.
> The gnuradio's USRPSurce already at a sample in ~10e6 gave out
> buffer overflow ("OOOOO..."), therefore its use has been
> immediately rejected. Next, I wrote the code that interacts
> directly with uhd and writes the results directly into the RAM
> (tmpfs) - I got rid of the overflow, but now faced the task of how
> to transfer data to gnuradio for further processing. Now I'm using
> FIFO and, on the side of the gnuradio i have an ordinary "file
> source" for reading from fifo. As a result, I again get overflows
> - gnuradio simply can not cope with the processing of so much
> data. Some cores are completely overloaded, realtimescheduling in
> flowgraph is turned ON.
> I get overflow even on this scheme:
>
> file_source->controlled_rotator->polyphase_arbitrary_resampler->fosphor_sink
> The only one flow-graph in which I managed to avoid overflows:
> file_source->null_sink =)
>
> Probably the main issue is my sincere surprise that the 40-th core
> processor can not cope with such a task.
>
> 1 Is there a way to "optimize" the gnuradio?)
> 2 Or does it make sense to write my own "implementation" of the
> all functionality I need from the gnuradio for optimization purposes?
> 3 Is it rare to work with 40e6 or more?
>
> Thank you in advance,
>
> Anik
>
>
>
>
> _______________________________________________
> 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/20170531/f9ea9c03/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 30 May 2017 18:28:32 -0400
From: Jonathon Pendlum <[email protected]>
To: "Muhammad, Siraj" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Running RFNoC HDL Testbench
Message-ID:
<CAGdo0uQQCg9GZOC_KuDC-p22mhZM6NJw=umnfwgnfwfggr_...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
Assuming you are using Ubuntu, make bash your default shell with
dpkg-reconfigure dash.
On May 30, 2017 3:31 PM, "Muhammad, Siraj via USRP-users" <
[email protected]> wrote:
> Hi,
>
>
>
> I have been following the RFNoC knowledge base to create custom RFNoC
> block and its HDL testbenches.
>
> Everything was going fine until I hit the point where I want to run the
> simulation with the following command:
>
>
>
> $ make noc_block_gain_tb
>
>
>
> I receive this error:
>
>
>
> siraj@rfnoc:~/rfnoc/src/rfnoc-tutorial/build$ make noc_block_gain_tb
>
> Scanning dependencies of target noc_block_gain_tb
>
> /bin/sh: 1: source: not found
>
> CMakeFiles/noc_block_gain_tb.dir/build.make:57: recipe for target
> 'CMakeFiles/noc_block_gain_tb' failed
>
> make[3]: *** [CMakeFiles/noc_block_gain_tb] Error 127
>
> CMakeFiles/Makefile2:131: recipe for target
> 'CMakeFiles/noc_block_gain_tb.dir/all'
> failed
>
> make[2]: *** [CMakeFiles/noc_block_gain_tb.dir/all] Error 2
>
> CMakeFiles/Makefile2:138: recipe for target
> 'CMakeFiles/noc_block_gain_tb.dir/rule'
> failed
>
> make[1]: *** [CMakeFiles/noc_block_gain_tb.dir/rule] Error 2
>
> Makefile:199: recipe for target 'noc_block_gain_tb' failed
>
> make: *** [noc_block_gain_tb] Error 2
>
>
>
> I have sourced ~/rfnoc/setup_env.sh and generated the everything using
> rfnocmodtool, according to the tutorial.
>
> Any thoughts would be appreciated!
>
>
>
> Thank you,
>
> Siraj
>
> _______________________________________________
> 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/20170530/ac4c7b46/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 31 May 2017 11:35:29 +1000
From: Walter Maguire <[email protected]>
To: [email protected]
Subject: [USRP-users] E310 Internal Reference Frequency.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi All,
I studied the circuit diagrams for the E310 and its associated
Daughterboard (DB). The data sheet for the product suggests that the
E310 supplies the TCXO to the DB. This is incorrect as it is sourced
from the E310 DB.
The circuit board does not have a part number for the VTCXO and
therefore I would be grateful someone could clarify the following.
The VTCXO reference frequency. I think this is 40MHz based on looking
at the code and assuming the fref mentioned line in ad9361_device.c, in
function double ad9361_device_t::_tune_bbvco(const double rate)
const double fref = 40e6;
is referring to the internal frequency reference.
Is this correct or is the internal VTCXO reference frequency different.
Regards
Walter
------------------------------
Message: 6
Date: Wed, 31 May 2017 09:55:18 +0800
From: liu Jong <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] About Self calibration
Message-ID:
<caeui2n16ys4snsd7hkcdqfapkqubrmy1hbv_fahvvc67bfx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,Marcus,
information as below:
/usr/local/lib/uhd/utils$ ./usrp_burn_mb_eeprom --args="addr=192.168.10.2,
type=x300,recover_mb_eeprom" --read-all
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.001.HEAD-0-g945fd653
Creating USRP device from address: addr=192.168.10.2,
type=x300,recover_mb_eeprom
-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
UHD Warning:
UHD is operating in EEPROM Recovery Mode which disables hardware
version checks.
Operating in this mode may cause hardware damage and unstable radio
performance!
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Detecting internal GPSDO.... No GPSDO found
-- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1179.2MB/s)
-- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1173.2MB/s)
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- Performing timer loopback test... pass
Error: RuntimeError: self_cal_adc_capture_delay: Self calibration failed.
Convergence error.
best regards
Jon
2017-05-29 4:51 GMT+08:00 Marcus M?ller <[email protected]>:
> Hi!
>
> Sorry, forgot to say: please try
>
> ./usrp_burn_mb_eeprom --args="addr=192.168.10.2,
> type=x300,recover_mb_eeprom" --read-all
> Best regards,
> Marcus
>
> On 05/27/2017 02:52 AM, liu Jong wrote:
>
> Hi,all
> Do you have any advice?Any suggestion is welcome.
>
>
> 2017-05-25 9:55 GMT+08:00 liu Jong <[email protected]>:
>
>> HI,Marcus,
>> information as below:
>> a sticker near the AUX I/O:
>> *154573H-02L*
>> then run usrp_burn_mb_eeprom:
>>
>> /usr/local/lib/uhd/utils$ ./usrp_burn_mb_eeprom
>> --args="addr=192.168.10.2, type=x300" --read-all
>> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.001.HEAD-0-g945fd6
>> 53
>>
>> Creating USRP device from address: addr=192.168.10.2, type=x300
>> -- X300 initialization sequence...
>> -- Determining maximum frame size... 1472 bytes.
>> -- Setup basic communication...
>> -- Loading values from EEPROM...
>> -- Setup RF frontend clocking...
>> -- Radio 1x clock:200
>> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1185.4MB/s)
>> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1171.2MB/s)
>> -- [RFNoC Radio] Performing register loopback test... pass
>> -- [RFNoC Radio] Performing register loopback test... pass
>> -- [RFNoC Radio] Performing register loopback test... pass
>> -- [RFNoC Radio] Performing register loopback test... pass
>> -- Performing timer loopback test... pass
>> Error: RuntimeError: self_cal_adc_capture_delay: Self calibration failed.
>> Convergence error.
>>
>> will be some hardware broken?Can we start RMA?
>>
>> thank you.
>> best regards
>> Jon
>>
>> 2017-05-25 5:44 GMT+08:00 Marcus M?ller via USRP-users <
>> [email protected]>:
>>
>>> Hi Jon!
>>> um,
>>> On 24.05.2017 04:51, liu Jong via USRP-users wrote:
>>>
>>> Error: RuntimeError: self_cal_adc_capture_delay: Self calibration
>>> failed. Convergence error.
>>>
>>> isn't very good. but: The only time I've seen that was when someone had
>>> overwritten the hardware revision number in EEPROM with a value that
>>> doesn't apply to the hardware.
>>>
>>> Can you share what the sticker at the highlighted position says? We
>>> should be able to figure out the right revision of the hardware!
>>>
>>> [image: Revision Sticker Placement]
>>>
>>> Then, find usrp_burn_mb_eeprom, and run it "/path/to/usrp_burn_mb_eeprom
>>> --args addr=192.168.40.2 --read-all" (replace the addr=x.x.x.x with the IP
>>> address of your USRP). What does the revision eeprom content say?
>>>
>>> Best regards,
>>> Marcus
>>>
>>> _______________________________________________
>>> 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/20170531/b92edca9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 22621 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170531/b92edca9/attachment-0001.jpe>
------------------------------
Message: 7
Date: Tue, 30 May 2017 22:33:32 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] E310 Internal Reference Frequency.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 05/30/2017 09:35 PM, Walter Maguire via USRP-users wrote:
> Hi All,
>
> I studied the circuit diagrams for the E310 and its associated
> Daughterboard (DB). The data sheet for the product suggests that the
> E310 supplies the TCXO to the DB. This is incorrect as it is sourced
> from the E310 DB.
>
> The circuit board does not have a part number for the VTCXO and
> therefore I would be grateful someone could clarify the following.
>
> The VTCXO reference frequency. I think this is 40MHz based on looking
> at the code and assuming the fref mentioned line in ad9361_device.c,
> in function double ad9361_device_t::_tune_bbvco(const double rate)
>
> const double fref = 40e6;
>
>
> is referring to the internal frequency reference.
>
>
> Is this correct or is the internal VTCXO reference frequency different.
>
>
> Regards
>
>
> Walter
>
>
I believe the VCTXO on the DB is indeed 40MHz.
------------------------------
Message: 8
Date: Wed, 31 May 2017 10:22:03 +0000
From: Galler Florian <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] [N210] AD9510 Configuration Issues
Message-ID:
<ec5cecfcc50d094aa99030a3304ed49d71dc3...@ex2010dag1.emce.tuwien.ac.at>
Content-Type: text/plain; charset="us-ascii"
Hello,
One update to the issue. According to ADIsimClk the loop bandwidth is only 14.2
Hz. Therefore, it seems that the PLL is not able to follow abrupt changes in
frequency, which are introduced by the (FOX924) TCOX (probably caused by the
temperature compensation). When this occurs the phase relation between the MIMO
clocks get unstable like in picture 2 (it does not skip a period, but for phase
coherent MIMO setups, this would be probably very bad).
If I uses an external 10 MHz frequency reference (currently from an Agilent
33522A), I have not seen this issue.
Looking forward to additional comments
Florian
------------------------------
Message: 9
Date: Wed, 31 May 2017 15:04:45 +0200
From: Marcus M?ller <[email protected]>
To: liu Jong <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] About Self calibration
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Jon,
in that mode, it shouldn't be doing the ADC check. I'll figure something
out.
Best regards,
Marcus
On 31.05.2017 03:55, liu Jong wrote:
> Hi,Marcus,
> information as below:
>
> /usr/local/lib/uhd/utils$ ./usrp_burn_mb_eeprom
> --args="addr=192.168.10.2, type=x300,recover_mb_eeprom" --read-all
> linux; GNU C++ version 4.8.4; Boost_105400;
> UHD_003.010.001.HEAD-0-g945fd653
>
> Creating USRP device from address: addr=192.168.10.2,
> type=x300,recover_mb_eeprom
> -- X300 initialization sequence...
> -- Determining maximum frame size... 1472 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
>
> UHD Warning:
> UHD is operating in EEPROM Recovery Mode which disables hardware
> version checks.
> Operating in this mode may cause hardware damage and unstable
> radio performance!
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Detecting internal GPSDO.... No GPSDO found
> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1179.2MB/s)
> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1173.2MB/s)
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- Performing timer loopback test... pass
> Error: RuntimeError: self_cal_adc_capture_delay: Self calibration
> failed. Convergence error.
>
> best regards
> Jon
>
>
> 2017-05-29 4:51 GMT+08:00 Marcus M?ller <[email protected]
> <mailto:[email protected]>>:
>
> Hi!
>
> Sorry, forgot to say: please try
>
> ./usrp_burn_mb_eeprom --args="addr=192.168.10.2,
> type=x300,recover_mb_eeprom" --read-all
>
> Best regards,
> Marcus
>
> On 05/27/2017 02:52 AM, liu Jong wrote:
>> Hi,all
>> Do you have any advice?Any suggestion is welcome.
>>
>>
>> 2017-05-25 9:55 GMT+08:00 liu Jong <[email protected]
>> <mailto:[email protected]>>:
>>
>> HI,Marcus,
>> information as below:
>> a sticker near the AUX I/O:
>> *154573H-02L*
>> then run usrp_burn_mb_eeprom:
>>
>> /usr/local/lib/uhd/utils$ ./usrp_burn_mb_eeprom
>> --args="addr=192.168.10.2, type=x300" --read-all
>> linux; GNU C++ version 4.8.4; Boost_105400;
>> UHD_003.010.001.HEAD-0-g945fd653
>>
>> Creating USRP device from address: addr=192.168.10.2, type=x300
>> -- X300 initialization sequence...
>> -- Determining maximum frame size... 1472 bytes.
>> -- Setup basic communication...
>> -- Loading values from EEPROM...
>> -- Setup RF frontend clocking...
>> -- Radio 1x clock:200
>> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput:
>> 1185.4MB/s)
>> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput:
>> 1171.2MB/s)
>> -- [RFNoC Radio] Performing register loopback test... pass
>> -- [RFNoC Radio] Performing register loopback test... pass
>> -- [RFNoC Radio] Performing register loopback test... pass
>> -- [RFNoC Radio] Performing register loopback test... pass
>> -- Performing timer loopback test... pass
>> Error: RuntimeError: self_cal_adc_capture_delay: Self
>> calibration failed. Convergence error.
>>
>> will be some hardware broken?Can we start RMA?
>>
>> thank you.
>> best regards
>> Jon
>>
>> 2017-05-25 5:44 GMT+08:00 Marcus M?ller via USRP-users
>> <[email protected] <mailto:[email protected]>>:
>>
>> Hi Jon!
>>
>> um,
>> On 24.05.2017 04:51, liu Jong via USRP-users wrote:
>>> Error: RuntimeError: self_cal_adc_capture_delay: Self
>>> calibration failed. Convergence error.
>> isn't very good. but: The only time I've seen that was
>> when someone had overwritten the hardware revision number
>> in EEPROM with a value that doesn't apply to the hardware.
>>
>> Can you share what the sticker at the highlighted
>> position says? We should be able to figure out the right
>> revision of the hardware!
>>
>> Revision Sticker Placement
>>
>> Then, find usrp_burn_mb_eeprom, and run it
>> "/path/to/usrp_burn_mb_eeprom --args addr=192.168.40.2
>> --read-all" (replace the addr=x.x.x.x with the IP address
>> of your USRP). What does the revision eeprom content say?
>>
>> Best regards,
>> Marcus
>>
>> _______________________________________________
>> 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>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170531/32e955c7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 22621 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170531/32e955c7/attachment-0001.jpe>
------------------------------
Message: 10
Date: Wed, 31 May 2017 14:53:01 +0000
From: "Hofer, Russell Dwayne" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] low frequency ADC flicker noise (Ettus x310)
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
We have developed a system that utilizes Ettus X310 radios in order to perform
low frequency data collection (0 - 2 MHz). The system is ruggedized for
outdoor use, and utilizes an x310 along with some of our own custom hardware.
We have used these systems several times in multi-day continuous collection
intervals.
There is one glaring concern that I found when doing noise comparisons between
the new Ettus based system and a legacy data collection system. The low
frequency 1/f flicker noise from the X310's ADC is significantly impacting our
performance, to the point where noise levels become dramatically worse than our
legacy system below 25 kHz (we decimate to 4 MSPS using the standard FPGA
image, and then perform an FFT to observe the ambient noise). 25 kHz is the
cross-over point, and the noise level continues to increase at a rate of 1/f -
i.e. very strong noise levels exist at lower frequencies. Not only that, there
is a significant level of flicker noise across the entire bandwidth; my testing
shows that the ADC's 1/f flicker noise doesn't level out until 10-20 MHz - so
it appears that we can obtain another 6 dB of system sensitivity if we solve
this flicker noise issue.
We are using our own custom daughterboard that essentially takes an RF input
that is both biased and differential, and passes directly into the X310's ADC
(there is a simple RC filter to help with sampling noise). I have some ideas
of how to modify this, but was interested in obtaining some feedback.
Has anyone come across this, if so, how did you mitigate it? I have done some
research, and the approaches either involve moving the signal of interest to a
higher value, or moving the low frequency noise higher.
1) I know that mixing the low frequency signal to a higher frequency may
be an option, but I would rather not do so in order to avoid dealing with the
non-ideal characteristics of a mixer, specifically the distortion. Or, is this
the only practical way to fix it?
2) Has anyone explored the idea of chopping the input by using a
synchronized RF/sampling switch ? The idea is to multiply the low frequency
input signal by a square wave, and then after it is digitized, multiply it by a
square wave in the digital domain. The end result is that the 1/f noise would
still exist, but would be shifted higher in frequency since it is only
multiplied by the square wave one time in the digital domain.
3) Is there a different replacement ADC that may perform better (i.e. have
a chopper mode) ?
Any thoughts or ideas you may have would be greatly appreciated. Thanks,
Russell
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170531/8571ccf6/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 31 May 2017 11:50:51 -0400
From: [email protected]
To: "Hofer, Russell Dwayne" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] low frequency ADC flicker noise (Ettus x310)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
High-speed, CMOS ADCs suffer from higher 1/F noise corners than there
older bipolar counterparts.
This article offers some insight:
http://www.highfrequencyelectronics.com/index.php?option=com_content&view=article&id=1160:eliminate-high-speed-adc-flicker-noise-with-chopper-upgrade&catid=123&Itemid=189
Installing a different ADC would be a *significant* amount of work,
involving hardware surgery, significant FPGA changes, and significant
changes in the UHD drivers. That would not be a trivial change.
On 2017-05-31 10:53, Hofer, Russell Dwayne via USRP-users wrote:
> We have developed a system that utilizes Ettus X310 radios in order to
> perform low frequency data collection (0 - 2 MHz). The system is ruggedized
> for outdoor use, and utilizes an x310 along with some of our own custom
> hardware. We have used these systems several times in multi-day continuous
> collection intervals.
>
> There is one glaring concern that I found when doing noise comparisons
> between the new Ettus based system and a legacy data collection system. The
> low frequency 1/f flicker noise from the X310's ADC is significantly
> impacting our performance, to the point where noise levels become
> dramatically worse than our legacy system below 25 kHz (we decimate to 4 MSPS
> using the standard FPGA image, and then perform an FFT to observe the ambient
> noise). 25 kHz is the cross-over point, and the noise level continues to
> increase at a rate of 1/f - i.e. very strong noise levels exist at lower
> frequencies. Not only that, there is a significant level of flicker noise
> across the entire bandwidth; my testing shows that the ADC's 1/f flicker
> noise doesn't level out until 10-20 MHz - so it appears that we can obtain
> another 6 dB of system sensitivity if we solve this flicker noise issue.
>
> We are using our own custom daughterboard that essentially takes an RF input
> that is both biased and differential, and passes directly into the X310's ADC
> (there is a simple RC filter to help with sampling noise). I have some ideas
> of how to modify this, but was interested in obtaining some feedback.
>
> Has anyone come across this, if so, how did you mitigate it? I have done
> some research, and the approaches either involve moving the signal of
> interest to a higher value, or moving the low frequency noise higher.
>
> 1) I know that mixing the low frequency signal to a higher frequency may
> be an option, but I would rather not do so in order to avoid dealing with the
> non-ideal characteristics of a mixer, specifically the distortion. Or, is
> this the only practical way to fix it?
>
> 2) Has anyone explored the idea of chopping the input by using a
> synchronized RF/sampling switch ? The idea is to multiply the low frequency
> input signal by a square wave, and then after it is digitized, multiply it by
> a square wave in the digital domain. The end result is that the 1/f noise
> would still exist, but would be shifted higher in frequency since it is only
> multiplied by the square wave one time in the digital domain.
>
> 3) Is there a different replacement ADC that may perform better (i.e.
> have a chopper mode) ?
>
> Any thoughts or ideas you may have would be greatly appreciated. Thanks,
>
> Russell
> _______________________________________________
> 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/20170531/32ec0dee/attachment-0001.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 81, Issue 31
******************************************
