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: Custom UHD Program terminate during set_clock_ref
(Martin Braun)
2. Connecting TX/RX and RX2 internally (NIKOLOV)
3. RFNoC XSIM support (Jonathon Pendlum)
4. Re: Custom UHD Program terminate during set_clock_ref
(Nate Temple)
5. Re: Not sure how to remove tuser CHDR header control and data
from m_axis_data_tdata and s_axis_data_tdata in noc_block
(Jonathon Pendlum)
6. Re: Examples and set up scripts used during NEWSDR 2016
(Jonathon Pendlum)
7. Noc_block_ddc (Sam Carey)
8. Re: Connecting TX/RX and RX2 internally (Michael West)
9. Re: Noc_block_ddc (Jonathon Pendlum)
10. Re: Octoclock-G GPS Lock (Derek Kozel)
11. USRP X310 FPGA (Ziang Gao)
12. Re: USRP X310 FPGA (Marcus M?ller)
13. Re: Not sure how to remove tuser CHDR header control and data
from m_axis_data_tdata and s_axis_data_tdata in noc_block
(Swanson, Craig)
14. Error when compiling module noc_block_skeleton_tb in modelsim
with latest commit (Swanson, Craig)
15. Re: Error when compiling module noc_block_skeleton_tb in
modelsim with latest commit (Jonathon Pendlum)
16. Re: Error when compiling module noc_block_skeleton_tb in
modelsim with latest commit (Swanson, Craig)
17. Re: Connecting TX/RX and RX2 internally (Sylvain Munaut)
18. Re: USRP X310 FPGA (Patrick Berger)
19. Re: Custom UHD Program terminate during set_clock_ref
(Patrick Berger)
20. Detailed RX/TX Filter Bank Specifications for E310/312
(Zhongren Cao)
21. Custom Board (Joshua Monson)
22. Re: Connecting TX/RX and RX2 internally (Michael West)
----------------------------------------------------------------------
Message: 1
Date: Wed, 8 Jun 2016 09:05:41 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Custom UHD Program terminate during
set_clock_ref
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Patrick,
I have a hunch something is hiding some error message, and that error
message would clue us in. The last line ("Press Return") is coming from
where exactly? Is it your dev environment? Maybe there's a hidden
segfault there. GRC is a bit like that, too.
M
On 06/08/2016 12:17 AM, Patrick Berger via USRP-users wrote:
> Hi all
>
> I'm trying to create my own program to communicate with an X310 USRP.
> Host is Linux (Mint 17.2) with uhd version 3.9.1 and boost 1.57.0
>
> During the build process in Qt Creator I've no errors or warnings
> (libraries are all correct linked). The device is correctly found and
> the initialization with uhd::usrp::multi_usrp::make(dev_adr) works also.
> In the second step I would set the mboard clocks, but there is something
> going bad.
>
> This is my current code (cross-checked with rx_samples_to_file,
> rx_samples_to_udp, rx_ascii_art_dft):
> int USRP_SDR::Init_USRP()
> {
> //create a usrp device
> uhd::device_addr_t dev_adr;
> dev_adr.set("addr", addr);
> usrp = uhd::usrp::multi_usrp::make(dev_adr);
>
> std::cout << "Hallo1" << std::endl;
> //Lock mboard clocks
> usrp->set_clock_source(ref);
> std::cout << "Hallo2" << std::endl;
>
> //always select the subdevice first, the channel mapping affects the
> other settings
> if (vm.count("subdev")) usrp->set_rx_subdev_spec(subdev);
>
> std::cout << boost::format("Using Device: %s") %
> usrp->get_pp_string() << std::endl;
>
> //set the sample rate
> if (rate <= 0.0){
> std::cerr << "Please specify a valid sample rate" << std::endl;
> return 0;
> }
> std::cout << boost::format("Setting RX Rate: %f Msps...") %
> (rate/1e6) << std::endl;
> usrp->set_rx_rate(rate);
> std::cout << boost::format("Actual RX Rate: %f Msps...") %
> (usrp->get_rx_rate()/1e6) << std::endl << std::endl;
>
> return 1;
> }
>
> And this is the resulting terminal output (the Hello2 is missing, and
> also the rest of the initialization process):
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.001-0-unknown
>
> UHD Warning:
> Unable to set the thread priority. Performance may be negatively
> affected.
> Please see the general application notes in the manual for instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
> -- X300 initialization sequence...
> -- Determining maximum frame size... 1472 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Initialize Radio0 control...
> -- Performing register loopback test... pass
> -- Initialize Radio1 control...
> -- Performing register loopback test... pass
> Hallo1
> Press <RETURN> to close this window...
>
> Does anyone see the fault?
>
> Best regards
> Patrick
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 2
Date: Wed, 8 Jun 2016 11:51:37 +0200
From: NIKOLOV <[email protected]>
To: [email protected]
Subject: [USRP-users] Connecting TX/RX and RX2 internally
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi,
Currently I am using the USRP B210 for my Bachelor Thesis. Since I got
the board yesterday I am still figuring out how it works and i have
programmed some basic Transmitters and Receivers via Simulink and via
Gnuradio. I wanted to test the receiver and the transmitter, but i still
do not have a SMA cable. My question is: Is there any way to connect
TX/RX port and RX2 port internally via software command, and if yes,
what could be the consequences from this ?
Thanks in Advance
Georgi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160608/0ccefb88/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 8 Jun 2016 11:23:45 -0500
From: Jonathon Pendlum <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] RFNoC XSIM support
Message-ID:
<cagdo0usvafdrzgswhw4apcum1msq6wuzyxqdbq7vtynivxn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
All,
The rfnoc-radio-redo branch now supports Xilinx's free XSIM HDL simulator
which is included with Vivado. To test out XSIM, there are several example
test benches in usrp3/lib/rfnoc. For example, run 'make xsim' while in
usrp3/lib/rfnoc/noc_block_fft_tb to run the FFT RFNoC block test bench. If
you want to see the simulation waveforms using Vivado's GUI, use 'make
GUI=1 xsim'.
Also, the test bench API has had some improvements. There will be a
knowledge base article on this topic in the future. For now, refer to the
example RFNoC block "Skeleton" (noc_block_skeleton.v) and associated test
bench.
Please let me know if you run into any issues or have any suggestions!
Jonathon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160608/ce5ee3bd/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 8 Jun 2016 09:28:45 -0700
From: Nate Temple <[email protected]>
To: Martin Braun <[email protected]>
Cc: Zhihong Luo via USRP-users <[email protected]>
Subject: Re: [USRP-users] Custom UHD Program terminate during
set_clock_ref
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Patrick,
Is 'ref' being properly set before it is called in usrp->set_clock_source(ref)
? A simple sanity check is to print it out before it is called:
std::cout << boost::format("Lock mboard clocks: %f") % ref << std::endl;
usrp->set_clock_source(ref);
- Nate
> On Jun 8, 2016, at 9:05 AM, Martin Braun via USRP-users
> <[email protected]> wrote:
>
> Patrick,
>
> I have a hunch something is hiding some error message, and that error
> message would clue us in. The last line ("Press Return") is coming from
> where exactly? Is it your dev environment? Maybe there's a hidden
> segfault there. GRC is a bit like that, too.
>
> M
>
> On 06/08/2016 12:17 AM, Patrick Berger via USRP-users wrote:
>> Hi all
>>
>> I'm trying to create my own program to communicate with an X310 USRP.
>> Host is Linux (Mint 17.2) with uhd version 3.9.1 and boost 1.57.0
>>
>> During the build process in Qt Creator I've no errors or warnings
>> (libraries are all correct linked). The device is correctly found and
>> the initialization with uhd::usrp::multi_usrp::make(dev_adr) works also.
>> In the second step I would set the mboard clocks, but there is something
>> going bad.
>>
>> This is my current code (cross-checked with rx_samples_to_file,
>> rx_samples_to_udp, rx_ascii_art_dft):
>> int USRP_SDR::Init_USRP()
>> {
>> //create a usrp device
>> uhd::device_addr_t dev_adr;
>> dev_adr.set("addr", addr);
>> usrp = uhd::usrp::multi_usrp::make(dev_adr);
>>
>> std::cout << "Hallo1" << std::endl;
>> //Lock mboard clocks
>> usrp->set_clock_source(ref);
>> std::cout << "Hallo2" << std::endl;
>>
>> //always select the subdevice first, the channel mapping affects the
>> other settings
>> if (vm.count("subdev")) usrp->set_rx_subdev_spec(subdev);
>>
>> std::cout << boost::format("Using Device: %s") %
>> usrp->get_pp_string() << std::endl;
>>
>> //set the sample rate
>> if (rate <= 0.0){
>> std::cerr << "Please specify a valid sample rate" << std::endl;
>> return 0;
>> }
>> std::cout << boost::format("Setting RX Rate: %f Msps...") %
>> (rate/1e6) << std::endl;
>> usrp->set_rx_rate(rate);
>> std::cout << boost::format("Actual RX Rate: %f Msps...") %
>> (usrp->get_rx_rate()/1e6) << std::endl << std::endl;
>>
>> return 1;
>> }
>>
>> And this is the resulting terminal output (the Hello2 is missing, and
>> also the rest of the initialization process):
>> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.001-0-unknown
>>
>> UHD Warning:
>> Unable to set the thread priority. Performance may be negatively
>> affected.
>> Please see the general application notes in the manual for instructions.
>> EnvironmentError: OSError: error in pthread_setschedparam
>> -- X300 initialization sequence...
>> -- Determining maximum frame size... 1472 bytes.
>> -- Setup basic communication...
>> -- Loading values from EEPROM...
>> -- Setup RF frontend clocking...
>> -- Radio 1x clock:200
>> -- Initialize Radio0 control...
>> -- Performing register loopback test... pass
>> -- Initialize Radio1 control...
>> -- Performing register loopback test... pass
>> Hallo1
>> Press <RETURN> to close this window...
>>
>> Does anyone see the fault?
>>
>> Best regards
>> Patrick
>>
>>
>> _______________________________________________
>> 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, 8 Jun 2016 11:29:36 -0500
From: Jonathon Pendlum <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: Martin Braun <[email protected]>, Marcus M?ller
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Not sure how to remove tuser CHDR header
control and data from m_axis_data_tdata and s_axis_data_tdata in
noc_block
Message-ID:
<CAGdo0uTjnOdKNFEp0LGty-dSUvo9CGobuoK6rdeu0Dr6CQA=z...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Craig,
Are you only simulating your AGC noc block and is your cocotb testbench
directly interfacing its top level I/O (i.e. i_tdata, o_tdata, etc)?
Jonathon
On Tue, Jun 7, 2016 at 9:26 PM, Swanson, Craig <
[email protected]> wrote:
> Jonathon,
>
> I am in the process of creating my own noc_block_Receiver.v which
> currently is acting as an AGC. When I run my own Modelsim testbench I am
> having undesired effects of the header requests and reply mingled in with
> my AGC data. I am not sure how to make sure that none of the header
> information for data, flow control, command or response be included in with
> what is going in or out of my AGC noc block.
>
> It appears that the only signals I have access to are m_axis and s_axis
> tdata, tlast, tvalid, and tready. How would you suggest I go about making
> sure only pure data enters and leaves the AGC when communicating with my
> cocotb testbench or gnuradio-companion? I have not looked at how the
> moving_avg deals with this.
>
>
>
> Craig
>
>
>
> *Craig F. Swanson*
>
> *Research Engineer II*
>
> *Information and Communications Laboratory*
>
> *Communications, Systems, and Spectrum Division*
>
> Georgia Tech Research Institute
>
> Room 560
>
> 250 14th Street NW
>
> Atlanta, GA 30318
>
> Cell: 770-298-9156
>
> http://www.gtri.gatech.edu
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160608/ee1f107f/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 8 Jun 2016 11:30:57 -0500
From: Jonathon Pendlum <[email protected]>
To: Cherif Chibane <[email protected]>
Cc: Sam Carey <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Examples and set up scripts used during
NEWSDR 2016
Message-ID:
<cagdo0uskmxqs1zofloduur4pdx+ld+b6+t9xiep6xxkhgfz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
We are working on it and will inform the list when we post the files.
Jonathon
On Mon, Jun 6, 2016 at 10:30 AM, Cherif Chibane via USRP-users <
[email protected]> wrote:
> Hello,
>
> Thnask a lot for putting together the tutorial session at Northeastern U.
> last week.
>
> Would it be possible to post the exercises tat were used during the NEWSDR
> tutorial held lats week for the E310.
> It would be nice to have the files that were used to set up the
> environment as well.
>
> Thanks,
> Cherif
>
> ________________________________________
> From: USRP-users [[email protected]] on behalf of Sam
> Carey via USRP-users [[email protected]]
> Sent: Monday, June 06, 2016 11:07 AM
> To: [email protected]
> Subject: [USRP-users] Cross Compiling RFNoC for E310
>
> Howdy,
>
> I'm a bit confused about how the E310 cross-compiling process is supposed
> to work, and I need someone to un-confuse me. I've been trying to follow
> the instructions on http://files.ettus.com/manual/page_usrp_e3x0.html
> while modifying them for a custom rfnoc-radio-redo branch installation.
>
> As I understand it, cross-compiling means that the building takes place on
> my desktop machine and then the results are installed on the E310.
>
> So I install the SDK toolchain on my desktop in /usr/local/.
>
> Then I run
> .
> /usr/local/oecore-x86_64/environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
> cmake -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake
> -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_E300=ON -DENABLE_B200=OFF ..
>
> which means that the resulting files will be installed to /usr on my
> desktop machine. At this point it seems there's a gap in the instructions
> where I need to install to the E310, either by setting CMAKE_INSTALL_PREFIX
> to the /usr directory on the E310 via sshfs, or by setting DESTDIR to the
> E310 via sshfs when I install.
>
> Anyway, I install uhd and gnuradio to the E310 in this manner.
>
> Then when I try to build gr-ettus:
>
> cmake
> -DCMAKE_TOOLCHAIN_FILE=/home/samcarey/GNURadio/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
> -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_DOXYGEN=OFF ..
>
> it can't find the correct rfnoc-radio-redo uhd library, apparently because
> it is looking where I installed the SDK on the machine (which I assume has
> non-rfnoc libraries) instead of where I installed the correct libraries on
> the E310:
>
> ...
> -- Found PkgConfig:
> /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config
> (found version "0.28")
> -- Found UHD:
> /usr/local/oecore-x86_64/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/lib/libuhd.so
> CMake Error at CMakeLists.txt:113 (message):
> RFNoC not found.
>
> I suppose I could set the CMAKE_INSTALL_PREFIX to the SDK installation,
> where it is looking for the libraries. But this would contradict the
> instructed location of "/usr" and I'd have to also install everything to
> the E310 afterward.
>
> Could someone please help me understand how this is supposed to work?
>
> Thanks,
> Sam Carey
>
> _______________________________________________
> 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/20160608/681bef92/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 8 Jun 2016 13:01:12 -0400
From: Sam Carey <[email protected]>
To: [email protected]
Subject: [USRP-users] Noc_block_ddc
Message-ID:
<cap85vd8tmh1qk-mfg1ryajkmkrdq-z6zjiz8vnxopepwtbj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Howdy,
When I try to add the noc_block_ddc to rfnoc_ce_auto_inst_e310.v and
synthesize, it complains that it can't find the axi_to_strobed module.
Looking at Makefile.e300.inc, I see that the lib/axi folder and AXI_SRCS
contianing axi_to_strobed are not included.
Why is this?
Thanks,
Sam Carey
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160608/9acc75d6/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 8 Jun 2016 11:05:50 -0700
From: Michael West <[email protected]>
To: NIKOLOV <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Connecting TX/RX and RX2 internally
Message-ID:
<CAM4xKro=+8zw5owusp+whyf8fvftodqdcfirve+exrq2ycz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Georgi,
You should be able to just boost the gain and use the leakage across the RF
switch.
Regards,
Michael
On Wed, Jun 8, 2016 at 2:51 AM, NIKOLOV via USRP-users <
[email protected]> wrote:
> Hi,
> Currently I am using the USRP B210 for my Bachelor Thesis. Since I got the
> board yesterday I am still figuring out how it works and i have programmed
> some basic Transmitters and Receivers via Simulink and via Gnuradio. I
> wanted to test the receiver and the transmitter, but i still do not have a
> SMA cable. My question is: Is there any way to connect TX/RX port and RX2
> port internally via software command, and if yes, what could be the
> consequences from this ?
>
> Thanks in Advance
>
> Georgi
>
> _______________________________________________
> 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/20160608/d66141be/attachment-0001.html>
------------------------------
Message: 9
Date: Wed, 8 Jun 2016 13:11:26 -0500
From: Jonathon Pendlum <[email protected]>
To: Sam Carey <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Noc_block_ddc
Message-ID:
<CAGdo0uSJ4_wkOdgsuodpG32YuHQ5cdKx5gYK=34_mnz5t5c...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Sam,
Not having AXI_SRCS in Makefile.e300.inc is an oversight and we'll fix
that. Thanks for catching it.
Jonathon
On Wed, Jun 8, 2016 at 12:01 PM, Sam Carey via USRP-users <
[email protected]> wrote:
> Howdy,
>
> When I try to add the noc_block_ddc to rfnoc_ce_auto_inst_e310.v and
> synthesize, it complains that it can't find the axi_to_strobed module.
> Looking at Makefile.e300.inc, I see that the lib/axi folder and AXI_SRCS
> contianing axi_to_strobed are not included.
>
> Why is this?
>
> Thanks,
> Sam Carey
>
> _______________________________________________
> 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/20160608/5d05c452/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 8 Jun 2016 11:24:02 -0700
From: Derek Kozel <[email protected]>
To: "Topliff, Charles Alexander" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Octoclock-G GPS Lock
Message-ID:
<CAA+K=tu2krqsxewk0dsrra-uyy6yshn0m2lu7kww96xadmh...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Charles,
Great to hear. Please let us know if you have any other questions or issues.
Cheers,
Derek
On Wed, Jun 8, 2016 at 7:50 AM, Topliff, Charles Alexander <
[email protected]> wrote:
> Hi,
>
>
> I was able to eventually get a GPS lock after giving the octoclock some
> time. It was able to establish a lock after about fifteen minutes or so.
>
>
> Thanks for your help!
>
>
> Charles
> ------------------------------
> *From:* Derek Kozel <[email protected]>
> *Sent:* Tuesday, June 7, 2016 2:36 PM
> *To:* Topliff, Charles Alexander; [email protected]
>
> *Subject:* Re: [USRP-users] Octoclock-G GPS Lock
>
> +usrp-users list
>
> Hello,
>
> I have found that it can take a quarter of an hour or more unless it has
> perfect, full sky view with nothing in the way. Can you leave it running
> for a while and see if a lock occurs?
>
> Thanks,
> Derek
>
> On Tue, Jun 7, 2016 at 12:31 PM, Topliff, Charles Alexander <
> [email protected]> wrote:
>
>> I gave it a few minutes, and it did not seem to resolve any lock after
>> that. Does it require an extended period of time?
>>
>>
>>
>>
>>
>> ------------------------------
>> *From:* Derek Kozel <[email protected]>
>> *Sent:* Tuesday, June 7, 2016 2:26 PM
>> *To:* Topliff, Charles Alexander
>> *Cc:* [email protected]
>> *Subject:* Re: [USRP-users] Octoclock-G GPS Lock
>>
>> Hello Charles,
>>
>> How long has the antenna been in sight of the sky since powering on the
>> Octoclock? Ethernet is not required, though it would be useful to query the
>> gps_lock sensor.
>>
>> Regards,
>> Derek
>>
>> On Tue, Jun 7, 2016 at 12:17 PM, Topliff, Charles Alexander via
>> USRP-users <[email protected]> wrote:
>>
>>> Hello All,
>>>
>>>
>>> I am having difficulty obtaining a GPS lock using the Octoclock - G.
>>> From my understanding, the front panel GPS LOCK LED is to light up once a
>>> GPS lock is obtained. I am using the 5V GPS antenna purchased here:
>>> https://www.ettus.com/product/details/GPS-ANT-5V.
>>> <https://www.ettus.com/product/details/GPS-ANT-5V> I want to ensure
>>> that I am not missing any steps in order to get a GPS lock. I have the
>>> Octoclock powered, but it is not connected to any host computer via
>>> ethernet. When the antenna is connected and in an area well free of any
>>> obstructions, it still seems that the GPS LOCK LED is not lit.
>>>
>>> Any input or suggestions are appreciated.
>>>
>>> Thanks,
>>> Charles
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20160608/349cae67/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 8 Jun 2016 17:38:09 -0400
From: Ziang Gao <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP X310 FPGA
Message-ID:
<CALmz3p0SRiBUMOLLHTj9SO1_8q0vRdsZc=kvyuedf5jedqn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
HI,
I just assembled the USRP X310 and connect to my host computer. When I
run uhd_find_devices it finds the devices correctly, however, when running
uhd_usrp_probe, it shows "Error: RuntimeError: Expected FPGA compatibility
number 19, but got 13:
The FPGA image on your device is not compatible with this host code build",
and I followed the instruction to download FPGA images and burn to on-board
flash storage.
However, when I run the command again, it still shows the same error. I
did that process twice but didn't work. Is there anything I can do to fix
that?
Thank you.
Best regards,
Zinag.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160608/1d36daab/attachment-0001.html>
------------------------------
Message: 12
Date: Thu, 9 Jun 2016 00:01:02 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP X310 FPGA
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Have you powered the device off and on again?
Best regards,
Marcus
On 08.06.2016 23:38, Ziang Gao via USRP-users wrote:
> HI,
> I just assembled the USRP X310 and connect to my host computer.
> When I run uhd_find_devices it finds the devices correctly, however,
> when running uhd_usrp_probe, it shows "Error: RuntimeError: Expected
> FPGA compatibility number 19, but got 13:
> The FPGA image on your device is not compatible with this host code
> build", and I followed the instruction to download FPGA images and
> burn to on-board flash storage.
> However, when I run the command again, it still shows the same
> error. I did that process twice but didn't work. Is there anything I
> can do to fix that?
> Thank you.
> Best regards,
> Zinag.
>
>
> _______________________________________________
> 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/20160609/bb6ed9e1/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 8 Jun 2016 22:25:41 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Not sure how to remove tuser CHDR header
control and data from m_axis_data_tdata and s_axis_data_tdata in
noc_block
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
?Jonathon,
Would it be difficult to modify Test 5 -- Test Sequence in
noc_block_skeleton_tb.sv to send a file sink of SC16 data that was generated in
gnuradio?
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
________________________________
From: Jonathon Pendlum <[email protected]>
Sent: Wednesday, June 8, 2016 2:24 PM
To: Swanson, Craig
Subject: Re: Not sure how to remove tuser CHDR header control and data from
m_axis_data_tdata and s_axis_data_tdata in noc_block
If you are interfacing with the top level I/O, then your test bench will have
to handle things such as flow control, setting up noc shell, control packets,
etc. There isn't much I can do to help you with that other than pointing you to
our existing code. That is why I suggest using the test bench infrastructure
since it handles all that for you. If you want to give it another try, check
out noc_block_skeleton.v and the associated test bench. That block is intended
as a starting point for new blocks.
On Wed, Jun 8, 2016 at 11:41 AM, Swanson, Craig
<[email protected]<mailto:[email protected]>> wrote:
?Jonathon,
Yes.
I would prefer to use your testbench but I don't know it well enough yet. I
simply want to send it a file in modelsim that was produced in gnuradio as a
file sink. Do you have a testbench with fairly good documentation that will
allow me to do this? I am not an expert in system verilog, but if it is simple
enough I think I can understand it.
My cocotb testbench is using python to write scripts that send and receive data
directly from my noc_block_Receiver.v which currently has the AGC in it.
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156<tel:770.298.9156>
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
________________________________
From: Jonathon Pendlum
<[email protected]<mailto:[email protected]>>
Sent: Wednesday, June 8, 2016 12:29 PM
To: Swanson, Craig
Cc: Martin Braun; Marcus M?ller;
[email protected]<mailto:[email protected]>
Subject: Re: Not sure how to remove tuser CHDR header control and data from
m_axis_data_tdata and s_axis_data_tdata in noc_block
Craig,
Are you only simulating your AGC noc block and is your cocotb testbench
directly interfacing its top level I/O (i.e. i_tdata, o_tdata, etc)?
Jonathon
On Tue, Jun 7, 2016 at 9:26 PM, Swanson, Craig
<[email protected]<mailto:[email protected]>> wrote:
Jonathon,
I am in the process of creating my own noc_block_Receiver.v which currently is
acting as an AGC. When I run my own Modelsim testbench I am having undesired
effects of the header requests and reply mingled in with my AGC data. I am not
sure how to make sure that none of the header information for data, flow
control, command or response be included in with what is going in or out of my
AGC noc block.
It appears that the only signals I have access to are m_axis and s_axis tdata,
tlast, tvalid, and tready. How would you suggest I go about making sure only
pure data enters and leaves the AGC when communicating with my cocotb testbench
or gnuradio-companion? I have not looked at how the moving_avg deals with this.
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th Street NW
Atlanta, GA 30318
Cell: 770-298-9156<tel:770-298-9156>
http://www.gtri.gatech.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160608/1adc05e4/attachment-0001.html>
------------------------------
Message: 14
Date: Thu, 9 Jun 2016 01:47:36 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] Error when compiling module
noc_block_skeleton_tb in modelsim with latest commit
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Jonathon,
I just did
git clone -b rfnoc-radio-redo https://github.com/EttusResearch/uhd
cd uhd
git submodule update --init
So I am sure I have your latest rfnoc-radio-redo.
?
I am starting to utilize noc_block_skeleton_tb as you have suggested. When I
run "make vsim" I get the following:
Model Technology ModelSim DE vlog 10.4c Compiler 2015.07 Jul 19 2015
Start time: 21:33:38 on Jun 08,2016
vlog -incr -sv -work work
"+define+WORKING_DIR=/home/craig/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_skeleton_tb"
"+incdir+../../../../../../radio" "+incdir+../../../../../"
"+incdir+../../../../../../../sim/general"
"+incdir+../../../../../../../sim/axi"
"+incdir+../../../../../../../sim/control"
"+incdir+../../../../../../../sim/rfnoc" ../../../../noc_block_skeleton_tb.sv
-- Compiling interface axis_t
-- Compiling interface axis_master
-- Compiling interface axis_slave
-- Compiling package noc_block_skeleton_tb_sv_unit
-- Compiling interface cvita_master
-- Compiling interface cvita_slave
-- Compiling interface settings_bus_t
-- Compiling interface settings_bus_master
-- Compiling interface settings_bus_slave
-- Compiling interface rfnoc_block_streamer
-- Compiling module noc_block_skeleton_tb
** Error: ../../../../noc_block_skeleton_tb.sv(61): (vlog-2123) Missing
argument for format specification '%d'.
** Error: ../../../../noc_block_skeleton_tb.sv(66): (vlog-2123) Missing
argument for format specification '%d'.
End time: 21:33:38 on Jun 08,2016, Elapsed time: 0:00:00
Errors: 2, Warnings: 0
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160609/66834be7/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 8 Jun 2016 20:58:19 -0500
From: Jonathon Pendlum <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Error when compiling module
noc_block_skeleton_tb in modelsim with latest commit
Message-ID:
<cagdo0uryckiu6w_3z3tb8h-+z6ujjkn8b0-adrlfmaj1sct...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Craig,
Fixed, pull the latest rfnoc-radio-redo.
Jonathon
On Wed, Jun 8, 2016 at 8:47 PM, Swanson, Craig <
[email protected]> wrote:
> Jonathon,
>
> I just did
>
>
> git clone -b rfnoc-radio-redo https://github.com/EttusResearch/uhd
> cd uhd
> git submodule update --init
>
> So I am sure I have your latest rfnoc-radio-redo.
>
> ?
>
> I am starting to utilize noc_block_skeleton_tb as you have suggested.
> When I run "make vsim" I get the following:
>
> Model Technology ModelSim DE vlog 10.4c Compiler 2015.07 Jul 19 2015
> Start time: 21:33:38 on Jun 08,2016
> vlog -incr -sv -work work
> "+define+WORKING_DIR=/home/craig/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_skeleton_tb"
> "+incdir+../../../../../../radio" "+incdir+../../../../../"
> "+incdir+../../../../../../../sim/general"
> "+incdir+../../../../../../../sim/axi"
> "+incdir+../../../../../../../sim/control"
> "+incdir+../../../../../../../sim/rfnoc" ../../../../
> noc_block_skeleton_tb.sv
> -- Compiling interface axis_t
> -- Compiling interface axis_master
> -- Compiling interface axis_slave
> -- Compiling package noc_block_skeleton_tb_sv_unit
> -- Compiling interface cvita_master
> -- Compiling interface cvita_slave
> -- Compiling interface settings_bus_t
> -- Compiling interface settings_bus_master
> -- Compiling interface settings_bus_slave
> -- Compiling interface rfnoc_block_streamer
> -- Compiling module noc_block_skeleton_tb
> ** Error: ../../../../noc_block_skeleton_tb.sv(61): (vlog-2123) Missing
> argument for format specification '%d'.
> ** Error: ../../../../noc_block_skeleton_tb.sv(66): (vlog-2123) Missing
> argument for format specification '%d'.
> End time: 21:33:38 on Jun 08,2016, Elapsed time: 0:00:00
> Errors: 2, Warnings: 0
>
>
>
>
> *Craig F. Swanson*
>
> *Research Engineer II *
> *Information and Communications Laboratory*
> *Communications, Systems, and Spectrum Division*
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW *
> *Atlanta, GA 30318*
> *Cell: 770.298.9156 <770.298.9156>*
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160608/556fa6c5/attachment-0001.html>
------------------------------
Message: 16
Date: Thu, 9 Jun 2016 02:18:15 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Error when compiling module
noc_block_skeleton_tb in modelsim with latest commit
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
?Jonathon,
Yes, that worked. Thanks for making the testbench much more readable.
I know you are very busy so I understand if you don't have time, but where can
I find some example code in any of the testbenches that will take a file sink
generated by gnuradio and run it through the noc_block_skeleton_tb.sv as the
payload?
Thanks,
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
________________________________
From: Jonathon Pendlum <[email protected]>
Sent: Wednesday, June 8, 2016 9:58 PM
To: Swanson, Craig
Cc: [email protected]
Subject: Re: Error when compiling module noc_block_skeleton_tb in modelsim with
latest commit
Hi Craig,
Fixed, pull the latest rfnoc-radio-redo.
Jonathon
On Wed, Jun 8, 2016 at 8:47 PM, Swanson, Craig
<[email protected]<mailto:[email protected]>> wrote:
Jonathon,
I just did
git clone -b rfnoc-radio-redo https://github.com/EttusResearch/uhd
cd uhd
git submodule update --init
So I am sure I have your latest rfnoc-radio-redo.
?
I am starting to utilize noc_block_skeleton_tb as you have suggested. When I
run "make vsim" I get the following:
Model Technology ModelSim DE vlog 10.4c Compiler 2015.07 Jul 19 2015
Start time: 21:33:38 on Jun 08,2016
vlog -incr -sv -work work
"+define+WORKING_DIR=/home/craig/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_skeleton_tb"
"+incdir+../../../../../../radio" "+incdir+../../../../../"
"+incdir+../../../../../../../sim/general"
"+incdir+../../../../../../../sim/axi"
"+incdir+../../../../../../../sim/control"
"+incdir+../../../../../../../sim/rfnoc"
../../../../noc_block_skeleton_tb.sv<http://noc_block_skeleton_tb.sv>
-- Compiling interface axis_t
-- Compiling interface axis_master
-- Compiling interface axis_slave
-- Compiling package noc_block_skeleton_tb_sv_unit
-- Compiling interface cvita_master
-- Compiling interface cvita_slave
-- Compiling interface settings_bus_t
-- Compiling interface settings_bus_master
-- Compiling interface settings_bus_slave
-- Compiling interface rfnoc_block_streamer
-- Compiling module noc_block_skeleton_tb
** Error:
../../../../noc_block_skeleton_tb.sv<http://noc_block_skeleton_tb.sv>(61):
(vlog-2123) Missing argument for format specification '%d'.
** Error:
../../../../noc_block_skeleton_tb.sv<http://noc_block_skeleton_tb.sv>(66):
(vlog-2123) Missing argument for format specification '%d'.
End time: 21:33:38 on Jun 08,2016, Elapsed time: 0:00:00
Errors: 2, Warnings: 0
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156<tel:770.298.9156>
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160609/6c77362e/attachment-0001.html>
------------------------------
Message: 17
Date: Thu, 9 Jun 2016 08:10:26 +0200
From: Sylvain Munaut <[email protected]>
To: NIKOLOV <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Connecting TX/RX and RX2 internally
Message-ID:
<cahl+j0__sr5eyg-o0uaugzho-vxzzmqs04fwsmm-oe-vdzc...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
> wanted to test the receiver and the transmitter, but i still do not have a
> SMA cable.
DO NOT connect TX to RX2 directly !
This would just fry the RX side of your USRP ... It's meant to receive
weak signals from an antenna, connecting the transmitter directly to
it would melt it down ...
You need to use an attenuator in the path, something like 50 dB .
Sending -40 dBm into the RX port is _plenty_ enough to have a clear
signal.
As Michael pointed out, you can actually just use the RF switch
leakage as attenuators ... each has ~ -30 dB leakage and there is 2 in
the path, giving -60 dB or so which should be just fine to see your
signal.
Cheers,
Sylvain
------------------------------
Message: 18
Date: Thu, 9 Jun 2016 13:41:07 +0200
From: Patrick Berger <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP X310 FPGA
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Zinag
This is a driver missmatch problem. Your fpga image is for uhd version x and
you installed uhd driver version y on your host.
You can download the corrent image from here and then flash:
http://files.ettus.com/binaries/images/
uhd_image_loader --args="type=x300,addr=192.168.10"
--fpga-path="/to/your/.bit-file"
or just by (uses default images with driver compatibility):
uhd_image_loader --args="type=x300,addr=192.168.10.2,fpga=HGS"
Best regards
Patrick
Date: Wed, 8 Jun 2016 17:38:09 -0400
To: [email protected]
Subject: [USRP-users] USRP X310 FPGA
From: [email protected]
HI,
I just assembled the USRP X310 and connect to my host computer. When I run
uhd_find_devices it finds the devices correctly, however, when running
uhd_usrp_probe, it shows "Error: RuntimeError: Expected FPGA compatibility
number 19, but got 13:
The FPGA image on your device is not compatible with this host code build", and
I followed the instruction to download FPGA images and burn to on-board flash
storage.
However, when I run the command again, it still shows the same error. I did
that process twice but didn't work. Is there anything I can do to fix that?
Thank you.
Best regards,
Zinag.
_______________________________________________
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/20160609/c942b7d0/attachment-0001.html>
------------------------------
Message: 19
Date: Thu, 9 Jun 2016 15:58:43 +0200
From: Patrick Berger <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Custom UHD Program terminate during
set_clock_ref
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi
I've managed to set breakpoints inside the function:
With a breakpoint on usrp->get_rx_freq() I could inspect the usrp pointer.
usrp @0x10148b0
uhd::usrp::multi_usrp::sptr
data @0x1015280
boost::shared_ptr<uhd::usrp::multi_usrp>::element_type
usecoutnt 1 int
weadkcount 1 int
Checking the pointer against NULL is successful (so that isn't the problem).
If I try to step over this function call the app crashes, or debuging is
terminated with following error message. Against my programming expierence this
indicates a bad pointer or something like this.
The inferior stopped because it received a signal from the Operating System.
Signal name: SIGSEGV
Signal meaning: Segmentation fault
During stepping through the instruction code in the disassembler, I get till
the function _ZN15multi_usrp_impl14rx_chan_to_mcpEm:
Function: _ZN15multi_usrp_impl14rx_chan_to_mcpEm
0x7f649e20a14c <+0x003c> movl $0x0,0x8(%rsp)
0x7f649e20a154 <+0x0044> mov %rax,0x20(%rsp)
0x7f649e20a159 <+0x0049> nopl 0x0(%rax)
0x7f649e20a160 <+0x0050> mov (%r15),%rax
On the last line I get the segmentation fault! So I think there is something
inside the uhd library wrong (accessing protected memory).
The stack view at the crash moment looks like this:
Level Function
0 multi_usrp_impl::rx_chan_to_mcp(unsinged long)
1 multi_usrp_impl::rx_rf_fe_roo(unsinged long)
2 multi_usrp_impl::get_fe_rx_freq_range(unsigned long)
3 USDP_SDR::Init_USRP
4 main
So there must be something wrong in the function rx_chan_to_mcp
Platform is Linux Mint 17.2, IDE is Qt Creator, linked UHD version is 3.9.1
(what I have to use for communicate also with matlab)
Best regards
Patrick
> Date: Wed, 8 Jun 2016 09:28:45 -0700
> To: [email protected]
> Subject: Re: [USRP-users] Custom UHD Program terminate during set_clock_ref
> From: [email protected]
> CC: [email protected]
>
> Patrick,
>
> Is 'ref' being properly set before it is called in
> usrp->set_clock_source(ref) ? A simple sanity check is to print it out before
> it is called:
>
> std::cout << boost::format("Lock mboard clocks: %f") % ref << std::endl;
> usrp->set_clock_source(ref);
>
>
> - Nate
>
> > On Jun 8, 2016, at 9:05 AM, Martin Braun via USRP-users
> > <[email protected]> wrote:
> >
> > Patrick,
> >
> > I have a hunch something is hiding some error message, and that error
> > message would clue us in. The last line ("Press Return") is coming from
> > where exactly? Is it your dev environment? Maybe there's a hidden
> > segfault there. GRC is a bit like that, too.
> >
> > M
> >
> > On 06/08/2016 12:17 AM, Patrick Berger via USRP-users wrote:
> >> Hi all
> >>
> >> I'm trying to create my own program to communicate with an X310 USRP.
> >> Host is Linux (Mint 17.2) with uhd version 3.9.1 and boost 1.57.0
> >>
> >> During the build process in Qt Creator I've no errors or warnings
> >> (libraries are all correct linked). The device is correctly found and
> >> the initialization with uhd::usrp::multi_usrp::make(dev_adr) works also.
> >> In the second step I would set the mboard clocks, but there is something
> >> going bad.
> >>
> >> This is my current code (cross-checked with rx_samples_to_file,
> >> rx_samples_to_udp, rx_ascii_art_dft):
> >> int USRP_SDR::Init_USRP()
> >> {
> >> //create a usrp device
> >> uhd::device_addr_t dev_adr;
> >> dev_adr.set("addr", addr);
> >> usrp = uhd::usrp::multi_usrp::make(dev_adr);
> >>
> >> std::cout << "Hallo1" << std::endl;
> >> //Lock mboard clocks
> >> usrp->set_clock_source(ref);
> >> std::cout << "Hallo2" << std::endl;
> >>
> >> //always select the subdevice first, the channel mapping affects the
> >> other settings
> >> if (vm.count("subdev")) usrp->set_rx_subdev_spec(subdev);
> >>
> >> std::cout << boost::format("Using Device: %s") %
> >> usrp->get_pp_string() << std::endl;
> >>
> >> //set the sample rate
> >> if (rate <= 0.0){
> >> std::cerr << "Please specify a valid sample rate" << std::endl;
> >> return 0;
> >> }
> >> std::cout << boost::format("Setting RX Rate: %f Msps...") %
> >> (rate/1e6) << std::endl;
> >> usrp->set_rx_rate(rate);
> >> std::cout << boost::format("Actual RX Rate: %f Msps...") %
> >> (usrp->get_rx_rate()/1e6) << std::endl << std::endl;
> >>
> >> return 1;
> >> }
> >>
> >> And this is the resulting terminal output (the Hello2 is missing, and
> >> also the rest of the initialization process):
> >> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.001-0-unknown
> >>
> >> UHD Warning:
> >> Unable to set the thread priority. Performance may be negatively
> >> affected.
> >> Please see the general application notes in the manual for instructions.
> >> EnvironmentError: OSError: error in pthread_setschedparam
> >> -- X300 initialization sequence...
> >> -- Determining maximum frame size... 1472 bytes.
> >> -- Setup basic communication...
> >> -- Loading values from EEPROM...
> >> -- Setup RF frontend clocking...
> >> -- Radio 1x clock:200
> >> -- Initialize Radio0 control...
> >> -- Performing register loopback test... pass
> >> -- Initialize Radio1 control...
> >> -- Performing register loopback test... pass
> >> Hallo1
> >> Press <RETURN> to close this window...
> >>
> >> Does anyone see the fault?
> >>
> >> Best regards
> >> Patrick
> >>
> >>
> >> _______________________________________________
> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160609/e86ba512/attachment-0001.html>
------------------------------
Message: 20
Date: Thu, 9 Jun 2016 11:33:48 -0400
From: Zhongren Cao <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Detailed RX/TX Filter Bank Specifications for
E310/312
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi,
The E310/312 Data Sheet has a coarse illustration of the characteristics of the
TX/RX front end filter banks, which only shows 6 dB of attenuation. Do you have
a more detailed presentation, which shows detailed frequency vs. attenuation in
the scale of 30-50 dB range?
For example, for the RX FB-5 & FB-6, where is the cut-off? What?s the response
in 2.1G, 2.5G, respectively?
Thanks,
Zhongren
------------------------------
Message: 21
Date: Thu, 9 Jun 2016 11:43:23 -0400
From: "Joshua Monson" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Custom Board
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
We're developing a custom bare-metal FPGA design for the USRP E310. The plan
is to have the FPGA configured with this design via an SDCard image when the
board powers up. To begin our development we'd like to start with minimal
FPGA design that can bring the board up safely without damaging the other
components. To this end I've created an initial design in Xilinx Vivado by
importing the PS configurations (presets) from the E3XX_idle design in UHD.
On the FPGA side (PL), I've imported and integrated the AXI PMU and constant
logic values connected to external I/O (also from E3XX_idle). I've also
imported the constraint files from E3XX_idle to ensure the I/O voltage
levels are configured properly.
Is there anything else that I need to do to ensure that the board and FPGA
powers on properly?
Thanks,
Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160609/95cbea58/attachment-0001.html>
------------------------------
Message: 22
Date: Thu, 9 Jun 2016 08:55:56 -0700
From: Michael West <[email protected]>
To: Sylvain Munaut <[email protected]>
Cc: NIKOLOV <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Connecting TX/RX and RX2 internally
Message-ID:
<cam4xkroj6r4tfhd+vjk5pulvvcbvfpvmaqc0kf9m_rcwbh3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Good points, Sylvain. Yes, connecting TX directly to RX can damage the
LNA. A 30 dB attenuator is sufficient to protect it. There is actually
only one RF switch between the TX and RX paths and it provides ~30 dB of
isolation.
Regards,
Michael
On Wed, Jun 8, 2016 at 11:10 PM, Sylvain Munaut via USRP-users <
[email protected]> wrote:
> Hi,
>
> > wanted to test the receiver and the transmitter, but i still do not have
> a
> > SMA cable.
>
> DO NOT connect TX to RX2 directly !
>
> This would just fry the RX side of your USRP ... It's meant to receive
> weak signals from an antenna, connecting the transmitter directly to
> it would melt it down ...
>
> You need to use an attenuator in the path, something like 50 dB .
> Sending -40 dBm into the RX port is _plenty_ enough to have a clear
> signal.
>
> As Michael pointed out, you can actually just use the RF switch
> leakage as attenuators ... each has ~ -30 dB leakage and there is 2 in
> the path, giving -60 dB or so which should be just fine to see your
> signal.
>
>
> Cheers,
>
> Sylvain
>
> _______________________________________________
> 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/20160609/dbc143a7/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 70, Issue 9
*****************************************
