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: How to debug the B210 by JTAG (Ian Buckley)
2. Re: Separate thread for each streaming channel (Rob Kossler)
3. Re: Separate thread for each streaming channel (Michael West)
4. Re: Separate thread for each streaming channel (Martin Braun)
5. Re: B210 FPGA Customize (Martin Braun)
6. Re: X310 RFNOC FFT block issue (Martin Braun)
7. Re: Compiling UHD examples (Martin Braun)
8. Re: Separate thread for each streaming channel (Michael West)
9. Re: Compiling UHD examples (Marcus M?ller)
10. Re: Separate thread for each streaming channel (Rob Kossler)
11. Re: Separate thread for each streaming channel (Marcus M?ller)
12. New test Image for E3XX (Philip Balister)
13. Adding a new peripheral to USRP E310 (Josh Monson)
----------------------------------------------------------------------
Message: 1
Date: Fri, 13 May 2016 10:25:10 -0700
From: Ian Buckley <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] How to debug the B210 by JTAG
Message-ID:
<CAM_0ocE32eLEo1=dupfntz8lp7hpf-_wrhonjx2tfbs-yhr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Generally the easiest flow for B210 FPGA development is, as Marcus said, to
let the FX3 upload the FPGA image at reset/boot. You can override the
default image using --args="fpga=FILEPATH" at the command line. To use
chipscope, just use the JTAG interface as normal, just wait until the image
has loaded before you start it running.
On Fri, May 13, 2016 at 7:37 AM, Marcus M?ller <[email protected]>
wrote:
> Hi Ddyyoo,
> have you loaded the FX3 firmware?
>
> Why are you loading the B210 image via JTAG? I've never considered doing
> so, because the B210, in totally normal operation, loads its FPGA image via
> USB.
> You should be able to load the Image normally over USB (e.g. using
> "uhd_uspr_probe --init-only") and use your favourite FPGA tools with the
> bitstream that is in the same directory as the loaded FPGA image.
>
> It seems like you try to debug something on the B210's FPGA ? which is a
> fine thing to do, we encourage customers to get to know their hardware to
> the fullest extent, but if there's something not working, we might be able
> to help you directly, if you ask :)
>
> Best regards,
> Marcus
>
>
> On 13.05.2016 03:30, ddyyoo via USRP-users wrote:
>
> 1.After the download usrp_b210_fpga.bit on JTAG? B210 can not run?What am
> I to do?
>
>
> 2.How to monitor the FPGA signal through CHIPSCOPE?
>
>
> Your help will be appreciated.
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160513/0f72fd5a/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 13 May 2016 14:03:50 -0400
From: Rob Kossler <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Separate thread for each streaming channel
Message-ID:
<CAB__hTTnAUVFS0za8zf2u4gUQ36GVB4=c7xe43whh20tgz0...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Michael,
I wasn't using 3.10, but instead 3.9.2. So, I went ahead and updated to
3.10 (which I assume has the improved threading architecture that you
mentioned). Unfortunately, I still have the same general issue: I can run
2 program instances with each instance handling 2 channels @ 100 MS/s
successfully, but if I try 1 program instance with 4 channels @ 100 MS/s, I
get overruns and other errors and several of the CPU's show that they are
pegged (using 'htop').
I then tried to see if I could get even better performance (i.e., lower CPU
usage) by running multiple streamers with each streamer having only 1
channel. It wasn't til after I implemented this (and it failed to work)
that I realized that there can only be 1 rx_streamer object at a time. So,
does this mean that my idea of running a separate thread for each channel's
data is impossible?
Rob
On Wed, May 11, 2016 at 7:33 PM, Michael West <[email protected]>
wrote:
> Hi Rob,
>
> Having multiple channels in a single streamer guarantees time alignment of
> the received data across the channels, even when there are overruns.
> Individual threads for each channel results in much better performance, but
> can cause more work in aligning the data later (especially if there are
> overruns).
>
> We are working on some improvements for UHD 3.10.0 that will definitely
> help. Namely, we added a thread to offload the receive side I/O for X310
> over 10 GbE. This removes a significant load from the rx_streamer::recv()
> call and should make it much easier for your application to achieve 4
> channels at 100 MS/s on one PC. If you are using the head of the master
> branch, that could explain the improvement.
>
> Regards,
> Michael
>
> On Wed, May 11, 2016 at 3:31 PM, Rob Kossler via USRP-users <
> [email protected]> wrote:
>
>> I am trying to capture samples to RAM drive on 4 channels (2 X310 w/
>> UBX-160) at 100 MS/s per channel. A while ago, I determined that my CPU
>> couldn't keep up at this rate. So, I modified my C++ application (loosely
>> based on rx_samples_to_file.cpp) so that I could run a separate instance on
>> each of 2 PCs with each PC linked to an X310. This involved synchronizing
>> X310 clocks and streaming start times, but seems to work fine.
>>
>> I recently discovered that if I ran both instances on the same PC (with
>> this PC connected to both X310s), I could successfully achieve 4 channels
>> at 100 MS/s on one PC. This surprised me because of my previous failure
>> using a single program instance. The primary difference I could think of
>> was that when two program instances are executing they are naturally on
>> different threads whereas my single instance pulls all samples from UHD on
>> one thread.
>>
>> With this long intro, here is my question: Given that using 2 threads to
>> pull the data from UHD seems to work better than 1 thread, would I be best
>> off taking it a step further such that I use a separate thread for each
>> channel? This would mean I would have a single channel assigned to each RX
>> streamer. Let me know any pros/cons of implementing in this way.
>>
>> Rob
>>
>> _______________________________________________
>> 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/20160513/335426e6/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 13 May 2016 11:13:11 -0700
From: Michael West <[email protected]>
To: Rob Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Separate thread for each streaming channel
Message-ID:
<cam4xkrp7k1d4vbpauway8f9qa7am94weowkksiv+mdgop+w...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Rob,
There can be multiple rx_streamer objects, but only a single multi_usrp
object. So, you could have a main thread that creates the multi_usrp
object and passes a reference to all the slave threads for them to use to
create their respective streamers.
Regards,
Michael
On Fri, May 13, 2016 at 11:03 AM, Rob Kossler <[email protected]> wrote:
> Michael,
> I wasn't using 3.10, but instead 3.9.2. So, I went ahead and updated to
> 3.10 (which I assume has the improved threading architecture that you
> mentioned). Unfortunately, I still have the same general issue: I can run
> 2 program instances with each instance handling 2 channels @ 100 MS/s
> successfully, but if I try 1 program instance with 4 channels @ 100 MS/s, I
> get overruns and other errors and several of the CPU's show that they are
> pegged (using 'htop').
>
> I then tried to see if I could get even better performance (i.e., lower
> CPU usage) by running multiple streamers with each streamer having only 1
> channel. It wasn't til after I implemented this (and it failed to work)
> that I realized that there can only be 1 rx_streamer object at a time. So,
> does this mean that my idea of running a separate thread for each channel's
> data is impossible?
> Rob
>
>
> On Wed, May 11, 2016 at 7:33 PM, Michael West <[email protected]>
> wrote:
>
>> Hi Rob,
>>
>> Having multiple channels in a single streamer guarantees time alignment
>> of the received data across the channels, even when there are overruns.
>> Individual threads for each channel results in much better performance, but
>> can cause more work in aligning the data later (especially if there are
>> overruns).
>>
>> We are working on some improvements for UHD 3.10.0 that will definitely
>> help. Namely, we added a thread to offload the receive side I/O for X310
>> over 10 GbE. This removes a significant load from the rx_streamer::recv()
>> call and should make it much easier for your application to achieve 4
>> channels at 100 MS/s on one PC. If you are using the head of the master
>> branch, that could explain the improvement.
>>
>> Regards,
>> Michael
>>
>> On Wed, May 11, 2016 at 3:31 PM, Rob Kossler via USRP-users <
>> [email protected]> wrote:
>>
>>> I am trying to capture samples to RAM drive on 4 channels (2 X310 w/
>>> UBX-160) at 100 MS/s per channel. A while ago, I determined that my CPU
>>> couldn't keep up at this rate. So, I modified my C++ application (loosely
>>> based on rx_samples_to_file.cpp) so that I could run a separate instance on
>>> each of 2 PCs with each PC linked to an X310. This involved synchronizing
>>> X310 clocks and streaming start times, but seems to work fine.
>>>
>>> I recently discovered that if I ran both instances on the same PC (with
>>> this PC connected to both X310s), I could successfully achieve 4 channels
>>> at 100 MS/s on one PC. This surprised me because of my previous failure
>>> using a single program instance. The primary difference I could think of
>>> was that when two program instances are executing they are naturally on
>>> different threads whereas my single instance pulls all samples from UHD on
>>> one thread.
>>>
>>> With this long intro, here is my question: Given that using 2 threads to
>>> pull the data from UHD seems to work better than 1 thread, would I be best
>>> off taking it a step further such that I use a separate thread for each
>>> channel? This would mean I would have a single channel assigned to each RX
>>> streamer. Let me know any pros/cons of implementing in this way.
>>>
>>> Rob
>>>
>>> _______________________________________________
>>> 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/20160513/5f22cb37/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 13 May 2016 11:23:26 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Separate thread for each streaming channel
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
This would definitely work; one thing I would like to point out for the
records is that you won't get aligned streams this way. If you're doing
MIMO processing or something similar, you only want a single streamer,
with N channels.
Cheers,
M
On 05/13/2016 11:13 AM, Michael West via USRP-users wrote:
> Hi Rob,
>
> There can be multiple rx_streamer objects, but only a single multi_usrp
> object. So, you could have a main thread that creates the multi_usrp
> object and passes a reference to all the slave threads for them to use
> to create their respective streamers.
>
> Regards,
> Michael
>
> On Fri, May 13, 2016 at 11:03 AM, Rob Kossler <[email protected]
> <mailto:[email protected]>> wrote:
>
> Michael,
> I wasn't using 3.10, but instead 3.9.2. So, I went ahead and
> updated to 3.10 (which I assume has the improved threading
> architecture that you mentioned). Unfortunately, I still have the
> same general issue: I can run 2 program instances with each instance
> handling 2 channels @ 100 MS/s successfully, but if I try 1 program
> instance with 4 channels @ 100 MS/s, I get overruns and other errors
> and several of the CPU's show that they are pegged (using 'htop').
>
> I then tried to see if I could get even better performance (i.e.,
> lower CPU usage) by running multiple streamers with each streamer
> having only 1 channel. It wasn't til after I implemented this (and
> it failed to work) that I realized that there can only be 1
> rx_streamer object at a time. So, does this mean that my idea of
> running a separate thread for each channel's data is impossible?
> Rob
>
>
> On Wed, May 11, 2016 at 7:33 PM, Michael West
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi Rob,
>
> Having multiple channels in a single streamer guarantees time
> alignment of the received data across the channels, even when
> there are overruns. Individual threads for each channel results
> in much better performance, but can cause more work in aligning
> the data later (especially if there are overruns).
>
> We are working on some improvements for UHD 3.10.0 that will
> definitely help. Namely, we added a thread to offload the
> receive side I/O for X310 over 10 GbE. This removes a
> significant load from the rx_streamer::recv() call and should
> make it much easier for your application to achieve 4 channels
> at 100 MS/s on one PC. If you are using the head of the master
> branch, that could explain the improvement.
>
> Regards,
> Michael
>
> On Wed, May 11, 2016 at 3:31 PM, Rob Kossler via USRP-users
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> I am trying to capture samples to RAM drive on 4 channels (2
> X310 w/ UBX-160) at 100 MS/s per channel. A while ago, I
> determined that my CPU couldn't keep up at this rate. So, I
> modified my C++ application (loosely based on
> rx_samples_to_file.cpp) so that I could run a separate
> instance on each of 2 PCs with each PC linked to an X310.
> This involved synchronizing X310 clocks and streaming start
> times, but seems to work fine.
>
> I recently discovered that if I ran both instances on the
> same PC (with this PC connected to both X310s), I could
> successfully achieve 4 channels at 100 MS/s on one PC. This
> surprised me because of my previous failure using a single
> program instance. The primary difference I could think of
> was that when two program instances are executing they are
> naturally on different threads whereas my single instance
> pulls all samples from UHD on one thread.
>
> With this long intro, here is my question: Given that using
> 2 threads to pull the data from UHD seems to work better
> than 1 thread, would I be best off taking it a step further
> such that I use a separate thread for each channel? This
> would mean I would have a single channel assigned to each RX
> streamer. Let me know any pros/cons of implementing in this
> way.
>
> Rob
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[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: Fri, 13 May 2016 11:29:00 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B210 FPGA Customize
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Sumit,
RFNoC is not available on the B210. To modify the FPGA source, you will
need to dive into the usrp3/top/b200 directory in the FPGA repository.
Cheers,
Martin
On 05/11/2016 04:53 AM, Sumit Kumar via USRP-users wrote:
> Hi,
>
> I would like to know which file to edit if I want to do include my own
> instructions in the FPGA.
>
> I already have successfully compiled the FPGA images and tested them.
>
> In order to achieve time constraints of SIFS and send ACK and NACK, I
> have to deploy some of the mechanisms on the FPGA.
>
> Is there any possibility that RFNoC can be used for B210 ?
>
>
> --
> --
> Sumit kumar
> Doctoral Student, UPMC
> Eurecom, BIOT
> France
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 6
Date: Fri, 13 May 2016 11:34:38 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] X310 RFNOC FFT block issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 05/09/2016 10:48 AM, James Wagner via USRP-users wrote:
> Right, so finally tracked down the problem. apparently the maximum frame
> size was violated by a spp of 512 on the X310. so the FFT was able to
> run on the E310 but not on the X310. apparently the system fails rather
> silently. when i set the SPP to 256 this time it worked( I tried this
> earlier but this was obscured by the other issues).
>
> This brings one interesting question to mind. Does RFNOC conflate
> processing block sizes and transfer sizes?
Typically, they're the same, if that was your question. So, if you go
host -> fft -> <somewhere else>, then the host -> fft connection will
include a transport (e.g. ethernet for X310), and it'll packet sizes
that match the FFT.
Now, that's not optimal for small FFT sizes, and it breaks transports
for larger-than-MTU sizes. We're working on fixing that, but we do have
a bunch of other things in the pipeline first.
Cheers,
Martin
------------------------------
Message: 7
Date: Fri, 13 May 2016 11:44:03 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Compiling UHD examples
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
BTW, we ship a standalone example that shows how to use CMake etc. to
link against UHD in `host/examples/init_usrp`.
Cheers,
M
On 05/07/2016 02:37 PM, Marcus M?ller via USRP-users wrote:
> Hi Sumit!
>
> No, "examples" can't be built as an out-of-tree Cmake project
> you'll have to do
>
> cd ~/Downloads/uhd/host/
> mkdir build
> cd build
> cmake ..
> make
>
> to build UHD /including/ the examples.
>
> Best regards,
> Marcus
>
> On 07.05.2016 23:00, Sumit Kumar wrote:
>> Hello Marcus,
>>
>> Yes I will definitely use the build system. But my first attempt gave
>> me this unfortunately :-/
>>
>> For this particular issue I am pasting the error message.
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> fourmi@fourmi:~/Downloads/uhd/host/examples$ mkdir build && cd build
>> fourmi@fourmi:~/Downloads/uhd/host/examples/build$ cmake ..
>> -- The C compiler identification is GNU 4.8.4
>> -- The CXX compiler identification is GNU 4.8.4
>> -- Check for working C compiler: /usr/bin/cc
>> -- Check for working C compiler: /usr/bin/cc -- works
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Check for working CXX compiler: /usr/bin/c++
>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> CMake Error at CMakeLists.txt:50 (UHD_INSTALL):
>> Unknown CMake command "UHD_INSTALL".
>>
>>
>> CMake Warning (dev) in CMakeLists.txt:
>> No cmake_minimum_required command is present. A line of code such as
>>
>> cmake_minimum_required(VERSION 2.8)
>>
>> should be added at the top of the file. The version specified may
>> be lower
>> if you wish to support older CMake versions for this project. For more
>> information run "cmake --help-policy CMP0000".
>> This warning is for project developers. Use -Wno-dev to suppress it.
>>
>> -- Configuring incomplete, errors occurred!
>> See also
>> "/home/fourmi/Downloads/uhd/host/examples/build/CMakeFiles/CMakeOutput.log".
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> On Fri, May 6, 2016 at 10:00 AM, Marcus M?ller
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> Hi Sumit,
>>
>> really, discard the idea of building a large project without the
>> help of its build system.
>>
>> Instead, get Cmake to work.
>> Now, I've never seen this problem you're mentioning:
>>> Unknown CMake command "UHD_INSTALL".
>> Can you give a bit more context to that line? Usually, CMake
>> points out the file and line where something "bad" happened.
>> What version of UHD are you building?
>> How did you get that UHD source tree?
>> UHD_INSTALL is in Modules/UHDComponent.cmake, so it should
>> definitely be found by any CMake version.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 06.05.2016 06:08, Sumit Kumar via USRP-users wrote:
>>> I edited some parts of rx_timed_samples.cpp and tried to compile
>>> it.
>>>
>>> First I tried (inside /host/build)
>>>
>>> cmake ..
>>> and this error came up
>>>
>>> Unknown CMake command "UHD_INSTALL".
>>>
>>> Then I tried doing other way round without cmake. I normally use
>>> it to compile my other files of cpp
>>>
>>> g ++ uhdd.cpp -luhd -o rx
>>>
>>> But it threw whole lot of linker errors.
>>>
>>> Here is a snapshot
>>>
>>> /tmp/ccNJGg4e.o: In function `_main(int, char**)':
>>> timeds.cpp:(.text+0x159): undefined reference to
>>> `boost::program_options::options_description::m_default_line_length'
>>> timeds.cpp:(.text+0x164): undefined reference to
>>> `boost::program_options::options_description::m_default_line_length'
>>> timeds.cpp:(.text+0x1a9): undefined reference to
>>>
>>> `boost::program_options::options_description::options_description(std::string
>>> const&, unsigned int, unsigned int)'
>>> timeds.cpp:(.text+0x35d): undefined reference to
>>> `boost::program_options::options_description::add_options()'
>>>
>>> It seems, it is not able to find the boost libraries.
>>>
>>> What I am missing ?
>>>
>>> ** These errors dint come for my other uhd based files where I
>>> dint use boost libraries.
>>>
>>>
>>>
>>> --
>>> --
>>> Sumit Kumar,
>>> Doctoral student, Upms
>>> Eurecom, BIOT
>>> France
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>
>> --
>> --
>> Sumit kumar
>> Doctoral Student, UPMC
>> Eurecom, BIOT
>> France
>>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 8
Date: Fri, 13 May 2016 11:52:04 -0700
From: Michael West <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Separate thread for each streaming channel
Message-ID:
<CAM4xKrp1Ri9P610=ubtnei1qqps4gejhajwxw8e7gxfufor...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Rob,
There can only be one streamer for a given channel, but there can be
multiple streamers. I have done it several times.
The manual should state that if a channel is included in one streamer, that
streamer must be destroyed before another is created that uses that
channel. But I think that kind of wording might make some people go
cross-eyed. :-)
Regards,
Michael
On Fri, May 13, 2016 at 11:23 AM, Martin Braun via USRP-users <
[email protected]> wrote:
> This would definitely work; one thing I would like to point out for the
> records is that you won't get aligned streams this way. If you're doing
> MIMO processing or something similar, you only want a single streamer,
> with N channels.
>
> Cheers,
> M
>
> On 05/13/2016 11:13 AM, Michael West via USRP-users wrote:
> > Hi Rob,
> >
> > There can be multiple rx_streamer objects, but only a single multi_usrp
> > object. So, you could have a main thread that creates the multi_usrp
> > object and passes a reference to all the slave threads for them to use
> > to create their respective streamers.
> >
> > Regards,
> > Michael
> >
> > On Fri, May 13, 2016 at 11:03 AM, Rob Kossler <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > Michael,
> > I wasn't using 3.10, but instead 3.9.2. So, I went ahead and
> > updated to 3.10 (which I assume has the improved threading
> > architecture that you mentioned). Unfortunately, I still have the
> > same general issue: I can run 2 program instances with each instance
> > handling 2 channels @ 100 MS/s successfully, but if I try 1 program
> > instance with 4 channels @ 100 MS/s, I get overruns and other errors
> > and several of the CPU's show that they are pegged (using 'htop').
> >
> > I then tried to see if I could get even better performance (i.e.,
> > lower CPU usage) by running multiple streamers with each streamer
> > having only 1 channel. It wasn't til after I implemented this (and
> > it failed to work) that I realized that there can only be 1
> > rx_streamer object at a time. So, does this mean that my idea of
> > running a separate thread for each channel's data is impossible?
> > Rob
> >
> >
> > On Wed, May 11, 2016 at 7:33 PM, Michael West
> > <[email protected] <mailto:[email protected]>> wrote:
> >
> > Hi Rob,
> >
> > Having multiple channels in a single streamer guarantees time
> > alignment of the received data across the channels, even when
> > there are overruns. Individual threads for each channel results
> > in much better performance, but can cause more work in aligning
> > the data later (especially if there are overruns).
> >
> > We are working on some improvements for UHD 3.10.0 that will
> > definitely help. Namely, we added a thread to offload the
> > receive side I/O for X310 over 10 GbE. This removes a
> > significant load from the rx_streamer::recv() call and should
> > make it much easier for your application to achieve 4 channels
> > at 100 MS/s on one PC. If you are using the head of the master
> > branch, that could explain the improvement.
> >
> > Regards,
> > Michael
> >
> > On Wed, May 11, 2016 at 3:31 PM, Rob Kossler via USRP-users
> > <[email protected] <mailto:[email protected]>>
> > wrote:
> >
> > I am trying to capture samples to RAM drive on 4 channels (2
> > X310 w/ UBX-160) at 100 MS/s per channel. A while ago, I
> > determined that my CPU couldn't keep up at this rate. So, I
> > modified my C++ application (loosely based on
> > rx_samples_to_file.cpp) so that I could run a separate
> > instance on each of 2 PCs with each PC linked to an X310.
> > This involved synchronizing X310 clocks and streaming start
> > times, but seems to work fine.
> >
> > I recently discovered that if I ran both instances on the
> > same PC (with this PC connected to both X310s), I could
> > successfully achieve 4 channels at 100 MS/s on one PC. This
> > surprised me because of my previous failure using a single
> > program instance. The primary difference I could think of
> > was that when two program instances are executing they are
> > naturally on different threads whereas my single instance
> > pulls all samples from UHD on one thread.
> >
> > With this long intro, here is my question: Given that using
> > 2 threads to pull the data from UHD seems to work better
> > than 1 thread, would I be best off taking it a step further
> > such that I use a separate thread for each channel? This
> > would mean I would have a single channel assigned to each RX
> > streamer. Let me know any pros/cons of implementing in this
> > way.
> >
> > Rob
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected] <mailto:
> [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/20160513/b86ff206/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 13 May 2016 20:55:14 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Compiling UHD examples
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
That's right; I should have mentioned that.
You could copy over the files that make up your example, and include
them in the CMakeLists.txt in your copy of init_usrp .
In fact, when I write a demo/example program, that's pretty often what I do.
Best regards,
Marcus
On 13.05.2016 20:44, Martin Braun via USRP-users wrote:
> BTW, we ship a standalone example that shows how to use CMake etc. to
> link against UHD in `host/examples/init_usrp`.
>
> Cheers,
> M
>
> On 05/07/2016 02:37 PM, Marcus M?ller via USRP-users wrote:
>> Hi Sumit!
>>
>> No, "examples" can't be built as an out-of-tree Cmake project
>> you'll have to do
>>
>> cd ~/Downloads/uhd/host/
>> mkdir build
>> cd build
>> cmake ..
>> make
>>
>> to build UHD /including/ the examples.
>>
>> Best regards,
>> Marcus
>>
>> On 07.05.2016 23:00, Sumit Kumar wrote:
>>> Hello Marcus,
>>>
>>> Yes I will definitely use the build system. But my first attempt gave
>>> me this unfortunately :-/
>>>
>>> For this particular issue I am pasting the error message.
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> fourmi@fourmi:~/Downloads/uhd/host/examples$ mkdir build && cd build
>>> fourmi@fourmi:~/Downloads/uhd/host/examples/build$ cmake ..
>>> -- The C compiler identification is GNU 4.8.4
>>> -- The CXX compiler identification is GNU 4.8.4
>>> -- Check for working C compiler: /usr/bin/cc
>>> -- Check for working C compiler: /usr/bin/cc -- works
>>> -- Detecting C compiler ABI info
>>> -- Detecting C compiler ABI info - done
>>> -- Check for working CXX compiler: /usr/bin/c++
>>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>>> -- Detecting CXX compiler ABI info
>>> -- Detecting CXX compiler ABI info - done
>>> CMake Error at CMakeLists.txt:50 (UHD_INSTALL):
>>> Unknown CMake command "UHD_INSTALL".
>>>
>>>
>>> CMake Warning (dev) in CMakeLists.txt:
>>> No cmake_minimum_required command is present. A line of code such as
>>>
>>> cmake_minimum_required(VERSION 2.8)
>>>
>>> should be added at the top of the file. The version specified may
>>> be lower
>>> if you wish to support older CMake versions for this project. For more
>>> information run "cmake --help-policy CMP0000".
>>> This warning is for project developers. Use -Wno-dev to suppress it.
>>>
>>> -- Configuring incomplete, errors occurred!
>>> See also
>>> "/home/fourmi/Downloads/uhd/host/examples/build/CMakeFiles/CMakeOutput.log".
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> On Fri, May 6, 2016 at 10:00 AM, Marcus M?ller
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> Hi Sumit,
>>>
>>> really, discard the idea of building a large project without the
>>> help of its build system.
>>>
>>> Instead, get Cmake to work.
>>> Now, I've never seen this problem you're mentioning:
>>>> Unknown CMake command "UHD_INSTALL".
>>> Can you give a bit more context to that line? Usually, CMake
>>> points out the file and line where something "bad" happened.
>>> What version of UHD are you building?
>>> How did you get that UHD source tree?
>>> UHD_INSTALL is in Modules/UHDComponent.cmake, so it should
>>> definitely be found by any CMake version.
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 06.05.2016 06:08, Sumit Kumar via USRP-users wrote:
>>>> I edited some parts of rx_timed_samples.cpp and tried to compile
>>>> it.
>>>>
>>>> First I tried (inside /host/build)
>>>>
>>>> cmake ..
>>>> and this error came up
>>>>
>>>> Unknown CMake command "UHD_INSTALL".
>>>>
>>>> Then I tried doing other way round without cmake. I normally use
>>>> it to compile my other files of cpp
>>>>
>>>> g ++ uhdd.cpp -luhd -o rx
>>>>
>>>> But it threw whole lot of linker errors.
>>>>
>>>> Here is a snapshot
>>>>
>>>> /tmp/ccNJGg4e.o: In function `_main(int, char**)':
>>>> timeds.cpp:(.text+0x159): undefined reference to
>>>> `boost::program_options::options_description::m_default_line_length'
>>>> timeds.cpp:(.text+0x164): undefined reference to
>>>> `boost::program_options::options_description::m_default_line_length'
>>>> timeds.cpp:(.text+0x1a9): undefined reference to
>>>>
>>>> `boost::program_options::options_description::options_description(std::string
>>>> const&, unsigned int, unsigned int)'
>>>> timeds.cpp:(.text+0x35d): undefined reference to
>>>> `boost::program_options::options_description::add_options()'
>>>>
>>>> It seems, it is not able to find the boost libraries.
>>>>
>>>> What I am missing ?
>>>>
>>>> ** These errors dint come for my other uhd based files where I
>>>> dint use boost libraries.
>>>>
>>>>
>>>>
>>>> --
>>>> --
>>>> Sumit Kumar,
>>>> Doctoral student, Upms
>>>> Eurecom, BIOT
>>>> France
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>>
>>>
>>> --
>>> --
>>> Sumit kumar
>>> Doctoral Student, UPMC
>>> Eurecom, BIOT
>>> France
>>>
>>
>>
>> _______________________________________________
>> 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: 10
Date: Fri, 13 May 2016 15:34:36 -0400
From: Rob Kossler <[email protected]>
To: Michael West <[email protected]>
Cc: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Separate thread for each streaming channel
Message-ID:
<cab__htsm_th_wrm4kx2zqf_wt9q_nddqu0+pxsadbamqvzr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Martin,
Just to be clear. If I have the clocks for each motherboard sync-ed AND I
use the same start time for each of my streamers AND I verify the metadata
of the first sample coming off the stream, then shouldn't the streams be
aligned perfectly for MIMO operation?
Rob
On Fri, May 13, 2016 at 2:52 PM, Michael West via USRP-users <
[email protected]> wrote:
> Hi Rob,
>
> There can only be one streamer for a given channel, but there can be
> multiple streamers. I have done it several times.
>
> The manual should state that if a channel is included in one streamer,
> that streamer must be destroyed before another is created that uses that
> channel. But I think that kind of wording might make some people go
> cross-eyed. :-)
>
> Regards,
> Michael
>
> On Fri, May 13, 2016 at 11:23 AM, Martin Braun via USRP-users <
> [email protected]> wrote:
>
>> This would definitely work; one thing I would like to point out for the
>> records is that you won't get aligned streams this way. If you're doing
>> MIMO processing or something similar, you only want a single streamer,
>> with N channels.
>>
>> Cheers,
>> M
>>
>> On 05/13/2016 11:13 AM, Michael West via USRP-users wrote:
>> > Hi Rob,
>> >
>> > There can be multiple rx_streamer objects, but only a single multi_usrp
>> > object. So, you could have a main thread that creates the multi_usrp
>> > object and passes a reference to all the slave threads for them to use
>> > to create their respective streamers.
>> >
>> > Regards,
>> > Michael
>> >
>> > On Fri, May 13, 2016 at 11:03 AM, Rob Kossler <[email protected]
>> > <mailto:[email protected]>> wrote:
>> >
>> > Michael,
>> > I wasn't using 3.10, but instead 3.9.2. So, I went ahead and
>> > updated to 3.10 (which I assume has the improved threading
>> > architecture that you mentioned). Unfortunately, I still have the
>> > same general issue: I can run 2 program instances with each instance
>> > handling 2 channels @ 100 MS/s successfully, but if I try 1 program
>> > instance with 4 channels @ 100 MS/s, I get overruns and other errors
>> > and several of the CPU's show that they are pegged (using 'htop').
>> >
>> > I then tried to see if I could get even better performance (i.e.,
>> > lower CPU usage) by running multiple streamers with each streamer
>> > having only 1 channel. It wasn't til after I implemented this (and
>> > it failed to work) that I realized that there can only be 1
>> > rx_streamer object at a time. So, does this mean that my idea of
>> > running a separate thread for each channel's data is impossible?
>> > Rob
>> >
>> >
>> > On Wed, May 11, 2016 at 7:33 PM, Michael West
>> > <[email protected] <mailto:[email protected]>> wrote:
>> >
>> > Hi Rob,
>> >
>> > Having multiple channels in a single streamer guarantees time
>> > alignment of the received data across the channels, even when
>> > there are overruns. Individual threads for each channel results
>> > in much better performance, but can cause more work in aligning
>> > the data later (especially if there are overruns).
>> >
>> > We are working on some improvements for UHD 3.10.0 that will
>> > definitely help. Namely, we added a thread to offload the
>> > receive side I/O for X310 over 10 GbE. This removes a
>> > significant load from the rx_streamer::recv() call and should
>> > make it much easier for your application to achieve 4 channels
>> > at 100 MS/s on one PC. If you are using the head of the master
>> > branch, that could explain the improvement.
>> >
>> > Regards,
>> > Michael
>> >
>> > On Wed, May 11, 2016 at 3:31 PM, Rob Kossler via USRP-users
>> > <[email protected] <mailto:[email protected]
>> >>
>> > wrote:
>> >
>> > I am trying to capture samples to RAM drive on 4 channels (2
>> > X310 w/ UBX-160) at 100 MS/s per channel. A while ago, I
>> > determined that my CPU couldn't keep up at this rate. So, I
>> > modified my C++ application (loosely based on
>> > rx_samples_to_file.cpp) so that I could run a separate
>> > instance on each of 2 PCs with each PC linked to an X310.
>> > This involved synchronizing X310 clocks and streaming start
>> > times, but seems to work fine.
>> >
>> > I recently discovered that if I ran both instances on the
>> > same PC (with this PC connected to both X310s), I could
>> > successfully achieve 4 channels at 100 MS/s on one PC. This
>> > surprised me because of my previous failure using a single
>> > program instance. The primary difference I could think of
>> > was that when two program instances are executing they are
>> > naturally on different threads whereas my single instance
>> > pulls all samples from UHD on one thread.
>> >
>> > With this long intro, here is my question: Given that using
>> > 2 threads to pull the data from UHD seems to work better
>> > than 1 thread, would I be best off taking it a step further
>> > such that I use a separate thread for each channel? This
>> > would mean I would have a single channel assigned to each RX
>> > streamer. Let me know any pros/cons of implementing in this
>> > way.
>> >
>> > Rob
>> >
>> > _______________________________________________
>> > USRP-users mailing list
>> > [email protected] <mailto:
>> [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
>>
>
>
> _______________________________________________
> 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/20160513/c95f066b/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 13 May 2016 22:05:31 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Separate thread for each streaming channel
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Rob,
Michael's point was that even if bad things?happen, the streams of a
single streamer stay aligned.
But yes, if you
1. use exactly one multi_usrp,
2. spawn multiple streamers,
3. start them at the same time,
4. pay attention not to tune the frontends at different times, and
5. avoid any underruns/overruns
Then your streams should be aligned.
Best regards,
Marcus
On 13.05.2016 21:34, Rob Kossler via USRP-users wrote:
> Martin,
> Just to be clear. If I have the clocks for each motherboard sync-ed
> AND I use the same start time for each of my streamers AND I verify
> the metadata of the first sample coming off the stream, then shouldn't
> the streams be aligned perfectly for MIMO operation?
>
> Rob
>
> On Fri, May 13, 2016 at 2:52 PM, Michael West via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi Rob,
>
> There can only be one streamer for a given channel, but there can
> be multiple streamers. I have done it several times.
>
> The manual should state that if a channel is included in one
> streamer, that streamer must be destroyed before another is
> created that uses that channel. But I think that kind of wording
> might make some people go cross-eyed. :-)
>
> Regards,
> Michael
>
> On Fri, May 13, 2016 at 11:23 AM, Martin Braun via USRP-users
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> This would definitely work; one thing I would like to point
> out for the
> records is that you won't get aligned streams this way. If
> you're doing
> MIMO processing or something similar, you only want a single
> streamer,
> with N channels.
>
> Cheers,
> M
>
> On 05/13/2016 11:13 AM, Michael West via USRP-users wrote:
> > Hi Rob,
> >
> > There can be multiple rx_streamer objects, but only a single
> multi_usrp
> > object. So, you could have a main thread that creates the
> multi_usrp
> > object and passes a reference to all the slave threads for
> them to use
> > to create their respective streamers.
> >
> > Regards,
> > Michael
> >
> > On Fri, May 13, 2016 at 11:03 AM, Rob Kossler
> <[email protected] <mailto:[email protected]>
> > <mailto:[email protected] <mailto:[email protected]>>> wrote:
> >
> > Michael,
> > I wasn't using 3.10, but instead 3.9.2. So, I went
> ahead and
> > updated to 3.10 (which I assume has the improved threading
> > architecture that you mentioned). Unfortunately, I
> still have the
> > same general issue: I can run 2 program instances with
> each instance
> > handling 2 channels @ 100 MS/s successfully, but if I
> try 1 program
> > instance with 4 channels @ 100 MS/s, I get overruns and
> other errors
> > and several of the CPU's show that they are pegged
> (using 'htop').
> >
> > I then tried to see if I could get even better
> performance (i.e.,
> > lower CPU usage) by running multiple streamers with each
> streamer
> > having only 1 channel. It wasn't til after I
> implemented this (and
> > it failed to work) that I realized that there can only be 1
> > rx_streamer object at a time. So, does this mean that
> my idea of
> > running a separate thread for each channel's data is
> impossible?
> > Rob
> >
> >
> > On Wed, May 11, 2016 at 7:33 PM, Michael West
> > <[email protected] <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>> wrote:
> >
> > Hi Rob,
> >
> > Having multiple channels in a single streamer
> guarantees time
> > alignment of the received data across the channels,
> even when
> > there are overruns. Individual threads for each
> channel results
> > in much better performance, but can cause more work
> in aligning
> > the data later (especially if there are overruns).
> >
> > We are working on some improvements for UHD 3.10.0
> that will
> > definitely help. Namely, we added a thread to
> offload the
> > receive side I/O for X310 over 10 GbE. This removes a
> > significant load from the rx_streamer::recv() call
> and should
> > make it much easier for your application to achieve
> 4 channels
> > at 100 MS/s on one PC. If you are using the head of
> the master
> > branch, that could explain the improvement.
> >
> > Regards,
> > Michael
> >
> > On Wed, May 11, 2016 at 3:31 PM, Rob Kossler via
> USRP-users
> > <[email protected]
> <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>>
> > wrote:
> >
> > I am trying to capture samples to RAM drive on 4
> channels (2
> > X310 w/ UBX-160) at 100 MS/s per channel. A
> while ago, I
> > determined that my CPU couldn't keep up at this
> rate. So, I
> > modified my C++ application (loosely based on
> > rx_samples_to_file.cpp) so that I could run a
> separate
> > instance on each of 2 PCs with each PC linked to
> an X310.
> > This involved synchronizing X310 clocks and
> streaming start
> > times, but seems to work fine.
> >
> > I recently discovered that if I ran both
> instances on the
> > same PC (with this PC connected to both X310s),
> I could
> > successfully achieve 4 channels at 100 MS/s on
> one PC. This
> > surprised me because of my previous failure
> using a single
> > program instance. The primary difference I could
> think of
> > was that when two program instances are
> executing they are
> > naturally on different threads whereas my single
> instance
> > pulls all samples from UHD on one thread.
> >
> > With this long intro, here is my question: Given
> that using
> > 2 threads to pull the data from UHD seems to
> work better
> > than 1 thread, would I be best off taking it a
> step further
> > such that I use a separate thread for each
> channel? This
> > would mean I would have a single channel
> assigned to each RX
> > streamer. Let me know any pros/cons of
> implementing in this
> > way.
> >
> > Rob
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> <mailto:[email protected]>
> <mailto:[email protected]
> <mailto:[email protected]>>
> >
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected] <mailto:[email protected]>
> >
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[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/20160513/97d89436/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 13 May 2016 18:20:11 -0400
From: Philip Balister <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] New test Image for E3XX
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
I made a new set of images for the E3XX series wuth uhd-3.9.4 and some
other updates (mostly CVE's in the base Linux build)
The images are here:
http://files.ettus.com/e3xx_images/beta/fido-test-2016.05/
The sg1 and sg3 directories are the speed grade of the zynq in the unit.
In general most people will have sg1 at the moment.
A bit about naming, if they are in the beta directory, there will be a
manifest you can use to rebuild the image yourself. For this case see;
https://github.com/EttusResearch/e300-manifest/tree/fido-test-2016.05
If something shows up in the alpha directory, I do not promise to ahve a
manifest available to help rebuild. These would be quick tests etc.
Philip
------------------------------
Message: 13
Date: Sat, 14 May 2016 07:26:54 -0700 (PDT)
From: Josh Monson <[email protected]>
To: [email protected]
Subject: [USRP-users] Adding a new peripheral to USRP E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi,
I?d like to add an additional hardware peripheral (to the ARM) into the
programmable logic of our USRP E310 board. What steps to I need to take to
ensure that the linux device tree is updated and properly compiled into the
file system?
Thanks,
Josh
------------------------------
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 69, Issue 14
******************************************
