[USRP-users] RFNOC OOT module no longer building

2017-07-07 Thread Jason Matusiak via USRP-users 
I added a new block to my OOT module and now when I run make from the 
build directory things don't build properly.


I source my setup_env.sh and then run make from build and see the following:
-- PyBOMBS installed GNU Radio. Setting CMAKE_INSTALL_PREFIX to 
/home/jmat/rfnoc

-- Build type not specified: defaulting to release.
-- Boost version: 1.54.0
-- Found the following Boost libraries:
--   filesystem
--   system
Checking for GNU Radio Module: RUNTIME
 * INCLUDES=/home/jmat/rfnoc/include
 * 
LIBS=/home/jmat/rfnoc/lib/libgnuradio-runtime.so;/home/jmat/rfnoc/lib/libgnuradio-pmt.so

GNURADIO_RUNTIME_FOUND = TRUE
-- checking for module 'ettus'
*--   package 'ettus' not found*
 * INCLUDES = /home/jmat/rfnoc/include
 * LIBS = /home/jmat/rfnoc/lib/libgnuradio-ettus.so
-- checking for module 'fpga'
*--   package 'fpga' not found*
--
-- Checking for module SWIG
-- Found SWIG version 2.0.11.
CMake Warning (dev) at rfnoc/testbenches/CMakeLists.txt:2 
(add_subdirectory):

  Policy CMP0013 is not set: Duplicate binary directories are not allowed.
  Run "cmake --help-policy CMP0013" for policy details.  Use the 
cmake_policy

  command to set the policy and suppress this warning.

  The binary directory

/home/jmat/rfnoc-multiaperture/build/rfnoc/testbenches/noc_block_cpremoval_tb

  is already used to build a source directory.  This command uses it to 
build

  source directory

/home/jmat/rfnoc-multiaperture/rfnoc/testbenches/noc_block_cpremoval_tb

  which can generate conflicting build files.  CMake does not support this
  use case but it used to work accidentally and is being allowed for
  compatibility.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Error at rfnoc/testbenches/CMakeLists.txt:2 (add_subdirectory):
  add_subdirectory given source "noc_block_freqShift_tb" which is not an
  existing directory.


CMake Error at CMakeLists.txt:277 (add_custom_target):
  add_custom_target cannot create target "noc_block_freqShift_tb" because
  another target with the same name already exists.  The existing 
target is a

  custom target created in source directory
  "/home/jmat/rfnoc-multiaperture".  See documentation for policy
  CMP0002 for more details.


-- Configuring incomplete, errors occurred!
See also "/home/jmat/rfnoc-multiaperture/build/CMakeFiles/CMakeOutput.log".
make: *** [cmake_check_build_system] Error 1


Any idea what went wrong?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNOC OOT module no longer building

2017-07-07 Thread Jason Matusiak via USRP-users 
I think I solved this by blowing away everything within the testbench 
directory.  I am not sure what happened, but this seems like the best 
fix for now.


On 07/07/2017 12:04 PM, Jason Matusiak wrote:
I added a new block to my OOT module and now when I run make from the 
build directory things don't build properly.


I source my setup_env.sh and then run make from build and see the 
following:
-- PyBOMBS installed GNU Radio. Setting CMAKE_INSTALL_PREFIX to 
/home/jmat/rfnoc

-- Build type not specified: defaulting to release.
-- Boost version: 1.54.0
-- Found the following Boost libraries:
--   filesystem
--   system
Checking for GNU Radio Module: RUNTIME
 * INCLUDES=/home/jmat/rfnoc/include
 * 
LIBS=/home/jmat/rfnoc/lib/libgnuradio-runtime.so;/home/jmat/rfnoc/lib/libgnuradio-pmt.so

GNURADIO_RUNTIME_FOUND = TRUE
-- checking for module 'ettus'
*--   package 'ettus' not found*
 * INCLUDES = /home/jmat/rfnoc/include
 * LIBS = /home/jmat/rfnoc/lib/libgnuradio-ettus.so
-- checking for module 'fpga'
*--   package 'fpga' not found*
--
-- Checking for module SWIG
-- Found SWIG version 2.0.11.
CMake Warning (dev) at rfnoc/testbenches/CMakeLists.txt:2 
(add_subdirectory):

  Policy CMP0013 is not set: Duplicate binary directories are not allowed.
  Run "cmake --help-policy CMP0013" for policy details.  Use the 
cmake_policy

  command to set the policy and suppress this warning.

  The binary directory

/home/jmat/rfnoc-multiaperture/build/rfnoc/testbenches/noc_block_cpremoval_tb

  is already used to build a source directory.  This command uses it 
to build

  source directory

/home/jmat/rfnoc-multiaperture/rfnoc/testbenches/noc_block_cpremoval_tb

  which can generate conflicting build files.  CMake does not support this
  use case but it used to work accidentally and is being allowed for
  compatibility.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Error at rfnoc/testbenches/CMakeLists.txt:2 (add_subdirectory):
  add_subdirectory given source "noc_block_freqShift_tb" which is not an
  existing directory.


CMake Error at CMakeLists.txt:277 (add_custom_target):
  add_custom_target cannot create target "noc_block_freqShift_tb" because
  another target with the same name already exists.  The existing 
target is a

  custom target created in source directory
  "/home/jmat/rfnoc-multiaperture".  See documentation for policy
  CMP0002 for more details.


-- Configuring incomplete, errors occurred!
See also 
"/home/jmat/rfnoc-multiaperture/build/CMakeFiles/CMakeOutput.log".

make: *** [cmake_check_build_system] Error 1


Any idea what went wrong?


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Bypass arm processor usrp e310/e312

2017-07-07 Thread Cho, Daniel J (332C) via USRP-users 
Hello -

For the USRP E310/E312 I was wondering if it is possible to bypass the 10 Msps 
bottleneck between FPGA and ARM processor when receiving and/or transmitting 
data.  Does all data streaming in and out of the USRP have to go through the 
ARM processor or can we have the data bypass the ARM processor and go straight 
from FPGA to Host PC via Ethernet (for rx_samples_to_file program and 
tx_samples_from_file program)?

Thanks
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Bypass arm processor usrp e310/e312

2017-07-07 Thread Nick Foster via USRP-users 
There's no direct path between the FPGA and the PS-side Ethernet controller
which would support this mode of operation. You have to go through the host
at some point.

--n

On Fri, Jul 7, 2017 at 10:16 AM Cho, Daniel J (332C) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello –
>
>
>
> For the USRP E310/E312 I was wondering if it is possible to bypass the 10
> Msps bottleneck between FPGA and ARM processor when receiving and/or
> transmitting data.  Does all data streaming in and out of the USRP have to
> go through the ARM processor or can we have the data bypass the ARM
> processor and go straight from FPGA to Host PC via Ethernet (for
> rx_samples_to_file program and tx_samples_from_file program)?
>
>
>
> Thanks
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Random errors while transmitting certain BPSK/QPSK types on x310s

2017-07-07 Thread Anon Lister via USRP-users 
FYI I've noticed a very similar issue, isolated it to non usrp gnuradio
blocks in tx chain. Specifically the constellation or *psk modulator
blocks. Certain combos produced garbage IQ data(visible as several spikes
in PSD display) at regular intervals (seemingly related to sample rate),
this is visible even with a very simple flowgraph, dumping data to a file,
no USRP involved. I actually changed the underlying data I was modulating
and the bad data appeared at the same position in time no matter how many
times I ran the flowgraph. I did try moving the symbols closer away from
unity, so used something like (-.707, .707) but that didn't change anything.
Still haven't completely eliminated user error, so I was going to try to
make an example flowgraph later today and submit to discuss-gnuradio.

On Jul 6, 2017 9:38 PM, "Michael Carosino via USRP-users" <
usrp-users@lists.ettus.com> wrote:

> A quick update to this question with more info. I did some further
> analysis by capturing the received I/Q data from the USRP Source block when
> transmitting the BPSK that works without errors (symbols are 0.707+0.707j,
> -0.707-0.707j) and also when using the BPSK that gives errors (symbols are
> +1/-1). You can see in the attached image there is quite a bit of small
> magnitude anomalies for the second image (also errors are probably
> occurring a bit more frequently than I had previously estimated).
>
> To me this points to the issue being either something to do with the USRP
> or possibly with the TX chain blocks.
>
> On Thu, Jul 6, 2017 at 4:37 PM, Michael Carosino 
> wrote:
>
>> Hi all,
>>
>> running Gnuradio 3.7.10.2 and UHD 4.0.0 rfnoc-devel latest commit (tried
>> earlier versions too). I've got a simple tx/rx flowgraph going on. The
>> simple description is:
>>
>> Random input data -> Pack 1 Bit->Chunks to Symbols->Interpolating FIR
>> Filter->USRP Sink
>>
>> USRP Source-> Polyphase Clock Sync -> Costas Loop-> Constellation
>> Receiver->Unpack 1 Bit
>>
>>
>> I'm transmitting on RF-B TX/RX and receiving on RF-B RX. The system works
>> almost perfectly, except that there are single bit errors occurring (not
>> many, maybe every couple of seconds at 500k samp rate).
>>
>> Now here's the real strange thing, these errors are ONLY present if
>> running real BPSK (-1,+1), imaginary BPSK (+j,-j), or rotated QPSK/QAM
>> (+1j,-1j,+1,-1)
>>
>> If I use a BPSK having symbols with real and complex parts like
>> (-.707-.707j, .707+.707j) or QPSK (+/- .707+/- .707j) the errors are NOT
>> present.
>>
>> A couple more notes:
>> Happens if using different x310s or the same for tx/rx.
>> Happens even if I try to add a small complex value before sending data to
>> the USRP.
>> Error always happens as a single bit error (not bursty).
>>
>> Attached are the constellation plots out of the polyphase clock sync
>> (PFB) and the costas loop. My guess is the issue is either at the USRP or
>> the Polyphase Clock Sync block.
>>
>> Anyone seen something like this before? I'll probably start diving in the
>> polyphase clock sync code to figure what's going on.
>>
>> Thanks,
>> Mike
>>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Random errors while transmitting certain BPSK/QPSK types on x310s

2017-07-07 Thread Michael Carosino via USRP-users 
Hi Marcus,

you are correct, reducing the magnitude did seem to fix the issue. I am
wondering though, the gnuradio constellation modulator hier block also
seems to suffer from the same issue and doesn't have any options for
reduced magnitude output - do most people just throw in a downstream block
to reduce the magnitude? Also, is there any reference that speaks a bit
about the scaling issues that can happen with the USRP's or is that the
just type of thing you learn on the fly?

Thanks,
Mike


> Date: Thu, 06 Jul 2017 21:43:54 -0400
> From: "Marcus D. Leech" 
> To: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] Random errors while transmitting certain
> BPSK/QPSK types on x310s
> Message-ID: <595ee75a.4070...@ripnet.com>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> On 07/06/2017 09:36 PM, Michael Carosino via USRP-users wrote:
> > A quick update to this question with more info. I did some further
> > analysis by capturing the received I/Q data from the USRP Source block
> > when transmitting the BPSK that works without errors (symbols are
> > 0.707+0.707j, -0.707-0.707j) and also when using the BPSK that gives
> > errors (symbols are +1/-1). You can see in the attached image there is
> > quite a bit of small magnitude anomalies for the second image (also
> > errors are probably occurring a bit more frequently than I had
> > previously estimated).
> >
> > To me this points to the issue being either something to do with the
> > USRP or possibly with the TX chain blocks.
> With a baseband magnitude near 1, scaling issues/filtering/interpolation
> issues can combine to produce distortions.
> I usually use a baseband magnitude no greater than 0.9 or so.
> >
> > On Thu, Jul 6, 2017 at 4:37 PM, Michael Carosino  > > wrote:
> >
> > Hi all,
> >
> > running Gnuradio 3.7.10.2 and UHD 4.0.0 rfnoc-devel latest commit
> > (tried earlier versions too). I've got a simple tx/rx flowgraph
> > going on. The simple description is:
> >
> > Random input data -> Pack 1 Bit->Chunks to Symbols->Interpolating
> > FIR Filter->USRP Sink
> >
> > USRP Source-> Polyphase Clock Sync -> Costas Loop-> Constellation
> > Receiver->Unpack 1 Bit
> >
> >
> > I'm transmitting on RF-B TX/RX and receiving on RF-B RX. The
> > system works almost perfectly, except that there are single bit
> > errors occurring (not many, maybe every couple of seconds at 500k
> > samp rate).
> >
> > Now here's the real strange thing, these errors are ONLY present
> > if running real BPSK (-1,+1), imaginary BPSK (+j,-j), or rotated
> > QPSK/QAM (+1j,-1j,+1,-1)
> >
> > If I use a BPSK having symbols with real and complex parts like
> > (-.707-.707j, .707+.707j) or QPSK (+/- .707+/- .707j) the errors
> > are NOT present.
> >
> > A couple more notes:
> > Happens if using different x310s or the same for tx/rx.
> > Happens even if I try to add a small complex value before sending
> > data to the USRP.
> > Error always happens as a single bit error (not bursty).
> >
> > Attached are the constellation plots out of the polyphase clock
> > sync (PFB) and the costas loop. My guess is the issue is either at
> > the USRP or the Polyphase Clock Sync block.
> >
> > Anyone seen something like this before? I'll probably start diving
> > in the polyphase clock sync code to figure what's going on.
> >
> > Thanks,
> > Mike
> >
> >
> >
> >
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Random errors while transmitting certain BPSK/QPSK types on x310s

2017-07-07 Thread Marcus Müller via USRP-users 
Hi Michael,

point is that having a magnitude too close to 1 can lead to problems in
the FPGA side of DSP – not in GNU Radio.

Best regards,

Marcus


On 07/07/2017 07:20 PM, Michael Carosino via USRP-users wrote:
> Hi Marcus, 
>
> you are correct, reducing the magnitude did seem to fix the issue. I
> am wondering though, the gnuradio constellation modulator hier block
> also seems to suffer from the same issue and doesn't have any options
> for reduced magnitude output - do most people just throw in a
> downstream block to reduce the magnitude? Also, is there any reference
> that speaks a bit about the scaling issues that can happen with the
> USRP's or is that the just type of thing you learn on the fly?
>
> Thanks,
> Mike
>  
>
> Date: Thu, 06 Jul 2017 21:43:54 -0400
> From: "Marcus D. Leech" mailto:mle...@ripnet.com>>
> To: usrp-users@lists.ettus.com 
> Subject: Re: [USRP-users] Random errors while transmitting certain
> BPSK/QPSK types on x310s
> Message-ID: <595ee75a.4070...@ripnet.com
> >
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> On 07/06/2017 09:36 PM, Michael Carosino via USRP-users wrote:
> > A quick update to this question with more info. I did some further
> > analysis by capturing the received I/Q data from the USRP Source
> block
> > when transmitting the BPSK that works without errors (symbols are
> > 0.707+0.707j, -0.707-0.707j) and also when using the BPSK that gives
> > errors (symbols are +1/-1). You can see in the attached image
> there is
> > quite a bit of small magnitude anomalies for the second image (also
> > errors are probably occurring a bit more frequently than I had
> > previously estimated).
> >
> > To me this points to the issue being either something to do with the
> > USRP or possibly with the TX chain blocks.
> With a baseband magnitude near 1, scaling
> issues/filtering/interpolation
> issues can combine to produce distortions.
> I usually use a baseband magnitude no greater than 0.9 or so.
> >
> > On Thu, Jul 6, 2017 at 4:37 PM, Michael Carosino
> mailto:m.caros...@gmail.com>
> > >> wrote:
> >
> > Hi all,
> >
> > running Gnuradio 3.7.10.2 and UHD 4.0.0 rfnoc-devel latest
> commit
> > (tried earlier versions too). I've got a simple tx/rx flowgraph
> > going on. The simple description is:
> >
> > Random input data -> Pack 1 Bit->Chunks to
> Symbols->Interpolating
> > FIR Filter->USRP Sink
> >
> > USRP Source-> Polyphase Clock Sync -> Costas Loop->
> Constellation
> > Receiver->Unpack 1 Bit
> >
> >
> > I'm transmitting on RF-B TX/RX and receiving on RF-B RX. The
> > system works almost perfectly, except that there are single bit
> > errors occurring (not many, maybe every couple of seconds at
> 500k
> > samp rate).
> >
> > Now here's the real strange thing, these errors are ONLY present
> > if running real BPSK (-1,+1), imaginary BPSK (+j,-j), or rotated
> > QPSK/QAM (+1j,-1j,+1,-1)
> >
> > If I use a BPSK having symbols with real and complex parts like
> > (-.707-.707j, .707+.707j) or QPSK (+/- .707+/- .707j) the errors
> > are NOT present.
> >
> > A couple more notes:
> > Happens if using different x310s or the same for tx/rx.
> > Happens even if I try to add a small complex value before
> sending
> > data to the USRP.
> > Error always happens as a single bit error (not bursty).
> >
> > Attached are the constellation plots out of the polyphase clock
> > sync (PFB) and the costas loop. My guess is the issue is
> either at
> > the USRP or the Polyphase Clock Sync block.
> >
> > Anyone seen something like this before? I'll probably start
> diving
> > in the polyphase clock sync code to figure what's going on.
> >
> > Thanks,
> > Mike
> >
> >
> >
> >
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com 
> >
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Random errors while transmitting certain BPSK/QPSK types on x310s

2017-07-07 Thread Marcus D. Leech via USRP-users 
If the modulator blocks always produce in {-1,+1}, then a downstream
multipier would be required to reduce the baseband magnitude. 

It will happen with any radio where there is a translation from floating
point {-1.0,+1.0} into some integer representation on the wire, followed
by interpolation/upconversion in the digital domain on the radio, and
then out the DAC, where it may be driving the mixer a little hard, or
the subsequent RF gain stages. 

On 2017-07-07 13:20, Michael Carosino via USRP-users wrote:

> Hi Marcus,  
> 
> you are correct, reducing the magnitude did seem to fix the issue. I am 
> wondering though, the gnuradio constellation modulator hier block also seems 
> to suffer from the same issue and doesn't have any options for reduced 
> magnitude output - do most people just throw in a downstream block to reduce 
> the magnitude? Also, is there any reference that speaks a bit about the 
> scaling issues that can happen with the USRP's or is that the just type of 
> thing you learn on the fly? 
> 
> Thanks, 
> Mike 
> 
>> Date: Thu, 06 Jul 2017 21:43:54 -0400
>> From: "Marcus D. Leech" 
>> To: usrp-users@lists.ettus.com
>> Subject: Re: [USRP-users] Random errors while transmitting certain
>> BPSK/QPSK types on x310s
>> Message-ID: <595ee75a.4070...@ripnet.com>
>> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>> 
>> On 07/06/2017 09:36 PM, Michael Carosino via USRP-users wrote:
>>> A quick update to this question with more info. I did some further
>>> analysis by capturing the received I/Q data from the USRP Source block
>>> when transmitting the BPSK that works without errors (symbols are
>>> 0.707+0.707j, -0.707-0.707j) and also when using the BPSK that gives
>>> errors (symbols are +1/-1). You can see in the attached image there is
>>> quite a bit of small magnitude anomalies for the second image (also
>>> errors are probably occurring a bit more frequently than I had
>>> previously estimated).
>>> 
>>> To me this points to the issue being either something to do with the
>>> USRP or possibly with the TX chain blocks.
>> With a baseband magnitude near 1, scaling issues/filtering/interpolation
>> issues can combine to produce distortions.
>> I usually use a baseband magnitude no greater than 0.9 or so.
>>> 
>>> On Thu, Jul 6, 2017 at 4:37 PM, Michael Carosino >> > wrote:
>>> 
>>> Hi all,
>>> 
>>> running Gnuradio 3.7.10.2 and UHD 4.0.0 rfnoc-devel latest commit
>>> (tried earlier versions too). I've got a simple tx/rx flowgraph
>>> going on. The simple description is:
>>> 
>>> Random input data -> Pack 1 Bit->Chunks to Symbols->Interpolating
>>> FIR Filter->USRP Sink
>>> 
>>> USRP Source-> Polyphase Clock Sync -> Costas Loop-> Constellation
>>> Receiver->Unpack 1 Bit
>>> 
>>> 
>>> I'm transmitting on RF-B TX/RX and receiving on RF-B RX. The
>>> system works almost perfectly, except that there are single bit
>>> errors occurring (not many, maybe every couple of seconds at 500k
>>> samp rate).
>>> 
>>> Now here's the real strange thing, these errors are ONLY present
>>> if running real BPSK (-1,+1), imaginary BPSK (+j,-j), or rotated
>>> QPSK/QAM (+1j,-1j,+1,-1)
>>> 
>>> If I use a BPSK having symbols with real and complex parts like
>>> (-.707-.707j, .707+.707j) or QPSK (+/- .707+/- .707j) the errors
>>> are NOT present.
>>> 
>>> A couple more notes:
>>> Happens if using different x310s or the same for tx/rx.
>>> Happens even if I try to add a small complex value before sending
>>> data to the USRP.
>>> Error always happens as a single bit error (not bursty).
>>> 
>>> Attached are the constellation plots out of the polyphase clock
>>> sync (PFB) and the costas loop. My guess is the issue is either at
>>> the USRP or the Polyphase Clock Sync block.
>>> 
>>> Anyone seen something like this before? I'll probably start diving
>>> in the polyphase clock sync code to figure what's going on.
>>> 
>>> Thanks,
>>> Mike
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1]
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
 

Links:
--
[1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Random errors while transmitting certain BPSK/QPSK types on x310s

2017-07-07 Thread Marcus Müller via USRP-users 
Oh! If that is the case, yes, please do make an example FG, and if you
find the time, also open an issue on
https://github.com/gnuradio/gnuradio/issues .

Thanks!

Marcus


On 07/07/2017 07:19 PM, Anon Lister via USRP-users wrote:
> FYI I've noticed a very similar issue, isolated it to non usrp
> gnuradio blocks in tx chain. Specifically the constellation or *psk
> modulator blocks. Certain combos produced garbage IQ data(visible as
> several spikes in PSD display) at regular intervals (seemingly related
> to sample rate), this is visible even with a very simple flowgraph,
> dumping data to a file, no USRP involved. I actually changed the
> underlying data I was modulating and the bad data appeared at the same
> position in time no matter how many times I ran the flowgraph. I did
> try moving the symbols closer away from unity, so used something like
> (-.707, .707) but that didn't change anything.
> Still haven't completely eliminated user error, so I was going to try
> to make an example flowgraph later today and submit to discuss-gnuradio.
>
> On Jul 6, 2017 9:38 PM, "Michael Carosino via USRP-users"
> mailto:usrp-users@lists.ettus.com>> wrote:
>
> A quick update to this question with more info. I did some further
> analysis by capturing the received I/Q data from the USRP Source
> block when transmitting the BPSK that works without errors
> (symbols are 0.707+0.707j, -0.707-0.707j) and also when using the
> BPSK that gives errors (symbols are +1/-1). You can see in the
> attached image there is quite a bit of small magnitude anomalies
> for the second image (also errors are probably occurring a bit
> more frequently than I had previously estimated).
>
> To me this points to the issue being either something to do with
> the USRP or possibly with the TX chain blocks.
>
> On Thu, Jul 6, 2017 at 4:37 PM, Michael Carosino
> mailto:m.caros...@gmail.com>> wrote:
>
> Hi all,
>
> running Gnuradio 3.7.10.2 and UHD 4.0.0 rfnoc-devel latest
> commit (tried earlier versions too). I've got a simple tx/rx
> flowgraph going on. The simple description is:
>
> Random input data -> Pack 1 Bit->Chunks to
> Symbols->Interpolating FIR Filter->USRP Sink
>
> USRP Source-> Polyphase Clock Sync -> Costas Loop->
> Constellation Receiver->Unpack 1 Bit
>
>
> I'm transmitting on RF-B TX/RX and receiving on RF-B RX. The
> system works almost perfectly, except that there are single
> bit errors occurring (not many, maybe every couple of seconds
> at 500k samp rate). 
>
> Now here's the real strange thing, these errors are ONLY
> present if running real BPSK (-1,+1), imaginary BPSK (+j,-j),
> or rotated QPSK/QAM (+1j,-1j,+1,-1)
>
> If I use a BPSK having symbols with real and complex parts
> like (-.707-.707j, .707+.707j) or QPSK (+/- .707+/- .707j) the
> errors are NOT present.
>
> A couple more notes: 
> Happens if using different x310s or the same for tx/rx.
> Happens even if I try to add a small complex value before
> sending data to the USRP.
> Error always happens as a single bit error (not bursty).
>
> Attached are the constellation plots out of the polyphase
> clock sync (PFB) and the costas loop. My guess is the issue is
> either at the USRP or the Polyphase Clock Sync block. 
>
> Anyone seen something like this before? I'll probably start
> diving in the polyphase clock sync code to figure what's going on.
>
> Thanks,
> Mike
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com 
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Random errors while transmitting certain BPSK/QPSK types on x310s

2017-07-07 Thread Ron Economos via USRP-users 
You can change the gain setting on the interpolating FIR filter to 
accomplish this.


The QT GUI Histogram Sink can be used to set a gain value that limits 
the IQ values to +1/-1.


Ron

On 07/07/2017 10:20 AM, Michael Carosino via USRP-users wrote:

Hi Marcus,

you are correct, reducing the magnitude did seem to fix the issue. I 
am wondering though, the gnuradio constellation modulator hier block 
also seems to suffer from the same issue and doesn't have any options 
for reduced magnitude output - do most people just throw in a 
downstream block to reduce the magnitude? Also, is there any reference 
that speaks a bit about the scaling issues that can happen with the 
USRP's or is that the just type of thing you learn on the fly?


Thanks,
Mike

Date: Thu, 06 Jul 2017 21:43:54 -0400
From: "Marcus D. Leech" mailto:mle...@ripnet.com>>
To: usrp-users@lists.ettus.com 
Subject: Re: [USRP-users] Random errors while transmitting certain
BPSK/QPSK types on x310s
Message-ID: <595ee75a.4070...@ripnet.com
>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

On 07/06/2017 09:36 PM, Michael Carosino via USRP-users wrote:
> A quick update to this question with more info. I did some further
> analysis by capturing the received I/Q data from the USRP Source
block
> when transmitting the BPSK that works without errors (symbols are
> 0.707+0.707j, -0.707-0.707j) and also when using the BPSK that gives
> errors (symbols are +1/-1). You can see in the attached image
there is
> quite a bit of small magnitude anomalies for the second image (also
> errors are probably occurring a bit more frequently than I had
> previously estimated).
>
> To me this points to the issue being either something to do with the
> USRP or possibly with the TX chain blocks.
With a baseband magnitude near 1, scaling
issues/filtering/interpolation
issues can combine to produce distortions.
I usually use a baseband magnitude no greater than 0.9 or so.
>
> On Thu, Jul 6, 2017 at 4:37 PM, Michael Carosino
mailto:m.caros...@gmail.com>
> >> wrote:
>
> Hi all,
>
> running Gnuradio 3.7.10.2 and UHD 4.0.0 rfnoc-devel latest
commit
> (tried earlier versions too). I've got a simple tx/rx flowgraph
> going on. The simple description is:
>
> Random input data -> Pack 1 Bit->Chunks to
Symbols->Interpolating
> FIR Filter->USRP Sink
>
> USRP Source-> Polyphase Clock Sync -> Costas Loop->
Constellation
> Receiver->Unpack 1 Bit
>
>
> I'm transmitting on RF-B TX/RX and receiving on RF-B RX. The
> system works almost perfectly, except that there are single bit
> errors occurring (not many, maybe every couple of seconds at
500k
> samp rate).
>
> Now here's the real strange thing, these errors are ONLY present
> if running real BPSK (-1,+1), imaginary BPSK (+j,-j), or rotated
> QPSK/QAM (+1j,-1j,+1,-1)
>
> If I use a BPSK having symbols with real and complex parts like
> (-.707-.707j, .707+.707j) or QPSK (+/- .707+/- .707j) the errors
> are NOT present.
>
> A couple more notes:
> Happens if using different x310s or the same for tx/rx.
> Happens even if I try to add a small complex value before
sending
> data to the USRP.
> Error always happens as a single bit error (not bursty).
>
> Attached are the constellation plots out of the polyphase clock
> sync (PFB) and the costas loop. My guess is the issue is
either at
> the USRP or the Polyphase Clock Sync block.
>
> Anyone seen something like this before? I'll probably start
diving
> in the polyphase clock sync code to figure what's going on.
>
> Thanks,
> Mike
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com 
>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com





___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] rfnoc-modtool cores

2017-07-07 Thread Jason Matusiak via USRP-users 
Circling back to this EJ, what should I make my Makefile.OOT.inc look 
like to include two directories, something like this?:

OOT_DIR = /home/jmat/rfnoc-multiaperture/rfnoc
OOT_DIR = /home/jmat/rfnoc-nocblocks/rfnoc
include $(OOT_DIR)/Makefile.inc



On 06/14/2017 08:43 PM, EJ Kreinar wrote:

Yes, this is an admitted hack, I should say.

The assignment to MY_OOT_DIR := OOT_DIR in the 
rfnoc-ootexample/rfnoc/Makefile.inc forces the evaluation of OOT_DIR 
immediately, and the OOT modules uses MY_OOT_DIR from then on, for 
example. I've tested this successfully with multiple different OOT repos.


If you have a suggested improvement that's less hacky though, I'm 
definitely interested :)


EJ

On Wed, Jun 14, 2017 at 2:08 PM, Jason Matusiak 
mailto:ja...@gardettoengineering.com>> 
wrote:


EJ,
I am creating a new RFNoC repo and thought I would go through your
write up and see if I can find anything that we missed while you
and I were working offline.  The first thing I wondered was, in
the Makefile.OOT.inc, can I have more than one OOT_DIR?  I have
one in there right now for my current blocks, but I am not sure
how to point to a different folder without screwing your setup up.

~Jason


On 05/23/2017 10:04 PM, EJ Kreinar wrote:

Hi Jason and others,

As a follow up, I put together an rfnoc OOT repo that uses
Makefiles to build Vivado IP and HLS IP:
https://github.com/ejk43/rfnoc-ootexample


The simulations should run successfully when uhd-fpga is set up
correctly (see readme),  and also should build the OOT noc_blocks
into an FPGA image using "make E310_RFNOC" etc etc.

Hope this helps,
EJ

On Fri, May 19, 2017 at 12:08 PM, EJ Kreinar mailto:ejkrei...@gmail.com>> wrote:

Jason,

Sure, I'd say just clone my fpga repo and apply the patch for
now.  Quick instructions:

1. In your uhd-fpga repo: `git remote add ejk
https://github.com/ejk43/fpga.git`

a. This now sets up a remote named "ejk" which points to
my fork
2. Then: `git fetch ejk new_oot_includes`
3. Then you can either checkout this branch (if you have no
other changes on your uhd-fpga repo), or cherry-pick the
commits from the new_oot_includes branch.


In lieu of an example OOT repo, here's how I set up my
"rfnoc" folder structure in the OOT repo:

rfnoc:
  + Makefile.inc
  + blocks
  + testbenches
  + fpga-src
 + Makefile.inc

 + noc_block_testblock.v

  + ip
 + Makefile.inc
 + my_ip
+ my_ip.xci
+ Makefile.inc



Here's an example top-level Makefile.inc:

RFNOC_MYTEST_DIR := $(OOT_DIR)
include $(abspath $(RFNOC_MYTEST_DIR)/fpga-src/Makefile.inc)
include $(abspath $(RFNOC_MYTEST_DIR)/ip/Makefile.inc)



Then the fpga-src Makefile.inc:

RFNOC_OOT_SRCS += $(addprefix
$(RFNOC_MYTEST_DIR)/fpga-src/, \
noc_block_testblock.v \
)



Then the IP Makefile.inc (modeled after the Makefile.inc in
the uhd-fpga/usrp3/lib/ip:

include $(RFNOC_MYTEST_DIR)/ip/my_ip/Makefile.inc

LIB_MYTEST_IP_XCI_SRCS = \
$(LIB_IP_MY_IP_SRCS)

LIB_MYTEST_IP_SYNTH_OUTPUTS = \
$(LIB_IP_MY_IP_OUTS)

LIB_IP_XCI_SRCS += $(LIB_MYTEST_IP_XCI_SRCS)



And finally, the Makefile.inc inside the my_ip directory
(modeled after the lib/ip/xxx Makefile.inc):

include $(TOOLS_DIR)/make/viv_ip_builder.mak

LIB_IP_MY_IP_SRCS = $(IP_BUILD_DIR)/my_ip/my_ip.xci

LIB_IP_MY_IP_OUTS = $(addprefix $(IP_BUILD_DIR)/my_ip/, \
my_ip.xci.out \
synth/my_ip.vhd \
)

$(LIB_IP_MY_IP_SRCS) $(LIB_IP_MY_IP_OUTS) :
$(LIB_IP_DIR)/my_ip/my_ip.xci
$(call

BUILD_VIVADO_IP,my_ip,$(ARCH),$(PART_ID),$(LIB_IP_DIR),$(IP_BUILD_DIR),0)



It's also possible to rejigger the testbench makefiles to
build the OOT IP for your testbench.

Again, I should pull this into an example OOT repo sometime
soon, which would make it a bit easier to have an example.
Let me know if you hit any problems.

EJ

On Fri, May 19, 2017 at 8:38 AM, Jason Matusiak
mailto:ja...@gardettoengineering.com>> wrote:

EJ, that looks exactly like what I need to do. Is there a
way for me to patch in your changes so I can try to use
them while we wait for Ettus to (dis)approve your PR?

Thanks!
~Jason



On 05/18/2017 04:11 PM, EJ Kreinar wrote:

Hi Jason,

I currently have a

Re: [USRP-users] Random errors while transmitting certain BPSK/QPSK types on x310s

2017-07-07 Thread Ron Economos via USRP-users 
I've created an OOT module with a little utility I use to print peak IQ 
levels. This allows for precise setting of the gain to insure IQ levels 
are within +1/-1.


https://github.com/drmpeg/gr-iqlevels

Ron

On 07/07/2017 11:28 AM, Ron Economos via USRP-users wrote:


You can change the gain setting on the interpolating FIR filter to 
accomplish this.


The QT GUI Histogram Sink can be used to set a gain value that limits 
the IQ values to +1/-1.


Ron

On 07/07/2017 10:20 AM, Michael Carosino via USRP-users wrote:

Hi Marcus,

you are correct, reducing the magnitude did seem to fix the issue. I 
am wondering though, the gnuradio constellation modulator hier block 
also seems to suffer from the same issue and doesn't have any options 
for reduced magnitude output - do most people just throw in a 
downstream block to reduce the magnitude? Also, is there any 
reference that speaks a bit about the scaling issues that can happen 
with the USRP's or is that the just type of thing you learn on the fly?


Thanks,
Mike

Date: Thu, 06 Jul 2017 21:43:54 -0400
From: "Marcus D. Leech" mailto:mle...@ripnet.com>>
To: usrp-users@lists.ettus.com 
Subject: Re: [USRP-users] Random errors while transmitting certain
BPSK/QPSK types on x310s
Message-ID: <595ee75a.4070...@ripnet.com
>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

On 07/06/2017 09:36 PM, Michael Carosino via USRP-users wrote:
> A quick update to this question with more info. I did some further
> analysis by capturing the received I/Q data from the USRP
Source block
> when transmitting the BPSK that works without errors (symbols are
> 0.707+0.707j, -0.707-0.707j) and also when using the BPSK that
gives
> errors (symbols are +1/-1). You can see in the attached image
there is
> quite a bit of small magnitude anomalies for the second image (also
> errors are probably occurring a bit more frequently than I had
> previously estimated).
>
> To me this points to the issue being either something to do
with the
> USRP or possibly with the TX chain blocks.
With a baseband magnitude near 1, scaling
issues/filtering/interpolation
issues can combine to produce distortions.
I usually use a baseband magnitude no greater than 0.9 or so.
>
> On Thu, Jul 6, 2017 at 4:37 PM, Michael Carosino
mailto:m.caros...@gmail.com>
> >> wrote:
>
> Hi all,
>
> running Gnuradio 3.7.10.2 and UHD 4.0.0 rfnoc-devel latest
commit
> (tried earlier versions too). I've got a simple tx/rx flowgraph
> going on. The simple description is:
>
> Random input data -> Pack 1 Bit->Chunks to
Symbols->Interpolating
> FIR Filter->USRP Sink
>
> USRP Source-> Polyphase Clock Sync -> Costas Loop->
Constellation
> Receiver->Unpack 1 Bit
>
>
> I'm transmitting on RF-B TX/RX and receiving on RF-B RX. The
> system works almost perfectly, except that there are single bit
> errors occurring (not many, maybe every couple of seconds
at 500k
> samp rate).
>
> Now here's the real strange thing, these errors are ONLY
present
> if running real BPSK (-1,+1), imaginary BPSK (+j,-j), or
rotated
> QPSK/QAM (+1j,-1j,+1,-1)
>
> If I use a BPSK having symbols with real and complex parts like
> (-.707-.707j, .707+.707j) or QPSK (+/- .707+/- .707j) the
errors
> are NOT present.
>
> A couple more notes:
> Happens if using different x310s or the same for tx/rx.
> Happens even if I try to add a small complex value before
sending
> data to the USRP.
> Error always happens as a single bit error (not bursty).
>
> Attached are the constellation plots out of the polyphase clock
> sync (PFB) and the costas loop. My guess is the issue is
either at
> the USRP or the Polyphase Clock Sync block.
>
> Anyone seen something like this before? I'll probably start
diving
> in the polyphase clock sync code to figure what's going on.
>
> Thanks,
> Mike
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com 
>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com





___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.

Re: [USRP-users] X310 transmit underflow when sampling rate is low

2017-07-07 Thread Hood, Christopher L. via USRP-users 
Sorry for the late reply,

The MTU is set to 9000.

The time spec was varied from a few dozen ms up to several seconds in the 
future with
no change in behavior.

chris

From: Jonathon Pendlum [mailto:jonathon.pend...@ettus.com]
Sent: Tuesday, June 27, 2017 12:18 PM
To: Hood, Christopher L. 
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] X310 transmit underflow when sampling rate is low

Hi Chris,

What is your MTU size set to? How far into the future do you set the timespec?

Jonathon

On Thu, Jun 22, 2017 at 2:12 PM, Hood, Christopher L. via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
I’m running a simple one pulse loopback transmit/receive and am running into 
transmit underflows when the sampling rate is LOW. Specifically, for my short 
30 us pulse, the underflow occurs when the sampling rate is 5 MHz or lower. I 
ran the test at 10, 20, 25, 33.3, 50, 100, and 200 MHz with no issues at all. 
The X310 is connected to the host over 10 gig Ethernet, and the tx stream send 
command is set with metadata so start of burst=1, end of burst=1, has time=1, 
and with the time spec well into the future wrt the device. The send command 
returns without incident, and when the time spec elapses, the async message is 
received, which indicates an underflow. Looking at the receive samples, the 
underflow appears to occur at the beginning of the intended transmission, 
because much of the intended waveform is being received.

Any direction into fixing this issue would be appreciated.

Thanks,
chris



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] ADC self-test failed

2017-07-07 Thread Nate Temple via USRP-users 
Hi Sam,

Can you please email into supp...@ettus.com. We can debug further off the 
mailing list.

Regards,
Nate


> On Jul 6, 2017, at 8:39 AM, Sam Vogel  wrote:
> 
> Hi Nate,
> 
> Sure, our company is using a custom UHD and I will have to redact part of the 
> text. When I run the command it outputs:
> 003.009.001
> This x300 has always been problematic. We have a different X300 that works 
> fine with this setup. The problem occurs when I duplicate the setup for use 
> with our second X300. We need the second setup running also. I have never 
> updated the UHD.
> Hopefully this is helpful, I assume our custom UHD is built from 003.009.001. 
> 
> Thanks so much,
> Sam
> 
> On Thu, Jul 6, 2017 at 1:12 AM, Nate Temple  wrote:
> Hi Sam,
> 
> Can you run the following command send what it's output is? This will print 
> out the exact version of UHD you're using: uhd_usrp_probe --version
> 
> My second question was if you have changed any thing with your setup since 
> the X300 has became problematic ? Have you updated the UHD version at all 
> recently?
> 
> Regards,
> Nate Temple
> 
> 
> > On Jul 5, 2017, at 9:10 PM, Sam Vogel  wrote:
> >
> > Hi Nate,
> >
> > Yes, there is a uhd_usrp_probe program in /examples/utils, perhaps this 
> > means I'm using the 'uhd_usrp_probe' version? I can get more info on this 
> > tomorrow when I'm in the office. We have two different X300 boards, let's 
> > call them X300A and X300B. Each are a different H/W revision. We have been 
> > using X300A for a while and the problem now occurs when I try to use X300B 
> > with the same code base we use for X300A. The main difference in the setups 
> > is the X300 board itself.  A lot of the code we use is custom and I don't 
> > know if starting from a fresh copy of the Ettus repository is feasible.
> >
> > Thanks,
> > Sam
> >
> > On Wed, Jul 5, 2017 at 8:29 PM, Nate Temple  wrote:
> > Hi Sam,
> >
> > Which version of UHD are you using? (uhd_usrp_probe --version)
> >
> > Have you recently updated UHD, or has anything changed in your setup from 
> > when it was previously work to now?
> >
> > Regards,
> > Nate Temple
> >
> > On Wed, Jul 5, 2017 at 3:08 PM, Sam Vogel via USRP-users 
> >  wrote:
> > Hi,
> >
> > This happens every time.
> >
> > Thanks,
> > Sam
> >
> > On Wed, Jul 5, 2017 at 6:01 PM, Martin Braun via USRP-users 
> >  wrote:
> > Does this happen intermittently? Or every time?
> >
> > -- M
> >
> > On 06/13/2017 01:55 PM, Sam Vogel via USRP-users wrote:
> > > Hi All, I’m running into an issue with our x300 revision E.  Any help
> > > resolving this is greatly appreciated.
> > >
> > > Following the procedure to recover the EEPROM yields a problem.
> > >
> > > [vogels@lprbld12 utils]$ ./usrp_burn_mb_eeprom
> > > --args="recover_mb_eeprom,addr=192.167.10.111" --values="revision=5"
> > >
> > > Creating USRP device from address: recover_mb_eeprom,addr=192.167.10.111
> > >
> > > -- X300 initialization sequence...
> > >
> > > -- Determining maximum frame size... 8000 bytes.
> > >
> > > -- Setup basic communication...
> > >
> > > -- Loading values from EEPROM...
> > >
> > >
> > >
> > > UHD Warning:
> > >
> > > UHD is operating in EEPROM Recovery Mode which disables hardware
> > > version checks.
> > >
> > > Operating in this mode may cause hardware damage and unstable radio
> > > performance!
> > >
> > > -- Setup RF frontend clocking...
> > >
> > >
> > >
> > > UHD Warning:
> > >
> > > Environment variable 'USRP_X300_REFERENCE_CLOCK_RATE_HZ' not found,
> > > defaulting to reference clock rate of 1000.00 Hz
> > >
> > > -- Using specified reference / master clock rates of 10.0 / 200.0 MHz
> > >
> > > -- Radio 1x clock:200
> > >
> > > -- Initialize Radio0 control...
> > >
> > > -- Performing register loopback test... pass
> > >
> > > -- Initialize Radio1 control...
> > >
> > > -- Performing register loopback test... pass
> > >
> > > Error: RuntimeError: ADC self-test failed! Ramp checker status:
> > > {ADC0_I=Bit Errors!, ADC0_Q=Bit Errors!, ADC1_I=Good, ADC1_Q=Good}
> > >
> > >
> > >
> > > Thanks !
> > >
> > > -Sam
> > >
> > >
> > >
> > > ___
> > > USRP-users mailing list
> > > USRP-users@lists.ettus.com
> > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> > >
> >
> >
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
> 
> 


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Different streaming modes at the same time with same USRP hardware

2017-07-07 Thread Michael West via USRP-users 
Hi Felipe,

If it works, it must be right!  The code looks fine to me.

Regards,
Michael

On Mon, Jul 3, 2017 at 3:58 AM, Felipe Augusto Pereira de Figueiredo <
zz4...@gmail.com> wrote:

> Dear Michael,
>
> I've followed your suggestion and hacked the rx_samples_c.c example.
> It seems to be working but I'm not sure if that is the right way of doing
> that.
> Could you please have a quick look and tell me if that is the correct way
> of creating 2 different RX streams.
>
> Thanks and Kind Regards,
>
> Felipe Augusto
>
> /*
>  * Copyright 2015 Ettus Research LLC
>  *
>  * This program is free software: you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License as published by
>  * the Free Software Foundation, either version 3 of the License, or
>  * (at your option) any later version.
>  *
>  * This program is distributed in the hope that it will be useful,
>  * but WITHOUT ANY WARRANTY; without even the implied warranty of
>  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>  * GNU General Public License for more details.
>  *
>  * You should have received a copy of the GNU General Public License
>  * along with this program.  If not, see .
>  */
>
> #include 
>
> #include "getopt.h"
>
> #include 
> #include 
> #include 
>
> #define EXECUTE_OR_GOTO(label, ...) \
> if(__VA_ARGS__){ \
> return_code = EXIT_FAILURE; \
> goto label; \
> }
>
> void print_help(void){
> fprintf(stderr, "rx_samples_c - A simple RX example using UHD's C
> API\n\n"
>
> "Options:\n"
> "-a (device args)\n"
> "-f (frequency in Hz)\n"
> "-r (sample rate in Hz)\n"
> "-g (gain)\n"
> "-n (number of samples to receive)\n"
> "-o (output filename, default = \"out.dat\")\n"
> "-v (enable verbose prints)\n"
> "-h (print this help message)\n");
> };
>
> int main(int argc, char* argv[])
> {
> if(uhd_set_thread_priority(uhd_default_thread_priority, true)){
> fprintf(stderr, "Unable to set thread priority. Continuing
> anyway.\n");
> }
>
> int option = 0;
> double freq = 2.4e9;
> double rate = 10e6;
> double gain = 5.0;
> char* device_args = "";
> size_t channel[2] = {0,1};
> char *filename0 = "out0.dat", *filename1 = "out1.dat";
> size_t n_samples = 100;
> bool verbose = false;
> int return_code = EXIT_SUCCESS;
> bool custom_filename0 = false, custom_filename1 = false;
> char error_string[512];
>
> // Process options
> while((option = getopt(argc, argv, "a:f:r:g:n:o:O:vh")) != -1){
> switch(option){
> case 'a':
> device_args = strdup(optarg);
> break;
>
> case 'f':
> freq = atof(optarg);
> break;
>
> case 'r':
> rate = atof(optarg);
> break;
>
> case 'g':
> gain = atof(optarg);
> break;
>
> case 'n':
> n_samples = atoi(optarg);
> break;
>
> case 'o':
> filename0 = strdup(optarg);
> custom_filename0 = true;
> break;
>
> case 'O':
> filename1 = strdup(optarg);
> custom_filename1 = true;
> break;
>
> case 'v':
> verbose = true;
> break;
>
> case 'h':
> print_help();
> goto free_option_strings;
>
> default:
> print_help();
> return_code = EXIT_FAILURE;
> goto free_option_strings;
> }
> }
>
> // Create USRP
> uhd_usrp_handle usrp;
> fprintf(stderr, "Creating USRP with args \"%s\"...\n", device_args);
> EXECUTE_OR_GOTO(free_option_strings,
> uhd_usrp_make(&usrp, device_args)
> )
>
> // Create RX streamer #0.
> uhd_rx_streamer_handle rx_streamer0;
> EXECUTE_OR_GOTO(free_usrp,
> uhd_rx_streamer_make(&rx_streamer0)
> )
>
> // Create RX metadata #0.
> uhd_rx_metadata_handle md0;
> EXECUTE_OR_GOTO(free_rx_streamer0,
> uhd_rx_metadata_make(&md0)
> )
>
> // Create RX streamer #1.
> uhd_rx_streamer_handle rx_streamer1;
> EXECUTE_OR_GOTO(free_usrp,
> uhd_rx_streamer_make(&rx_streamer1)
> )
>
> // Create RX metadata #1.
> uhd_rx_metadata_handle md1;
> EXECUTE_OR_GOTO(free_rx_streamer1,
> uhd_rx_metadata_make(&md1)
> )
>
> // Create other necessary structs
> uhd_tune_request_t tune_request = {
> .target_freq = freq,
> .rf_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO,
> .dsp_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO,
>

Re: [USRP-users] Different streaming modes at the same time with same USRP hardware

2017-07-07 Thread Felipe Augusto Pereira de Figueiredo via USRP-users 
Thanks Michael!

Now I'm trying to create different streamers for TX and RX in channels
0 and 1, but my application running on a b210 returns the following
error:

Error opening RX stream for channel 1 with error code: 44
No compatible RF frontend found
Error opening rf

I checked and code 44 means UHD_ERROR_RUNTIME.

The most strange thing is that with a x310 the same code (see code
below) works. The code I sent previously to you runs with both b210
and x310 USRPs, however, it only creates/configures RX streamers.

What could be the reason for this different behaviour? Is there a
sequence for creating and setting TX and RX streamers for channels 0
and 1?

Thanks and Kind Regards,

Felipe Augusto

   /* Find available devices */
uhd_string_vector_handle devices_str;
uhd_string_vector_make(&devices_str);
uhd_usrp_find("", &devices_str);

char args2[512];

handler->dynamic_rate = true;

// Allow NULL parameter
if (args == NULL) {
  args = "";
}
handler->devname = NULL;

// Initialize handler
handler->uhd_error_handler = NULL;

/* If device type or name not given in args, choose a B200 */
if (args[0]=='\0') {
  if (find_string(devices_str, "type=b200") && !strstr(args,
"recv_frame_size")) {
// If B200 is available, use it
args = "type=b200";
handler->devname = DEVNAME_B200;
  } else if (find_string(devices_str, "type=x300")) {
// Else if X300 is available, set master clock rate now (with
x310 it can't be changed later)
args = "type=x300,master_clock_rate=184.32e6";// If no
argument is passed we set master clock rate to 184.32 MHz in order to
use standard LTE rates, i.e., carrier sepration of 15 KHz.
//args = "type=x300,master_clock_rate=200e6"; // In case we
need longer CP periods, we should set master clock rate to 200 MHz in
order to be able to set the sampling rate to 5 MHz and have bigger
CPs.
handler->dynamic_rate = false;
handler->devname = DEVNAME_X300;
  }
} else {
  // If args is set and x300 type is specified, make sure
master_clock_rate is defined
  if (strstr(args, "type=x300") && !strstr(args, "master_clock_rate")) {
sprintf(args2, "%s,master_clock_rate=184.32e6",args);
args = args2;
handler->dynamic_rate = false;
handler->devname = DEVNAME_X300;
  } else if (strstr(args, "type=b200")) {
handler->devname = DEVNAME_B200;
  }
}

uhd_string_vector_free(&devices_str);

/* Create UHD handler */
printf("Opening USRP with args: %s\n", args);
uhd_error error = uhd_usrp_make(&handler->usrp, args);
if (error) {
  fprintf(stderr, "Error opening UHD: code %d\n", error);
  return -1;
}

if (!handler->devname) {
  char dev_str[1024];
  uhd_usrp_get_mboard_name(handler->usrp, 0, dev_str, 1024);
  if (strstr(dev_str, "B2") || strstr(dev_str, "B2")) {
handler->devname = DEVNAME_B200;
  } else if (strstr(dev_str, "X3") || strstr(dev_str, "X3")) {
handler->devname = DEVNAME_X300;
  }
}
if (!handler->devname) {
  handler->devname = "uhd_unknown";
}

// Set external clock reference
if (strstr(args, "clock=external")) {
  uhd_usrp_set_clock_source(handler->usrp, "external", 0);
}

// * Initialize Channes 0 and 1. *
size_t channels[2] = {0,1};
uhd_stream_args_t stream_args = {
  .cpu_format = "fc32",
  .otw_format = "sc16",
  .args = "",
  .channel_list = channels,
  .n_channels = 2
};

// Stream args for channels 0 and 1
for(size_t channel = 0; channel < 2; channel++) {

  handler->channels[channel].has_rssi = get_has_rssi(handler, channel);
  if (handler->channels[channel].has_rssi) {

uhd_sensor_value_make_from_realnum(&handler->channels[channel].rssi_value,
"rssi", 0, "dBm", "%f");
  }

  /* Initialize RX and TX streamers */
  uhd_rx_streamer_make(&handler->channels[channel].rx_stream);
  stream_args.channel_list = &channels[channel];
  stream_args.n_channels = 1;
  error = uhd_usrp_get_rx_stream(handler->usrp, &stream_args,
handler->channels[channel].rx_stream);
  if (error) {
fprintf(stderr, "Error opening RX stream for channel %d with
error code: %d\n",channel, error);
return -1;
  }
  uhd_tx_streamer_make(&handler->channels[channel].tx_stream);
  error = uhd_usrp_get_tx_stream(handler->usrp, &stream_args,
handler->channels[channel].tx_stream);
  if (error) {
fprintf(stderr, "Error opening TX stream: %d\n", error);
return -1;
  }

  uhd_rx_streamer_max_num_samps(handler->channels[channel].rx_stream,
&handler->channels[channel].rx_nof_samples);
  uhd_tx_streamer_max_num_samps(handler->channels[channel].tx_stream,
&handler->channels[channel].tx_nof_samples);

  uhd_meta_range_make(&handler->channels[channel].rx_gain_range);
  uhd_usrp_get_rx_g

Re: [USRP-users] rfnoc-modtool cores

2017-07-07 Thread EJ Kreinar via USRP-users 
Sure:

OOT_DIR = /home/jmat/rfnoc-multiaperture/rfnoc
include $(OOT_DIR)/Makefile.inc

OOT_DIR = /home/jmat/rfnoc-nocblocks/rfnoc
include $(OOT_DIR)/Makefile.inc


You'll also need your out-of-tree makefile to agree with the OOT_DIR
format. See here for example (which I think you probably have correct by
now, but just in case): https://github.com/ejk43/rfnoc-ootexample

Good news is that this OOT_DIR infrastructure is now in the
uhd-fpga/rfnoc-devel branch as of last week. It should also be supported
with uhd_image_builder.py, if you supply multiple directories as -I
parameters.

Let me know if this works for you.
EJ

On Fri, Jul 7, 2017 at 3:02 PM, Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> Circling back to this EJ, what should I make my Makefile.OOT.inc look like
> to include two directories, something like this?:
> OOT_DIR = /home/jmat/rfnoc-multiaperture/rfnoc
> OOT_DIR = /home/jmat/rfnoc-nocblocks/rfnoc
> include $(OOT_DIR)/Makefile.inc
>
>
>
> On 06/14/2017 08:43 PM, EJ Kreinar wrote:
>
> Yes, this is an admitted hack, I should say.
>
> The assignment to MY_OOT_DIR := OOT_DIR in the
> rfnoc-ootexample/rfnoc/Makefile.inc forces the evaluation of OOT_DIR
> immediately, and the OOT modules uses MY_OOT_DIR from then on, for example.
> I've tested this successfully with multiple different OOT repos.
>
> If you have a suggested improvement that's less hacky though, I'm
> definitely interested :)
>
> EJ
>
> On Wed, Jun 14, 2017 at 2:08 PM, Jason Matusiak <
> ja...@gardettoengineering.com> wrote:
>
>> EJ,
>> I am creating a new RFNoC repo and thought I would go through your write
>> up and see if I can find anything that we missed while you and I were
>> working offline.  The first thing I wondered was, in the Makefile.OOT.inc,
>> can I have more than one OOT_DIR?  I have one in there right now for my
>> current blocks, but I am not sure how to point to a different folder
>> without screwing your setup up.
>>
>> ~Jason
>>
>>
>> On 05/23/2017 10:04 PM, EJ Kreinar wrote:
>>
>> Hi Jason and others,
>>
>> As a follow up, I put together an rfnoc OOT repo that uses Makefiles to
>> build Vivado IP and HLS IP: https://github.com/ejk43/rfnoc-ootexample
>>
>> The simulations should run successfully when uhd-fpga is set up correctly
>> (see readme),  and also should build the OOT noc_blocks into an FPGA image
>> using "make E310_RFNOC" etc etc.
>>
>> Hope this helps,
>> EJ
>>
>> On Fri, May 19, 2017 at 12:08 PM, EJ Kreinar  wrote:
>>
>>> Jason,
>>>
>>> Sure, I'd say just clone my fpga repo and apply the patch for now.
>>> Quick instructions:
>>>
>>> 1. In your uhd-fpga repo: `git remote add ejk
>>> https://github.com/ejk43/fpga.git` 
>>> a. This now sets up a remote named "ejk" which points to my fork
>>> 2. Then: `git fetch ejk new_oot_includes`
>>> 3. Then you can either checkout this branch (if you have no other
>>> changes on your uhd-fpga repo), or cherry-pick the commits from the
>>> new_oot_includes branch.
>>>
>>>
>>> In lieu of an example OOT repo, here's how I set up my "rfnoc" folder
>>> structure in the OOT repo:
>>>
>>> rfnoc:
>>>   + Makefile.inc
>>>   + blocks
>>>   + testbenches
>>>   + fpga-src
>>>  + Makefile.inc
>>>
>>>  + noc_block_testblock.v
>>>
>>>   + ip
>>>  + Makefile.inc
>>>  + my_ip
>>> + my_ip.xci
>>> + Makefile.inc
>>>
>>>
>>>
>>> Here's an example top-level Makefile.inc:
>>>
>>> RFNOC_MYTEST_DIR := $(OOT_DIR)
>>> include $(abspath $(RFNOC_MYTEST_DIR)/fpga-src/Makefile.inc)
>>> include $(abspath $(RFNOC_MYTEST_DIR)/ip/Makefile.inc)
>>>
>>>
>>>
>>> Then the fpga-src Makefile.inc:
>>>
>>> RFNOC_OOT_SRCS += $(addprefix $(RFNOC_MYTEST_DIR)/fpga-src/, \
>>> noc_block_testblock.v \
>>> )
>>>
>>>
>>>
>>> Then the IP Makefile.inc (modeled after the Makefile.inc in the
>>> uhd-fpga/usrp3/lib/ip:
>>>
>>> include $(RFNOC_MYTEST_DIR)/ip/my_ip/Makefile.inc
>>>
>>> LIB_MYTEST_IP_XCI_SRCS = \
>>> $(LIB_IP_MY_IP_SRCS)
>>>
>>> LIB_MYTEST_IP_SYNTH_OUTPUTS = \
>>> $(LIB_IP_MY_IP_OUTS)
>>>
>>> LIB_IP_XCI_SRCS += $(LIB_MYTEST_IP_XCI_SRCS)
>>>
>>>
>>>
>>> And finally, the Makefile.inc inside the my_ip directory (modeled after
>>> the lib/ip/xxx Makefile.inc):
>>>
>>> include $(TOOLS_DIR)/make/viv_ip_builder.mak
>>>
>>> LIB_IP_MY_IP_SRCS = $(IP_BUILD_DIR)/my_ip/my_ip.xci
>>>
>>> LIB_IP_MY_IP_OUTS = $(addprefix $(IP_BUILD_DIR)/my_ip/, \
>>> my_ip.xci.out \
>>> synth/my_ip.vhd \
>>> )
>>>
>>> $(LIB_IP_MY_IP_SRCS) $(LIB_IP_MY_IP_OUTS) : $(LIB_IP_DIR)/my_ip/my_ip
>>> .xci
>>> $(call BUILD_VIVADO_IP,my_ip,$(ARCH),$(PART_ID),$(LIB_IP_DIR),$(IP_
>>> BUILD_DIR),0)
>>>
>>>
>>>
>>> It's also possible to rejigger the testbench makefiles to build the OOT
>>> IP for your testbench.
>>>
>>> Again, I should pull this into an example OOT repo sometime soon, which
>>> would make it a bit easier to have an example. Let me know if you hit any
>>> problems.
>>>
>>> EJ
>>>
>>> On Fri, May 19, 2017 at 8:38 AM, Jason Matusiak <
>>> ja...@gardettoengi