[USRP-users] Maximal number of RFNoC-blocks

[Armin Schmidt via USRP-users]

Hallo everyone and Ettus development team,

We use uhd 3.14 rc1 and we have the strange behaviour, that after the magic
number of 10 RFNoC-blocks on the FPGA, we get the following error:

[ERROR] [UHD] Exception caught in safe-call.
  in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with
uhd::endianness_t _endianness = (uhd::endianness_t)0u]
  at /home/gab2/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:60
this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl
(CE_13_Port_00) no response packet - AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
[with uhd::endianness_t _endianness = (uhd::endianness_t)0u; uint64_t =
long unsigned int]
  at /home/gab2/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:155

terminate called after throwing an instance of 'uhd::io_error'
  what():  EnvironmentError: IOError: Block ctrl (CE_00_Port_30) packet
parse error - EnvironmentError: IOError: Expected SID: 02:30>00:00
Received SID: 00:12>02:00
Aborted (core dumped)

It is not a problem of the FPGA-Capacity and also not a timing issue. So it
seems to be somehow a hardcoded limit from ettus. Does someone know how to
stretch this limit? So 10 RFNoC-blocks works just fine, but with 12 we get
this error! It is also not dependant of the type of blocks, we put on the
FPGA.

Many thanks for your help!

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

[USRP-users] OFDM Transceiver on E310

[Ramazan Çetin via USRP-users]

Hello all,

I am trying to implement OFDM transceiver on E310. Lastly, i already 
implemented OFDM on N310 (in network mode connected to computer) using 
GNURadio blocks. But when i run same example 
(*ofdm_rx_tx_hier_blocks.grc)* on E310 it gives 'U' and 'O's. Processor 
cannot handle incoming and outgoing data.


Then, i put OFDM transmit block to one E310 and OFDM receive to anther 
to decrease load on processor. Again, transmitter gives 'U' and receiver 
gives 'O's. Receiver also gives that info:


INFO: Detected an invalid packet at item

INFO: Parser returned #f


So, it cannot decode OFDM header. I guess packets are corrupted because 
of bad transmission.


I know that, processor cannot handle that much data. I should go to FPGA 
and RFNoC. But in here, available OFDM implementation in RFNoC using 
GNURadio is not fit into FPGA (i can put 3 RFNoC blocks).


So should i implement my own OFDM implementation on FPGA?

Or, can you please suggest another way to implement OFDM Transceiver on 
E310?



Best regards.




  Thu Jan 17 14:32:20 2019
  
options

  author
  


  window_size
  2000,2000


  category
  [GRC Hier Blocks]


  comment
  


  description
  


  _enabled
  True


  _coordinate
  (8, 8)


  _rotation
  0


  generate_options
  no_gui


  hier_block_src_path
  .:


  id
  ofdm_rx_tx_hier_blocks


  max_nouts
  0


  qt_qss_theme
  


  realtime_scheduling
  


  run_command
  {python} -u {filename}


  run_options
  prompt


  run
  True


  sizing_mode
  fixed


  thread_safe_setters
  


  title
  


  placement
  (0,0)

  
  
variable

  comment
  


  _enabled
  True


  _coordinate
  (16, 156)


  _rotation
  0


  id
  center_freq


  value
  910e6

  
  
variable

  comment
  


  _enabled
  True


  _coordinate
  (312, 12)


  _rotation
  0


  id
  fft_len


  value
  128

  
  
variable

  comment
  


  _enabled
  True


  _coordinate
  (880, 84)


  _rotation
  0


  id
  header_equalizer


  value
  digital.ofdm_equalizer_simpledfe(fft_len, header_mod.base(), occupied_carriers, pilot_carriers, pilot_symbols)

  
  
variable

  comment
  


  _enabled
  True


  _coordinate
  (864, 12)


  _rotation
  0


  id
  header_formatter


  value
  digital.packet_header_ofdm(occupied_carriers, n_syms=1, len_tag_key=packet_length_tag_key, frame_len_tag_key=length_tag_key, bits_per_header_sym=header_mod.bits_per_symbol(), bits_per_payload_sym=payload_mod.bits_per_symbol(), scramble_header=False)

  
  
variable

  comment
  


  _enabled
  True


  _coordinate
  (504, 12)


  _rotation
  0


  id
  header_mod


  value
  digital.constellation_bpsk()

  
  
variable

  comment
  


  _enabled
  True


  _coordinate
  (376, 12)


  _rotation
  0


  id
  length_tag_key


  value
  "frame_len"

  
  
variable

  comment
  


  _enabled
  True


  _coordinate
  (200, 52)


  _rotation
  0


  id
  min_obuffer


  value
  2**15

  
  
variable

  comment
  


  _enabled
  True


  _coordinate
  (800, 148)


  _rotation
  0


  id
  occupied_carriers


  value
  (range(-52, -49) + range(-48, -35) + range(-34, -21) + range(-20, -7) + range(-6, 0) + range(1, 7) + range(8, 21) + range(22, 35) + range(36, 49) + range(50, 52),)

  
  
variable

  comment
  


  _enabled
  True


  _coordinate
  (1128, 92)


  _rotation
  0


  id
  packet_len


  value
  96

  
  
variable

  comment
  


  _enabled
  True


  _coordinate
  (1120, 28)


  _rotation
  0


  id
  packet_length_tag_key


  value
  "packet_len"

  
  
variable

  comment
  


  _enabled
  True


  _coordinate
  (880, 84)


  _rotation
  0


  

Re: [USRP-users] noc script SR_WRITE missing port argument

[EJ Kreinar via USRP-users]

Hi Rob, and various Ettus folk,

(Resurrecting an old unreplied thread here...)

This exact issue came up to bite me this this week and I'm curious how this
would be implemented. I consider this a solvable bug in RFNOC in its
current state.

Initially, I expected that if I have a nocscript arg that includes an
"SR_WRITE" action on a specific port, then the action would be applied to
the corresponding port:

```

  enable
  int
  0
  GE($enable, 0) AND LE($enable, 1)
  SR_WRITE("ENABLE_OUTPUT", $enable)
  1

```

This only ever writes to port 0 (consistent with a "sr_write" call without
a specified port).

Secondly I tried hardcoding the port input to SR_WRITE like so:

```

  enable
  int
  0
  GE($enable, 0) AND LE($enable, 1)
  SR_WRITE("ENABLE_OUTPUT", $enable, 1)
  1

```

And this becomes a runtime crash, of course, because the code here clearly
indicates that the NocScript SR_WRITE does not support a "port" argument:
https://github.com/EttusResearch/uhd/blob/master/host/lib/rfnoc/nocscript/block_iface.cpp#L28

So I see two potential solutions...
1. Use the "X" field of the nocscript to indicate which port
the SR_WRITE applies to (a nice solution)
2. Add an optional "port" input to the SR_WRITE argument, similar to the
"SET_ARG" and "SET_VAR" commands (then my second solution would apply)

Any thoughts? I couldnt puzzle out how #1 would work in the nocscript
architecture, but #2 seems pretty straightforward to me

By the way, the workaround I found is to instantiate a block controller
that adds a "set_coerced_subscriber" onto the "enable/value" property tree
which calls the *correct* sr_write function with the corresponding port.

EJ


On Thu, Jul 26, 2018 at 12:04 PM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> When trying to set a custom register in a noc block with multiple ports, I
> noticed that there is no noc script SR_WRITE that includes the port
> argument.  Is this on the list to be added?
>
> Rob
> ___
> 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] OFDM Transceiver on E310

[Ramazan Çetin via USRP-users]

Actually, i tried it. But i guess minimum sample rate is 1Ms/s, when i 
set less than it, it gives this warning on transmitter side;


[WARNING] [MULTI_USRP] The hardware does not support the requested TX 
sample rate:


Target sample rate: 0.50 MSps

Actual sample rate: 1.00 MSps


When i set 500Ks/s, transmitter again gives 'U's but receiver does not. 
I guess receiver can be set to lower sample rates, but transmitter not. 
Do you know any way to work transmitter on lower rates?



On 4.04.2019 15:57, Malik Saad wrote:

Just use sampling rate lesser than the existing mode.

On Thursday, April 4, 2019, Ramazan Çetin via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Hello all,

I am trying to implement OFDM transceiver on E310. Lastly, i
already implemented OFDM on N310 (in network mode connected to
computer) using GNURadio blocks. But when i run same example
(*ofdm_rx_tx_hier_blocks.grc)* on E310 it gives 'U' and 'O's.
Processor cannot handle incoming and outgoing data.

Then, i put OFDM transmit block to one E310 and OFDM receive to
anther to decrease load on processor. Again, transmitter gives 'U'
and receiver gives 'O's. Receiver also gives that info:

INFO: Detected an invalid packet at item

INFO: Parser returned #f


So, it cannot decode OFDM header. I guess packets are corrupted
because of bad transmission.

I know that, processor cannot handle that much data. I should go
to FPGA and RFNoC. But in here, available OFDM implementation in
RFNoC using GNURadio is not fit into FPGA (i can put 3 RFNoC blocks).

So should i implement my own OFDM implementation on FPGA?

Or, can you please suggest another way to implement OFDM
Transceiver on E310?


Best regards.

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

Re: [USRP-users] Maximal number of RFNoC-blocks

[Jason Matusiak via USRP-users]

I don't know why this would be, but it almost feels like a hex issue somewhere. 
 Where are you setting the block size to 10?  It feels like something is 
interpreting that as 0x10, and I think 16 is a magic number that is too large.


From: USRP-users  on behalf of Armin 
Schmidt via USRP-users 
Sent: Thursday, April 4, 2019 4:13 AM
To: USRP-users@lists.ettus.com
Subject: [USRP-users] Maximal number of RFNoC-blocks

Hallo everyone and Ettus development team,

We use uhd 3.14 rc1 and we have the strange behaviour, that after the magic 
number of 10 RFNoC-blocks on the FPGA, we get the following error:


[ERROR] [UHD] Exception caught in safe-call.
  in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with uhd::endianness_t 
_endianness = (uhd::endianness_t)0u]
  at /home/gab2/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:60
this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl 
(CE_13_Port_00) no response packet - AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with 
uhd::endianness_t _endianness = (uhd::endianness_t)0u; uint64_t = long unsigned 
int]
  at /home/gab2/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:155

terminate called after throwing an instance of 'uhd::io_error'
  what():  EnvironmentError: IOError: Block ctrl (CE_00_Port_30) packet parse 
error - EnvironmentError: IOError: Expected SID: 02:30>00:00  Received SID: 
00:12>02:00
Aborted (core dumped)

It is not a problem of the FPGA-Capacity and also not a timing issue. So it 
seems to be somehow a hardcoded limit from ettus. Does someone know how to 
stretch this limit? So 10 RFNoC-blocks works just fine, but with 12 we get this 
error! It is also not dependant of the type of blocks, we put on the FPGA.

Many thanks for your help!

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

Re: [USRP-users] Maximal number of RFNoC-blocks

[Jonathon Pendlum via USRP-users]

Hi,

On the X310, the crossbar is limited to 16 ports. Of the 16 ports, only 10
are available because the other 6 are already occupied: 2x 10GigE, 1x PCIe,
2x Radio Core RFNoC blocks, 1x DmaFIFO RFNoC block.

Jonathon

On Thu, Apr 4, 2019 at 11:03 PM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I don't know why this would be, but it almost feels like a hex issue
> somewhere.  Where are you setting the block size to 10?  It feels like
> something is interpreting that as 0x10, and I think 16 is a magic number
> that is too large.
>
> --
> *From:* USRP-users  on behalf of
> Armin Schmidt via USRP-users 
> *Sent:* Thursday, April 4, 2019 4:13 AM
> *To:* USRP-users@lists.ettus.com
> *Subject:* [USRP-users] Maximal number of RFNoC-blocks
>
> Hallo everyone and Ettus development team,
>
> We use uhd 3.14 rc1 and we have the strange behaviour, that after the
> magic number of 10 RFNoC-blocks on the FPGA, we get the following error:
>
> [ERROR] [UHD] Exception caught in safe-call.
>   in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with
> uhd::endianness_t _endianness = (uhd::endianness_t)0u]
>   at /home/gab2/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:60
> this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl
> (CE_13_Port_00) no response packet - AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
> [with uhd::endianness_t _endianness = (uhd::endianness_t)0u; uint64_t =
> long unsigned int]
>   at /home/gab2/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:155
>
> terminate called after throwing an instance of 'uhd::io_error'
>   what():  EnvironmentError: IOError: Block ctrl (CE_00_Port_30) packet
> parse error - EnvironmentError: IOError: Expected SID: 02:30>00:00
> Received SID: 00:12>02:00
> Aborted (core dumped)
>
> It is not a problem of the FPGA-Capacity and also not a timing issue. So
> it seems to be somehow a hardcoded limit from ettus. Does someone know how
> to stretch this limit? So 10 RFNoC-blocks works just fine, but with 12 we
> get this error! It is also not dependant of the type of blocks, we put on
> the FPGA.
>
> Many thanks for your help!
>
> Armin Schmidt
> ___
> 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] E310 environment

[Jason Matusiak via USRP-users]

FWIW, these are the steps I use (some of them aren't really needed, but it 
works, so I do it every time):

mkdir ~/E310   ###This is the directory that will be a mount point for your 
remote E310
sshfs -o allow_root root@192.168.1.10:/ ~/E310   ###Your E310's / directory now 
starts at ~/E310 on your host
mkdir ~/E310/home/root/localinstall
PREFIX=/opt/gnuradio/test
PREFIX_E310=~/E310/home/root/localinstall
cd ~/Downloads
get your oecore .sh file mine is renamed, so yours will be different
chmod +x oecore-x86_64-armv7ahf-neon-toolchain-nodistro.0_rocko_with_qt.sh
sh ./oecore-x86_64-armv7ahf-neon-toolchain-nodistro.0_rocko_with_qt.sh -y -d 
$PREFIX

cd $PREFIX
source ./environment-setup-armv7ahf-neon-oe-linux-gnueabi
echo $CC###This is just to verify that we have the cross-compile tools 
setup right. You see armv7 in some of the values
mkdir src && cd src

(in the next step I am building for RFNoC, most likely you can leave that out 
if you don't care for it)
git clone --recursive -b rfnoc-devel https://github.com/EttusResearch/uhd.git
cd uhd
git submodule foreach --recursive git checkout rfnoc-devel
cd host/ && mkdir arm-build && cd arm-build
cmake -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake 
-DCMAKE_INSTALL_PREFIX=/usr -DENABLE_E300=ON -DENABLE_B100=OFF 
-DENABLE_X300=OFF -DENABLE_B200=OFF -DENABLE_USRP1=OFF -DENABLE_USRP2=OFF 
-DENABLE_N300=OFF -DENABLE_OCTOCLOCK=OFF -DENABLE_N230=OFF -DENABLE_DOXYGEN=OFF 
-DENABLE_MANUAL=OFF -DENABLE_MAN_PAGES=OFF ..
make -j32
make install DESTDIR=$PREFIX
make install DESTDIR=$PREFIX/sysroots/armv7ahf-neon-oe-linux-gnueabi
make install DESTDIR=$PREFIX_E310

(This next step is something I do so I can source the new environment on the 
E310 when I am ready to use it)
printf "LOCALPREFIX=~/localinstall/usr
export PATH=\$LOCALPREFIX/bin:\$PATH
export LD_LOAD_LIBRARY=\$LOCALPREFIX/lib:\$LD_LOAD_LIBRARY
export LD_LIBRARY_PATH=\$LOCALPREFIX/lib:\$LD_LIBRARY_PATH
export PYTHONPATH=\$LOCALPREFIX/lib/python2.7/site-packages:\$PYTHONPATH
export PKG_CONFIG_PATH=\$LOCALPREFIX/lib/pkgconfig:\$PKG_CONFIG_PATH
export GRC_BLOCKS_PATH=\$LOCALPREFIX/share/gnuradio/grc/blocks:\$GRC_BLOCKS_PATH
export UHD_RFNOC_DIR=\$LOCALPREFIX/share/uhd/rfnoc/
export UHD_IMAGES_DIR=\$LOCALPREFIX/share/uhd/images" > 
$PREFIX_E310/../setup_env.sh
chmod +x $PREFIX_E310/../setup_env.sh

(use the fefault version if you want, this is just what I am currently using)
cd $PREFIX/src
git clone -b v3.7.12.0 --recursive https://github.com/gnuradio/gnuradio.git
cd gnuradio && mkdir arm-build && cd arm-build
cmake -Wno-dev -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/oe-sdk_cross.cmake 
-DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF -DENABLE_GR_DTV=OFF 
-DENABLE_GR_ATSC=OFF -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ../
make -j32
make install DESTDIR=$PREFIX
make install DESTDIR=$PREFIX/sysroots/armv7ahf-neon-oe-linux-gnueabi
make install DESTDIR=$PREFIX_E310

(the next one is for if you want RFNoC)
cd $PREFIX/src
git clone -b master https://github.com/EttusResearch/gr-ettus.git
cd gr-ettus/ && mkdir arm-build && cd arm-build
cmake -Wno-dev 
-DCMAKE_TOOLCHAIN_FILE=$PREFIX/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake 
-DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ..
make -j32
make install DESTDIR=$PREFIX
make install DESTDIR=$PREFIX/sysroots/armv7ahf-neon-oe-linux-gnueabi
make install DESTDIR=$PREFIX_E310


Now, whenever you have a project that you want to cross-compile for the E310:
d $PREFIX/src
git clone   
https://github.com/myawesomeproject/myawesomeproject.git
cd myawesomeproject/ && mkdir arm-build && cd arm-build
cmake -Wno-dev 
-DCMAKE_TOOLCHAIN_FILE=$PREFIX/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake 
-DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ..
make -j32
make install DESTDIR=$PREFIX
make install DESTDIR=$PREFIX/sysroots/armv7ahf-neon-oe-linux-gnueabi
make install DESTDIR=$PREFIX_E310


From: USRP-users  on behalf of Martin K via 
USRP-users 
Sent: Wednesday, April 3, 2019 11:23 AM
To: usrp-users
Subject: [USRP-users] E310 environment

I am trying to follow the instructions at
https://files.ettus.com/manual/page_usrp_e3x0.html

I have a fresh installation of Ubuntu (either 16.04 or 18.04)

When I get to the point of setting up the cross compilation
environment, I get a fatal error. This is some sort of Python issue,
for which I am not a Python developer, I have no idea what I should be
doing to fix this.

My goal is to compile my custom C++ code against UHD for the E310. If
there is a better solution please let me know. Thank you.

$ . e3xx/environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
$ CC
Fatal Python error: Py_Initialize: Unable to get the locale encoding
ModuleNotFoundError: No module named 'encodings'

Current thread 0x7f05861ce740 (most recent call first):
Aborted (core dumped)

--
Martin K.

___
USRP-users mailing l

Re: [USRP-users] Issues/suggestions for latest rfnocmodtool

[switchlanez via USRP-users]

Hello,



Preface: When I checkout older RFNoC versions and using "rfnocmodtool
newmod" I also have to use the srcdir flag as suggested above in your
thread:

rfnocmodtool newmod [NAME OF THE MODULE] --srcdir
~/{USER_PREFIX}/src/gr-ettus/python/rfnoc_
modtool/rfnoc-newmod/



That works fine, but there are other problems I face after that:


Issue #1: I went through building the OOT "Gain" example from your "Getting
Started with RFNoC" knowledge base wiki. After doing "make install" in the
build directory and opening GNU Radio Companion, I do not see the Gain
block in the options list (confirms result I get with another custom OOT
block I'm working on).



Issue #2: When building the FPGA image of my custom OOT module using the
make command, I get this error:



Makefile.x300.inc:111: recipe for target 'bin' failed
make[1]: *** [bin] Error 1



Line 111 of Makefile.x300.inc looks like this:



# DESIGN_SRCS and VERILOG_DEFS must be defined
bin: .prereqs $$(DESIGN_SRCS) ip
$(call BUILD_VIVADO_DESIGN,$(abspath
./build_x300.tcl),$(TOP_MODULE),$(PART_ID))



In both issues #1 and #2 it looks like files aren't getting linked
properly for any OOT module. Before I start going into files and modifying
them, I'd like to know what you recommend for both issues (similar to the
rfnocmodtool's --srcdir solution I prefaced).

If it matters I am using these older versions (git hashes in parentheses)
of UHD (ec9138eb6634b0af106762832c7518c887576a94), gr-ettus
(22e1e3634c3f74fd9cbcf4162117a4765b781c60), GNU Radio
(a098720f430fae36fbd28d7e9c1548a1e6c4fdf4), and uhd-fpga
(b0890fa97ef3dc7d90ed8047d678ca280c72ad61). I need to use these versions to
do this full hardware loopback hack which I haven't found to work on newer
versions: https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/



V/R,

Andrew

On Thu, Jul 13, 2017 at 9:54 AM Nicolas Cuervo via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Michael,
>
> if you are certain that having the templates for QA in either python or
> cpp (any specific language you are using from these two for the unit
> tests?) is useful for you (and potentially for other users), then I will
> push them back.
>
> From this discussion, I will also set a more descriptive warning then the
> "newmod" template is not found.
>
>
>
> On Thu, Jul 13, 2017 at 5:45 PM, Michael Wentz  wrote:
>
>> Hi Nicolas,
>>
>> Thanks for the feedback. Interesting since I had a few blocks with
>> underscores in the name and had just removed the underscore from the XML
>> that UHD uses.
>>
>> Regarding the QA tests, I tried porting some of the code I was using
>> before and am mostly getting 'timeout on chan 0' when using vector
>> source/sink to send test vectors through. In the past I had some success
>> with this, not only when using GR but with other tests I wrote using only
>> UHD. From my prospective it would definitely be nice to repeat the type of
>> tests I do in RTL simulation with hardware in the loop, i.e. doing a
>> loopback through the FPGA with signals generated from software.
>>
>> -Michael
>>
>> On Thu, Jul 13, 2017 at 7:18 AM, Nicolas Cuervo > > wrote:
>>
>>> Hello Michael,
>>>
>>> It seems that 'import sys' is missing from the top of
 gr-ettus/python/utils/rfnocmodtool

>>> Yeah, this was known actually, and the fix is there. It just needs to be
>>> pushed public. We are sorry you had to face this.
>>>
>>>
 After changing that, I ran into this problem:

 rfnocmodtool newmod test
 Could not find rfnoc-newmod source dir

 It turns out that gr-ettus/modtool_newmod.py is not set up for people
 that do not use PYBOMBS but do have a custom install prefix. All I had to
 do was copy that over to PYBOMBS_PREFIX and then newmod worked. I would
 have thought my install prefix would have been set up in any necessary
 files during cmake?

>>> The path hint that the modtool uses is PyBombs (as you correctly point
>>> out) and the common /usr/local/ and such. When the path is custom,
>>> rfnocmodtool requires the path of the newmod to be given with the
>>> "--srcdir" option.
>>>
>>> $ rfnocmodtool help newmod
>>>General options:
>>>.
>>>.
>>>.
>>>   newmod:
>>>   New out-of-tree module options
>>>
>>>   --srcdir SRCDIR   Source directory for the module template.
>>>
>>> Maybe a more descriptive "Could not find message" would be required,
>>> where it is said that the --srcdir option might be required to be
>>> explicitly given.
>>>
>>>
 I was also wondering if there are reasons why underscores are not
 allowed in block names

>>> The underscores are not allowed in the names because we use them to
>>> designate block identifiers. This means, for example, that under the hood
>>> we refer to the "RFNoC: Radio" on channel 0 as 0/Radio_0 and so on. Given
>>> this, some naming that has underscores in it will lead to code
>>> mismatches and conflicts that could only be solved by code refactoring.
>

Re: [USRP-users] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

[Rigney, Kevin E via USRP-users]

Pitor:

We've seen a similar issue and have worked around it by just using a slightly 
different frequency. Can you post the frequencies that you're seeing it on? I 
think Ettus should be able to duplicate. I saw an issue with spectral inversion 
(I think I and Q are getting swapped somewhere) at 2.8GHz but not 2.9GHz.

-Kevin
 
On 4/4/19, 12:00 PM, "USRP-users on behalf of 
usrp-users-requ...@lists.ettus.com"  wrote:

Hi,

After disconnecting LO cables signal on the daughter-board that imports
LOs disappears. So GNU Radio correctly configures distribution of LOs.
Also the +/- 90 degree changes happen completely deterministically in
given ranges of carrier frequencies.

So the question remains open: what is causing the issue described in the
first post of this thread?

--
Best Regards,
Piotr Krysik

W dniu 03.04.2019 o?12:15, Fabian Schwartau via USRP-users pisze:
>Hi,
>
>yes, the result for multiple measurements (start ups of the system) at
>a single frequency was different by multiples of 90?.
>We did not investigated the problem any further, but I am quite sure
>that gnuradio was not synchronizing the channels using the LO-sharing,
>although it was selected. So do the test I described. If you see that
>he is not using the LO-sharing, you know where to look further.
>Keep in mind that it is not necessary to use LO-sharing to get a well
>defined phase relation between the channels. Depending on your
>frequency and bandwidth settings, it is possible to also achive this,
>as all LOs are driven from a common 200 MHz reference clock.
>
>Best regards,
>Fabian
>
>Am 03.04.2019 um 12:05 schrieb Piotr Krysik via USRP-users:
>>Hi Fabian,
>>
>>W dniu 03.04.2019 o?11:05, Fabian Schwartau via USRP-users pisze:
>>>Hi Piotr,
>>>
>>>we once had a very similar issue. But we also saw this on the same
>>>frequency when switching between frequencies. Can you try this as
>>>well? Just switch forth and back between two frequencies and just plot
>>>one of them?
>>
>>I'm not sure I understand correctly what you mean. You mean that the
>>result for a given frequency was not stable in your case across many
>>measurements? In our case this situation was repeating, but the
>>application doing the recording was restarted for each measurement.
>>
>>>As far as I remember the issue was because we were not using the
>>>LO-Sharing. We were able to get everything running by using a C++
>>>application and not gnuradio (I can see you are using python - which
>>>is basically the same). There was a bug in gnuradio/python causing
>>>this issue.
>>>You can try to remove one of the LO-sharing cables while doing a
>>>measurement and see if the phase suddenly starts to do crazy things
>>>(the signal should also be lost). If that is not the case, you are not
>>>actually using LO-sharing.
>>>
>>Do you know what this bug was exactly? GNU Radio didn't configure
>>LO-Sharing the way it was specified?
>>
>>-- 
>>Best Regards,
>>Piotr Krysik

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

Re: [USRP-users] What is the best way to trigger rfnoc receiver radio?

[Jonathon Pendlum via USRP-users]

Hi James,

I suggest taking a look at rx_control_gen3.v. RX is started by issuing
commands to the state machine in that file. You could modify it to instead
accept a trigger signal.

Jonathon

On Thu, Apr 4, 2019 at 3:20 AM Xingjian Chen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear all,
> I have some questions about how to trigger RFNOC receiver. I have a module
> detecting the rising edge of a fixed clock. I used that clock to trigger Tx
> and Rx modules. Now the transmit RFNOC module is working properly but the
> receive module gives me non-deterministic m_axis_data_tvalid such that I
> cannot determine when the Rx radio started recording. I am wondering if
> anyone know how to use a clock or any trigger to let RFNOC Rx radio
> starting to record signal? The USRP I am using now is E312. Thank you!
>
> James
> ___
> 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