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: Usage of Ettus B205mini (regarding OFDM) (Marcus M?ller)
2. Re: E310 FPGA rebuild not able to complete (Jonathon Pendlum)
3. Re: E310 FPGA rebuild not able to complete (Jason Matusiak)
4. MSVC Versions 2012 and 2017 (Martin Braun)
5. [UHD] Logging features on master branch (Martin Braun)
6. Re: E310 FPGA rebuild not able to complete (Jonathon Pendlum)
7. X300 continuous overflow errors (Perelman, Nathan)
8. Re: USRP command port (Usman Haider)
----------------------------------------------------------------------
Message: 1
Date: Fri, 21 Apr 2017 18:01:38 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Usage of Ettus B205mini (regarding OFDM)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Dear Shuang Hu,
> How can I integrate my modules into the project b205 (bulit
> automatically from github)?
Have you already succeeded in building an unmodified FPGA image? If not,
you should do that first! Follow the "Xilinx ISE Instructions" from
http://files.ettus.com/manual/md_usrp3_build_instructions.html . Only
after you have built a working FPGA image, and loaded it onto the
B205mini should you continue to modify it :)
You'd have to start by reading usrp3/top/b2xxmini/b205_core.v ; that's
the place where all the interesting parts of the digital signal chain
come together.
You'll, however find that most of the interesting stuff happens in the
radio_legacy module, so go and open usrp3/lib/radio_200/radio_legacy.v.
You'll probably want to insert your module before duc_chain, and route
the sample[31:0] signal through it ? each value of these is Q and I,
16bit, combined.
> Is there any other methods?
First of: Generally, you'd simply do something like that in software
running on the computer controlling the USRP (you can't use a B205mini
without a computer). So, if someone asked me "how would I implement an
OFDM transmitter", I'd say: simply write it in software! There's working
e.g. LTE, WiFi, DVB-T implementations that work with the USRPs, so it's
certainly possible.
>From a bandwidth perspective, there's not that much advantage to doing
it in the FPGA at all. It might be easier for the CPU of the computer,
but compute power is cheap, and FPGA debugging is time-intense...
Best regards,
Marcus
On 04/21/2017 05:37 PM, Shuang Hu via USRP-users wrote:
> Dear all,
>
> To make an OFDM signal transmitter, I have programmed modules in
> Verilog according to the block diagram of transmitting part of OFDM.
>
> How can I integrate my modules into the project b205 (bulit
> automatically from github)? Is there any other methods?
>
> Thank you in advance.
>
> Best regards,
> xxxs
>
>
> _______________________________________________
> 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/20170421/6b36ce47/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 21 Apr 2017 12:21:24 -0500
From: Jonathon Pendlum <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 FPGA rebuild not able to complete
Message-ID:
<cagdo0ur05gfsm30ntnxxfa0wawm63ux0hdujxem+xuesawc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
How many signals are you looking at with chipscope? Also, what CEs do you
have enabled? The default build is really tight on resources because I
wanted to have as many CEs as possible.
16G is definitely enough RAM.
On Apr 21, 2017 7:39 AM, "Jason Matusiak" <[email protected]>
wrote:
> Jonathon, I just tried this on a server with 48G of RAM and it worked for
> a fresh build, but as soon as I added chipscope, it failed with not enough
> LUTs (even though I got this to work on my PC one time). All of these
> machines are running Ubuntu 14.04 if that helps any.
>
> ~Jason
>
>
> On 04/20/2017 08:55 AM, Jason Matusiak wrote:
>
> I have 16G of RAM, I would think that would be enough, but maybe not. Do
> you have a recommendation for minimum amounts?
>
> On 04/19/2017 04:07 PM, Jonathon Pendlum wrote:
>
> Jason,
>
> How much RAM does your build machine have? Sometimes builds on machines
> with inadequate RAM will fail.
>
> On Wed, Apr 19, 2017 at 1:59 PM, Jason Matusiak via USRP-users <
> [email protected]> wrote:
>
>> I am curious how on the edge the E310 FPGA build is (particularly the
>> RFNoC one) and whether there is a known solution to completing a build?
>>
>> I was completing builds fine the other day, now it is failing for not
>> enough LUTs. I tried doing a brand new fresh build and it still fails (I
>> haven't touched the code at all). Is it so far on the edge that the tools
>> can *sometimes* complete and other times not?
>>
>> _______________________________________________
>> 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/20170421/2291fc09/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 21 Apr 2017 13:57:12 -0400
From: Jason Matusiak <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 FPGA rebuild not able to complete
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
I have one 32b register I made data only, and one 1b register I made the
trigger (I thought changing it from data/trigger would help ease things,
but no dice).
I would need to check on the RFNoC CEs, but it probably whatever the
default is (which I think when you run make E310 is the "default.v"
version, should just be the 2 CEs....).
~Jason
On 04/21/2017 01:21 PM, Jonathon Pendlum wrote:
> How many signals are you looking at with chipscope? Also, what CEs do
> you have enabled? The default build is really tight on resources
> because I wanted to have as many CEs as possible.
>
> 16G is definitely enough RAM.
>
> On Apr 21, 2017 7:39 AM, "Jason Matusiak"
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> Jonathon, I just tried this on a server with 48G of RAM and it
> worked for a fresh build, but as soon as I added chipscope, it
> failed with not enough LUTs (even though I got this to work on my
> PC one time). All of these machines are running Ubuntu 14.04 if
> that helps any.
>
> ~Jason
>
>
> On 04/20/2017 08:55 AM, Jason Matusiak wrote:
>> I have 16G of RAM, I would think that would be enough, but maybe
>> not. Do you have a recommendation for minimum amounts?
>>
>> On 04/19/2017 04:07 PM, Jonathon Pendlum wrote:
>>> Jason,
>>>
>>> How much RAM does your build machine have? Sometimes builds on
>>> machines with inadequate RAM will fail.
>>>
>>> On Wed, Apr 19, 2017 at 1:59 PM, Jason Matusiak via USRP-users
>>> <[email protected] <mailto:[email protected]>>
>>> wrote:
>>>
>>> I am curious how on the edge the E310 FPGA build is
>>> (particularly the RFNoC one) and whether there is a known
>>> solution to completing a build?
>>>
>>> I was completing builds fine the other day, now it is
>>> failing for not enough LUTs. I tried doing a brand new
>>> fresh build and it still fails (I haven't touched the code
>>> at all). Is it so far on the edge that the tools can
>>> /sometimes/ complete and other times not?
>>>
>>> _______________________________________________
>>> 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/20170421/101f9c5c/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 21 Apr 2017 13:46:03 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: [USRP-users] MSVC Versions 2012 and 2017
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Note on the MSVC versions above:
We will be deprecating support for MSVC 2012 (11.0) on the current
master branch, i.e., the upcoming 3.11 release. Its lack of support of
certain C++ features is starting to cause us headaches.
The recently released MSVC 2017 shall be officially tested and supported
sometime in the near future; we're a little dependent on Boost
officially supporting it (which they still don't do as of their latest
release). However, we're not anticipating any issues with that version
of MSVC.
For UHD 3.9 and 3.10, the following MSVC versions are and will be
supported: 2012, 2013, and 2015. This *will not change*. As long as we
are releasing UHDs starting with 3.9 and 3.10, those compilers will stay
supported.
Cheers,
Martin
------------------------------
Message: 5
Date: Fri, 21 Apr 2017 14:01:10 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: [USRP-users] [UHD] Logging features on master branch
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi all,
as announced a while back, we were about to affect changes to our
logging subsystem. We've given it a shot, and so far, we've received the
following feedback from the community:
- The only thing that people really cared about was the ability to
register custom message handlers. This was moved into the uhd::log
namespace, but the function signature to do so is also different. The
logging test case log_test.cpp includes an example on how to use the new
API.
- Main reason for customers registering custom message handlers was to
turn off logging to stdout and stderr. This is now a built-in feature;
we can control logging levels and other things at
configure/compile-time, and at runtime both via environment variables
and API calls.
- Reason number two people registered message handlers was to track if
overruns or underruns were occurring. This caught us a bit by surprise,
since it's not a reliable way to track those. A reliable way, to track
overruns is to read back the rx_metadata from a recv() call. To track
underruns, read back async messages from a tx streamer (you can do that
in a different thread even as not to interrupt your send() calls if
you're doing fast streaming). Both methods are superior to tracking
logging messages. We are not intending to further support reason number two.
- Fastpath- and regular logging are now separated. Fastpath logging
basically means printing the UOSDL characters. It can be turned on and
off, and will go to stderr with as little burden as possible on the
calling thread. Regular logging (all the rest) can be routed to wherever
you like via API calls. By default, it'll go to stderr and to a file.
It's possible that we'll tweak the logging further, but overall, we're
fairly happy with the current state and it'll most likely go into the
next release. As usual, feedback is welcome.
As a side note, when we started this, our intention was to use Boost.Log
instead of our own code (we really don't like to reinvent wheels). We
had some successes pretty soon, actually, but using Boost.Log imposed a
much larger burden on people compiling UHD themselves, so that we backed
that out again. However, our API would allow to switch to Boost.Log
should we ever want to do that. We'll possibly revisit this in the
future, but let me add that this is not a high priority for us.
Cheers,
Martin
------------------------------
Message: 6
Date: Fri, 21 Apr 2017 16:11:06 -0500
From: Jonathon Pendlum <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 FPGA rebuild not able to complete
Message-ID:
<cagdo0utqoj4tvc+bfvc-y_tyjdsfidfrugmjb6ykcnrmbtr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Try removing a CE from the default image, that should make a big difference.
On Apr 21, 2017 12:57 PM, "Jason Matusiak" <[email protected]>
wrote:
> I have one 32b register I made data only, and one 1b register I made the
> trigger (I thought changing it from data/trigger would help ease things,
> but no dice).
>
> I would need to check on the RFNoC CEs, but it probably whatever the
> default is (which I think when you run make E310 is the "default.v"
> version, should just be the 2 CEs....).
>
> ~Jason
>
> On 04/21/2017 01:21 PM, Jonathon Pendlum wrote:
>
> How many signals are you looking at with chipscope? Also, what CEs do you
> have enabled? The default build is really tight on resources because I
> wanted to have as many CEs as possible.
>
> 16G is definitely enough RAM.
>
> On Apr 21, 2017 7:39 AM, "Jason Matusiak" <[email protected]>
> wrote:
>
>> Jonathon, I just tried this on a server with 48G of RAM and it worked for
>> a fresh build, but as soon as I added chipscope, it failed with not enough
>> LUTs (even though I got this to work on my PC one time). All of these
>> machines are running Ubuntu 14.04 if that helps any.
>>
>> ~Jason
>>
>>
>> On 04/20/2017 08:55 AM, Jason Matusiak wrote:
>>
>> I have 16G of RAM, I would think that would be enough, but maybe not. Do
>> you have a recommendation for minimum amounts?
>>
>> On 04/19/2017 04:07 PM, Jonathon Pendlum wrote:
>>
>> Jason,
>>
>> How much RAM does your build machine have? Sometimes builds on machines
>> with inadequate RAM will fail.
>>
>> On Wed, Apr 19, 2017 at 1:59 PM, Jason Matusiak via USRP-users <
>> [email protected]> wrote:
>>
>>> I am curious how on the edge the E310 FPGA build is (particularly the
>>> RFNoC one) and whether there is a known solution to completing a build?
>>>
>>> I was completing builds fine the other day, now it is failing for not
>>> enough LUTs. I tried doing a brand new fresh build and it still fails (I
>>> haven't touched the code at all). Is it so far on the edge that the tools
>>> can *sometimes* complete and other times not?
>>>
>>> _______________________________________________
>>> 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/20170421/7fdd99cd/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 21 Apr 2017 21:18:16 +0000
From: "Perelman, Nathan" <[email protected]>
To: Ben Hilburn via USRP-users <[email protected]>
Subject: [USRP-users] X300 continuous overflow errors
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I'm using UHD 3.10.1.1 and a TwinRX in an X310. My application does many
repeated captures, some very short (~200000 samples), some 2-5 seconds long.
After many captures (5-10 minutes, all on the same channel), I am seeing it get
into a state where every capture errors out with an overflow (error 8) after
2-5 thousand samples have been received. This is with reusing the same RX
Streamer for every capture. Any ideas for what might be causing this or how to
debug?
-Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170421/79d328bb/attachment-0001.html>
------------------------------
Message: 8
Date: Sat, 22 Apr 2017 10:53:44 +0500
From: Usman Haider <[email protected]>
To: Steven Knudsen <[email protected]>
Cc: GNURadio Discussion List <[email protected]>, USRP-users
<[email protected]>
Subject: Re: [USRP-users] USRP command port
Message-ID:
<CANxWOTaWRLv=ZE=ohlgzwyt2v7tukjocu5pz9r3lwjurj73...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I'll check the source code. Thanks for your reply.
--
Usman
On Thu, Apr 20, 2017 at 8:36 PM, Steven Knudsen <[email protected]> wrote:
> Last I checked, the answer is no. I wanted to do the same thing last year
> and ended up modifying the source for the sink/source blocks.
>
> However, I later turned away from that approach and instead got a pointer
> to the USRP source/sink block inside one of my custom blocks at runtime and
> accessed the time commands that way.
>
> Have a look at the source and you?ll see what can and cannot be accessed
> via the command port.
>
> good luck,
>
> steven
>
>
>
> Steven Knudsen, Ph.D., P.Eng.
> www. techconficio.ca
> www.linkedin.com/in/knudstevenknudsen
>
> Du bist die Aufgabe. Kein Sch?ler weit und breit. *- Franz Kafka *
>
> On Apr 20, 2017, at 09:32, Usman Haider via USRP-users <
> [email protected]> wrote:
>
> Hi,
>
> I want to know is it possible to send the "set_time_next_pps" and
> "get_time_last_pps" commands using command port of the usrp sink block?
>
>
> --
> Usman
> _______________________________________________
> 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/20170422/cfa0cdff/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 80, Issue 22
******************************************
