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: Bandpass filter for DBS-RX2 ([email protected])
2. Re: USRP E310. Update UHD on SD card to latest version
(Moritz Fischer)
3. Re: USRP E310. Update UHD on SD card to latest version
(Philip Balister)
4. Re: Bandpass filter for DBS-RX2 (Venkatesh Sandilya)
5. Re: problem with MISO signal receiving (scott tiger)
6. Re: Accessing a customized register of FPGA code from UHD
(Marcus M?ller)
7. Re: Gen3 FPGA Code License? (Matt Ettus)
8. Re: 003.008.002 Build Issues (Ben Hilburn)
9. Re: 003.008.002 Build Issues (Ben Hilburn)
10. Re: 003.008.002 Build Issues (Smithhisler, Thomas A.)
11. Re: 003.008.002 Build Issues (Ben Hilburn)
12. rfnoc, using the settings register bus (Anselm Karl)
13. Re: rfnoc, using the settings register bus (Sylvain Munaut)
----------------------------------------------------------------------
Message: 1
Date: Tue, 07 Apr 2015 12:08:10 -0400
From: [email protected]
To: Venkatesh Sandilya <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Bandpass filter for DBS-RX2
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
The MAX2112 chip implements a variable baseband filter on the I/Q analog
outputs going to the ADCs on whatever motherboard
you're using.
You can use set_rx_bandwidtth() to set these explicitly, but by default
they're set to values that are appropriate for the sample-rate in use.
However, if you're having, for example, non-linearity (intermod, etc)
problems at the *RF* level, then you'll need to place an
application-specific filter in front of the DBSRX2, this very often
won't be required, but if there are signals of significant magnitude
outside your RF passband, you may need additional filtering up front.
On 2015-04-07 11:39, Venkatesh Sandilya wrote:
> A filter at RF. I have the schematics for DBS-RX2. Can you tell me where it
> implements analog baseband filtering? Thanks.
> On Apr 7, 2015 11:29 AM, <[email protected]> wrote:
>
> Do you mean a filter at RF, or baseband?
>
> It already implements analog baseband filtering, with selectable bandwidths.
>
> On 2015-04-07 11:18, Venkatesh Sandilya via USRP-users wrote:
>
> Hello
>
> Is there anyway to implement a bandpass filter for the DBS-RX2 daughter
> board. Is there already a default setting in the UHD api for it? Thanks much.
>
> Venkatesh
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
Links:
------
[1] 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/20150407/c879a4f9/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 7 Apr 2015 09:23:46 -0700
From: Moritz Fischer <[email protected]>
To: Paul Harbanau <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] USRP E310. Update UHD on SD card to latest
version
Message-ID:
<caatxahftt1vk4gnmpchu7wbqtca0ur2gbycqjgogqmp4tvt...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi Paul,
please check out our manual [1] for upgrading your sdcard image. It
has a section on upgrading the SD card.
Thanks,
Moritz
[1] http://files.ettus.com/manual/page_usrp_e3x0.html
On Tue, Apr 7, 2015 at 2:17 AM, Paul Harbanau via USRP-users
<[email protected]> wrote:
> Greetings to all!
>
> I have a problem with the communicating with E310. I can run a preinstalled
> to SD card examples. But when I tried to run the examples on my host machine
> (with --args="addr=..."), I got the error FPGA compatibility.
> The problem was solved after running uhd_images_downloader on E310 device.
> But now the version of the library is not compatible with FPGA images. So i
> need help to update UHD to the latest version (003.008.002).
>
> I tried to make checkout and cmake (on E310). But it gives an error:
>
> # cmake -DCMAKE_TOOLCHAIN_FILE = .. / cmake / Toolchains /
> arm_cortex_a8_native.cmake -DENABLE_E100 = ON -DENABLE_USRP_E_UTILS = TRUE
> ../
>
> ...
> The C ++ compiler "/ usr / bin / g ++" is not able to compile a simple test
> program
> ...
>
> Then I tried to install OpenEmbedded SDK on the host computer and cross
> compile for E310. Then copy this UHD build to the SD card.
> But the example programs doesn't see libs like boost.
>
> root @ ettus-e300: /usr/lib/uhd/examples # ldd benchmark_rate
> ./benchmark_rate: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.20 'not
> found (required by ./benchmark_rate)
> ./benchmark_rate: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.20 'not
> found (required by /usr/lib/libuhd.so.003)
> libuhd.so.003 => /usr/lib/libuhd.so.003 (0xb6a08000)
> libboost_program_options.so.1.57.0 => not found
> libboost_system.so.1.57.0 => not found
> libboost_thread.so.1.57.0 => not found
> libpthread.so.0 => /lib/libpthread.so.0 (0xb69e8000)
> libstdc ++. so.6 => /usr/lib/libstdc++.so.6 (0xb691c000)
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb68f7000)
> libc.so.6 => /lib/libc.so.6 (0xb67c0000)
> libboost_date_time.so.1.57.0 => not found
> libboost_filesystem.so.1.57.0 => not found
> libboost_regex.so.1.57.0 => not found
> libboost_system.so.1.57.0 => not found
> libboost_thread.so.1.57.0 => not found
> libboost_serialization.so.1.57.0 => not found
> librt.so.1 => /lib/librt.so.1 (0xb67b1000)
> liborc-0.4.so.0 => /usr/lib/liborc-0.4.so.0 (0xb6741000)
> libusb-1.0.so.0 => /lib/libusb-1.0.so.0 (0xb672d000)
> libudev.so.0 => /lib/libudev.so.0 (0xb671a000)
> libdl.so.2 => /lib/libdl.so.2 (0xb670f000)
> libm.so.6 => /lib/libm.so.6 (0xb669e000)
> /lib/ld-linux-armhf.so.3 (0xb6f3d000)
>
> Please help, how can I update UHD on SD card?
>
>
> Best Regards,
> Paul
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 3
Date: Tue, 07 Apr 2015 13:28:24 -0400
From: Philip Balister <[email protected]>
To: Moritz Fischer <[email protected]>, Paul Harbanau
<[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] USRP E310. Update UHD on SD card to latest
version
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 04/07/2015 12:23 PM, Moritz Fischer via USRP-users wrote:
> Hi Paul,
>
> please check out our manual [1] for upgrading your sdcard image. It
> has a section on upgrading the SD card.
It sounded like you may be mixing sdk's from different versions of the
card. For the card that ships with the unit use the sdk from here:
http://files.ettus.com/e3xx_images/e3xx-release-001/
If you use the test file system from here, use the sdk from this directory:
http://files.ettus.com/e3xx_images/beta/dizzy-test/
This sdk likely will not work against the shipping image.
Also note uhd-3.8.2 has a bug in the fpga image that leads to the LO
stepping about 100Hz across a small range. Ask engineering for an
updated fpga image.
Philip
>
> Thanks,
>
> Moritz
>
> [1] http://files.ettus.com/manual/page_usrp_e3x0.html
>
> On Tue, Apr 7, 2015 at 2:17 AM, Paul Harbanau via USRP-users
> <[email protected]> wrote:
>> Greetings to all!
>>
>> I have a problem with the communicating with E310. I can run a preinstalled
>> to SD card examples. But when I tried to run the examples on my host machine
>> (with --args="addr=..."), I got the error FPGA compatibility.
>> The problem was solved after running uhd_images_downloader on E310 device.
>> But now the version of the library is not compatible with FPGA images. So i
>> need help to update UHD to the latest version (003.008.002).
>>
>> I tried to make checkout and cmake (on E310). But it gives an error:
>>
>> # cmake -DCMAKE_TOOLCHAIN_FILE = .. / cmake / Toolchains /
>> arm_cortex_a8_native.cmake -DENABLE_E100 = ON -DENABLE_USRP_E_UTILS = TRUE
>> ../
>>
>> ...
>> The C ++ compiler "/ usr / bin / g ++" is not able to compile a simple test
>> program
>> ...
>>
>> Then I tried to install OpenEmbedded SDK on the host computer and cross
>> compile for E310. Then copy this UHD build to the SD card.
>> But the example programs doesn't see libs like boost.
>>
>> root @ ettus-e300: /usr/lib/uhd/examples # ldd benchmark_rate
>> ./benchmark_rate: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.20 'not
>> found (required by ./benchmark_rate)
>> ./benchmark_rate: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.20 'not
>> found (required by /usr/lib/libuhd.so.003)
>> libuhd.so.003 => /usr/lib/libuhd.so.003 (0xb6a08000)
>> libboost_program_options.so.1.57.0 => not found
>> libboost_system.so.1.57.0 => not found
>> libboost_thread.so.1.57.0 => not found
>> libpthread.so.0 => /lib/libpthread.so.0 (0xb69e8000)
>> libstdc ++. so.6 => /usr/lib/libstdc++.so.6 (0xb691c000)
>> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb68f7000)
>> libc.so.6 => /lib/libc.so.6 (0xb67c0000)
>> libboost_date_time.so.1.57.0 => not found
>> libboost_filesystem.so.1.57.0 => not found
>> libboost_regex.so.1.57.0 => not found
>> libboost_system.so.1.57.0 => not found
>> libboost_thread.so.1.57.0 => not found
>> libboost_serialization.so.1.57.0 => not found
>> librt.so.1 => /lib/librt.so.1 (0xb67b1000)
>> liborc-0.4.so.0 => /usr/lib/liborc-0.4.so.0 (0xb6741000)
>> libusb-1.0.so.0 => /lib/libusb-1.0.so.0 (0xb672d000)
>> libudev.so.0 => /lib/libudev.so.0 (0xb671a000)
>> libdl.so.2 => /lib/libdl.so.2 (0xb670f000)
>> libm.so.6 => /lib/libm.so.6 (0xb669e000)
>> /lib/ld-linux-armhf.so.3 (0xb6f3d000)
>>
>> Please help, how can I update UHD on SD card?
>>
>>
>> Best Regards,
>> Paul
>>
>> _______________________________________________
>> 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: 4
Date: Tue, 7 Apr 2015 15:09:06 -0400
From: Venkatesh Sandilya <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Bandpass filter for DBS-RX2
Message-ID:
<CAGNcrNLUMMAzpB1vTYUsLeBOXx0wjiEowZo2pqfqcW8yAL=m...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks much. Appreciate it.
On Apr 7, 2015 12:08 PM, <[email protected]> wrote:
> The MAX2112 chip implements a variable baseband filter on the I/Q analog
> outputs going to the ADCs on whatever motherboard
> you're using.
>
> You can use set_rx_bandwidtth() to set these explicitly, but by default
> they're set to values that are appropriate for the sample-rate in use.
>
> However, if you're having, for example, non-linearity (intermod, etc)
> problems at the *RF* level, then you'll need to place an
> application-specific filter in front of the DBSRX2, this very often won't
> be required, but if there are signals of significant magnitude outside your
> RF passband, you may need additional filtering up front.
>
>
>
>
> On 2015-04-07 11:39, Venkatesh Sandilya wrote:
>
> A filter at RF. I have the schematics for DBS-RX2. Can you tell me where
> it implements analog baseband filtering? Thanks.
> On Apr 7, 2015 11:29 AM, <[email protected]> wrote:
>
>> Do you mean a filter at RF, or baseband?
>>
>> It already implements analog baseband filtering, with selectable
>> bandwidths.
>>
>>
>>
>>
>>
>>
>> On 2015-04-07 11:18, Venkatesh Sandilya via USRP-users wrote:
>>
>> Hello
>>
>> Is there anyway to implement a bandpass filter for the DBS-RX2 daughter
>> board. Is there already a default setting in the UHD api for it? Thanks
>> much.
>>
>> Venkatesh
>>
>> _______________________________________________
>> USRP-users mailing
>> [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/20150407/97a8ba20/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 7 Apr 2015 22:01:12 +0200
From: scott tiger <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] problem with MISO signal receiving
Message-ID:
<ca+kb_ucduecpgrpd1gi1v4tt+g+m61mds4nw8gjujysg3j6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Sun, Apr 5, 2015 at 7:18 PM, Martin Braun <[email protected]> wrote:
> Maksim,
>
> please re-send that email to the list, I won't be able to respond before
> tomorrow.
>
> M
>
> On 05.04.2015 07:26, scott tiger wrote:
>
>> Dear Martin thank you very much for you previous reply.
>>
>> I am using WBX daughter-boards and transmitting LAS orthogonal codes
>> (codes consists of +1, -1, 0) and also I tried to send zadoff chu
>> sequence.
>> I generated the sequences in matlab then I transmitting them using
>> source file in gnu radio and usrp block. I feel that I am loosing
>> the orthogonality of these sequences when I receive them.
>> Can be unsynchronization between the transmitter with receiver cause that?
>> Thank you very much for your reply
>> Maksim Veronov
>>
>> On Thu, Apr 2, 2015 at 10:40 PM, Martin Braun via USRP-users
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> Which daughterboards are you using?
>>
>> Also, which signals are you transmitting? Is it some kind of
>> orthogonal code (zadoff-chu or something like that?). Or are you
>> relying on some fixed phase relation?
>>
>> M
>>
>>
>> On 02.04.2015 02:12, scott tiger via USRP-users wrote:
>>
>> Hello all,
>> I am trying to send two orthogonal sequences from different
>> antennas and
>> receive them in one (2 by 1) . I am using two USRP for
>> transmitting
>> purpose synchronized using MIMO cable (with two antennas) and
>> receive
>> one signal but when I check it it seems that all the orthogonality
>> disappears. While when I use SISO transmission I can receive a
>> good
>> signal. Can you please help me in this problem? Can be this
>> problem
>> caused because of unsynchronized receiver with the transmission
>> part ?
>>
>>
>>
>>
>>
>> _________________________________________________
>> 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/20150407/491b2bcb/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 07 Apr 2015 22:32:04 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Accessing a customized register of FPGA code
from UHD
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Commenting on code that I don't know is a bit hard, but:
you will need to have a working instance of setting_reg; after that,
you'll be able to use the register just like the other registers you'd
find in your uhd/host/lib/usrp/x300/x300_regs.hpp.
Git grep is really helpful finding examples for the usage of setting_reg:
cd fpga/usrp3/lib
git grep --context 3 setting_reg
Greetings,
Marcus
On 04/05/2015 04:38 AM, Isen I-Chun Chao via USRP-users wrote:
> Hi,
> I have a customized register in x300_core.v, say named *my_var.* I would
> like to get the register value from the application layer through UHD or
> whatever.
>
> I wonder if there any example in UHD can be used for my reference or anyone
> could provide some advice.
> j
> Thank you very much.
>
>
>
> *Best Regards,Isen I-Chun Chao*
>
>
>
> _______________________________________________
> 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/20150407/2ecabe78/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 7 Apr 2015 14:00:19 -0700
From: Matt Ettus <[email protected]>
To: Tom Wallace <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Gen3 FPGA Code License?
Message-ID:
<CAN=1kn_f2utshhdyurzatfqlagxuy0lj23qvirmrp2sp1rg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Tom,
The notices were removed because we were thinking of switching to another
open source license, but we have decided not to switch. Everything is
covered by GPL3. Similar to UHD, there is an alternative license which
allows you to avoid the limitations of GPL on hardware you purchase from us.
I will put a notice in the source code explaining this and also how we
interpret the GPL for FPGA code.
Thanks,
Matt
On Mon, Apr 6, 2015 at 7:29 AM, Tom Wallace via USRP-users <
[email protected]> wrote:
> From the Git repo logs, it looks like the Gen3 FPGA code had the GPLv3
> license statements removed last year. Is there a license that describes the
> terms under which the Gen3 code is now distributed?
>
>
>
> In particular, is it still distributed under an open source license, and
> if so, what flavor (BSD/GPL/LGPL/other)?
>
>
>
> ---
>
> Tom Wallace ([email protected])
>
> Vesperix Corporation
>
> 803 West Broad Street, Suite 520
>
> Falls Church, VA 22046
>
> Phone 703-224-4422 Mobile 703-220-8711
>
>
>
> _______________________________________________
> 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/20150407/7e186231/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 7 Apr 2015 14:32:57 -0700
From: Ben Hilburn <[email protected]>
To: "Smithhisler, Thomas A." <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] 003.008.002 Build Issues
Message-ID:
<caoevzk+jsejv1-11powa_jvz2h-dtbbh2kvl86gkkjkyv95...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Tom -
We have successfully built (and distribute) UHD-3.8.2 with MSVC2013 and
Boost 1.56. We have not tried building with Boost 1.57, but more
importantly, we do not build for Windows 8. That latter difference is
pretty significant, and may the cause of the issues. You could try rolling
back to Boost 1.56 just in case, though.
Cheers,
Ben
On Mon, Apr 6, 2015 at 6:35 PM, Smithhisler, Thomas A. via USRP-users <
[email protected]> wrote:
> ??Hello,
>
>
> I'm having trouble building the latest release of the UHD drivers. I'm
> using windows 8.1, boost 1.57, MSVC2013. I was able to successfully build
> 003.008.001, but and having trouble on 003.008.002. I was able to build
> from the latest maint branch, but master will not build. I'm not sure if
> the rest of the errors are due to the first four. Attached is the complete
> error list I receive.
>
>
> Let me know if anyone has any ideas.
>
>
> --
>
> Tom Smithhisler
>
> _______________________________________________
> 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/20150407/58079fc9/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 7 Apr 2015 14:53:20 -0700
From: Ben Hilburn <[email protected]>
To: "Smithhisler, Thomas A." <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] 003.008.002 Build Issues
Message-ID:
<CAOEVZkJBwLKmrvJkMZ6nDcPi66=bckak0jds9dzrsh67fs3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Tom -
Michael just pointed out to me that you are building from the HEAD of the
`master` branch. In that case, we haven't tested this thoroughly, as it is
our bleeding edge. We'll try to reproduce and fix it as soon as possible.
Cheers,
Ben
On Tue, Apr 7, 2015 at 2:32 PM, Ben Hilburn <[email protected]> wrote:
> Hi Tom -
>
> We have successfully built (and distribute) UHD-3.8.2 with MSVC2013 and
> Boost 1.56. We have not tried building with Boost 1.57, but more
> importantly, we do not build for Windows 8. That latter difference is
> pretty significant, and may the cause of the issues. You could try rolling
> back to Boost 1.56 just in case, though.
>
> Cheers,
> Ben
>
> On Mon, Apr 6, 2015 at 6:35 PM, Smithhisler, Thomas A. via USRP-users <
> [email protected]> wrote:
>
>> ??Hello,
>>
>>
>> I'm having trouble building the latest release of the UHD drivers. I'm
>> using windows 8.1, boost 1.57, MSVC2013. I was able to successfully build
>> 003.008.001, but and having trouble on 003.008.002. I was able to build
>> from the latest maint branch, but master will not build. I'm not sure if
>> the rest of the errors are due to the first four. Attached is the complete
>> error list I receive.
>>
>>
>> Let me know if anyone has any ideas.
>>
>>
>> --
>>
>> Tom Smithhisler
>>
>> _______________________________________________
>> 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/20150407/2dbba11e/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 7 Apr 2015 23:06:42 +0000
From: "Smithhisler, Thomas A." <[email protected]>
To: Ben Hilburn <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] 003.008.002 Build Issues
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
?Ben,
My mistake. I just pulled the latest tagged commit of 3.8.2 and it built just
fine. I was just trying to get the latest RC and don't have a need for the
bleeding edge stuff right now. No need to rush anything.
Thanks!
Tom
________________________________
From: Ben Hilburn <[email protected]>
Sent: Tuesday, April 7, 2015 5:53 PM
To: Smithhisler, Thomas A.
Cc: [email protected]
Subject: Re: [USRP-users] 003.008.002 Build Issues
Tom -
Michael just pointed out to me that you are building from the HEAD of the
`master` branch. In that case, we haven't tested this thoroughly, as it is our
bleeding edge. We'll try to reproduce and fix it as soon as possible.
Cheers,
Ben
On Tue, Apr 7, 2015 at 2:32 PM, Ben Hilburn
<[email protected]<mailto:[email protected]>> wrote:
Hi Tom -
We have successfully built (and distribute) UHD-3.8.2 with MSVC2013 and Boost
1.56. We have not tried building with Boost 1.57, but more importantly, we do
not build for Windows 8. That latter difference is pretty significant, and may
the cause of the issues. You could try rolling back to Boost 1.56 just in case,
though.
Cheers,
Ben
On Mon, Apr 6, 2015 at 6:35 PM, Smithhisler, Thomas A. via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
??Hello,
I'm having trouble building the latest release of the UHD drivers. I'm using
windows 8.1, boost 1.57, MSVC2013. I was able to successfully build
003.008.001, but and having trouble on 003.008.002. I was able to build from
the latest maint branch, but master will not build. I'm not sure if the rest of
the errors are due to the first four. Attached is the complete error list I
receive.
Let me know if anyone has any ideas.
--
Tom Smithhisler
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[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/20150407/b1470ba6/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 7 Apr 2015 16:16:15 -0700
From: Ben Hilburn <[email protected]>
To: "Smithhisler, Thomas A." <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] 003.008.002 Build Issues
Message-ID:
<CAOEVZk+UUzAJJn-kZRJZZJ4p12hUYdakSVW6Q+=NY5TrPbK=d...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Okay, great. Thanks for the update, Tom!
Cheers,
Ben
On Tue, Apr 7, 2015 at 4:06 PM, Smithhisler, Thomas A. <
[email protected]> wrote:
> ?Ben,
>
>
> My mistake. I just pulled the latest tagged commit of 3.8.2 and it built
> just fine. I was just trying to get the latest RC and don't have a need for
> the bleeding edge stuff right now. No need to rush anything.
>
>
> Thanks!
>
>
> Tom
> ------------------------------
> *From:* Ben Hilburn <[email protected]>
> *Sent:* Tuesday, April 7, 2015 5:53 PM
> *To:* Smithhisler, Thomas A.
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] 003.008.002 Build Issues
>
> Tom -
>
> Michael just pointed out to me that you are building from the HEAD of
> the `master` branch. In that case, we haven't tested this thoroughly, as it
> is our bleeding edge. We'll try to reproduce and fix it as soon as possible.
>
> Cheers,
> Ben
>
> On Tue, Apr 7, 2015 at 2:32 PM, Ben Hilburn <[email protected]> wrote:
>
>> Hi Tom -
>>
>> We have successfully built (and distribute) UHD-3.8.2 with MSVC2013 and
>> Boost 1.56. We have not tried building with Boost 1.57, but more
>> importantly, we do not build for Windows 8. That latter difference is
>> pretty significant, and may the cause of the issues. You could try rolling
>> back to Boost 1.56 just in case, though.
>>
>> Cheers,
>> Ben
>>
>> On Mon, Apr 6, 2015 at 6:35 PM, Smithhisler, Thomas A. via USRP-users <
>> [email protected]> wrote:
>>
>>> ??Hello,
>>>
>>>
>>> I'm having trouble building the latest release of the UHD drivers. I'm
>>> using windows 8.1, boost 1.57, MSVC2013. I was able to successfully build
>>> 003.008.001, but and having trouble on 003.008.002. I was able to build
>>> from the latest maint branch, but master will not build. I'm not sure if
>>> the rest of the errors are due to the first four. Attached is the complete
>>> error list I receive.
>>>
>>>
>>> Let me know if anyone has any ideas.
>>>
>>>
>>> --
>>>
>>> Tom Smithhisler
>>>
>>> _______________________________________________
>>> 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/20150407/91b025aa/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 8 Apr 2015 14:16:48 +0200
From: Anselm Karl <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] rfnoc, using the settings register bus
Message-ID:
<cakcs5r0jqfgjyzumfd+2x10r4npvmrv1w20em4vnaef7c2m...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
i want to write a rfnoc block with some settings registers.
On the fpga side things are quite clear: (Correct me if i am wrong.)
There are the signals set_addr, set_data and set_strb. The settings
registers gets written with the set_data if the address matches and
ste_strb is high. The UHD translates the rfnoc-id to the block name in the
xml descriptor.
On the host side its a little more complicated:
The getting started says a own block control has to be witten. (a public
header, an implementation and a xml descriptor) To use it in GRC, the
generic block descriptor template has to be customized to fit the header
and the block name in the xml descriptor. (I have not done it, but i handle
it, i think.)
But some blocks (the FIFO loopback for example) only have a xml descriptor,
as far as i see. I guess, that is because they only use the base
functionality of some rfnoc class.
So here?s my question:
Is there any (generic) way to write to a settings register in an rfnoc
block from GRC without doing an own block control? (By only making a xml
descriptor and the block descriptor for GRC) Something like putting the
register address and the binary value in the args argument?
Its for testing the blocks fpga design. I don?t need any plausibility check
on the host side right now. It would save a lot of time, because for a
additional register one would not need to change any host side code.
--
Mit freundlichen Gr??en
*Anselm Karl*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150408/c7f1d519/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 8 Apr 2015 14:43:35 +0200
From: Sylvain Munaut <[email protected]>
To: Anselm Karl <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rfnoc, using the settings register bus
Message-ID:
<CAHL+j08tgPx7P=9_2sqbrgxfgmg18ojqb9vbtastsfm-pap...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
The standard python block has a set_register(reg_address, reg_value) method.
It might be possible to call it from GRC using the 'function probe'
block. But when I tested stuff with my block, I just manually edited
the .py generated by GRC to add a couple of .set_register call ...
It's lost when I regenerate the .py from GRC but for quick tests, it
did the trick.
Cheers,
Sylvain
------------------------------
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 56, Issue 8
*****************************************
