Re: [USRP-users] Transmit Thread Stuck Receiving Tx Flow Control Packets

[Brian Padalino via USRP-users]

On Tue, Aug 28, 2018 at 4:02 PM Alan Conrad via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi All,
>
>
>
> I’ve been working on an application that requires two receive streams and
> two transmit streams, written using the C++ API.  I have run into a problem
> when transmitting packets and I am hoping that someone has seen something
> similar and/or may be able to shed some light on this.
>
>
>
> My application is streaming two receive and two transmit channels, each at
> 100 Msps over dual 10GigE interfaces (NIC is Intel X520-DA2).  I have two
> receive threads, each calling recv() on separate receive streams, and two
> transmit threads each calling send(), also on separate transmit streams.
> Each receive thread copies samples into a large circular buffer.  Each
> transmit thread reads samples from the buffer to be sent in the send()
> call.  So, each receive thread is paired with a transmit thread through a
> shared circular buffer with some mutex locking to prevent simultaneous
> access to shared circular buffer memory.
>
>
>
> I did read in the UHD manual that recv() is not thread safe.  I assumed
> that this meant that recv() is not thread safe when called on the same
> rx_streamer from two different threads but would be ok when called on
> different rx_streamers.  If this is not the case, please let me know.
>
>
>
> On to my problem…
>
>
>
> After running for several minutes, one of the transmit threads will get
> stuck in the send() call.  Using strace to monitor the system calls it
> appears that the thread is in a loop continuously calling the
>
> poll() and recvfrom() system calls from within the UHD API.  Here’s the
> output of strace attached to one of the transmit threads after this has
> occurred.  These are the only two system calls that get logged for the
> transmit thread once this problem occurs.
>
>
>
> 11:19:04.564078 poll([{fd=62, events=POLLIN}], 1, 100) = 0 (Timeout)
>
> 11:19:04.664276 recvfrom(62, 0x5619724e90c0, 1472, MSG_DONTWAIT, NULL,
> NULL) = -1 EAGAIN (Resource temporarily unavailable)
>
> 11:19:04.664381 poll([{fd=62, events=POLLIN}], 1, 100) = 0 (Timeout)
>
> 11:19:04.764600 recvfrom(62, 0x5619724e90c0, 1472, MSG_DONTWAIT, NULL,
> NULL) = -1 EAGAIN (Resource temporarily unavailable)
>
> 11:19:04.764699 poll([{fd=62, events=POLLIN}], 1, 100) = 0 (Timeout)
>
> 11:19:04.864906 recvfrom(62, 0x5619724e90c0, 1472, MSG_DONTWAIT, NULL,
> NULL) = -1 EAGAIN (Resource temporarily unavailable)
>
>
>
> This partial stack trace shows that the transmit thread is stuck in the
> while loop in the tx_flow_ctrl() function.  I think this is happening due
> to missed or missing TX flow control packets.
>
>
>
> #0  0x7fdb8fe4fbf9 in __GI___poll (fds=fds@entry=0x7fdb167fb510,
> nfds=nfds@entry=1, timeout=timeout@entry=100) at
> ../sysdeps/unix/sysv/linux/poll.c:29
>
> #1  0x7fdb9186de45 in poll (__timeout=100, __nfds=1,
> __fds=0x7fdb167fb510) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
>
> #2  uhd::transport::wait_for_recv_ready (timeout=0.10001,
> sock_fd=) at
> /home/aconrad/rfnoc/src/uhd/host/lib/transport/udp_common.hpp:59
>
> #3  udp_zero_copy_asio_mrb::get_new (index=@0x55726266f6e8: 28,
> timeout=, this=)
>
> at /home/aconrad/rfnoc/src/uhd/host/lib/transport/udp_zero_copy.cpp:79
>
> #4  udp_zero_copy_asio_impl::get_recv_buff (this=0x55726266f670,
> timeout=) at
> /home/aconrad/rfnoc/src/uhd/host/lib/transport/udp_zero_copy.cpp:226
>
> #5  0x7fdb915d48cc in tx_flow_ctrl (fc_cache=..., async_xport=...,
> endian_conv=0x7fdb915df600 (unsigned int)>,
>
> unpack=0x7fdb918b1090
>  uhd::transport::vrt::if_packet_info_t&)>)
>
> at
> /home/aconrad/rfnoc/src/uhd/host/lib/usrp/device3/device3_io_impl.cpp:345
>
>
>
> The poll() and recvfrom() calls are in the
> udp_zero_copy_asio_mrb::get_new() function in udp_zero_copy.cpp.
>
>
>
> Has anyone seen this problem before or have any suggestions on what else
> to look at to further debug this problem?  I have not yet used Wireshark to
> see what’s happening on the wire, but I’m planning to do that.  Also note
> that, if I run a single transmit/receive pair (instead of two) I don’t see
> this problem and everything works as I expect.
>
>
>
> My hardware is an X310 with the XG firmware and dual SBX-120
> daughterboards.  Here are the software versions I’m using, as displayed by
> the UHD API when the application starts.
>
>
>
> [00:00:00.49] Creating the usrp device with:
> addr=192.168.30.2,second_addr=192.168.40.2...
>
> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
> UHD_4.0.0.rfnoc-devel-788-g1f8463cc
>
>
>
> The host is a Dell PowerEdge R420 with 24 CPU cores and 24 GB ram.  I
> think the clock speed is a little lower than recommended at 2.7 GHz but
> thought that I could distribute the work load across the various cores to
> account for that.  Also, I have followed the instructions to setup dual 10
> GigE interfaces for the X310 here,
> https://kb.ettus.com/Using_Dual_10_Gigabit_Etherne

[USRP-users] Multiple instances of RFNOC block in single flow graph

[Andrew Danowitz via USRP-users]

Hi all,

Has anyone used multiple instances of an RFNOC block in a single flow
graph? I Built an image with my block, mAvgFilter, twice in the build args.
When I try to use both in a flow graph, though, I get:

File "/home/root/e300/src/test_code/top_block.py", line 255, in __init__
self.device3.connect(self.wf_delay_0.get_block_id(), 0,
self.wf_mAvgFilter_1.get_block_id(), 0)
  File
"/home/root/e300/usr/lib/python2.7/site-packages/ettus/ettus_swig.py", line
1267, in connect
return _ettus_swig.device3_sptr_connect(self, *args)
RuntimeError: RuntimeError: On node 0/mAvgFilter_0, input port 0 is already
connected.

As you can see, the python is properly using instance _1, but somehow the C
is defaulting to instance _0.

I'm running UHD_3.13

Thanks,
Andrew

-- 

Information contained, linked, or attached to this email and all verbal 
communications from WhiteFox Defense to your entity in the prior 30 days 
constitute proprietary and confidential information unless otherwise 
indicated and is therefore subject to obligations in any executed 
confidentiality agreements. Further, this email is intended solely for the 
use of the individual or entity to whom they are addressed. If you are not 
the intended recipient and this message has been addressed to you in error, 
please promptly notify i...@whitefoxdefense.com 
 and destroy all copies of the message and 
any attachments. This email and attachments may contain technical data as 
defined in the International Traffic In Arms Regulations (ITAR) 22 CFR 
120.10 or the Export Administration Regulations (EAR) 15 CFR Parts 730 – 
780.  Export of this material may be controlled by these regulations and 
may not be exported or transferred to non-U.S. persons without prior 
written approval from the U.S. government.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Transmit Thread Stuck Receiving Tx Flow Control Packets

[Alan Conrad via USRP-users]

Hi All,

I've been working on an application that requires two receive streams and two 
transmit streams, written using the C++ API.  I have run into a problem when 
transmitting packets and I am hoping that someone has seen something similar 
and/or may be able to shed some light on this.

My application is streaming two receive and two transmit channels, each at 100 
Msps over dual 10GigE interfaces (NIC is Intel X520-DA2).  I have two receive 
threads, each calling recv() on separate receive streams, and two transmit 
threads each calling send(), also on separate transmit streams.  Each receive 
thread copies samples into a large circular buffer.  Each transmit thread reads 
samples from the buffer to be sent in the send() call.  So, each receive thread 
is paired with a transmit thread through a shared circular buffer with some 
mutex locking to prevent simultaneous access to shared circular buffer memory.

I did read in the UHD manual that recv() is not thread safe.  I assumed that 
this meant that recv() is not thread safe when called on the same rx_streamer 
from two different threads but would be ok when called on different 
rx_streamers.  If this is not the case, please let me know.

On to my problem...

After running for several minutes, one of the transmit threads will get stuck 
in the send() call.  Using strace to monitor the system calls it appears that 
the thread is in a loop continuously calling the
poll() and recvfrom() system calls from within the UHD API.  Here's the output 
of strace attached to one of the transmit threads after this has occurred.  
These are the only two system calls that get logged for the transmit thread 
once this problem occurs.

11:19:04.564078 poll([{fd=62, events=POLLIN}], 1, 100) = 0 (Timeout)
11:19:04.664276 recvfrom(62, 0x5619724e90c0, 1472, MSG_DONTWAIT, NULL, NULL) = 
-1 EAGAIN (Resource temporarily unavailable)
11:19:04.664381 poll([{fd=62, events=POLLIN}], 1, 100) = 0 (Timeout)
11:19:04.764600 recvfrom(62, 0x5619724e90c0, 1472, MSG_DONTWAIT, NULL, NULL) = 
-1 EAGAIN (Resource temporarily unavailable)
11:19:04.764699 poll([{fd=62, events=POLLIN}], 1, 100) = 0 (Timeout)
11:19:04.864906 recvfrom(62, 0x5619724e90c0, 1472, MSG_DONTWAIT, NULL, NULL) = 
-1 EAGAIN (Resource temporarily unavailable)

This partial stack trace shows that the transmit thread is stuck in the while 
loop in the tx_flow_ctrl() function.  I think this is happening due to missed 
or missing TX flow control packets.

#0  0x7fdb8fe4fbf9 in __GI___poll (fds=fds@entry=0x7fdb167fb510, 
nfds=nfds@entry=1, timeout=timeout@entry=100) at 
../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7fdb9186de45 in poll (__timeout=100, __nfds=1, __fds=0x7fdb167fb510) 
at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2  uhd::transport::wait_for_recv_ready (timeout=0.10001, 
sock_fd=) at 
/home/aconrad/rfnoc/src/uhd/host/lib/transport/udp_common.hpp:59
#3  udp_zero_copy_asio_mrb::get_new (index=@0x55726266f6e8: 28, 
timeout=, this=)
at /home/aconrad/rfnoc/src/uhd/host/lib/transport/udp_zero_copy.cpp:79
#4  udp_zero_copy_asio_impl::get_recv_buff (this=0x55726266f670, 
timeout=) at 
/home/aconrad/rfnoc/src/uhd/host/lib/transport/udp_zero_copy.cpp:226
#5  0x7fdb915d48cc in tx_flow_ctrl (fc_cache=..., async_xport=..., 
endian_conv=0x7fdb915df600 (unsigned int)>,
unpack=0x7fdb918b1090 )
at /home/aconrad/rfnoc/src/uhd/host/lib/usrp/device3/device3_io_impl.cpp:345

The poll() and recvfrom() calls are in the udp_zero_copy_asio_mrb::get_new() 
function in udp_zero_copy.cpp.

Has anyone seen this problem before or have any suggestions on what else to 
look at to further debug this problem?  I have not yet used Wireshark to see 
what's happening on the wire, but I'm planning to do that.  Also note that, if 
I run a single transmit/receive pair (instead of two) I don't see this problem 
and everything works as I expect.

My hardware is an X310 with the XG firmware and dual SBX-120 daughterboards.  
Here are the software versions I'm using, as displayed by the UHD API when the 
application starts.

[00:00:00.49] Creating the usrp device with: 
addr=192.168.30.2,second_addr=192.168.40.2...
[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501; 
UHD_4.0.0.rfnoc-devel-788-g1f8463cc

The host is a Dell PowerEdge R420 with 24 CPU cores and 24 GB ram.  I think the 
clock speed is a little lower than recommended at 2.7 GHz but thought that I 
could distribute the work load across the various cores to account for that.  
Also, I have followed the instructions to setup dual 10 GigE interfaces for the 
X310 here, 
https://kb.ettus.com/Using_Dual_10_Gigabit_Ethernet_on_the_USRP_X300/X310.

Any help is appreciated.

Thanks,

Al


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

Re: [USRP-users] Import Error Issue

[Marcus D. Leech via USRP-users]

On 08/28/2018 02:22 PM, Malik Saad via USRP-users wrote:
I am trying to run the python files for Pseudorandom Multiband 
Frequency Hopping for Interference Avoidance Using GNU Radio and 
Universal Software Radio Peripheral.  But i was facing the problem 
when i run this code i get import error issues:


cannot import name usrp
Optfir import error

how do i resolve them.

My guess is that you don't have a "modern" instance of Gnu Radio and UHD 
drivers.


Could you give us the complete error output?

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

[USRP-users] Import Error Issue

[Malik Saad via USRP-users]

I am trying to run the python files for Pseudorandom Multiband Frequency
Hopping for Interference Avoidance Using GNU Radio and Universal Software
Radio Peripheral.  But i was facing the problem when i run this code i get
import error issues:

cannot import name usrp
Optfir import error

how do i resolve them.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] X310 error: fw communication failure

[Jessica Iwamoto via USRP-users]

Hi all,

I am running a simple application where I am receiving and transmitting on both 
channels of multiple USRPs. I recently updated to the latest version of UHD 
(3.14) from v3.11, and now I can't run my program without getting the following 
errors:

[ERROR] [X300] 192.168.40.2: x300 fw communication failure #1
EnvironmentError: IOError: x300 fw poke32 - reply timed out
[ERROR] [X300] 192.168.40.4: x300 fw communication failure #1
EnvironmentError: IOError: x300 fw poke32 - reply timed out
[ERROR] [X300] 192.168.41.3: x300 fw communication failure #2
EnvironmentError: IOError: x300 fw poke32 - reply timed out
[ERROR] [X300] 192.168.40.2: x300 fw communication failure #2
EnvironmentError: IOError: x300 fw poke32 - reply timed out
[ERROR] [X300] 192.168.40.4: x300 fw communication failure #2
EnvironmentError: IOError: x300 fw poke32 - reply timed out
[ERROR] [X300] 192.168.41.3: x300 fw communication failure #3
EnvironmentError: IOError: x300 fw poke32 - reply timed out
[ERROR] [UHD] An unexpected exception was caught in a task loop.The task loop 
will now exit, things may not work.EnvironmentError: IOError: 192.168.41.3: 
x300 fw communication failure #3

My MTU size is 548 bytes (for low latency), I am using 10G ethernet, and my max 
buffer size is 5000. UHD does give me a warning requesting larger recv 
buffer sizes, but the requested sizes are larger than what is allowed on my 
host machine, and increasing them doesn't seem to get rid of this error. Any 
help would be appreciated.

Thanks,

Jessica Iwamoto
Member of Technical Staff
The Aerospace Corporation

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

Re: [USRP-users] USRP B200 not transmitting

[Johan Lans via USRP-users]

Great, that worked.

/Johan

2018-08-28 17:06 GMT+02:00 Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com>:

> On 08/28/2018 10:51 AM, Johan Lans via USRP-users wrote:
>
> Hi
>  I'm a hardware developer who is trying to get the B200 working.
> Everything seemed fine until I actually connected a spectrum analyzer to
> the tx output to find no output when the TX led is red. Ive measured the
> output with both spec and oscilloscope during benchmark and tx_waveforms
> with this command
> ./tx_waveforms --freq 915e6 --rate 5e6 --gain 10 --wave-type SINE
> --wave-freq 915e1
>
> I've probed the circuit board along the TX signal path up to the analog
> devices chip, nothing but DC-voltages. Receiveing works excellent.
>
> Does this mean that the board output is  dead or can in be software
> related?
> I'll paste the uhd probe output:
>
> ~ $ uhd_usrp_probe
> [INFO] [UHD] linux; GNU C++ version 8.2.0; Boost_106200;
> UHD_3.13.0.HEAD-0-g0ddc19e5
> [INFO] [B200] Detected Device: B200
> [INFO] [B200] Loading FPGA image: /usr/local/share/uhd/images/us
> rp_b200_fpga.bin...
> [INFO] [B200] Operating over USB 3.
> [INFO] [B200] Detecting internal GPSDO
> [INFO] [GPS] No GPSDO found
> [INFO] [B200] Initialize CODEC control...
> [INFO] [B200] Initialize Radio control...
> [INFO] [B200] Performing register loopback test...
> [INFO] [B200] Register loopback test passed
> [INFO] [B200] Setting master clock rate selection to 'automatic'.
> [INFO] [B200] Asking for clock rate 16.00 MHz...
> [INFO] [B200] Actually got clock rate 16.00 MHz.
>   _
>  /
> |   Device: B-Series Device
> | _
> |/
> |   |   Mboard: B200
> |   |   revision: 5
> |   |   product: 1
> |   |   serial: 3134BB7
> |   |   name: MyB200
> |   |   FW Version: 8.0
> |   |   FPGA Version: 15.0
> |   |
> |   |   Time sources:  none, internal, external, gpsdo
> |   |   Clock sources: internal, external, gpsdo
> |   |   Sensors: ref_locked
> |   | _
> |   |/
> |   |   |   RX DSP: 0
> |   |   |
> |   |   |   Freq range: -8.000 to 8.000 MHz
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: A
> |   |   |   |   Name: FE-RX1
> |   |   |   |   Antennas: TX/RX, RX2
> |   |   |   |   Sensors: temp, rssi, lo_locked
> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Codec: A
> |   |   |   |   Name: B200 RX dual ADC
> |   |   |   |   Gain Elements: None
> |   | _
> |   |/
> |   |   |   TX DSP: 0
> |   |   |
> |   |   |   Freq range: -8.000 to 8.000 MHz
> |   | _
> |   |/
> |   |   |   TX Dboard: A
> |   |   | _
> |   |   |/
> |   |   |   |   TX Frontend: A
> |   |   |   |   Name: FE-TX1
> |   |   |   |   Antennas: TX/RX
> |   |   |   |   Sensors: temp, lo_locked
> |   |   |   |   Freq range: 50.000 to 6000.000 MHz
> |   |   |   |   Gain range PGA: 0.0 to 89.8 step 0.2 dB
> |   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   TX Codec: A
> |   |   |   |   Name: B200 TX dual DAC
> |   |   |   |   Gain Elements: None
>
>
> best regards /Johan
>
>
> The gain-control range on the AD936x is about 90dB, so try a higher gain
> value.
>
>
>
> ___
> 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] USRP B200 not transmitting

[Marcus D. Leech via USRP-users]

On 08/28/2018 10:51 AM, Johan Lans via USRP-users wrote:

Hi
 I'm a hardware developer who is trying to get the B200 working. 
Everything seemed fine until I actually connected a spectrum analyzer 
to the tx output to find no output when the TX led is red. Ive 
measured the output with both spec and oscilloscope during benchmark 
and tx_waveforms with this command
./tx_waveforms --freq 915e6 --rate 5e6 --gain 10 --wave-type SINE 
--wave-freq 915e1


I've probed the circuit board along the TX signal path up to the 
analog devices chip, nothing but DC-voltages. Receiveing works excellent.


Does this mean that the board output is  dead or can in be software 
related?

I'll paste the uhd probe output:

~ $ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 8.2.0; Boost_106200; 
UHD_3.13.0.HEAD-0-g0ddc19e5

[INFO] [B200] Detected Device: B200
[INFO] [B200] Loading FPGA image: 
/usr/local/share/uhd/images/usrp_b200_fpga.bin...

[INFO] [B200] Operating over USB 3.
[INFO] [B200] Detecting internal GPSDO
[INFO] [GPS] No GPSDO found
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.00 MHz...
[INFO] [B200] Actually got clock rate 16.00 MHz.
  _
 /
|   Device: B-Series Device
| _
|/
|   |   Mboard: B200
|   |   revision: 5
|   |   product: 1
|   |   serial: 3134BB7
|   |   name: MyB200
|   |   FW Version: 8.0
|   |   FPGA Version: 15.0
|   |
|   |   Time sources:  none, internal, external, gpsdo
|   |   Clock sources: internal, external, gpsdo
|   |   Sensors: ref_locked
|   | _
|   |/
|   |   |   RX DSP: 0
|   |   |
|   |   |   Freq range: -8.000 to 8.000 MHz
|   | _
|   |/
|   |   |   RX Dboard: A
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: A
|   |   |   |   Name: FE-RX1
|   |   |   |   Antennas: TX/RX, RX2
|   |   |   |   Sensors: temp, rssi, lo_locked
|   |   |   |   Freq range: 50.000 to 6000.000 MHz
|   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
|   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: A
|   |   |   |   Name: B200 RX dual ADC
|   |   |   |   Gain Elements: None
|   | _
|   |/
|   |   |   TX DSP: 0
|   |   |
|   |   |   Freq range: -8.000 to 8.000 MHz
|   | _
|   |/
|   |   |   TX Dboard: A
|   |   | _
|   |   |/
|   |   |   |   TX Frontend: A
|   |   |   |   Name: FE-TX1
|   |   |   |   Antennas: TX/RX
|   |   |   |   Sensors: temp, lo_locked
|   |   |   |   Freq range: 50.000 to 6000.000 MHz
|   |   |   |   Gain range PGA: 0.0 to 89.8 step 0.2 dB
|   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   TX Codec: A
|   |   |   |   Name: B200 TX dual DAC
|   |   |   |   Gain Elements: None


best regards /Johan


The gain-control range on the AD936x is about 90dB, so try a higher gain 
value.



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

[USRP-users] USRP B200 not transmitting

[Johan Lans via USRP-users]

Hi
 I'm a hardware developer who is trying to get the B200 working. Everything
seemed fine until I actually connected a spectrum analyzer to the tx output
to find no output when the TX led is red. Ive measured the output with both
spec and oscilloscope during benchmark and tx_waveforms with this command
./tx_waveforms --freq 915e6 --rate 5e6 --gain 10 --wave-type SINE
--wave-freq 915e1

I've probed the circuit board along the TX signal path up to the analog
devices chip, nothing but DC-voltages. Receiveing works excellent.

Does this mean that the board output is  dead or can in be software related?
I'll paste the uhd probe output:

~ $ uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 8.2.0; Boost_106200;
UHD_3.13.0.HEAD-0-g0ddc19e5
[INFO] [B200] Detected Device: B200
[INFO] [B200] Loading FPGA image: /usr/local/share/uhd/images/
usrp_b200_fpga.bin...
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Detecting internal GPSDO
[INFO] [GPS] No GPSDO found
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test...
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.00 MHz...
[INFO] [B200] Actually got clock rate 16.00 MHz.
  _
 /
|   Device: B-Series Device
| _
|/
|   |   Mboard: B200
|   |   revision: 5
|   |   product: 1
|   |   serial: 3134BB7
|   |   name: MyB200
|   |   FW Version: 8.0
|   |   FPGA Version: 15.0
|   |
|   |   Time sources:  none, internal, external, gpsdo
|   |   Clock sources: internal, external, gpsdo
|   |   Sensors: ref_locked
|   | _
|   |/
|   |   |   RX DSP: 0
|   |   |
|   |   |   Freq range: -8.000 to 8.000 MHz
|   | _
|   |/
|   |   |   RX Dboard: A
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: A
|   |   |   |   Name: FE-RX1
|   |   |   |   Antennas: TX/RX, RX2
|   |   |   |   Sensors: temp, rssi, lo_locked
|   |   |   |   Freq range: 50.000 to 6000.000 MHz
|   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
|   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: A
|   |   |   |   Name: B200 RX dual ADC
|   |   |   |   Gain Elements: None
|   | _
|   |/
|   |   |   TX DSP: 0
|   |   |
|   |   |   Freq range: -8.000 to 8.000 MHz
|   | _
|   |/
|   |   |   TX Dboard: A
|   |   | _
|   |   |/
|   |   |   |   TX Frontend: A
|   |   |   |   Name: FE-TX1
|   |   |   |   Antennas: TX/RX
|   |   |   |   Sensors: temp, lo_locked
|   |   |   |   Freq range: 50.000 to 6000.000 MHz
|   |   |   |   Gain range PGA: 0.0 to 89.8 step 0.2 dB
|   |   |   |   Bandwidth range: 20.0 to 5600.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   TX Codec: A
|   |   |   |   Name: B200 TX dual DAC
|   |   |   |   Gain Elements: None


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

Re: [USRP-users] frequency switching

[Marcus D. Leech via USRP-users]

On 08/28/2018 02:35 AM, Malik Saad via USRP-users wrote:
I want to switch frequency using frequency sensing spectrum technique. 
Any help is appreciated.



General signal-processing "stuff" is better discussed on the 
discuss-gnuradio mailing list.


You'll need to come up with a more-specific description of exactly what 
you need help with.





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

Re: [USRP-users] Problem running RFNoC testbench all of a sudden

[Jon Pendlum via USRP-users]

Hey Jason,

I ran into this problem too when I had a syntax error in sim_rfnoc_lib.svh
(I was messing around with the core RFNoC testbench infrastructure code).
After I fixed my typo, it went away. I suspect this is just a bug in xsim.

Jonathon

On Wed, Aug 8, 2018 at 9:52 PM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I am not sure what I've done, but all of a sudden I don't seem to be able
> to run my testbench.  Things are in the "compiling" stage of the testbench
> when I get hit with this:
>
>
>
>
>
> *Built simulation snapshot ddc_chain_behav*
>
> *** Webtalk v2017.4 (64-bit)*
> *  SW Build 2086221 on Fri Dec 15 20:54:30 MST 2017*
> *  IP Build 2085800 on Fri Dec 15 22:25:07 MST 2017*
> * ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.*
>
> *source
> /opt/gnuradio/v3.7.12.0_rfnoc/src/rfnoc-nocblocks/rfnoc/testbenches/noc_block_responder_tb/xsim_proj/xsim_proj.sim/sim_1/behav/xsim/xsim.dir/ddc_chain_behav/webtalk/xsim_webtalk.tcl
> -notrace*
> *INFO: [Common 17-186]
> '/opt/gnuradio/v3.7.12.0_rfnoc/src/rfnoc-nocblocks/rfnoc/testbenches/noc_block_responder_tb/xsim_proj/xsim_proj.sim/sim_1/behav/xsim/xsim.dir/ddc_chain_behav/webtalk/usage_statistics_ext_xsim.xml'
> has been successfully sent to Xilinx on Wed Aug 8 08:40:08 2018. For
> additional details about this file, please refer to the WebTalk help file
> at /opt/Xilinx/Vivado/2017.4/doc/webtalk_introduction.html.*
> *INFO: [Common 17-206] Exiting Webtalk at Wed Aug 8 08:40:08 2018...*
> *run_program: Time (s): cpu = 00:00:04 ; elapsed = 00:00:05 . Memory (MB):
> peak = 1340.074 ; gain = 0.000 ; free physical = 48514 ; free virtual =
> 292443*
> *INFO: [USF-XSim-69] 'elaborate' step finished in '5' seconds*
> *INFO: [USF-XSim-4] XSim::Simulate design*
> *INFO: [USF-XSim-61] Executing 'SIMULATE' step in
> '/opt/gnuradio/v3.7.12.0_rfnoc/src/rfnoc-nocblocks/rfnoc/testbenches/noc_block_responder_tb/xsim_proj/xsim_proj.sim/sim_1/behav/xsim'*
> *INFO: [USF-XSim-98] *** Running xsim*
> * with args "ddc_chain_behav -key {Behavioral:sim_1:Functional:ddc_chain}
> -tclbatch {ddc_chain.tcl} -log {simulate.log}"*
> *INFO: [USF-XSim-8] Loading simulator feature*
> *Vivado Simulator 2017.4*
> *Time resolution is 1 ps*
> *source ddc_chain.tcl*
> *## current_wave_config*
> *ERROR : The following component DSP48A1 at instance
> ddc_chain.old_hb.small_hb_i.mult.dsp_st.DSP48AST is not supported for
> retargeting in this architecture. Please modify your source code to use
> supported primitives. The complete list of supported primitives for this
> architectures is provided in the 7 Series HDL Libraries Guide available on
> www.xilinx.com .*
> *$finish called at time : 0 fs : File
> "/wrk/2017.4/nightly/2017_12_15_2086221/data/verilog/src/retarget/DSP48A1.v"
> Line 74*
> *INFO: [USF-XSim-96] XSim completed. Design snapshot 'ddc_chain_behav'
> loaded.*
> *INFO: [USF-XSim-97] XSim simulation ran for 10us*
> *launch_simulation: Time (s): cpu = 00:00:12 ; elapsed = 00:00:16 . Memory
> (MB): peak = 1407.582 ; gain = 112.375 ; free physical = 48509 ; free
> virtual = 292438*
> *# if [string equal $vivado_mode "batch"] {*
> *# puts "BUILDER: Closing project"*
> *# close_project*
> *# } else {*
> *# puts "BUILDER: In GUI mode. Leaving project open."*
> *# }*
> *BUILDER: Closing project*
>
>
>
> I didn't update UHD or anything like that, so I can't figure out what I've
> done wrong.  I assume the DSP48A1 is because I am attempting to use most of
> the siggen code in my block.  This seemed to be working fine, and then this
> hit all of a sudden.
>
> Any thoughts?
> ___
> 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