[USRP-users] Issues with Transmitting when using 1xTX 2xRX mode on USRP E312

[Ronakraj Gosalia via USRP-users]

Hello,

I am developing a program on an Ettus USRP E312 using GNU Radio 3.7.10.2
and Ubuntu 16.04.3. I have created a cross-compile environment on my host
machine and copied this onto the E312 by following:
https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source

I have also installed the following SD Card image:
http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg3/
(Demo on one device and Development on another, just to verify the issue is
not restricted to any one of them). The RFNoC FPGA Image
rfnoc-devel-238-g39a41476 was installed onto the device.

In my application I am using the RFNoC Radio blocks in gr-ettus as my radio
source and sink blocks. My issue is that when I set my radio to TX on 1
port (Channel 0 TRX port) and RX on 2 ports (Channel 0 RX2 and Channel 1
RX2) the TX signal no longer transmits my modulated waveform. Instead, and
this is my hypothesis based on my observations using a separate Spectrum
Analyser, it outputs the local oscillator pulse at the set RF frequency.
The problem goes away when I set it to TX on 1 port (Channel 0 TRX) and RX
on 1 port (Channel 0 RX2), or when I TX on 2 ports (Channel 0 TRX and
Channel 1 TRX) and RX on 2 ports (Channel 0 RX2 and Channel 1 RX2).

Is this a known bug with the RFNoC FPGA image provided in the first link
above or in the SD Card image in the second link and has there been a fix
implemented for this? So far my work around for the 1 TX 2 RX link is to
set it up as a 2 TX 2 RX link and send a null source to the second
transmitter in my GNU Radio flowgraph - but this is not ideal as energy is
still used to transmit the local oscillator pulse on the second TX output.

Any insight into this will be greatly appreciated.
Thank you for reading this message.

Kind regards,

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

[USRP-users] Turbo Product Codes on USRP E312

[Ronakraj Gosalia via USRP-users]

Hi everyone,

I am using a USRP E312 with GNU Radio 3.7.10.2. GNU Radio has an inbuilt
FEC block that supports Turbo Product Codes (TPC). I'm trying to run a
flowgraph (completely in simulation) on the E312 that includes a TPC
encoder and decoder. The TPC parameters are:

parallelism: 0
row encoding polynomial: 3
column encoding polynomial: 123
K Row: 3
K Column: 18
B: 0
Q: 6

This is a standard 1/2 rate TPC with 6 data byte frame and 12 coded byte
frame as per slide 6 on
https://kirankarra.files.wordpress.com/2016/01/sep18_02_karra_turbocodes.pdf.
On my host machine running Ubuntu 16.04 LTS the flowgraph simulates as
expected and my ASYNC FEC encoding and decoding blocks with TPC work and
decode properly. I copied across the exact same flowgraph to my E312 and
ran it on there, but the decoded bits that come out of the FEC Decoder
(diagnosed using a Message Debug block) are all 0s. It's as if the TPC
decoder has not attempted to decode at all and prints out the default
initialised vector of 0s. I tried all types of TPC decoding including
LOG-MAP C factor, LOG-MAP LUT factor, Constant LOG-MAP, max LOG-MAP and
Linear LOG-MAP with various levels of iterations from 1-6. All yielded the
same response. I even tried to use a ZMQ push/pull sink/source and
offloaded the FEC decoding to my host machine while everything else leading
up to it was done on the E312 - this works perfectly and the FEC decoding
performs as expected on my host laptop.

I suspect there's a subtle bit of code that is malfunctioning on the E312,
but there's no diagnosis output that hint at where this may be. For
reference, I followed the instructions here
https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
to setup my E312. I have not faced an issue like this before with any other
block either in tree or out of tree.

Has anyone experienced an issue like this before or know where I should
look?
Thank you for reading and for your help in advance :).

Kind Regards,

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

Re: [USRP-users] Running RFNoC examples on E310

[Ronakraj Gosalia via USRP-users]

Hey everyone!


This is my very first message, so apologies if I didnt send this correctly
.


I am also facing the same issue outlined by Paul and would really
appreciate some assistance with this. I am using an Ettus USRP E312, GNU
Radio 3.7.10.2 <+6137102> and Ubuntu 16.04.3. <+6116043> Here is what I
tried.


I first started by following the PyBOMBS process in [1] to setup the
cross-compile environment on my host machine (laptop). After using sshfs on
my sdr (USRP E312) I was unable to use the set_env file in the ~/usr
directory, but instead had to source the set_env file in ~/usr/usr. After
this, uhd_find_devices was routed properly, but uhd_usrp_probe gave me the
following error:


Error: RuntimeError: Expected FPGA compatibility number 255.x, but got 14.0:
The FPGA build is not compatible with the host code build.

Now I think this error is due to the fact that the script was trying to run
the default fpga image stored
in/usr/share/uhd/images/usrp_e310_fpga_sg3.bit which was developed for an
older (or different?) version of UHD. From the uhd_usrp_probe output it
says that my current version is UHD_4.0.0.rfnoc-devel-409-gec9138eb so I
tried to download the FPGA images for this version and store them inside
~/usr/usr/share/uhd/images/ and running "uhd_usrp_probe
--args='fpga=/home/root/usr/usr/share/uhd/images/usrp_e3xx_fpga_idle_sg3.bit'"
this
loaded up and gave me the exact same output error as what Paul got. I also
cannot run any uhd examples and get the same runtime error.


Following this, I tried [2], and the fosphor example at the end ran really
well. However, again I was unable to run any of the uhd examples after
this. I also found issues trying to run a simple BPSK transmitter that I
made with the B205. I was unable to use the USRP sink/sources in my GNU
Radio flowchart as it gave me the following error when running the python
script:


Traceback (most recent call last):
File "simple_tx_e312.py", line 229, in 
main()
File "simple_tx_e312.py", line 218, in main
tb = top_block_cls()
File "simple_tx_e312.py", line 68, in __init__
channels=range(1),
File
"/home/root/usr/usr/lib/python2.7/site-packages/gnuradio/uhd/__init__.py",
line 122, in constructor_interceptor
return old_constructor(*args)
File
"/home/root/usr/usr/lib/python2.7/site-packages/gnuradio/uhd/uhd_swig.py",
line 2082, in make
return _uhd_swig.usrp_sink_make(*args)
RuntimeError: RuntimeError: On node 0/FIFO_0, output port 0 is already
connected


I was able to run code by replacing the USRP Sink with an RFNoC Radio TX
block, however the FPGA image is missing the DMAFifo and DUC RFNoC blocks
so I directly connected my flowchart to a FIFO buffer -> RFNoC:Radio
TXblock. This produced a signal with a desired frequency response, but I
was unable to decode the signal when I ran it over the air and via a
coaxial cable. I tried many different configurations (over the air and via
coaxial cable) including an E312 TX -> E312 (another one) RX, E312 TX ->
B205 RX. I also tried B205 TX -> E312 RX and this worked perfectly. B205 TX
-> B205 RX with the same code also works well. This is why I think the
issue is due to the RFNoC Radio TX block. I am also unable to use the
Channel B TX/RX antennas or the GPSDO timing source as the images provided
in "uhd-images_4.0.0.rfnoc-devel-238-g39a41476 <+6141476>" and
"uhd-images_4.0.0.rfnoc-devel-409-gec9138eb" do not support these options
(I can send more specifics about this if it helps, otherwise I will create
a new thread in the near future).


Lastly, I have been following [3]. At the top of this document it does
state "
*However*, this document only covers using RFNoC for the USRP X300/X310.
Using RFNoC with the E310/E312 will be covered in another document.
" which is why I did not initially follow the instructions on this
document. Having read that now I found that there are several references to
the E310 throughout the document, which was very confusing. The document
states that the non-RFNOC fpga images should have DMAFifo and DUC blocks,
however whenever I tried loading these images via "uhd_usrp_probe
--args='fpga=...'" it always gave me same output as that in Paul's message
with always the following blocks included:


|*   |/
*|*   |   |   RFNoC blocks on this device:
*|*   |   |
*|*   |   |   * Radio_0
*|*   |   |   * FIFO_0
*|*   |   |   * Window_0
*|*   |   |   * FFT_0
*|*   |   |   * fosphor_0
*|*   |   |   * FIFO_1
*|*   |   |   * FIR_0*


My next strategy is to create a custom FPGA image and try this by following
the instructions in [3]. Is this the only way to install the DMAFifo, DUC
RFNoC blocks to transmit on my E312? I may have made a mistake in my
understanding/diagnosis somewhere and would appreciate any help that you
may be able to give me. Thank you for your time in advance.


Ronakraj



References:


[1] https://kb.ettus.com/Software_Development_on_the_E310_and_E312

[2] 

[USRP-users] RFNoC Radio Select B E312/E310 and GPSDO

[Ronakraj Gosalia via USRP-users]

Hi folks!

I'm really new to the E312 and RFNoC and I'm having trouble getting the
Channel B RX/TX antennas working on my E312. When I selected B in my RFNoC
Radio block of my GNU Radio flowgraph the code could not run on the E312
and gave me an error saying I was missing the RFNoC block "Radio_1". After
trying all the images that came with the source installation of the
cross-compiled environment [1] I found that none of them included Radio_1
(only Radio_0). I also tried creating my own image with uhd_image_loader
but couldn't find the option for Radio_1. Am I looking in the right
direction?

Also, I am unsure about how to enable GPSDO (an external GPS as external
clock) on the FPGA image.

Thank you for your reply in advance.
Kind regards,

Ronakraj


[1]
https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Running RFNoC examples on E310

[Ronakraj Gosalia via USRP-users]

Hello,

I'm also experiencing the same issues - I tried using the commits that you
said Paul and they still gave me the RuntimeErrors. I thought I was doing
something wrong, so I was trying a fresh install in the meantime, but had
little success. This is what I tried:

In the e300 folder (on host machine, i.e. my laptop) I used "git checkout
" to checkout the uhd and gr-ettus branches. Then I remade uhd and
gr-ettus and copied them over to my E312 and ran "uhd_usrp_probe" and the
benchmark test uhd example - both gave errors and the benchmark test gave
the same RuntimeError as above. Did I make a mistake/misunderstand what you
were saying Paul? Having said that, I am able to run GNU Radio flowgraphs
that use the RFNoC Radio blocks (instead of UHD USRP Sink/Source) but the
performance is limited (i.e. the sample rate of my flowchart has to be
below 500 kHz) due to, from my understanding, the limitations of the ARM
processor.

Also, were any of you able to receive/transmit on channel B on the
E310/E312? I was unable to do this by selecting "B" in the RFNoC Radio
block as it gave me an error regarding missing block "Radio_1". I was
unable to find how to add this block in with a custom fpga image.

Thank you for your help so far gentlemen. Hopefully the USRP folks are able
to fix this issue soon :).
Kind regards,

Ronakraj

On Wed, Feb 7, 2018 at 3:01 AM, Brais Ares <ba...@gradiant.org> wrote:

> ​Hello,
>
> I'm experiencing the same problems as Paul and Ronakraj did.​
>
> It seems the automatic installation using PyBOMBS falls in that error: 
> "RuntimeError:
> RuntimeError: On node 0/FIFO_0, output port 0 is already connected".
> Will it be fixed soon or is there any easy workaround?
>
> I also tried the uhd commit mentioned by Paul (I'm planning to develop
> through C API, so I don't need gr-ettus) but I didn't manage to make it
> work. Even though I load environment variables for cross-compilation, after
> using cmake, make and make install (following this guide
> <https://kb.ettus.com/Software_Development_on_the_E310_and_E312>) I end
> up with executables compiled for x86_64 architecture, instead of ARM. I'm
> in a dead end.
>
> Regards,
> ~Brais
>
>
>
>
> 2018-02-02 0:36 GMT+01:00 Paul Sorensen via USRP-users <
> usrp-users@lists.ettus.com>:
>
>> I was able to get it up and running by following this guide:
>>
>> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-
>> _Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
>>
>> BUT: using the gr-ettus commit of 30302780a44f3f0b146e9b81f88e70c9d983f559
>> and the uhd commit of 12a34d6ef6b9666e29a23039291138f989c7c2ce
>>
>> -Paul Sorensen
>>
>> On Thu, Feb 1, 2018 at 5:27 PM Ronakraj Gosalia via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hey everyone!
>>>
>>>
>>> This is my very first message, so apologies if I didnt send this
>>> correctly .
>>>
>>>
>>> I am also facing the same issue outlined by Paul and would really
>>> appreciate some assistance with this. I am using an Ettus USRP E312, GNU
>>> Radio 3.7.10.2 <+6137102> and Ubuntu 16.04.3. <+6116043> Here is what I
>>> tried.
>>>
>>>
>>> I first started by following the PyBOMBS process in [1] to setup the
>>> cross-compile environment on my host machine (laptop). After using sshfs on
>>> my sdr (USRP E312) I was unable to use the set_env file in the ~/usr
>>> directory, but instead had to source the set_env file in ~/usr/usr. After
>>> this, uhd_find_devices was routed properly, but uhd_usrp_probe gave me the
>>> following error:
>>>
>>>
>>> Error: RuntimeError: Expected FPGA compatibility number 255.x, but got
>>> 14.0:
>>> The FPGA build is not compatible with the host code build.
>>>
>>> Now I think this error is due to the fact that the script was trying to
>>> run the default fpga image stored 
>>> in/usr/share/uhd/images/usrp_e310_fpga_sg3.bit which
>>> was developed for an older (or different?) version of UHD. From the
>>> uhd_usrp_probe output it says that my current version
>>> is UHD_4.0.0.rfnoc-devel-409-gec9138eb so I tried to download the FPGA
>>> images for this version and store them inside ~/usr/usr/share/uhd/images/
>>> and running "uhd_usrp_probe --args='fpga=/home/root/usr/us
>>> r/share/uhd/images/usrp_e3xx_fpga_idle_sg3.bit'" this loaded up and
>>> gave me the exact same output error as what Paul got. I also cannot run any
>>> uhd examples and get the same runtime error.
>>>

Re: [USRP-users] E310/E312 Receive on all 4 inputs

[Ronakraj Gosalia via USRP-users]

Thank you Marcus for the quick reply :).
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] E310/E312 Receive on all 4 inputs

[Ronakraj Gosalia via USRP-users]

Hi folks!

I am wondering if it is possible to receive on all 4 inputs at the same
time on the E310/E312? I.e. is it possible to receive on TRX A, RX A, TRX
B, RX B all at the same time? I tried creating a GNU Radio flowchart with
this setup and got the following Runtime Error:

thread[thread-per-block[16]: ]: RuntimeError: On
node 0/Radio_0, output port 0 is already connected.

I received the same error when trying to receive on three inputs instead,
and the program defaulted to receiving on RX A and RX B instead.

Thank you.
Kind regards,

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

Re: [USRP-users] RFNoC Radio Select B E312/E310 and GPSDO

[Ronakraj Gosalia via USRP-users]

Just in case someone like myself is stumbled by this in the future.

Turns out I was misinterpreting Radio Select "B" as being the second RX and
TX channel on the E312. Instead, in the RFNoC Radio block the Radio Select
A and B refer to two different daughterboards (probably designed for the
X310 which can handle up to two daughterboards). Whereas if you are using
the E312, it has a single MIMO XVCR daughterboard with two channels.

The correct thing to do here therefore would be to change "Num Channels" to
"2 Channels" on both the RX and TX blocks and then set your center
frequency appropriately. Since the RX channel and the TX channel both have
two different Local Oscillators (which are shared, i.e. TRX A and TRX B
share a local oscillator, RX A and RX B share another local oscillator),
they will have the same center frequency. If the center frequency needs to
be set independently, then the digital tune stages need to be set - this is
something I'm still trying to understand how to implement in GNU Radio.

This manual is a good resource:
http://files.ettus.com/manual/page_usrp_e3x0.html


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