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: RFNoC Installation Problems (Nicolas Cuervo Benavides)
2. Re: RFNoC Installation Problems (Neel Pandeya)
3. Re: RFNoC Installation Problems (Yin, Charles - 0665 - MITLL)
4. Re: uhd unix drivers (Martin Braun)
5. Re: B200mini/B205mini FPGA Acceleration (Martin Braun)
6. Re: B200mini/B205mini FPGA Acceleration (Robin Coxe)
7. Re: B200mini/B205mini FPGA Acceleration (Austin Anderson)
8. Size of TX Buffer on N210 (Dave NotTelling)
9. Re: How do I turn off one of the radios in rfnoc-radio-redo
and how can I use the debug UART? (Swanson, Craig)
10. UHD: 44 (Jasuja, Ishwar)
11. Re: UHD: 44 (Marcus D. Leech)
12. Re: How do I turn off one of the radios in rfnoc-radio-redo
and how can I use the debug UART? (Jonathon Pendlum)
13. Re: Size of TX Buffer on N210 (Martin Braun)
14. Re: UHD: 44 (Jasuja, Ishwar)
15. Re: Size of TX Buffer on N210 (Dave NotTelling)
16. Re: UHD: 44 (Marcus D. Leech)
17. Re: UHD: 44 (Jasuja, Ishwar)
18. Re: UHD: 44 (Marcus D. Leech)
19. S printouts and then either U printouts (and fails/stops
transmitting) or seg fault with 4 USRPs (Pavan Yedavalli)
20. Re: Compiling new firmware on N210 (Henrique Bucher)
21. Re: UHD: 44 (Jasuja, Ishwar)
22. Re: S printouts and then either U printouts (and fails/stops
transmitting) or seg fault with 4 USRPs (Marcus D. Leech)
23. Re: Compiling new firmware on N210 (Marcus D. Leech)
24. Re: Compiling new firmware on N210 (Marcus D. Leech)
25. Re: Size of TX Buffer on N210 (Martin Braun)
26. Re: UHD: 44 (Marcus D. Leech)
27. Re: Compiling new firmware on N210 (Nick Foster)
28. Re: UHD: 44 (Jasuja, Ishwar)
29. Re: UHD: 44 (Marcus M?ller)
30. Sampling with more than 50 MSps on N210 (Vladica Sark)
31. Re: Sampling with more than 50 MSps on N210 (Marcus M?ller)
32. Re: Sampling with more than 50 MSps on N210 (Vladica Sark)
33. Re: Sampling with more than 50 MSps on N210 (Vladica Sark)
34. Re: Sampling with more than 50 MSps on N210 (Marcus M?ller)
35. Re: AXI_FIR encrypted IP in Modelsim protected mode when
running noc_block_fir_filter from my own cocotb testbench
(Swanson, Craig)
36. Re: Sampling with more than 50 MSps on N210 (Vladica Sark)
37. Re: RFNoC Installation Problems (Yin, Charles - 0665 - MITLL)
38. Re: N200 RX center frequency changes ignored (Francisco Albani)
39. Re: N200 RX center frequency changes ignored (Marcus M?ller)
40. Re: N200 RX center frequency changes ignored ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Wed, 22 Jun 2016 09:07:46 -0700
From: Nicolas Cuervo Benavides <[email protected]>
To: "Yin, Charles - 0665 - MITLL" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC Installation Problems
Message-ID:
<CAG-Bkha6vy8PbgLGuRJdZJcn8ak5CGQ6WEQnMaYm=m6uz4i...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Charles,
Are you running your installation into a Virtual Machine? It appears that
you are running out of virtual memory. You can overcome that by adding some
memory to your swap. Please tell us if it works.
Regards,
Nicolas
On Tue, Jun 21, 2016 at 1:24 PM, Yin, Charles - 0665 - MITLL via USRP-users
<[email protected]> wrote:
> Hi Neel and Jonathon,
>
>
>
> I am having problems building RFNoC with GNU Radio. I am using GNU Radio
> Version 3.9.7.2 on Ubuntu 14.04. You mentioned to check for the swig
> package, and I can confirm that it is there. The error from the build
> process is as follows:
>
>
>
> Linking CXX executable test-gr-blocks
>
> [ 67%] Built target test-gr-blocks
>
> Scanning dependencies of target _blocks_swig3
>
> [ 67%] Building CXX object
> gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/blocks_swig3PYTHON_wrap.cxx.o
>
> {standard input}: Assembler messages:
>
> {standard input}:380989: Warning: end of file not at end of a line;
> newline inserted
>
> {standard input}:381666: Error: invalid operands (*UND* and .ARM.extab
> sections) for `-'
>
> {standard input}:381669: Error: invalid operands (*UND* and .ARM.extab
> sections) for `-'
>
> arm-oe-linux-gnueabi-g++: internal compiler error: Killed (program cc1plus)
>
> Please submit a full bug report,
>
> with preprocessed source if appropriate.
>
> See <http://gcc.gnu.org/bugs.html> for instructions.
>
> make[2]: ***
> [gr-blocks/swig/CMakeFiles/_blocks_swig2.dir/blocks_swig2PYTHON_wrap.cxx.o]
> Error 4
>
> make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig2.dir/all] Error 2
>
> make[1]: *** Waiting for unfinished jobs....
>
> virtual memory exhausted: Cannot allocate memory
>
> {standard input}: Assembler messages:
>
> {standard input}:1273004: Warning: end of file not at end of a line;
> newline inserted
>
> {standard input}:1274439: Error: unknown pseudo-op: `.'
>
> make[2]: ***
> [gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/blocks_swig0PYTHON_wrap.cxx.o]
> Error 1
>
> make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/all] Error 2
>
> {standard input}: Error: open CFI at the end of file; missing .cfi_endproc
> directive
>
> arm-oe-linux-gnueabi-g++: internal compiler error: Killed (program cc1plus)
>
> Please submit a full bug report,
>
> with preprocessed source if appropriate.
>
> See <http://gcc.gnu.org/bugs.html> for instructions.
>
> make[2]: ***
> [gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/blocks_swig3PYTHON_wrap.cxx.o]
> Error 4
>
> make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/all] Error 2
>
> Linking CXX shared module _blocks_swig1.so
>
> [ 67%] Built target _blocks_swig1
>
> make: *** [all] Error 2
>
>
>
>
>
>
>
> I?m not entirely sure what I am missing. Please let me know if you find
> anything. Thanks!
>
>
>
> Charles Yin
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
Nicol?s Cuervo Benavides
Handy: +49 157 70476855
Electric and Electronic Engineering department.
Electronic Engineering
Universidad Nacional de Colombia
--
Student M.Sc. Information and Communication Technology
Karlsruher Institut f?r Technologie
Karlsruhe, Baden W?rttemberg, Germany
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160622/20c72fb5/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 22 Jun 2016 09:16:55 -0700
From: Neel Pandeya <[email protected]>
To: "Yin, Charles - 0665 - MITLL" <[email protected]>
Cc: "[email protected]" <[email protected]>,
"Chibane, Cherif - 0665 - MITLL" <[email protected]>
Subject: Re: [USRP-users] RFNoC Installation Problems
Message-ID:
<CACaXmv_pHfR=gVMUwCUt9BXMjjep+N+Tbck=2rmtvy1w-w3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Charles:
It looks like you're running in a Virtual Machine, and it's run out of
memory. See the line in the output:
virtual memory exhausted: Cannot allocate memory
Try increasing the memory for the VM to 4 GB, and re-building.
Please let us know if you're able to make any further progress.
--Neel Pandeya
On 21 June 2016 at 13:24, Yin, Charles - 0665 - MITLL via USRP-users <
[email protected]> wrote:
> Hi Neel and Jonathon,
>
>
>
> I am having problems building RFNoC with GNU Radio. I am using GNU Radio
> Version 3.9.7.2 on Ubuntu 14.04. You mentioned to check for the swig
> package, and I can confirm that it is there. The error from the build
> process is as follows:
>
>
>
> Linking CXX executable test-gr-blocks
>
> [ 67%] Built target test-gr-blocks
>
> Scanning dependencies of target _blocks_swig3
>
> [ 67%] Building CXX object
> gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/blocks_swig3PYTHON_wrap.cxx.o
>
> {standard input}: Assembler messages:
>
> {standard input}:380989: Warning: end of file not at end of a line;
> newline inserted
>
> {standard input}:381666: Error: invalid operands (*UND* and .ARM.extab
> sections) for `-'
>
> {standard input}:381669: Error: invalid operands (*UND* and .ARM.extab
> sections) for `-'
>
> arm-oe-linux-gnueabi-g++: internal compiler error: Killed (program cc1plus)
>
> Please submit a full bug report,
>
> with preprocessed source if appropriate.
>
> See <http://gcc.gnu.org/bugs.html> for instructions.
>
> make[2]: ***
> [gr-blocks/swig/CMakeFiles/_blocks_swig2.dir/blocks_swig2PYTHON_wrap.cxx.o]
> Error 4
>
> make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig2.dir/all] Error 2
>
> make[1]: *** Waiting for unfinished jobs....
>
> virtual memory exhausted: Cannot allocate memory
>
> {standard input}: Assembler messages:
>
> {standard input}:1273004: Warning: end of file not at end of a line;
> newline inserted
>
> {standard input}:1274439: Error: unknown pseudo-op: `.'
>
> make[2]: ***
> [gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/blocks_swig0PYTHON_wrap.cxx.o]
> Error 1
>
> make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/all] Error 2
>
> {standard input}: Error: open CFI at the end of file; missing .cfi_endproc
> directive
>
> arm-oe-linux-gnueabi-g++: internal compiler error: Killed (program cc1plus)
>
> Please submit a full bug report,
>
> with preprocessed source if appropriate.
>
> See <http://gcc.gnu.org/bugs.html> for instructions.
>
> make[2]: ***
> [gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/blocks_swig3PYTHON_wrap.cxx.o]
> Error 4
>
> make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/all] Error 2
>
> Linking CXX shared module _blocks_swig1.so
>
> [ 67%] Built target _blocks_swig1
>
> make: *** [all] Error 2
>
>
>
>
>
>
>
> I?m not entirely sure what I am missing. Please let me know if you find
> anything. Thanks!
>
>
>
> Charles Yin
>
>
>
> _______________________________________________
> 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/20160622/22ad791e/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 22 Jun 2016 16:16:58 +0000
From: "Yin, Charles - 0665 - MITLL" <[email protected]>
To: Nicolas Cuervo Benavides <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC Installation Problems
Message-ID:
<13657fc12b4974458e8326454370255105e...@lle2k10-mbx02.mitll.ad.local>
Content-Type: text/plain; charset="utf-8"
Hi Nicolas,
I am using a virtual machine. I have allocated 4 processing cores (8 threads)
and 16GB RAM to the VM, which I figured should be enough. I could try
allocating 32GB and see if that helps, but I don?t think I remember seeing the
RAM usage spike anywhere near 100%. Should I try it anyway? Please let me
know. Thanks!
Charles
From: Nicolas Cuervo Benavides [mailto:[email protected]]
Sent: Wednesday, June 22, 2016 12:08 PM
To: Yin, Charles - 0665 - MITLL
Cc: [email protected]
Subject: Re: [USRP-users] RFNoC Installation Problems
Hi Charles,
Are you running your installation into a Virtual Machine? It appears that you
are running out of virtual memory. You can overcome that by adding some memory
to your swap. Please tell us if it works.
Regards,
Nicolas
On Tue, Jun 21, 2016 at 1:24 PM, Yin, Charles - 0665 - MITLL via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hi Neel and Jonathon,
I am having problems building RFNoC with GNU Radio. I am using GNU Radio
Version 3.9.7.2 on Ubuntu 14.04. You mentioned to check for the swig package,
and I can confirm that it is there. The error from the build process is as
follows:
Linking CXX executable test-gr-blocks
[ 67%] Built target test-gr-blocks
Scanning dependencies of target _blocks_swig3
[ 67%] Building CXX object
gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/blocks_swig3PYTHON_wrap.cxx.o
{standard input}: Assembler messages:
{standard input}:380989: Warning: end of file not at end of a line; newline
inserted
{standard input}:381666: Error: invalid operands (*UND* and .ARM.extab
sections) for `-'
{standard input}:381669: Error: invalid operands (*UND* and .ARM.extab
sections) for `-'
arm-oe-linux-gnueabi-g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: ***
[gr-blocks/swig/CMakeFiles/_blocks_swig2.dir/blocks_swig2PYTHON_wrap.cxx.o]
Error 4
make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig2.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
virtual memory exhausted: Cannot allocate memory
{standard input}: Assembler messages:
{standard input}:1273004: Warning: end of file not at end of a line; newline
inserted
{standard input}:1274439: Error: unknown pseudo-op: `.'
make[2]: ***
[gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/blocks_swig0PYTHON_wrap.cxx.o]
Error 1
make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/all] Error 2
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
arm-oe-linux-gnueabi-g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: ***
[gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/blocks_swig3PYTHON_wrap.cxx.o]
Error 4
make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/all] Error 2
Linking CXX shared module _blocks_swig1.so
[ 67%] Built target _blocks_swig1
make: *** [all] Error 2
I?m not entirely sure what I am missing. Please let me know if you find
anything. Thanks!
Charles Yin
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Nicol?s Cuervo Benavides
Handy: +49 157 70476855
Electric and Electronic Engineering department.
Electronic Engineering
Universidad Nacional de Colombia
--
Student M.Sc. Information and Communication Technology
Karlsruher Institut f?r Technologie
Karlsruhe, Baden W?rttemberg, Germany
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160622/e1f8be2a/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 22 Jun 2016 09:32:58 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] uhd unix drivers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 06/22/2016 08:38 AM, Samy CHBINOU via USRP-users wrote:
> I got:
> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.005.005-0-unknown
This is the line that could have tipped you off: Notice you're running
3.5.5.
M
------------------------------
Message: 5
Date: Wed, 22 Jun 2016 09:34:00 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] B200mini/B205mini FPGA Acceleration
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi,
we have no plans of releasing RFNoC on the B205.
Cheers,
Martin
On 06/22/2016 03:34 AM, Marcus M?ller wrote:
> Hi Austin,
>
>
> On 21.06.2016 21:22, Austin Anderson via USRP-users wrote:
>> I'm interested in trying to get FPGA acceleration in place using the
>> FPGAs on the B200mini or B205mini. I've got the firmware built for the
>> B200mini and I'm working to determine path of least resistance:
>>
>> 1. I plan on just replacing the DDCs/DUCs (as this is a suggestion in
>> the USRP2 firmware notes). This seems like a straightforward path and
>> is compatible with existing DSP firmware I've developed for
>> Zedboard+AD9361. With respect to the framing of output data, is there
>> documentation on how the RX framer/RX control handle packet
>> generation? For example, if I want to receive a sample window, take a
>> fixed point FFT, and send a complete frame of FFT samples back to the
>> host, what's the best way to do that? Is that handled by the host side
>> (ie just request the FFT bin size)?
> The frame format is described in our Compressed vita header format
> description[1]. We call that format CHDR.
> Requesting only FFT sizes (or multiples thereof) as CVITA packet sizes
> should work, if the FFT is the last step before the streamer.
>>
>> 2. While implementing the DSP looks straightforward enough, what's the
>> suggested path to adding user configuration? I see there's a user
>> register setting generate statement that can be enabled with 256
>> registers mapped. Is that easily accessed from UHD?
> It is; you could modify UHD to actually expose something like a function
> call to your UHD-using program, or you can go "raw", get the property
> tree (which is the software design "approach" we use to make things
> accessible) and peek and poke through that.
>> I saw some posts on the usrp list that suggested the poke32 method
>> would be exposed in a future release of UHD, but it's not clear if
>> that happened. Is that part of the B200/B205 API now?
> AFAIK, no. I've got to ask *+Martin* about that, though.
>>
>> 3. The settings I'd want to configure would be filter taps and maybe
>> some register level settings. For the taps, is there a faster
>> alternative to loading through perhaps the AXI stream configuration
>> bus or is that more of a pain than it's worth?
> probably the latter. In fact, UHD loads filter taps for the AD9361
> through the peek/poke mechanism, too, if I remember correctly
>>
>> 4. The B205 has a bigger FPGA and is listed under the USRP3 firmware
>> directory, is RFNoC support planned for the B205?
> No. I think that's technically impossible, but, again, Martin, as the
> UHD release manager, will be much more competent in answering that than
> I am.
>
> Best regards,
> Marcus
>
> [1] http://files.ettus.com/manual/page_rtp.html#rtp_chdr
------------------------------
Message: 6
Date: Wed, 22 Jun 2016 09:39:48 -0700
From: Robin Coxe <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B200mini/B205mini FPGA Acceleration
Message-ID:
<CAGVTi8XYjmCH93p4Bs-MS4Ng=ly6qscbtgef6eo860cxb-q...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
To reiterate (this issue has come up on usrp-users several times in the
past ), RFNoC requires the Xilinx Vivado toolchain, which only supports
Virtex-7 and newer FPGAs (Virtex-7, Artix-7, Kintex-7, Zynq, Zynq
Ultrascale+).
*The USRP X300, X310, E310, and E312 currently have RFNoC support. *
*All new Ettus products with FPGAs in the future will support RFNoC.*
The USRP B200, B210, B200mini, B200mini-i, and B205mini-i have Spartan-6
FPGAs that require the older Xilinx ISE v. 14.7 toolchain. The do not and
will not have RFNoC support.
-Robin
On Wed, Jun 22, 2016 at 9:34 AM, Martin Braun via USRP-users <
[email protected]> wrote:
> Hi,
>
> we have no plans of releasing RFNoC on the B205.
>
> Cheers,
> Martin
>
> On 06/22/2016 03:34 AM, Marcus M?ller wrote:
> > Hi Austin,
> >
> >
> > On 21.06.2016 21:22, Austin Anderson via USRP-users wrote:
> >> I'm interested in trying to get FPGA acceleration in place using the
> >> FPGAs on the B200mini or B205mini. I've got the firmware built for the
> >> B200mini and I'm working to determine path of least resistance:
> >>
> >> 1. I plan on just replacing the DDCs/DUCs (as this is a suggestion in
> >> the USRP2 firmware notes). This seems like a straightforward path and
> >> is compatible with existing DSP firmware I've developed for
> >> Zedboard+AD9361. With respect to the framing of output data, is there
> >> documentation on how the RX framer/RX control handle packet
> >> generation? For example, if I want to receive a sample window, take a
> >> fixed point FFT, and send a complete frame of FFT samples back to the
> >> host, what's the best way to do that? Is that handled by the host side
> >> (ie just request the FFT bin size)?
> > The frame format is described in our Compressed vita header format
> > description[1]. We call that format CHDR.
> > Requesting only FFT sizes (or multiples thereof) as CVITA packet sizes
> > should work, if the FFT is the last step before the streamer.
> >>
> >> 2. While implementing the DSP looks straightforward enough, what's the
> >> suggested path to adding user configuration? I see there's a user
> >> register setting generate statement that can be enabled with 256
> >> registers mapped. Is that easily accessed from UHD?
> > It is; you could modify UHD to actually expose something like a function
> > call to your UHD-using program, or you can go "raw", get the property
> > tree (which is the software design "approach" we use to make things
> > accessible) and peek and poke through that.
> >> I saw some posts on the usrp list that suggested the poke32 method
> >> would be exposed in a future release of UHD, but it's not clear if
> >> that happened. Is that part of the B200/B205 API now?
> > AFAIK, no. I've got to ask *+Martin* about that, though.
> >>
> >> 3. The settings I'd want to configure would be filter taps and maybe
> >> some register level settings. For the taps, is there a faster
> >> alternative to loading through perhaps the AXI stream configuration
> >> bus or is that more of a pain than it's worth?
> > probably the latter. In fact, UHD loads filter taps for the AD9361
> > through the peek/poke mechanism, too, if I remember correctly
> >>
> >> 4. The B205 has a bigger FPGA and is listed under the USRP3 firmware
> >> directory, is RFNoC support planned for the B205?
> > No. I think that's technically impossible, but, again, Martin, as the
> > UHD release manager, will be much more competent in answering that than
> > I am.
> >
> > Best regards,
> > Marcus
> >
> > [1] http://files.ettus.com/manual/page_rtp.html#rtp_chdr
>
>
> _______________________________________________
> 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/20160622/f05c83b0/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 22 Jun 2016 11:14:25 -0600
From: Austin Anderson <[email protected]>
To: Robin Coxe <[email protected]>, Martin Braun
<[email protected]>, "[email protected]"
<[email protected]>, [email protected]
Subject: Re: [USRP-users] B200mini/B205mini FPGA Acceleration
Message-ID:
<CAF30z8e82UfM=0-4dtz4_9panlmsk3fqwgkdtafdzqbg++v...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks for the replies, I just wanted to clarify a couple things:
1. With respect to framing and building on the FFT example, if I specify
CVITA packet sizes that are integer multiples of my number of FFT bins,
what's to guarantee the FFT framing is synchronous to the streamer framing?
Is a reset pulsed to the fabric to accomplish synchronization?
2. It sounds like exposing the user setting registers for configuration is
the best approach. If I understand your response, though, host-side
software access to configuration registers is not supported by UHD out of
the box? That is to say I would need to alter UHD to get access to user
configuration registers?
3. Looking at the firmware, I don't think there is anything that would make
it technically impossible to port RFNoC to the B205 given enough time
(which is probably the tricky bit). While the current version of RFNoC
requires Vivado, initial releases (and I believe most of the initial
development) existed in ISE. In fact most of the firmware is just verilog
which works the same in Vivado or ISE. IP cores compiled in Vivado would
need to be adapted for ISE, which might be time consuming, but not
impossible. The point, I think, is moot, though. What I want to understand
is, if you're not planning on porting RFNoC functionality to the B205,
what's the methodology users should follow to develop DSP firmware for it?
Is it just what I described in my previous post?
Thanks,
-Austin
On Wed, Jun 22, 2016 at 10:39 AM, Robin Coxe via USRP-users <
[email protected]> wrote:
> To reiterate (this issue has come up on usrp-users several times in the
> past ), RFNoC requires the Xilinx Vivado toolchain, which only supports
> Virtex-7 and newer FPGAs (Virtex-7, Artix-7, Kintex-7, Zynq, Zynq
> Ultrascale+).
>
> *The USRP X300, X310, E310, and E312 currently have RFNoC support. *
> *All new Ettus products with FPGAs in the future will support RFNoC.*
>
> The USRP B200, B210, B200mini, B200mini-i, and B205mini-i have Spartan-6
> FPGAs that require the older Xilinx ISE v. 14.7 toolchain. The do not and
> will not have RFNoC support.
>
> -Robin
>
>
> On Wed, Jun 22, 2016 at 9:34 AM, Martin Braun via USRP-users <
> [email protected]> wrote:
>
>> Hi,
>>
>> we have no plans of releasing RFNoC on the B205.
>>
>> Cheers,
>> Martin
>>
>> On 06/22/2016 03:34 AM, Marcus M?ller wrote:
>> > Hi Austin,
>> >
>> >
>> > On 21.06.2016 21:22, Austin Anderson via USRP-users wrote:
>> >> I'm interested in trying to get FPGA acceleration in place using the
>> >> FPGAs on the B200mini or B205mini. I've got the firmware built for the
>> >> B200mini and I'm working to determine path of least resistance:
>> >>
>> >> 1. I plan on just replacing the DDCs/DUCs (as this is a suggestion in
>> >> the USRP2 firmware notes). This seems like a straightforward path and
>> >> is compatible with existing DSP firmware I've developed for
>> >> Zedboard+AD9361. With respect to the framing of output data, is there
>> >> documentation on how the RX framer/RX control handle packet
>> >> generation? For example, if I want to receive a sample window, take a
>> >> fixed point FFT, and send a complete frame of FFT samples back to the
>> >> host, what's the best way to do that? Is that handled by the host side
>> >> (ie just request the FFT bin size)?
>> > The frame format is described in our Compressed vita header format
>> > description[1]. We call that format CHDR.
>> > Requesting only FFT sizes (or multiples thereof) as CVITA packet sizes
>> > should work, if the FFT is the last step before the streamer.
>> >>
>> >> 2. While implementing the DSP looks straightforward enough, what's the
>> >> suggested path to adding user configuration? I see there's a user
>> >> register setting generate statement that can be enabled with 256
>> >> registers mapped. Is that easily accessed from UHD?
>> > It is; you could modify UHD to actually expose something like a function
>> > call to your UHD-using program, or you can go "raw", get the property
>> > tree (which is the software design "approach" we use to make things
>> > accessible) and peek and poke through that.
>> >> I saw some posts on the usrp list that suggested the poke32 method
>> >> would be exposed in a future release of UHD, but it's not clear if
>> >> that happened. Is that part of the B200/B205 API now?
>> > AFAIK, no. I've got to ask *+Martin* about that, though.
>> >>
>> >> 3. The settings I'd want to configure would be filter taps and maybe
>> >> some register level settings. For the taps, is there a faster
>> >> alternative to loading through perhaps the AXI stream configuration
>> >> bus or is that more of a pain than it's worth?
>> > probably the latter. In fact, UHD loads filter taps for the AD9361
>> > through the peek/poke mechanism, too, if I remember correctly
>> >>
>> >> 4. The B205 has a bigger FPGA and is listed under the USRP3 firmware
>> >> directory, is RFNoC support planned for the B205?
>> > No. I think that's technically impossible, but, again, Martin, as the
>> > UHD release manager, will be much more competent in answering that than
>> > I am.
>> >
>> > Best regards,
>> > Marcus
>> >
>> > [1] http://files.ettus.com/manual/page_rtp.html#rtp_chdr
>>
>>
>> _______________________________________________
>> 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/20160622/587f70ea/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 22 Jun 2016 17:09:55 -0400
From: Dave NotTelling <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Size of TX Buffer on N210
Message-ID:
<CAK6GVuO=JmTLFz=gmmtc0ih-xukcg6r0g13nujzioelkrxp...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
What is the byte size of the TX buffer on the N210? I want to make sure
that I am not mauling the TX buffer by sending large numbers of samples for
future transmission.
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160622/cdbc5efe/attachment-0001.html>
------------------------------
Message: 9
Date: Wed, 22 Jun 2016 21:48:36 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] How do I turn off one of the radios in
rfnoc-radio-redo and how can I use the debug UART?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
?Jonathon,
Hmm.., I opened the file up and it is already set to NUM_CHANNELS = 1. Does
that mean there is only one radio? If so, why does uhd_usrp_probe --init-only
show two radios?
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
________________________________
From: Jonathon Pendlum <[email protected]>
Sent: Monday, June 20, 2016 11:24 AM
To: Swanson, Craig
Cc: [email protected]
Subject: Re: How do I turn off one of the radios in rfnoc-radio-redo and how
can I use the debug UART?
Hi Craig,
>From the HDL perspective, setting NUM_CHANNELS = 1 on noc_block_radio_core.v
>should work without any issues. However, I haven't tested it with UHD.
The DELETE_DSP defines will be cleaned up. Since the DSP has been separated out
as part of radio redo, they have no meaning.
The debug UART is for the ZPU. It is useful if you are debugging or write
custom ZPU code.
Jonathon
On Wed, Jun 15, 2016 at 11:41 AM, Swanson, Craig
<[email protected]<mailto:[email protected]>> wrote:
Jonathon,
I am assuming that I un-comment out one of the lines in the /top/x300/Makefile
to turn off one of the radios. It says it is experimental. Is it more robust
now? I think this only applies to the DSP's, but not removing the actual
radio? I want to remove one of the radios to save space for someday moving my
code over to the much smaller E310.
Also I noticed a UART is available for debug. Have you found that useful?
Here is the portion in the Makefile:
# Debug Options
# Uncomment the following lines to build radio's with no DSP's (experimental!)
#OPTIONS += DELETE_DSP0=1
#OPTIONS += DELETE_DSP1=1
# Uncomment the following line to add a debug UART on GPIO 10 & 11
#OPTIONS += DEBUG_UART=1
Here is what I get when I uhd_usrp_probe:
-- ========== Full list of RFNoC blocks: ============
-- * 0/Radio_0
-- * 0/Radio_1
-- * 0/FIFO_0
-- * 0/MovingAverage_0
-- * 0/Receiver_0
?
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156<tel:770.298.9156>
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160622/53624ab0/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 22 Jun 2016 21:50:40 +0000
From: "Jasuja, Ishwar" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] UHD: 44
Message-ID:
<by2pr1001mb1061ef2546f556320da722dfec...@by2pr1001mb1061.namprd10.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hi,
What could cause following error?
ijasuja@ijasuja-desktop /home2/ijasuja/srsLTE/build/srslte/examples $
./pdsch_ue -f 2400000000 -a "type=x300,master_clock_rate=184.32e6"
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-0-unknown
Opening RF device...
Opening USRP with args: type=x300,master_clock_rate=184.32e6
-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
Error opening UHD: code 44
Opening bladeRF...
Unable to open device: Invalid operation or parameter
No compatible RF frontend found
Error opening rf
Thanks,
Ishwar
Spirent Communications e-mail confidentiality.
------------------------------------------------------------------------
This e-mail contains confidential and / or privileged information belonging to
Spirent Communications plc, its affiliates and / or subsidiaries. If you are
not the intended recipient, you are hereby notified that any disclosure,
copying, distribution and / or the taking of any action based upon reliance on
the contents of this transmission is strictly forbidden. If you have received
this message in error please notify the sender by return e-mail and delete it
from your system.
Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677
Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN,
United Kingdom.
Or if within the US,
Spirent Communications,
27349 Agoura Road, Calabasas, CA, 91301, USA.
Tel No. 1-818-676- 2300
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160622/1e17b6bd/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 22 Jun 2016 17:56:04 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD: 44
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 06/22/2016 05:50 PM, Jasuja, Ishwar via USRP-users wrote:
>
> Hi,
>
> What could cause following error?
>
> ijasuja@ijasuja-desktop /home2/ijasuja/srsLTE/build/srslte/examples $
> ./pdsch_ue -f 2400000000 -a "type=x300,master_clock_rate=184.32e6"
>
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-0-unknown
>
> Opening RF device...
>
> Opening USRP with args: type=x300,master_clock_rate=184.32e6
>
> -- X300 initialization sequence...
>
> -- Determining maximum frame size... 8000 bytes.
>
> -- Setup basic communication...
>
> *Error opening UHD: code 44*
>
> Opening bladeRF...
>
> Unable to open device: Invalid operation or parameter
>
> No compatible RF frontend found
>
> Error opening rf
>
That "Error opening UHD" isn't a message from UHD itself, you'd have to
ask the folks who wrote pdsch_ue
> Thanks,
>
> Ishwar
>
>
>
>
>
> Spirent Communications e-mail confidentiality.
> ------------------------------------------------------------------------
> This e-mail contains confidential and / or privileged information
> belonging to Spirent Communications plc, its affiliates and / or
> subsidiaries. If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution and / or the
> taking of any action based upon reliance on the contents of this
> transmission is strictly forbidden. If you have received this message
> in error please notify the sender by return e-mail and delete it from
> your system.
>
> Spirent Communications plc
> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United
> Kingdom.
> Tel No. +44 (0) 1293 767676
> Fax No. +44 (0) 1293 767677
>
> Registered in England Number 470893
> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10
> 9XN, United Kingdom.
>
> Or if within the US,
>
> Spirent Communications,
> 27349 Agoura Road, Calabasas, CA, 91301, USA.
> Tel No. 1-818-676- 2300
>
>
> _______________________________________________
> 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/20160622/5d9d8b4a/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 22 Jun 2016 17:04:46 -0500
From: Jonathon Pendlum <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] How do I turn off one of the radios in
rfnoc-radio-redo and how can I use the debug UART?
Message-ID:
<cagdo0utvsa7es4mc_wcpcevfuzfkzzqqositxnhf1gh_ke5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Craig,
There is one channel per radio and two radio instances on the X300. The
E300 has one radio instance with two channels.
Jonathon
On Wed, Jun 22, 2016 at 4:48 PM, Swanson, Craig <
[email protected]> wrote:
> ?Jonathon,
>
> Hmm.., I opened the file up and it is already set to NUM_CHANNELS = 1.
> Does that mean there is only one radio? If so, why does uhd_usrp_probe
> --init-only show two radios?
>
>
> Craig
>
>
> *Craig F. Swanson*
>
> *Research Engineer II *
> *Information and Communications Laboratory*
> *Communications, Systems, and Spectrum Division*
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW *
> *Atlanta, GA 30318*
> *Cell: 770.298.9156 <770.298.9156>*
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
> ------------------------------
> *From:* Jonathon Pendlum <[email protected]>
> *Sent:* Monday, June 20, 2016 11:24 AM
> *To:* Swanson, Craig
> *Cc:* [email protected]
> *Subject:* Re: How do I turn off one of the radios in rfnoc-radio-redo
> and how can I use the debug UART?
>
> Hi Craig,
>
> From the HDL perspective, setting NUM_CHANNELS = 1 on
> noc_block_radio_core.v should work without any issues. However, I haven't
> tested it with UHD.
>
> The DELETE_DSP defines will be cleaned up. Since the DSP has been
> separated out as part of radio redo, they have no meaning.
>
> The debug UART is for the ZPU. It is useful if you are debugging or write
> custom ZPU code.
>
>
>
> Jonathon
>
> On Wed, Jun 15, 2016 at 11:41 AM, Swanson, Craig <
> [email protected]> wrote:
>
>> Jonathon,
>>
>> I am assuming that I un-comment out one of the lines in the
>> /top/x300/Makefile to turn off one of the radios. It says it is
>> experimental. Is it more robust now? I think this only applies to the
>> DSP's, but not removing the actual radio? I want to remove one of the
>> radios to save space for someday moving my code over to the much smaller
>> E310.
>>
>>
>> Also I noticed a UART is available for debug. Have you found that useful?
>>
>> Here is the portion in the Makefile:
>>
>>
>> # Debug Options
>> # Uncomment the following lines to build radio's with no DSP's
>> (experimental!)
>> #OPTIONS += DELETE_DSP0=1
>> #OPTIONS += DELETE_DSP1=1
>> # Uncomment the following line to add a debug UART on GPIO 10 & 11
>> #OPTIONS += DEBUG_UART=1
>>
>> Here is what I get when I uhd_usrp_probe:
>>
>> -- ========== Full list of RFNoC blocks: ============
>> -- * 0/Radio_0
>> -- * 0/Radio_1
>> -- * 0/FIFO_0
>> -- * 0/MovingAverage_0
>> -- * 0/Receiver_0
>> ?
>>
>> Craig
>>
>>
>> *Craig F. Swanson*
>>
>> *Research Engineer II *
>> *Information and Communications Laboratory*
>> *Communications, Systems, and Spectrum Division*
>> *Georgia Tech Research Institute*
>>
>>
>> *Room 560 250 14th St NW *
>> *Atlanta, GA 30318*
>> *Cell: 770.298.9156 <770.298.9156>*
>> http://www.gtri.gatech.edu
>> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160622/ae9bfe41/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 22 Jun 2016 15:13:27 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Size of TX Buffer on N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
It's 1048576 bytes, but if you try and do that, your send() command will
time out.
M
On 06/22/2016 02:09 PM, Dave NotTelling via USRP-users wrote:
> What is the byte size of the TX buffer on the N210? I want to make sure
> that I am not mauling the TX buffer by sending large numbers of samples
> for future transmission.
>
> Thanks!
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 14
Date: Wed, 22 Jun 2016 22:28:54 +0000
From: "Jasuja, Ishwar" <[email protected]>
To: "Marcus D. Leech" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD: 44
Message-ID:
<by2pr1001mb106142a6720a49dc584766f0ec...@by2pr1001mb1061.namprd10.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
It was picking up old libuhd.so file. This always bites me..
The error code 44 is returned by UHD API call. It says it is a runtime error.
That is why I thought I might ask the question here
Thanks,
Ishwar
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus D. Leech via USRP-users
Sent: Wednesday, June 22, 2016 2:56 PM
To: [email protected]
Subject: Re: [USRP-users] UHD: 44
On 06/22/2016 05:50 PM, Jasuja, Ishwar via USRP-users wrote:
Hi,
What could cause following error?
ijasuja@ijasuja-desktop /home2/ijasuja/srsLTE/build/srslte/examples $
./pdsch_ue -f 2400000000 -a "type=x300,master_clock_rate=184.32e6"
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-0-unknown
Opening RF device...
Opening USRP with args: type=x300,master_clock_rate=184.32e6
-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
Error opening UHD: code 44
Opening bladeRF...
Unable to open device: Invalid operation or parameter
No compatible RF frontend found
Error opening rf
That "Error opening UHD" isn't a message from UHD itself, you'd have to ask the
folks who wrote pdsch_ue
Thanks,
Ishwar
Spirent Communications e-mail confidentiality.
------------------------------------------------------------------------
This e-mail contains confidential and / or privileged information belonging to
Spirent Communications plc, its affiliates and / or subsidiaries. If you are
not the intended recipient, you are hereby notified that any disclosure,
copying, distribution and / or the taking of any action based upon reliance on
the contents of this transmission is strictly forbidden. If you have received
this message in error please notify the sender by return e-mail and delete it
from your system.
Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677
Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN,
United Kingdom.
Or if within the US,
Spirent Communications,
27349 Agoura Road, Calabasas, CA, 91301, USA.
Tel No. 1-818-676- 2300
_______________________________________________
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/20160622/2e72c06d/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 22 Jun 2016 18:38:02 -0400
From: Dave NotTelling <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Size of TX Buffer on N210
Message-ID:
<CAK6GVuMoGNN8YYa210KrgPsJ-7jYz8+r9EMR=6bfusheh6a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Martin,
Thank you! Would you happen to know the size of the TX buffer on the
X310? I see that there is a DRAM build that I assume increases the TX
buffer.
V/R,
-Dave
On Wed, Jun 22, 2016 at 6:13 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> It's 1048576 bytes, but if you try and do that, your send() command will
> time out.
>
> M
>
> On 06/22/2016 02:09 PM, Dave NotTelling via USRP-users wrote:
> > What is the byte size of the TX buffer on the N210? I want to make sure
> > that I am not mauling the TX buffer by sending large numbers of samples
> > for future transmission.
> >
> > Thanks!
> >
> >
> > _______________________________________________
> > 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/20160622/14b93cea/attachment-0001.html>
------------------------------
Message: 16
Date: Wed, 22 Jun 2016 21:28:54 -0400
From: "Marcus D. Leech" <[email protected]>
To: "Jasuja, Ishwar" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD: 44
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 06/22/2016 06:28 PM, Jasuja, Ishwar wrote:
>
> It was picking up old libuhd.so file. This always bites me..
>
> The error code 44 is returned by UHD API call. It says it is a runtime
> error. That is why I thought I might ask the question here
>
> Thanks,
>
> Ishwar
>
My point is that "Error Opening UHD: Code 44" is not a message produced
by UHD itself, so without further context (like, what UHD API call was
it making, what does 'opening UHD' actually mean in this context, etc),
it's hard to give advice.
> *From:*USRP-users [mailto:[email protected]] *On
> Behalf Of *Marcus D. Leech via USRP-users
> *Sent:* Wednesday, June 22, 2016 2:56 PM
> *To:* [email protected]
> *Subject:* Re: [USRP-users] UHD: 44
>
> On 06/22/2016 05:50 PM, Jasuja, Ishwar via USRP-users wrote:
>
> Hi,
>
> What could cause following error?
>
> ijasuja@ijasuja-desktop
> /home2/ijasuja/srsLTE/build/srslte/examples $ ./pdsch_ue -f
> 2400000000 -a "type=x300,master_clock_rate=184.32e6"
>
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-0-unknown
>
> Opening RF device...
>
> Opening USRP with args: type=x300,master_clock_rate=184.32e6
>
> -- X300 initialization sequence...
>
> -- Determining maximum frame size... 8000 bytes.
>
> -- Setup basic communication...
>
> *Error opening UHD: code 44*
>
> Opening bladeRF...
>
> Unable to open device: Invalid operation or parameter
>
> No compatible RF frontend found
>
> Error opening rf
>
> That "Error opening UHD" isn't a message from UHD itself, you'd have
> to ask the folks who wrote pdsch_ue
>
>
>
> Thanks,
>
> Ishwar
>
>
>
>
> Spirent Communications e-mail confidentiality.
> ------------------------------------------------------------------------
> This e-mail contains confidential and / or privileged information
> belonging to Spirent Communications plc, its affiliates and / or
> subsidiaries. If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution and / or the
> taking of any action based upon reliance on the contents of this
> transmission is strictly forbidden. If you have received this message
> in error please notify the sender by return e-mail and delete it from
> your system.
>
> Spirent Communications plc
> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United
> Kingdom.
> Tel No. +44 (0) 1293 767676
> Fax No. +44 (0) 1293 767677
>
> Registered in England Number 470893
> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10
> 9XN, United Kingdom.
>
> Or if within the US,
>
> Spirent Communications,
> 27349 Agoura Road, Calabasas, CA, 91301, USA.
> Tel No. 1-818-676- 2300
>
>
>
>
> _______________________________________________
> 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/20160622/cddbca5e/attachment-0001.html>
------------------------------
Message: 17
Date: Thu, 23 Jun 2016 01:41:01 +0000
From: "Jasuja, Ishwar" <[email protected]>
To: "Marcus D. Leech" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD: 44
Message-ID:
<by2pr1001mb10618aa8d3c3d871908ccf45ec...@by2pr1001mb1061.namprd10.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
I am sorry. I should have specified that the error code was the return value of
uhd_usrp_make() call.
Thanks,
Ishwar
From: Marcus D. Leech [mailto:[email protected]]
Sent: Wednesday, June 22, 2016 6:29 PM
To: Jasuja, Ishwar; [email protected]
Subject: Re: [USRP-users] UHD: 44
On 06/22/2016 06:28 PM, Jasuja, Ishwar wrote:
It was picking up old libuhd.so file. This always bites me..
The error code 44 is returned by UHD API call. It says it is a runtime error.
That is why I thought I might ask the question here
Thanks,
Ishwar
My point is that "Error Opening UHD: Code 44" is not a message produced by UHD
itself, so without further context (like, what UHD API call was it making, what
does 'opening UHD' actually mean in this context, etc), it's hard to give
advice.
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus D. Leech via USRP-users
Sent: Wednesday, June 22, 2016 2:56 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] UHD: 44
On 06/22/2016 05:50 PM, Jasuja, Ishwar via USRP-users wrote:
Hi,
What could cause following error?
ijasuja@ijasuja-desktop /home2/ijasuja/srsLTE/build/srslte/examples $
./pdsch_ue -f 2400000000 -a "type=x300,master_clock_rate=184.32e6"
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-0-unknown
Opening RF device...
Opening USRP with args: type=x300,master_clock_rate=184.32e6
-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
Error opening UHD: code 44
Opening bladeRF...
Unable to open device: Invalid operation or parameter
No compatible RF frontend found
Error opening rf
That "Error opening UHD" isn't a message from UHD itself, you'd have to ask the
folks who wrote pdsch_ue
Thanks,
Ishwar
Spirent Communications e-mail confidentiality.
------------------------------------------------------------------------
This e-mail contains confidential and / or privileged information belonging to
Spirent Communications plc, its affiliates and / or subsidiaries. If you are
not the intended recipient, you are hereby notified that any disclosure,
copying, distribution and / or the taking of any action based upon reliance on
the contents of this transmission is strictly forbidden. If you have received
this message in error please notify the sender by return e-mail and delete it
from your system.
Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677
Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN,
United Kingdom.
Or if within the US,
Spirent Communications,
27349 Agoura Road, Calabasas, CA, 91301, USA.
Tel No. 1-818-676- 2300
_______________________________________________
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/20160623/486e681d/attachment-0001.html>
------------------------------
Message: 18
Date: Wed, 22 Jun 2016 22:05:09 -0400
From: "Marcus D. Leech" <[email protected]>
To: "Jasuja, Ishwar" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD: 44
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 06/22/2016 09:41 PM, Jasuja, Ishwar wrote:
>
> I am sorry. I should have specified that the error code was the return
> value of uhd_usrp_make() call.
>
> Thanks,
>
> Ishwar
>
You might consider using uhd_get_last_error() call to produce a string,
rather than a numeric value.
And it wasn't clear until the comment above that you were using the C,
rather than C++ API.
> *From:*Marcus D. Leech [mailto:[email protected]]
> *Sent:* Wednesday, June 22, 2016 6:29 PM
> *To:* Jasuja, Ishwar; [email protected]
> *Subject:* Re: [USRP-users] UHD: 44
>
> On 06/22/2016 06:28 PM, Jasuja, Ishwar wrote:
>
> It was picking up old libuhd.so file. This always bites me..
>
> The error code 44 is returned by UHD API call. It says it is a
> runtime error. That is why I thought I might ask the question here
>
> Thanks,
>
> Ishwar
>
> My point is that "Error Opening UHD: Code 44" is not a message
> produced by UHD itself, so without further context (like, what UHD API
> call was it making, what does 'opening UHD' actually mean in this
> context, etc), it's hard to give advice.
>
>
>
> *From:*USRP-users [mailto:[email protected]] *On
> Behalf Of *Marcus D. Leech via USRP-users
> *Sent:* Wednesday, June 22, 2016 2:56 PM
> *To:* [email protected] <mailto:[email protected]>
> *Subject:* Re: [USRP-users] UHD: 44
>
> On 06/22/2016 05:50 PM, Jasuja, Ishwar via USRP-users wrote:
>
> Hi,
>
> What could cause following error?
>
> ijasuja@ijasuja-desktop
> /home2/ijasuja/srsLTE/build/srslte/examples $ ./pdsch_ue -f
> 2400000000 -a "type=x300,master_clock_rate=184.32e6"
>
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-0-unknown
>
> Opening RF device...
>
> Opening USRP with args: type=x300,master_clock_rate=184.32e6
>
> -- X300 initialization sequence...
>
> -- Determining maximum frame size... 8000 bytes.
>
> -- Setup basic communication...
>
> *Error opening UHD: code 44*
>
> Opening bladeRF...
>
> Unable to open device: Invalid operation or parameter
>
> No compatible RF frontend found
>
> Error opening rf
>
> That "Error opening UHD" isn't a message from UHD itself, you'd have
> to ask the folks who wrote pdsch_ue
>
>
>
>
> Thanks,
>
> Ishwar
>
>
>
>
>
> Spirent Communications e-mail confidentiality.
> ------------------------------------------------------------------------
> This e-mail contains confidential and / or privileged information
> belonging to Spirent Communications plc, its affiliates and / or
> subsidiaries. If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution and / or the
> taking of any action based upon reliance on the contents of this
> transmission is strictly forbidden. If you have received this message
> in error please notify the sender by return e-mail and delete it from
> your system.
>
> Spirent Communications plc
> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United
> Kingdom.
> Tel No. +44 (0) 1293 767676
> Fax No. +44 (0) 1293 767677
>
> Registered in England Number 470893
> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10
> 9XN, United Kingdom.
>
> Or if within the US,
>
> Spirent Communications,
> 27349 Agoura Road, Calabasas, CA, 91301, USA.
> Tel No. 1-818-676- 2300
>
>
>
>
>
> _______________________________________________
> 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/20160622/c96ad38f/attachment-0001.html>
------------------------------
Message: 19
Date: Wed, 22 Jun 2016 19:36:50 -0700
From: Pavan Yedavalli <[email protected]>
To: [email protected], GNURadio Discussion List
<[email protected]>
Subject: [USRP-users] S printouts and then either U printouts (and
fails/stops transmitting) or seg fault with 4 USRPs
Message-ID:
<CACaX0_Od1-77VeTPDqNJm2tOTCK4DqhXsXhXvJXDSCAULg=j...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I am connecting 4 USRPs to the Octoclock and my host CPU, and created two
of my own blocks (one in python and one in C++), but neither of them runs
very long, as countless Ss are streamed out and then finally Us, which
signify underruns and so they stop transmitting. I was told that
implementing the block in Python would be slower, as expected, which could
be the reason why my computer is not able to transmit samples to the USRPs
quickly enough. However, when I tried to implement in C++, which is
supposed to be much faster, I'm seeing the same problem.
One key piece of information is that both the python and C++
implementations work about 75% of the time when 2 USRPs are connected, but
with 4, it fails quickly close to 100% of the time, so it is clear that
adding more antennas is causing issues, but I don't know what I can do
about it. My project requires multiple antennas, so this is a major
problem, unfortunately. Any help would be much appreciated. Thank you so
much.
--
Pavan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160622/9c05a6b6/attachment-0001.html>
------------------------------
Message: 20
Date: Wed, 22 Jun 2016 21:40:02 -0500
From: Henrique Bucher <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Compiling new firmware on N210
Message-ID:
<calngcsz4scmns_er-3p7ezjjtpf-pbda97uva_bpmmduwm_...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
It looks like the usrp2p is the right firmware for the "new" hardware.
Found this by trial and error but I still would like some official word on
this.
On Mon, Jun 20, 2016 at 8:54 AM, Henrique Bucher <[email protected]> wrote:
> Hello
>
> I want to customize the current firmware on the N210 but hit a glitch.
>
> So far I was able to compile successfully both the FPGA bin and also the
> USRP2 firmware binaries.
>
> However I do not know which one is the actual firmware for the N210 that
> should be used in the upload tool.
>
> If I upload the FPGA binary with --no-fw, the fpga bin works fine: I
> reboot and it behaves the same.
>
> uhd_image_loader --args="type=usrp2,addr=192.168.26.180" --no-fw
> --fpga-path uhd/fpga-src/usrp2/top/N2x0/build-N210R4/u2plus.bin
>
> However when I try both the device apparently bricks, ie I cannot find it
> anymore with uhd_find_devices or uhd_usrp_probe, even changing the
> interface IP address:
>
> uhd_image_loader --args="type=usrp2,addr=192.168.26.180" --fw-path
> uhd/firmware/usrp2/build/usrp2/usrp2_txrx_uhd.bin --fpga-path
> uhd/fpga-src/usrp2/top/N2x0/build-N210R4/u2plus.bin
>
> The whole process finishes and I can see the LEDs but it just does not
> further work, which leads me to the realization that perhaps the
> usrp2_txrx_uhd.bin firmware is not actually a perfect replacement to the
> factory-issued one.
>
> I also see these additional/potential firmwares being created but not sure
> what is the difference between them
>
> ./usrp2p/bootloader/bootloader.bin
> ./usrp2p/usrp2p_txrx_uhd.bin
> ./usrp2/usrp2_txrx_uhd.bin
>
> Would you please advise?
>
> Thank you.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160622/086bce48/attachment-0001.html>
------------------------------
Message: 21
Date: Thu, 23 Jun 2016 02:41:35 +0000
From: "Jasuja, Ishwar" <[email protected]>
To: "Marcus D. Leech" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD: 44
Message-ID:
<by2pr1001mb106128dcd14d08e2fb1547feec...@by2pr1001mb1061.namprd10.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
I am trying to get srsLTE PHY code running on X300. That open source package
uses C API.
From: Marcus D. Leech [mailto:[email protected]]
Sent: Wednesday, June 22, 2016 7:05 PM
To: Jasuja, Ishwar; [email protected]
Subject: Re: [USRP-users] UHD: 44
On 06/22/2016 09:41 PM, Jasuja, Ishwar wrote:
I am sorry. I should have specified that the error code was the return value of
uhd_usrp_make() call.
Thanks,
Ishwar
You might consider using uhd_get_last_error() call to produce a string, rather
than a numeric value.
And it wasn't clear until the comment above that you were using the C, rather
than C++ API.
From: Marcus D. Leech [mailto:[email protected]]
Sent: Wednesday, June 22, 2016 6:29 PM
To: Jasuja, Ishwar;
[email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] UHD: 44
On 06/22/2016 06:28 PM, Jasuja, Ishwar wrote:
It was picking up old libuhd.so file. This always bites me..
The error code 44 is returned by UHD API call. It says it is a runtime error.
That is why I thought I might ask the question here
Thanks,
Ishwar
My point is that "Error Opening UHD: Code 44" is not a message produced by UHD
itself, so without further context (like, what UHD API call was it making, what
does 'opening UHD' actually mean in this context, etc), it's hard to give
advice.
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus D. Leech via USRP-users
Sent: Wednesday, June 22, 2016 2:56 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] UHD: 44
On 06/22/2016 05:50 PM, Jasuja, Ishwar via USRP-users wrote:
Hi,
What could cause following error?
ijasuja@ijasuja-desktop /home2/ijasuja/srsLTE/build/srslte/examples $
./pdsch_ue -f 2400000000 -a "type=x300,master_clock_rate=184.32e6"
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-0-unknown
Opening RF device...
Opening USRP with args: type=x300,master_clock_rate=184.32e6
-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
Error opening UHD: code 44
Opening bladeRF...
Unable to open device: Invalid operation or parameter
No compatible RF frontend found
Error opening rf
That "Error opening UHD" isn't a message from UHD itself, you'd have to ask the
folks who wrote pdsch_ue
Thanks,
Ishwar
Spirent Communications e-mail confidentiality.
------------------------------------------------------------------------
This e-mail contains confidential and / or privileged information belonging to
Spirent Communications plc, its affiliates and / or subsidiaries. If you are
not the intended recipient, you are hereby notified that any disclosure,
copying, distribution and / or the taking of any action based upon reliance on
the contents of this transmission is strictly forbidden. If you have received
this message in error please notify the sender by return e-mail and delete it
from your system.
Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677
Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN,
United Kingdom.
Or if within the US,
Spirent Communications,
27349 Agoura Road, Calabasas, CA, 91301, USA.
Tel No. 1-818-676- 2300
_______________________________________________
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/20160623/c8e8c340/attachment-0001.html>
------------------------------
Message: 22
Date: Wed, 22 Jun 2016 22:42:44 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] S printouts and then either U printouts (and
fails/stops transmitting) or seg fault with 4 USRPs
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 06/22/2016 10:36 PM, Pavan Yedavalli via USRP-users wrote:
> Hi,
>
> I am connecting 4 USRPs to the Octoclock and my host CPU, and created
> two of my own blocks (one in python and one in C++), but neither of
> them runs very long, as countless Ss are streamed out and then finally
> Us, which signify underruns and so they stop transmitting. I was told
> that implementing the block in Python would be slower, as expected,
> which could be the reason why my computer is not able to transmit
> samples to the USRPs quickly enough. However, when I tried to
> implement in C++, which is supposed to be much faster, I'm seeing the
> same problem.
>
> One key piece of information is that both the python and C++
> implementations work about 75% of the time when 2 USRPs are connected,
> but with 4, it fails quickly close to 100% of the time, so it is clear
> that adding more antennas is causing issues, but I don't know what I
> can do about it. My project requires multiple antennas, so this is a
> major problem, unfortunately. Any help would be much appreciated.
> Thank you so much.
>
> --
> Pavan
>
>
What type of USRPs? What type of interface? Are they all connected to
the same computer?
What if you create a very simple flow-graph that has, for example, a
narrowband tone being sent to all four USRPs. Does that work?
Build from there, at what point do things start to fall apart? What
sample-rates are you using? How fast is your computer?
'U' is underrun, which means your computer isn't keeping up with the
USRP. 'S' is a sequence error which should, under ordinary circumstances
never happen. Unless your connection channel is broken in some way,
or is wildly overloaded.
------------------------------
Message: 23
Date: Wed, 22 Jun 2016 22:47:39 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Compiling new firmware on N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 06/22/2016 10:40 PM, Henrique Bucher via USRP-users wrote:
> It looks like the usrp2p is the right firmware for the "new" hardware.
> Found this by trial and error but I still would like some official
> word on this.
>
> On Mon, Jun 20, 2016 at 8:54 AM, Henrique Bucher <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hello
>
> I want to customize the current firmware on the N210 but hit a glitch.
>
> So far I was able to compile successfully both the FPGA bin and
> also the USRP2 firmware binaries.
>
> However I do not know which one is the actual firmware for the
> N210 that should be used in the upload tool.
>
> If I upload the FPGA binary with --no-fw, the fpga bin works fine:
> I reboot and it behaves the same.
>
> uhd_image_loader --args="type=usrp2,addr=192.168.26.180" --no-fw
> --fpga-path uhd/fpga-src/usrp2/top/N2x0/build-N210R4/u2plus.bin
>
> However when I try both the device apparently bricks, ie I cannot
> find it anymore with uhd_find_devices or uhd_usrp_probe, even
> changing the interface IP address:
>
> uhd_image_loader --args="type=usrp2,addr=192.168.26.180" --fw-path
> uhd/firmware/usrp2/build/usrp2/usrp2_txrx_uhd.bin --fpga-path
> uhd/fpga-src/usrp2/top/N2x0/build-N210R4/u2plus.bin
>
> The whole process finishes and I can see the LEDs but it just does
> not further work, which leads me to the realization that perhaps
> the usrp2_txrx_uhd.bin firmware is not actually a perfect
> replacement to the factory-issued one.
>
> I also see these additional/potential firmwares being created but
> not sure what is the difference between them
>
> ./usrp2p/bootloader/bootloader.bin
> ./usrp2p/usrp2p_txrx_uhd.bin
> ./usrp2/usrp2_txrx_uhd.bin
>
> Would you please advise?
>
> Thank you.
>
>
>
You should be able to use usrp_n210_fw.bin which is normally installed
in <prefix>share/uhd/images
The usrp2_txrx_uhd.bin is specifically for USRP2
The "firmware" in this context is for the ZPU fpga-based RISC CPU
implementation, whereas the FPGA image just contains the FPGA logic.
You generally need both, even if you're doing custom FPGA code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160622/19e348ce/attachment-0001.html>
------------------------------
Message: 24
Date: Wed, 22 Jun 2016 22:52:14 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Compiling new firmware on N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 06/22/2016 10:40 PM, Henrique Bucher via USRP-users wrote:
> It looks like the usrp2p is the right firmware for the "new" hardware.
> Found this by trial and error but I still would like some official
> word on this.
>
> On Mon, Jun 20, 2016 at 8:54 AM, Henrique Bucher <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hello
>
> I want to customize the current firmware on the N210 but hit a glitch.
>
> So far I was able to compile successfully both the FPGA bin and
> also the USRP2 firmware binaries.
>
> However I do not know which one is the actual firmware for the
> N210 that should be used in the upload tool.
>
> If I upload the FPGA binary with --no-fw, the fpga bin works fine:
> I reboot and it behaves the same.
>
> uhd_image_loader --args="type=usrp2,addr=192.168.26.180" --no-fw
> --fpga-path uhd/fpga-src/usrp2/top/N2x0/build-N210R4/u2plus.bin
>
> However when I try both the device apparently bricks, ie I cannot
> find it anymore with uhd_find_devices or uhd_usrp_probe, even
> changing the interface IP address:
>
> uhd_image_loader --args="type=usrp2,addr=192.168.26.180" --fw-path
> uhd/firmware/usrp2/build/usrp2/usrp2_txrx_uhd.bin --fpga-path
> uhd/fpga-src/usrp2/top/N2x0/build-N210R4/u2plus.bin
>
> The whole process finishes and I can see the LEDs but it just does
> not further work, which leads me to the realization that perhaps
> the usrp2_txrx_uhd.bin firmware is not actually a perfect
> replacement to the factory-issued one.
>
> I also see these additional/potential firmwares being created but
> not sure what is the difference between them
>
> ./usrp2p/bootloader/bootloader.bin
> ./usrp2p/usrp2p_txrx_uhd.bin
> ./usrp2/usrp2_txrx_uhd.bin
>
> Would you please advise?
>
> Thank you.
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Also, you might find this useful:
http://files.ettus.com/manual/md_fpga.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160622/e3322ab0/attachment-0001.html>
------------------------------
Message: 25
Date: Wed, 22 Jun 2016 20:05:14 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] Size of TX Buffer on N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Short answer: A bit north of 32 MB.
M
On 06/22/2016 03:38 PM, Dave NotTelling wrote:
> Martin,
>
> Thank you! Would you happen to know the size of the TX buffer on
> the X310? I see that there is a DRAM build that I assume increases the
> TX buffer.
>
> V/R,
>
> -Dave
>
> On Wed, Jun 22, 2016 at 6:13 PM, Martin Braun via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> It's 1048576 bytes, but if you try and do that, your send() command will
> time out.
>
> M
>
> On 06/22/2016 02:09 PM, Dave NotTelling via USRP-users wrote:
> > What is the byte size of the TX buffer on the N210? I want to
> make sure
> > that I am not mauling the TX buffer by sending large numbers of
> samples
> > for future transmission.
> >
> > Thanks!
> >
> >
> > _______________________________________________
> > 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
>
>
------------------------------
Message: 26
Date: Wed, 22 Jun 2016 23:06:15 -0400
From: "Marcus D. Leech" <[email protected]>
To: "Jasuja, Ishwar" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD: 44
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 06/22/2016 10:41 PM, Jasuja, Ishwar wrote:
>
> I am trying to get srsLTE PHY code running on X300. That open source
> package uses C API.
>
Ah. OK. Now there's even more context.
We're happy to help on here, but the density of folks on the list who
are using srsLTE code is rather sparse--is there a specific mailng-list,
or support channel for srsLTE? [Answering my own question:
http://www.softwareradiosystems.com/mailman/listinfo/srslte-users]
> *From:*Marcus D. Leech [mailto:[email protected]]
> *Sent:* Wednesday, June 22, 2016 7:05 PM
> *To:* Jasuja, Ishwar; [email protected]
> *Subject:* Re: [USRP-users] UHD: 44
>
> On 06/22/2016 09:41 PM, Jasuja, Ishwar wrote:
>
> I am sorry. I should have specified that the error code was the
> return value of uhd_usrp_make() call.
>
> Thanks,
>
> Ishwar
>
> You might consider using uhd_get_last_error() call to produce a
> string, rather than a numeric value.
>
> And it wasn't clear until the comment above that you were using the C,
> rather than C++ API.
>
>
>
> *From:*Marcus D. Leech [mailto:[email protected]]
> *Sent:* Wednesday, June 22, 2016 6:29 PM
> *To:* Jasuja, Ishwar; [email protected]
> <mailto:[email protected]>
> *Subject:* Re: [USRP-users] UHD: 44
>
> On 06/22/2016 06:28 PM, Jasuja, Ishwar wrote:
>
> It was picking up old libuhd.so file. This always bites me..
>
> The error code 44 is returned by UHD API call. It says it is a
> runtime error. That is why I thought I might ask the question here
>
> Thanks,
>
> Ishwar
>
> My point is that "Error Opening UHD: Code 44" is not a message
> produced by UHD itself, so without further context (like, what UHD API
> call was it making, what does 'opening UHD' actually mean in this
> context, etc), it's hard to give advice.
>
>
>
>
> *From:*USRP-users [mailto:[email protected]] *On
> Behalf Of *Marcus D. Leech via USRP-users
> *Sent:* Wednesday, June 22, 2016 2:56 PM
> *To:* [email protected] <mailto:[email protected]>
> *Subject:* Re: [USRP-users] UHD: 44
>
> On 06/22/2016 05:50 PM, Jasuja, Ishwar via USRP-users wrote:
>
> Hi,
>
> What could cause following error?
>
> ijasuja@ijasuja-desktop
> /home2/ijasuja/srsLTE/build/srslte/examples $ ./pdsch_ue -f
> 2400000000 -a "type=x300,master_clock_rate=184.32e6"
>
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-0-unknown
>
> Opening RF device...
>
> Opening USRP with args: type=x300,master_clock_rate=184.32e6
>
> -- X300 initialization sequence...
>
> -- Determining maximum frame size... 8000 bytes.
>
> -- Setup basic communication...
>
> *Error opening UHD: code 44*
>
> Opening bladeRF...
>
> Unable to open device: Invalid operation or parameter
>
> No compatible RF frontend found
>
> Error opening rf
>
> That "Error opening UHD" isn't a message from UHD itself, you'd have
> to ask the folks who wrote pdsch_ue
>
>
>
>
>
> Thanks,
>
> Ishwar
>
>
>
>
>
>
> Spirent Communications e-mail confidentiality.
> ------------------------------------------------------------------------
> This e-mail contains confidential and / or privileged information
> belonging to Spirent Communications plc, its affiliates and / or
> subsidiaries. If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution and / or the
> taking of any action based upon reliance on the contents of this
> transmission is strictly forbidden. If you have received this message
> in error please notify the sender by return e-mail and delete it from
> your system.
>
> Spirent Communications plc
> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United
> Kingdom.
> Tel No. +44 (0) 1293 767676
> Fax No. +44 (0) 1293 767677
>
> Registered in England Number 470893
> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10
> 9XN, United Kingdom.
>
> Or if within the US,
>
> Spirent Communications,
> 27349 Agoura Road, Calabasas, CA, 91301, USA.
> Tel No. 1-818-676- 2300
>
>
>
>
>
>
> _______________________________________________
> 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/20160622/999df37c/attachment-0001.html>
------------------------------
Message: 27
Date: Thu, 23 Jun 2016 03:11:03 +0000
From: Nick Foster <[email protected]>
To: "Marcus D. Leech" <[email protected]>, [email protected]
Subject: Re: [USRP-users] Compiling new firmware on N210
Message-ID:
<ca+jmmq-9gluarvhrrg2j6tjc+p3fbneb_ywkm+sw0z+gnxr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
To directly answer, yes, the correct firmware is usrp2p. The original
internal name of the N210 was the USRP 2 Plus.
--n
On Wed, Jun 22, 2016 at 7:53 PM Marcus D. Leech via USRP-users <
[email protected]> wrote:
> On 06/22/2016 10:40 PM, Henrique Bucher via USRP-users wrote:
>
> It looks like the usrp2p is the right firmware for the "new" hardware.
> Found this by trial and error but I still would like some official word on
> this.
>
> On Mon, Jun 20, 2016 at 8:54 AM, Henrique Bucher <[email protected]>
> wrote:
>
>> Hello
>>
>> I want to customize the current firmware on the N210 but hit a glitch.
>>
>> So far I was able to compile successfully both the FPGA bin and also the
>> USRP2 firmware binaries.
>>
>> However I do not know which one is the actual firmware for the N210 that
>> should be used in the upload tool.
>>
>> If I upload the FPGA binary with --no-fw, the fpga bin works fine: I
>> reboot and it behaves the same.
>>
>> uhd_image_loader --args="type=usrp2,addr=192.168.26.180" --no-fw
>> --fpga-path uhd/fpga-src/usrp2/top/N2x0/build-N210R4/u2plus.bin
>>
>> However when I try both the device apparently bricks, ie I cannot find it
>> anymore with uhd_find_devices or uhd_usrp_probe, even changing the
>> interface IP address:
>>
>> uhd_image_loader --args="type=usrp2,addr=192.168.26.180" --fw-path
>> uhd/firmware/usrp2/build/usrp2/usrp2_txrx_uhd.bin --fpga-path
>> uhd/fpga-src/usrp2/top/N2x0/build-N210R4/u2plus.bin
>>
>> The whole process finishes and I can see the LEDs but it just does not
>> further work, which leads me to the realization that perhaps the
>> usrp2_txrx_uhd.bin firmware is not actually a perfect replacement to the
>> factory-issued one.
>>
>> I also see these additional/potential firmwares being created but not
>> sure what is the difference between them
>>
>> ./usrp2p/bootloader/bootloader.bin
>> ./usrp2p/usrp2p_txrx_uhd.bin
>> ./usrp2/usrp2_txrx_uhd.bin
>>
>> Would you please advise?
>>
>> Thank you.
>>
>>
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> Also, you might find this useful:
>
> http://files.ettus.com/manual/md_fpga.html
>
>
> _______________________________________________
> 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/20160623/0cdf335d/attachment-0001.html>
------------------------------
Message: 28
Date: Thu, 23 Jun 2016 04:22:20 +0000
From: "Jasuja, Ishwar" <[email protected]>
To: "Marcus D. Leech" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD: 44
Message-ID:
<by2pr1001mb10612e1d5a27001cb622fd39ec...@by2pr1001mb1061.namprd10.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
There is but that list is moderated. Looks like moderator is on vacation. Have
been dormant for last few days. Absolutely no activity at all.
That is why I have been trying my luck on this list hoping someone here might
be running that software on X300.
From: Marcus D. Leech [mailto:[email protected]]
Sent: Wednesday, June 22, 2016 8:06 PM
To: Jasuja, Ishwar; [email protected]
Subject: Re: [USRP-users] UHD: 44
On 06/22/2016 10:41 PM, Jasuja, Ishwar wrote:
I am trying to get srsLTE PHY code running on X300. That open source package
uses C API.
Ah. OK. Now there's even more context.
We're happy to help on here, but the density of folks on the list who are using
srsLTE code is rather sparse--is there a specific mailng-list,
or support channel for srsLTE? [Answering my own question:
http://www.softwareradiosystems.com/mailman/listinfo/srslte-users]
From: Marcus D. Leech [mailto:[email protected]]
Sent: Wednesday, June 22, 2016 7:05 PM
To: Jasuja, Ishwar;
[email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] UHD: 44
On 06/22/2016 09:41 PM, Jasuja, Ishwar wrote:
I am sorry. I should have specified that the error code was the return value of
uhd_usrp_make() call.
Thanks,
Ishwar
You might consider using uhd_get_last_error() call to produce a string, rather
than a numeric value.
And it wasn't clear until the comment above that you were using the C, rather
than C++ API.
From: Marcus D. Leech [mailto:[email protected]]
Sent: Wednesday, June 22, 2016 6:29 PM
To: Jasuja, Ishwar;
[email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] UHD: 44
On 06/22/2016 06:28 PM, Jasuja, Ishwar wrote:
It was picking up old libuhd.so file. This always bites me..
The error code 44 is returned by UHD API call. It says it is a runtime error.
That is why I thought I might ask the question here
Thanks,
Ishwar
My point is that "Error Opening UHD: Code 44" is not a message produced by UHD
itself, so without further context (like, what UHD API call was it making, what
does 'opening UHD' actually mean in this context, etc), it's hard to give
advice.
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus D. Leech via USRP-users
Sent: Wednesday, June 22, 2016 2:56 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] UHD: 44
On 06/22/2016 05:50 PM, Jasuja, Ishwar via USRP-users wrote:
Hi,
What could cause following error?
ijasuja@ijasuja-desktop /home2/ijasuja/srsLTE/build/srslte/examples $
./pdsch_ue -f 2400000000 -a "type=x300,master_clock_rate=184.32e6"
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-0-unknown
Opening RF device...
Opening USRP with args: type=x300,master_clock_rate=184.32e6
-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
Error opening UHD: code 44
Opening bladeRF...
Unable to open device: Invalid operation or parameter
No compatible RF frontend found
Error opening rf
That "Error opening UHD" isn't a message from UHD itself, you'd have to ask the
folks who wrote pdsch_ue
Thanks,
Ishwar
Spirent Communications e-mail confidentiality.
------------------------------------------------------------------------
This e-mail contains confidential and / or privileged information belonging to
Spirent Communications plc, its affiliates and / or subsidiaries. If you are
not the intended recipient, you are hereby notified that any disclosure,
copying, distribution and / or the taking of any action based upon reliance on
the contents of this transmission is strictly forbidden. If you have received
this message in error please notify the sender by return e-mail and delete it
from your system.
Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677
Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN,
United Kingdom.
Or if within the US,
Spirent Communications,
27349 Agoura Road, Calabasas, CA, 91301, USA.
Tel No. 1-818-676- 2300
_______________________________________________
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/20160623/d947bcae/attachment-0001.html>
------------------------------
Message: 29
Date: Thu, 23 Jun 2016 09:30:15 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD: 44
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Ishwar,
picking up where the other Marcus probably had to call it a day:
as he hinted at, there's not very many (if any) srs experts on here;
that's a bad state, so you're more than welcome to contribute your own
experience, but it's really impossible for us to help you with that
specific error instantly. So although this list is pretty active, I'm
not sure we can help you better than the srsLTE list ? we're simply
lacking the expertise in that particular software; it's one of the
thousands of software products out there that uses UHD, and we can only
try to apply general experience here, no actual knowledge of the srs stack.
That being said:
As you've noticed, that is but a general error type. That's simply due
to the fact that UHD itself is C++, and it's not easy to properly wrap
the C++ exception handling for the C API ? and offering users of that C
API a million different error codes doesn't really make error handling
easier for them, either. Hence, every instance of a uhd::runtime_error
is converted to an error code of UHD_ERROR_RUNTIME==44, and details are
extracted from the C++ exception and put into the error string that
Marcus mentioned.
So, for now, I'd say your best bet is twofold:
1. Add something like
char error_string[255];
uhd_get_last_error(error_string, 255);
printf("ERROR; uhd error string: \"%s\"\n", error_string)
where the error code is printed.
2. srsLTE conveniently prints:
Opening USRP with args: type=x300,master_clock_rate=184.32e6
Can you try whether a simple
uhd_usrp_probe --args "type=x300,master_clock_rate=184.32e6"
works?
Best regards,
Marcus
On 23.06.2016 06:22, Jasuja, Ishwar via USRP-users wrote:
>
> There is but that list is moderated. Looks like moderator is on
> vacation. Have been dormant for last few days. Absolutely no activity
> at all.
>
> That is why I have been trying my luck on this list hoping someone
> here might be running that software on X300.
>
>
>
> *From:*Marcus D. Leech [mailto:[email protected]]
> *Sent:* Wednesday, June 22, 2016 8:06 PM
> *To:* Jasuja, Ishwar; [email protected]
> *Subject:* Re: [USRP-users] UHD: 44
>
>
>
> On 06/22/2016 10:41 PM, Jasuja, Ishwar wrote:
>
> I am trying to get srsLTE PHY code running on X300. That open
> source package uses C API.
>
> Ah. OK. Now there's even more context.
>
> We're happy to help on here, but the density of folks on the list who
> are using srsLTE code is rather sparse--is there a specific mailng-list,
> or support channel for srsLTE? [Answering my own question:
> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users]
>
>
>
>
>
> *From:*Marcus D. Leech [mailto:[email protected]]
> *Sent:* Wednesday, June 22, 2016 7:05 PM
> *To:* Jasuja, Ishwar; [email protected]
> <mailto:[email protected]>
> *Subject:* Re: [USRP-users] UHD: 44
>
>
>
> On 06/22/2016 09:41 PM, Jasuja, Ishwar wrote:
>
> I am sorry. I should have specified that the error code was the
> return value of uhd_usrp_make() call.
>
>
>
> Thanks,
>
> Ishwar
>
> You might consider using uhd_get_last_error() call to produce a
> string, rather than a numeric value.
>
> And it wasn't clear until the comment above that you were using the C,
> rather than C++ API.
>
>
>
>
>
>
> *From:*Marcus D. Leech [mailto:[email protected]]
> *Sent:* Wednesday, June 22, 2016 6:29 PM
> *To:* Jasuja, Ishwar; [email protected]
> <mailto:[email protected]>
> *Subject:* Re: [USRP-users] UHD: 44
>
>
>
> On 06/22/2016 06:28 PM, Jasuja, Ishwar wrote:
>
> It was picking up old libuhd.so file. This always bites me..
>
>
>
> The error code 44 is returned by UHD API call. It says it is a
> runtime error. That is why I thought I might ask the question here
>
>
>
> Thanks,
>
> Ishwar
>
>
>
> My point is that "Error Opening UHD: Code 44" is not a message
> produced by UHD itself, so without further context (like, what UHD API
> call was it making, what does 'opening UHD' actually mean in this
> context, etc), it's hard to give advice.
>
>
>
>
>
> *From:*USRP-users [mailto:[email protected]] *On
> Behalf Of *Marcus D. Leech via USRP-users
> *Sent:* Wednesday, June 22, 2016 2:56 PM
> *To:* [email protected] <mailto:[email protected]>
> *Subject:* Re: [USRP-users] UHD: 44
>
>
>
> On 06/22/2016 05:50 PM, Jasuja, Ishwar via USRP-users wrote:
>
> Hi,
>
>
>
> What could cause following error?
>
>
>
> ijasuja@ijasuja-desktop
> /home2/ijasuja/srsLTE/build/srslte/examples $ ./pdsch_ue -f
> 2400000000 -a "type=x300,master_clock_rate=184.32e6"
>
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-0-unknown
>
>
>
> Opening RF device...
>
> Opening USRP with args: type=x300,master_clock_rate=184.32e6
>
> -- X300 initialization sequence...
>
> -- Determining maximum frame size... 8000 bytes.
>
> -- Setup basic communication...
>
> *Error opening UHD: code 44*
>
> Opening bladeRF...
>
> Unable to open device: Invalid operation or parameter
>
> No compatible RF frontend found
>
> Error opening rf
>
>
>
>
>
> That "Error opening UHD" isn't a message from UHD itself, you'd have
> to ask the folks who wrote pdsch_ue
>
>
>
>
>
>
> Thanks,
>
> Ishwar
>
>
>
>
>
>
>
> Spirent Communications e-mail confidentiality.
> ------------------------------------------------------------------------
> This e-mail contains confidential and / or privileged information
> belonging to Spirent Communications plc, its affiliates and / or
> subsidiaries. If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution and / or the
> taking of any action based upon reliance on the contents of this
> transmission is strictly forbidden. If you have received this message
> in error please notify the sender by return e-mail and delete it from
> your system.
>
> Spirent Communications plc
> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United
> Kingdom.
> Tel No. +44 (0) 1293 767676
> Fax No. +44 (0) 1293 767677
>
> Registered in England Number 470893
> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10
> 9XN, United Kingdom.
>
> Or if within the US,
>
> Spirent Communications,
> 27349 Agoura Road, Calabasas, CA, 91301, USA.
> Tel No. 1-818-676- 2300
>
>
>
>
>
>
>
> _______________________________________________
> 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/20160623/b9f2ae2b/attachment-0001.html>
------------------------------
Message: 30
Date: Thu, 23 Jun 2016 11:04:46 +0200
From: Vladica Sark <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Sampling with more than 50 MSps on N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi folks,
I was thinking if it is possible to sample with more than 50 MSps (i.e.
100 MSps) on the N210. I know the Gbit Ethernet is the bottleneck, but
if I want to transmit only short bursts, and receive short bursts, it
won't be a bottleneck anymore. For example, in a TDD mode, where I
transmit 50 % of the time and I receive 50 % of the time, with 8 bit
samples, and sample rate of 100 MSps, the Ethernet throughput would be
exactly 1 Gbps in the both directions.
Is this supported by UHD and the firmware?
BR,
Vladica
------------------------------
Message: 31
Date: Thu, 23 Jun 2016 11:21:56 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Sampling with more than 50 MSps on N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Vladica,
out of the box, this will be hard; I haven't checked if this actually
works, but I slightly doubt it ? the limiting factor is that you can't
pre-buffer that much on an N210, and that would limit the durations of
your bursts severely.
On a different note: what's your use case? Aside from the filterless
BasicRX/TX, all daughterboards for the N210 have at most 40 MHz of
analog bandwidth - hence, your undecimated 100MS/s stream would carry no
more information than the same stream at 50MS/s.
Best regards,
Marcus
On 23.06.2016 11:04, Vladica Sark via USRP-users wrote:
> Hi folks,
>
> I was thinking if it is possible to sample with more than 50 MSps
> (i.e. 100 MSps) on the N210. I know the Gbit Ethernet is the
> bottleneck, but if I want to transmit only short bursts, and receive
> short bursts, it won't be a bottleneck anymore. For example, in a TDD
> mode, where I transmit 50 % of the time and I receive 50 % of the
> time, with 8 bit samples, and sample rate of 100 MSps, the Ethernet
> throughput would be exactly 1 Gbps in the both directions.
>
> Is this supported by UHD and the firmware?
>
> BR,
> Vladica
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 32
Date: Thu, 23 Jun 2016 11:42:12 +0200
From: Vladica Sark <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Sampling with more than 50 MSps on N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Marcus,
In my case data would be streamed not more than 20% of the time. It is a
TDM scenario, where the radios have only a small slots for transmission
i.e. reception. Therefore, basically, the rate would be way below 1 Gbps.
Regarding the bandwidth, I would like to do some oversampling of the
signal (2x) or so, in order do make better timing recovery. It is also
an application where RF ranging between the stations is to be performed.
In this cases, a nanosecond timing should be measured. Basically,
perfect reconstruction can be made with sinc functions, but that is
practically not possible. I agree that even interpolation, for
reconstruction of a higher sample rate signal, would introduce only
small errors, but they matter in RF ranging applications. Therefore,
sampling with higher sample rate, would be required to minimize latter
the timing errors, when the time of arrival is to be estimated.
BR,
Vladica
On 23.06.2016 11:21, Marcus M?ller via USRP-users wrote:
> Hi Vladica,
>
> out of the box, this will be hard; I haven't checked if this actually
> works, but I slightly doubt it ? the limiting factor is that you can't
> pre-buffer that much on an N210, and that would limit the durations of
> your bursts severely.
>
> On a different note: what's your use case? Aside from the filterless
> BasicRX/TX, all daughterboards for the N210 have at most 40 MHz of
> analog bandwidth - hence, your undecimated 100MS/s stream would carry no
> more information than the same stream at 50MS/s.
>
> Best regards,
> Marcus
>
> On 23.06.2016 11:04, Vladica Sark via USRP-users wrote:
>> Hi folks,
>>
>> I was thinking if it is possible to sample with more than 50 MSps
>> (i.e. 100 MSps) on the N210. I know the Gbit Ethernet is the
>> bottleneck, but if I want to transmit only short bursts, and receive
>> short bursts, it won't be a bottleneck anymore. For example, in a TDD
>> mode, where I transmit 50 % of the time and I receive 50 % of the
>> time, with 8 bit samples, and sample rate of 100 MSps, the Ethernet
>> throughput would be exactly 1 Gbps in the both directions.
>>
>> Is this supported by UHD and the firmware?
>>
>> BR,
>> Vladica
>>
>> _______________________________________________
>> 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: 33
Date: Thu, 23 Jun 2016 11:50:59 +0200
From: Vladica Sark <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Sampling with more than 50 MSps on N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
An BTW, is there a way to see the state of the buffer memory in the
N210, before putting a new transmit burst in it? Just not to overfill it.
BR,
Vladica
On 23.06.2016 11:21, Marcus M?ller via USRP-users wrote:
> Hi Vladica,
>
> out of the box, this will be hard; I haven't checked if this actually
> works, but I slightly doubt it ? the limiting factor is that you can't
> pre-buffer that much on an N210, and that would limit the durations of
> your bursts severely.
>
> On a different note: what's your use case? Aside from the filterless
> BasicRX/TX, all daughterboards for the N210 have at most 40 MHz of
> analog bandwidth - hence, your undecimated 100MS/s stream would carry no
> more information than the same stream at 50MS/s.
>
> Best regards,
> Marcus
>
> On 23.06.2016 11:04, Vladica Sark via USRP-users wrote:
>> Hi folks,
>>
>> I was thinking if it is possible to sample with more than 50 MSps
>> (i.e. 100 MSps) on the N210. I know the Gbit Ethernet is the
>> bottleneck, but if I want to transmit only short bursts, and receive
>> short bursts, it won't be a bottleneck anymore. For example, in a TDD
>> mode, where I transmit 50 % of the time and I receive 50 % of the
>> time, with 8 bit samples, and sample rate of 100 MSps, the Ethernet
>> throughput would be exactly 1 Gbps in the both directions.
>>
>> Is this supported by UHD and the firmware?
>>
>> BR,
>> Vladica
>>
>> _______________________________________________
>> 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: 34
Date: Thu, 23 Jun 2016 11:54:50 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Sampling with more than 50 MSps on N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Vladica,
my radar knowledge might be a bit rusty here, but wouldn't ranging
resolution be only proportional to effective signal bandwidth ? and that
being limited by the analog bandwidth, here?
Regarding the technical feasibility: With a minor hack in
tx_dsp_core_200.cpp::get_host_rates to allow rates down to decimation==1
(even if these exceed the link rate), you should be able to bypass all
decimating filters on the USRP, and just try. In essence, you'd send out
finite acquisition rx stream commands with appropriate timespecs for
your tdd RX, and and fill in the correct tx_metadata for send() for TX.
You can't overfill the on-device buffers. The USRP will simply not ack
further packets if the buffers are full, leading to back-pressure on the
host.
Best regards,
Marcus
On 23.06.2016 11:42, Vladica Sark via USRP-users wrote:
> Hi Marcus,
>
> In my case data would be streamed not more than 20% of the time. It is
> a TDM scenario, where the radios have only a small slots for
> transmission i.e. reception. Therefore, basically, the rate would be
> way below 1 Gbps.
>
> Regarding the bandwidth, I would like to do some oversampling of the
> signal (2x) or so, in order do make better timing recovery. It is also
> an application where RF ranging between the stations is to be
> performed. In this cases, a nanosecond timing should be measured.
> Basically, perfect reconstruction can be made with sinc functions, but
> that is practically not possible. I agree that even interpolation, for
> reconstruction of a higher sample rate signal, would introduce only
> small errors, but they matter in RF ranging applications. Therefore,
> sampling with higher sample rate, would be required to minimize latter
> the timing errors, when the time of arrival is to be estimated.
>
>
> BR,
> Vladica
>
>
>
> On 23.06.2016 11:21, Marcus M?ller via USRP-users wrote:
>> Hi Vladica,
>>
>> out of the box, this will be hard; I haven't checked if this actually
>> works, but I slightly doubt it ? the limiting factor is that you can't
>> pre-buffer that much on an N210, and that would limit the durations of
>> your bursts severely.
>>
>> On a different note: what's your use case? Aside from the filterless
>> BasicRX/TX, all daughterboards for the N210 have at most 40 MHz of
>> analog bandwidth - hence, your undecimated 100MS/s stream would carry no
>> more information than the same stream at 50MS/s.
>>
>> Best regards,
>> Marcus
>>
>> On 23.06.2016 11:04, Vladica Sark via USRP-users wrote:
>>> Hi folks,
>>>
>>> I was thinking if it is possible to sample with more than 50 MSps
>>> (i.e. 100 MSps) on the N210. I know the Gbit Ethernet is the
>>> bottleneck, but if I want to transmit only short bursts, and receive
>>> short bursts, it won't be a bottleneck anymore. For example, in a TDD
>>> mode, where I transmit 50 % of the time and I receive 50 % of the
>>> time, with 8 bit samples, and sample rate of 100 MSps, the Ethernet
>>> throughput would be exactly 1 Gbps in the both directions.
>>>
>>> Is this supported by UHD and the firmware?
>>>
>>> BR,
>>> Vladica
>>>
>>> _______________________________________________
>>> 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
------------------------------
Message: 35
Date: Thu, 23 Jun 2016 10:08:38 +0000
From: "Swanson, Craig" <[email protected]>
To: Ian Buckley <[email protected]>
Cc: Jonathon Pendlum <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] AXI_FIR encrypted IP in Modelsim protected
mode when running noc_block_fir_filter from my own cocotb testbench
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
?Ian,
I got around the issue by:
1. Create an axi_wrapper.v file around axi_fir.xci.
2. Create a new Vivado project with the Ettus setupenv.sh environment.
3. Add axi_wrapper.v and axi_fir.xci to the new project. Axi_wrapper.v is a
simple verilog wrapper to axi_fir.xci. Axi_fir.xci is an FIR IP generated from
Vivado within the Etttus setupenv.sh environment.
4. Elaborate and Synthesize the new project. Open up the synthesized
design. From the tcl window "write_verilog axi_fir_synth.v" to generate a
non-encrypted verilog file which can be simulated in Modelsim in another
environment such as cocotb.
5. Before simulation in Modelsim, in the makefile add something like "vlog
-64 -93 -work fir_compiler_v7_2_5 ~/path-to-file/axi_fir_synth.v"
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
________________________________
From: Swanson, Craig
Sent: Tuesday, June 21, 2016 3:56 AM
To: Ian Buckley
Cc: Jonathon Pendlum; [email protected]
Subject: Re: [USRP-users] AXI_FIR encrypted IP in Modelsim protected mode when
running noc_block_fir_filter from my own cocotb testbench
?Ian,
Thanks but I already have the -L secureip option in my vsim command and it is
still giving me the <protected> error.
It seems that I cannot simulate an encrypted file outside of the uhd/fpga-src
directory. I cannot figure out what environment settings Jonathon has that
only allow me to run a Xilinx IP within the /lib/rfnoc/noc_block_fir_filter_tb
directory. I think he told me at one time that Modelsim will not simulate
encrypted IP unless it is running within Vivado. I don't think I am running
cocotb within Vivado, but I am using the source setupenv.sh environment.
>From what I am reading, the best solution is to run /top/x300/make
>X310_RFNOC_HGS GUI=1, and then save the project file, and then within
>synthesis create a .vhd or . file. Then run a post-synthesis .vhd or .v
>version of the IP that is not encrypted. This is what I am trying right now.
I am using cocotb to run a python script to simulate my noc_block_Receiver.v
(customized noc_block_skeleton.v in rfnoc-radio-redo branch).
The reason for running cocotb instead of Jonathon's testbench environment is
that I am running a uhd file sink data file through my noc_block_Receiver.
I would love to do this in Jonathon's testbench but modifying his system
verilog testbench seems very, very difficult. He is an amazing code writer but
understanding what he is doing is very challenging and then modifying it seems
to be next to impossible for a novice system verilog coder like myself.
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
________________________________
From: Ian Buckley <[email protected]>
Sent: Tuesday, June 21, 2016 3:35 AM
To: Swanson, Craig
Cc: Jonathon Pendlum; [email protected]
Subject: Re: [USRP-users] AXI_FIR encrypted IP in Modelsim protected mode when
running noc_block_fir_filter from my own cocotb testbench
Craig, This may help
http://www.xilinx.com/support/answers/32936.html
-Ian
On Mon, Jun 20, 2016 at 6:22 PM, Swanson, Craig via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Jonathon,
I was hoping you might help me figure this out since it really has me stumped.
I have created a testbench using cocotb with python, and it really works well
with several of your noc_blocks, BUT with the exception if they are using any
encrypted IP such as axi_fir in noc_block_fir_filter_tb. I have gotten around
a lot of issues but this one has me out of ideas. When I run Modelsim, I get
the following error:
Loading ieee.std_logic_textio(body)
# Loading ieee.math_real(body)
# ** Fatal: (vsim-7) Failed to open <protected> file "<protected>" in
<protected> mode.
# No such file or directory. (errno = ENOENT)
# Time: 0 ps Iteration: 0 Protected:
/noc_block_Receiver/inst_axi_fir/<protected>/<protected>/<protected>/<protected>
File:
/home/craig/cocotb/examples/noc_block_Receiver/modelsim_proj/modelsim_proj.ip_user_files/ipstatic/fir_compiler_v7_2_5/hdl/fir_compiler_v7_2_vh_rfs.vhd
Line: UNKNOWN
# FATAL ERROR while loading design
# Error loading design?
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156<tel:770.298.9156>
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
_______________________________________________
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/20160623/861f407a/attachment-0001.html>
------------------------------
Message: 36
Date: Thu, 23 Jun 2016 12:15:04 +0200
From: Vladica Sark <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Sampling with more than 50 MSps on N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Markus,
You are completely right about the radars. Yes, the BW and SNR are the
main players. Anyway, my issue is with the estimator. In my case, the
estimator is sensitive, so to say, on the sample rate. There are other
approaches, where this can be avoided, but then another issues arise.
Thanks for the hack. I would try it soon, to see what comes out.
The approach is exactly the one you described, acquisition of finite
number of samples with a given timespecs and transmition of finite
length frames with given timespecs.
BR,
Vladica
On 23.06.2016 11:54, Marcus M?ller via USRP-users wrote:
> Hi Vladica,
>
> my radar knowledge might be a bit rusty here, but wouldn't ranging
> resolution be only proportional to effective signal bandwidth ? and that
> being limited by the analog bandwidth, here?
>
> Regarding the technical feasibility: With a minor hack in
> tx_dsp_core_200.cpp::get_host_rates to allow rates down to decimation==1
> (even if these exceed the link rate), you should be able to bypass all
> decimating filters on the USRP, and just try. In essence, you'd send out
> finite acquisition rx stream commands with appropriate timespecs for
> your tdd RX, and and fill in the correct tx_metadata for send() for TX.
>
> You can't overfill the on-device buffers. The USRP will simply not ack
> further packets if the buffers are full, leading to back-pressure on the
> host.
>
> Best regards,
> Marcus
>
> On 23.06.2016 11:42, Vladica Sark via USRP-users wrote:
>> Hi Marcus,
>>
>> In my case data would be streamed not more than 20% of the time. It is
>> a TDM scenario, where the radios have only a small slots for
>> transmission i.e. reception. Therefore, basically, the rate would be
>> way below 1 Gbps.
>>
>> Regarding the bandwidth, I would like to do some oversampling of the
>> signal (2x) or so, in order do make better timing recovery. It is also
>> an application where RF ranging between the stations is to be
>> performed. In this cases, a nanosecond timing should be measured.
>> Basically, perfect reconstruction can be made with sinc functions, but
>> that is practically not possible. I agree that even interpolation, for
>> reconstruction of a higher sample rate signal, would introduce only
>> small errors, but they matter in RF ranging applications. Therefore,
>> sampling with higher sample rate, would be required to minimize latter
>> the timing errors, when the time of arrival is to be estimated.
>>
>>
>> BR,
>> Vladica
>>
>>
>>
>> On 23.06.2016 11:21, Marcus M?ller via USRP-users wrote:
>>> Hi Vladica,
>>>
>>> out of the box, this will be hard; I haven't checked if this actually
>>> works, but I slightly doubt it ? the limiting factor is that you can't
>>> pre-buffer that much on an N210, and that would limit the durations of
>>> your bursts severely.
>>>
>>> On a different note: what's your use case? Aside from the filterless
>>> BasicRX/TX, all daughterboards for the N210 have at most 40 MHz of
>>> analog bandwidth - hence, your undecimated 100MS/s stream would carry no
>>> more information than the same stream at 50MS/s.
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On 23.06.2016 11:04, Vladica Sark via USRP-users wrote:
>>>> Hi folks,
>>>>
>>>> I was thinking if it is possible to sample with more than 50 MSps
>>>> (i.e. 100 MSps) on the N210. I know the Gbit Ethernet is the
>>>> bottleneck, but if I want to transmit only short bursts, and receive
>>>> short bursts, it won't be a bottleneck anymore. For example, in a TDD
>>>> mode, where I transmit 50 % of the time and I receive 50 % of the
>>>> time, with 8 bit samples, and sample rate of 100 MSps, the Ethernet
>>>> throughput would be exactly 1 Gbps in the both directions.
>>>>
>>>> Is this supported by UHD and the firmware?
>>>>
>>>> BR,
>>>> Vladica
>>>>
>>>> _______________________________________________
>>>> 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
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 37
Date: Thu, 23 Jun 2016 11:07:51 +0000
From: "Yin, Charles - 0665 - MITLL" <[email protected]>
To: Neel Pandeya <[email protected]>
Cc: "[email protected]" <[email protected]>,
"Chibane, Cherif - 0665 - MITLL" <[email protected]>
Subject: Re: [USRP-users] RFNoC Installation Problems
Message-ID:
<13657fc12b4974458e8326454370255105e...@lle2k10-mbx02.mitll.ad.local>
Content-Type: text/plain; charset="utf-8"
Neel,
Thank you very much. I had allocated 16GB of RAM for my VM originally, but
Martin recommended me to increase my swap space to 32GB, and that fixed the
problem. I am, running into another problem when trying to build GR-Ettus. I
am using the devel branch of https://github.com/ettusresearch/gr-ettus and I
am get the following error message when running cmake:
CMake Error at
/local_disk/e310_gr_3.7.9.2/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake:4
(string):
string sub-command REGEX, mode MATCH needs at least 5 arguments total to
command.
Call Stack (most recent call first):
build/CMakeFiles/2.8.12.2/CMakeSystem.cmake:6 (include)
CMakeLists.txt:24 (project)
CMake Error at
/local_disk/e310_gr_3.7.9.2/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake:5
(string):
string sub-command REGEX, mode REPLACE needs at least 6 arguments total to
command.
Call Stack (most recent call first):
build/CMakeFiles/2.8.12.2/CMakeSystem.cmake:6 (include)
CMakeLists.txt:24 (project)
-- The CXX compiler identification is GNU 4.8.4
-- The C compiler identification is GNU 4.8.4
-- Check for working CXX compiler: /usr/bin/c++
CMake Error at
/local_disk/e310_gr_3.7.9.2/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake:4
(string):
string sub-command REGEX, mode MATCH needs at least 5 arguments total to
command.
Call Stack (most recent call first):
/local_disk/e310_gr_3.7.9.2/src/gr-ettus/build/CMakeFiles/2.8.12.2/CMakeSystem.cmake:6
(include)
CMakeLists.txt:2 (PROJECT)
CMake Error at
/local_disk/e310_gr_3.7.9.2/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake:5
(string):
string sub-command REGEX, mode REPLACE needs at least 6 arguments total to
command.
Call Stack (most recent call first):
/local_disk/e310_gr_3.7.9.2/src/gr-ettus/build/CMakeFiles/2.8.12.2/CMakeSystem.cmake:6
(include)
CMakeLists.txt:2 (PROJECT)
CMake Error: Internal CMake error, TryCompile configure of cmake failed
-- Check for working CXX compiler: /usr/bin/c++ -- broken
CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:54
(message):
The C++ compiler "/usr/bin/c++" is not able to compile a simple test
program.
It fails with the following output:
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:24 (project)
-- Configuring incomplete, errors occurred!
See also
"/local_disk/e310_gr_3.7.9.2/src/gr-ettus/build/CMakeFiles/CMakeOutput.log".
See also
"/local_disk/e310_gr_3.7.9.2/src/gr-ettus/build/CMakeFiles/CMakeError.log".
I?m guessing it?s another really small problem that I am missing again. Please
let me know if you think of anything. Thanks!
Charles
From: Neel Pandeya [mailto:[email protected]]
Sent: Wednesday, June 22, 2016 12:17 PM
To: Yin, Charles - 0665 - MITLL
Cc: [email protected]; Chibane, Cherif - 0665 - MITLL
Subject: Re: [USRP-users] RFNoC Installation Problems
Hello Charles:
It looks like you're running in a Virtual Machine, and it's run out of memory.
See the line in the output:
virtual memory exhausted: Cannot allocate memory
Try increasing the memory for the VM to 4 GB, and re-building.
Please let us know if you're able to make any further progress.
--Neel Pandeya
On 21 June 2016 at 13:24, Yin, Charles - 0665 - MITLL via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hi Neel and Jonathon,
I am having problems building RFNoC with GNU Radio. I am using GNU Radio
Version 3.9.7.2 on Ubuntu 14.04. You mentioned to check for the swig package,
and I can confirm that it is there. The error from the build process is as
follows:
Linking CXX executable test-gr-blocks
[ 67%] Built target test-gr-blocks
Scanning dependencies of target _blocks_swig3
[ 67%] Building CXX object
gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/blocks_swig3PYTHON_wrap.cxx.o
{standard input}: Assembler messages:
{standard input}:380989: Warning: end of file not at end of a line; newline
inserted
{standard input}:381666: Error: invalid operands (*UND* and .ARM.extab
sections) for `-'
{standard input}:381669: Error: invalid operands (*UND* and .ARM.extab
sections) for `-'
arm-oe-linux-gnueabi-g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: ***
[gr-blocks/swig/CMakeFiles/_blocks_swig2.dir/blocks_swig2PYTHON_wrap.cxx.o]
Error 4
make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig2.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
virtual memory exhausted: Cannot allocate memory
{standard input}: Assembler messages:
{standard input}:1273004: Warning: end of file not at end of a line; newline
inserted
{standard input}:1274439: Error: unknown pseudo-op: `.'
make[2]: ***
[gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/blocks_swig0PYTHON_wrap.cxx.o]
Error 1
make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/all] Error 2
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
arm-oe-linux-gnueabi-g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: ***
[gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/blocks_swig3PYTHON_wrap.cxx.o]
Error 4
make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/all] Error 2
Linking CXX shared module _blocks_swig1.so
[ 67%] Built target _blocks_swig1
make: *** [all] Error 2
I?m not entirely sure what I am missing. Please let me know if you find
anything. Thanks!
Charles Yin
_______________________________________________
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/20160623/46796ae1/attachment-0001.html>
------------------------------
Message: 38
Date: Thu, 23 Jun 2016 11:57:22 -0300
From: Francisco Albani <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] N200 RX center frequency changes ignored
Message-ID:
<caagu92kw1nht68+yv1wfsriodzskzzjdgxoatk9dwhqspjo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
We will try, but it will take some time.
In the meantime, two thing would be very useful: ability to query frequency
to device, not to UHD block; and ability to reset device from software. Are
those possible? (We didn't find a way to do them)
Bye and thanks!
2016-06-21 22:27 GMT-03:00 Marcus D. Leech <[email protected]>:
> On 06/21/2016 09:11 PM, Francisco Albani wrote:
>
>
>
> 2016-06-21 20:49 GMT-03:00 Marcus D. Leech via USRP-users <
> [email protected]>:
>
>> Have you tried this on different N210s? Do you have attenuation in the
>> loopback cable? If so, how much?
>>
>
> *We didn't try in other N200 (we don't have N210). When everything works,
> the RX is a -30dB sample signal from the TX+PA output.*
>
> Sorry, I meant N200. If you have another N200, you could see if it is
> reproducible there.
>
>
>
>>
>>
>>
>>
> What version of UHD are you using? Have you made any custom modifications
>> to it, or the FPGA image?
>>
>
>
>
> *linux; GNU C++ version 4.9.2; Boost_105500; UHD_003.009.git-204-g984575c9
> *
>
>
> *No modifications. *
> *Thanks for your time!*
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160623/17575c34/attachment-0001.html>
------------------------------
Message: 39
Date: Thu, 23 Jun 2016 17:03:38 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] N200 RX center frequency changes ignored
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Dear Francisco,
the device has no notion of frequency itself. All you can do is ask for
the last frequency that UHD set (which multi_usrp::get_rx/tx_frequency
(UHD) or usrp_source/sink::get_frequency (GNU Radio USRP blocks) do);
that might or might not yet be in effect due to timed commands.
Resetting from software: Haven't tried that myself, but you could run
'uhd_image_loader --args "addr=xxx.xxx.xxx.xxx" --reset'.
Best regards,
Marcus
On 06/23/2016 04:57 PM, Francisco Albani via USRP-users wrote:
> We will try, but it will take some time.
>
> In the meantime, two thing would be very useful: ability to query
> frequency to device, not to UHD block; and ability to reset device
> from software. Are those possible? (We didn't find a way to do them)
>
> Bye and thanks!
>
> 2016-06-21 22:27 GMT-03:00 Marcus D. Leech <[email protected]
> <mailto:[email protected]>>:
>
> On 06/21/2016 09:11 PM, Francisco Albani wrote:
>>
>>
>> 2016-06-21 20:49 GMT-03:00 Marcus D. Leech via USRP-users
>> <[email protected] <mailto:[email protected]>>:
>>
>> Have you tried this on different N210s? Do you have
>> attenuation in the loopback cable? If so, how much?
>>
>>
>> *We didn't try in other N200 (we don't have N210). When
>> everything works, the RX is a -30dB sample signal from the TX+PA
>> output.*
> Sorry, I meant N200. If you have another N200, you could see if
> it is reproducible there.
>
>>
>>
>>
>>
>>
>>
>> What version of UHD are you using? Have you made any custom
>> modifications to it, or the FPGA image?
>>
>>
>> *linux; GNU C++ version 4.9.2; Boost_105500;
>> UHD_003.009.git-204-g984575c9
>>
>> *
>> *No modifications.
>>
>> *
>> *Thanks for your time!*
>
>
>
>
> _______________________________________________
> 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/20160623/f535ebad/attachment-0001.html>
------------------------------
Message: 40
Date: Thu, 23 Jun 2016 11:06:01 -0400
From: [email protected]
To: Francisco Albani <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] N200 RX center frequency changes ignored
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
At the device level (the synthesizer in use), there's no "frequency"
setting, but rather, the settings of a significant number of device
registers that actually tune the synthesizer to the desired frequency.
In order to make that work:
(A) The hardware device would require the ability to read-back all those
registers. Some do, some don't.
(B) The UHD-side driver would need to fetch all those registers, and
basically invert the calculations that were used to set the device
registers. There is significant opportunity for bugs in there. And it
would be different for each type of daughtercard device.
The USRPs do get reset back to a "sane" state across sessions, so if
that isn't happening, then this might be a hardware issue.
On 2016-06-23 10:57, Francisco Albani wrote:
> We will try, but it will take some time.
>
> In the meantime, two thing would be very useful: ability to query frequency
> to device, not to UHD block; and ability to reset device from software. Are
> those possible? (We didn't find a way to do them)
>
> Bye and thanks!
>
> 2016-06-21 22:27 GMT-03:00 Marcus D. Leech <[email protected]>:
>
> On 06/21/2016 09:11 PM, Francisco Albani wrote:
>
> 2016-06-21 20:49 GMT-03:00 Marcus D. Leech via USRP-users
> <[email protected]>:
>
> Have you tried this on different N210s? Do you have attenuation in the
> loopback cable? If so, how much?
>
> WE DIDN'T TRY IN OTHER N200 (WE DON'T HAVE N210). WHEN EVERYTHING WORKS, THE
> RX IS A -30DB SAMPLE SIGNAL FROM THE TX+PA OUTPUT.
Sorry, I meant N200. If you have another N200, you could see if it is
reproducible there.
>>
>
>> What version of UHD are you using? Have you made any custom modifications
>> to it, or the FPGA image?
>
> linux; GNU C++ version 4.9.2; Boost_105500; UHD_003.009.git-204-g984575c9
>
> No modifications.
>
> THANKS FOR YOUR TIME!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160623/accb0ecb/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 70, Issue 24
******************************************
