usrp-users@lists.ettus.com

Discussion and technical support related to USRP, UHD, RFNoC

View all threads

Re: [USRP-users] x310 with twin rx uhd_usrp probe issue

MK
Mark Koenig
Mon, Aug 21, 2017 7:02 PM

Just to follow up on this, I updated the UHD rev and am now getting the output below.  It is showing the Connection Type as II and QQ for Rx front end 0 and 1.  Is this correct?  I would expect to see IQ……is this the problem?  Below is my output.

Thanks

Mark

linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-11); Boost_105300; UHD_003.010.001.000-0-unknown

-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Detecting internal GPSDO.... Found an internal GPSDO: LC_XO, Firmware Rev 0.929a
-- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1182.8MB/s)
-- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1168.8MB/s)
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass


/
|      Device: X-Series Device
|    _____________________________________________________
|    /
|  |      Mboard: X310
|  |  revision: 4
|  |  product: 30410
|  |  mac-addr0: 00:80:2f:0a:e3:35
|  |  mac-addr1: 00:80:2f:0a:e3:36
|  |  gateway: 192.168.10.1
|  |  ip-addr0: 192.168.10.2
|  |  subnet0: 255.255.255.0
|  |  ip-addr1: 192.168.20.2
|  |  subnet1: 255.255.255.0
|  |  ip-addr2: 192.168.30.2
|  |  subnet2: 255.255.255.0
|  |  ip-addr3: 192.168.40.2
|  |  subnet3: 255.255.255.0
|  |  serial: F4717C
|  |  FW Version: 5.0
|  |  FPGA Version: 33.0
|  |  RFNoC capable: Yes
|  |
|  |  Time sources:  internal, external, gpsdo
|  |  Clock sources: internal, external, gpsdo
|  |  Sensors: gps_gpgga, gps_gprmc, gps_time, gps_locked, gps_servo, ref_locked
|  |    _____________________________________________________
|  |    /
|  |  |      RX Dboard: A
|  |  |  ID: TwinRX v1.1 (0x0093)
|  |  |  Serial: 30F2039
|  |  |    _____________________________________________________
|  |  |    /
|  |  |  |      RX Frontend: 0
|  |  |  |  Name: TwinRX RX0
|  |  |  |  Antennas: RX1, RX2
|  |  |  |  Sensors: lo_locked
|  |  |  |  Freq range: 10.000 to 6000.000 MHz
|  |  |  |  Gain range all: 0.0 to 95.0 step 1.0 dB
|  |  |  |  Bandwidth range: 80000000.0 to 80000000.0 step 0.0 Hz
|  |  |  |  Connection Type: II
|  |  |  |  Uses LO offset: No
|  |  |    _____________________________________________________
|  |  |    /
|  |  |  |      RX Frontend: 1
|  |  |  |  Name: TwinRX RX1
|  |  |  |  Antennas: RX1, RX2
|  |  |  |  Sensors: lo_locked
|  |  |  |  Freq range: 10.000 to 6000.000 MHz
|  |  |  |  Gain range all: 0.0 to 95.0 step 1.0 dB
|  |  |  |  Bandwidth range: 80000000.0 to 80000000.0 step 0.0 Hz
|  |  |  |  Connection Type: QQ
|  |  |  |  Uses LO offset: No
|  |  |    _____________________________________________________
|  |  |    /
|  |  |  |      RX Codec: A
|  |  |  |  Name: ads62p48
|  |  |  |  Gain range digital: 0.0 to 6.0 step 0.5 dB
|  |    _____________________________________________________
|  |    /
|  |  |      RX Dboard: B
|  |  |  ID: TwinRX v1.1 (0x0093)
|  |  |  Serial: 30F2025
|  |  |    _____________________________________________________
|  |  |    /
|  |  |  |      RX Frontend: 0
|  |  |  |  Name: TwinRX RX0
|  |  |  |  Antennas: RX1, RX2
|  |  |  |  Sensors: lo_locked
|  |  |  |  Freq range: 10.000 to 6000.000 MHz
|  |  |  |  Gain range all: 0.0 to 95.0 step 1.0 dB
|  |  |  |  Bandwidth range: 80000000.0 to 80000000.0 step 0.0 Hz
|  |  |  |  Connection Type: II
|  |  |  |  Uses LO offset: No
|  |  |    _____________________________________________________
|  |  |    /
|  |  |  |      RX Frontend: 1
|  |  |  |  Name: TwinRX RX1
|  |  |  |  Antennas: RX1, RX2
|  |  |  |  Sensors: lo_locked
|  |  |  |  Freq range: 10.000 to 6000.000 MHz
|  |  |  |  Gain range all: 0.0 to 95.0 step 1.0 dB
|  |  |  |  Bandwidth range: 80000000.0 to 80000000.0 step 0.0 Hz
|  |  |  |  Connection Type: QQ
|  |  |  |  Uses LO offset: No
|  |  |    _____________________________________________________
|  |  |    /
|  |  |  |      RX Codec: B
|  |  |  |  Name: ads62p48
|  |  |  |  Gain range digital: 0.0 to 6.0 step 0.5 dB
|  |    _____________________________________________________
|  |    /
|  |  |      TX Dboard: A
|  |  |  ID: Unknown (0x0092)
|  |  |  Serial: 30F29BC
|  |  |    _____________________________________________________
|  |  |    /
|  |  |  |      TX Frontend: 0
|  |  |  |  Name: Unknown (0x0092) - 0
|  |  |  |  Antennas:
|  |  |  |  Sensors:
|  |  |  |  Freq range: 0.000 to 0.000 MHz
|  |  |  |  Gain Elements: None
|  |  |  |  Bandwidth range: 0.0 to 0.0 step 0.0 Hz
|  |  |  |  Connection Type: IQ
|  |  |  |  Uses LO offset: No
|  |  |    _____________________________________________________
|  |  |    /
|  |  |  |      TX Codec: A
|  |  |  |  Name: ad9146
|  |  |  |  Gain Elements: None
|  |    _____________________________________________________
|  |    /
|  |  |      TX Dboard: B
|  |  |  ID: Unknown (0x0092)
|  |  |  Serial: 30F2B48
|  |  |    _____________________________________________________
|  |  |    /
|  |  |  |      TX Frontend: 0
|  |  |  |  Name: Unknown (0x0092) - 0
|  |  |  |  Antennas:
|  |  |  |  Sensors:
|  |  |  |  Freq range: 0.000 to 0.000 MHz
|  |  |  |  Gain Elements: None
|  |  |  |  Bandwidth range: 0.0 to 0.0 step 0.0 Hz
|  |  |  |  Connection Type: IQ
|  |  |  |  Uses LO offset: No
|  |  |    _____________________________________________________
|  |  |    /
|  |  |  |      TX Codec: B
|  |  |  |  Name: ad9146
|  |  |  |  Gain Elements: None
|  |    _____________________________________________________
|  |    /
|  |  |      RFNoC blocks on this device:
|  |  |
|  |  |  * DmaFIFO_0
|  |  |  * Radio_0
|  |  |  * Radio_1
|  |  |  * DDC_0
|  |  |  * DDC_1
|  |  |  * DUC_0
|  |  |  * DUC_1

On 8/21/17, 12:01 PM, "USRP-users on behalf of usrp-users-request@lists.ettus.com" <usrp-users-bounces@lists.ettus.com on behalf of usrp-users-request@lists.ettus.com> wrote:

Send USRP-users mailing list submissions to
	usrp-users@lists.ettus.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
	usrp-users-request@lists.ettus.com

You can reach the person managing the list at
	usrp-users-owner@lists.ettus.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."


Today's Topics:

   1. Synchronised RX and TX control in X310 (Karan Suri)
   2. Run Time Error in Sending MIMO on B210 (Masoud Naderpour)
   3. Re: continues streaming with rx_multi_samps (Nicolas Cuervo)
   4. Re: USRP-users Digest, Vol 84, Issue 19 (Mark Koenig)
   5. ADC Overflow - B205i (Dominik Eyerly)
   6. Re: ADC Overflow - B205i (Marcus M?ller)
   7. Re: ADC Overflow - B205i (Dominik Eyerly)


----------------------------------------------------------------------

Message: 1
Date: Mon, 21 Aug 2017 00:17:15 -0400
From: Karan Suri <youngsuri@gmail.com>
To: usrp-users <usrp-users@lists.ettus.com>
Subject: [USRP-users] Synchronised RX and TX control in X310
Message-ID:
	<CAN+qiuPntGDfA9Q0jbojs3LpQ3_h1fBrGsUALz3fDkQtZj8sRg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello usrp-users.
I was successfully using a source code capable of transmitting and
Receiving OFDM packets in USRP X310. The anchor USRP  transmits an OFDM
packet at frequency f1 , it is received by a tag USRP which loops back the
received OFDM packets at frequency f2. The same OFDM packet is then
captured back at the RX of Anchor and dumped into a file.

I was using version 3.10.1 until few days back when  I shifted to 3.10.2 to
allow the compatibility of Rev D UBX-160 daughter board. The code
successfully builds but can no longer function as it used to in the
previous version.
I am using "uhd::get_time_now() and uhd::time_sepc_t(n)" to synchronise the
start of transmit and receive.   I need to transfer 20 such packets (so
that the result can be averaged). Between each iteration of packet transfer
the tx and RX of anchor USRP are put to sleep for specific duration.
Do you have any idea what might be going wrong when i shifted to a newer
version. Are the old codes no longer compatible, or do they function
differently?

Karan Suri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170821/8eef2ec3/attachment-0001.html>

------------------------------

Message: 2
Date: Mon, 21 Aug 2017 13:48:18 +0430
From: Masoud Naderpour <naderpour.masoud@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Run Time Error in Sending MIMO on B210
Message-ID:
	<CACasZmQiyZcuZiwwspt=s9P-3XhKu8g+3zL0J1XZBWce=PnbeA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Dear All,
When I transmit on both channels on USRP b210, after some time I receive
the following error:

terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::_S_create

But, in SISO mode there is no problem. Please help me.
Thanks,
Masoud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170821/9f9bb7d2/attachment-0001.html>

------------------------------

Message: 3
Date: Mon, 21 Aug 2017 12:18:53 +0200
From: Nicolas Cuervo <nicolas.cuervo@ettus.com>
To: Snehasish Kar <snehasish.cse@live.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] continues streaming with rx_multi_samps
Message-ID:
	<CAOuPCvhXTb2crNQ3seghGecO+QWJTsNkRY=GoZT67rtU1aggJQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello Snehasish,

you can modify the example to get as many samples as you want, even if what
you want is previously undefined. You might want to change the while loop
condition in order to meet this [1] and add a stop signal (such as ctrl+c)
with std::signal(SIGINT), which is used in other provided examples, so you
can check how it is done.

Analogously, other examples use continuous streaming either for send (like
tx_samples_from_file) or receive (rx_samples_to_file). Adding the
continuous streaming should functionality be straightforward.

Regards,
- Nicolas

[1]
https://github.com/EttusResearch/uhd/blob/maint/host/examples/rx_multi_samples.cpp#L162


On Sat, Aug 12, 2017 at 9:32 AM, Snehasish Kar via USRP-users <
usrp-users@lists.ettus.com> wrote:

Hello

I am able to receive data using rx_multi_samps from two daughter boards of
NI USRP 2954R, but now I nedd it to continuesly stream data, like in
gnuradio.How can i achieve that,  Please help me

with it.

BR

Snehasish


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170821/555d6684/attachment-0001.html>

------------------------------

Message: 4
Date: Mon, 21 Aug 2017 12:08:59 +0000
From: Mark Koenig <mark.koenig@iubelttechnologies.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] USRP-users Digest, Vol 84, Issue 19
Message-ID:
	<ED93198C-19ED-466A-9E6F-67FB3DF45C95@iubelttechnologies.com>
Content-Type: text/plain; charset="utf-8"

Thank you Marcus, so I need to rev my UHD version to 003.010.001?

Mark

On 8/19/17, 12:02 PM, "USRP-users on behalf of usrp-users-request@lists.ettus.com" <usrp-users-bounces@lists.ettus.com on behalf of usrp-users-request@lists.ettus.com> wrote:

    Send USRP-users mailing list submissions to
    	usrp-users@lists.ettus.com
    
    To subscribe or unsubscribe via the World Wide Web, visit
    	http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
    or, via email, send a message with subject or body 'help' to
    	usrp-users-request@lists.ettus.com
    
    You can reach the person managing the list at
    	usrp-users-owner@lists.ettus.com
    
    When replying, please edit your Subject line so it is more specific
    than "Re: Contents of USRP-users digest..."
    
    
    Today's Topics:
    
       1. Re: Building FPGA image (Jason Matusiak)
       2. Re: How is Resolution and Type Determined From ADC - Using
          Ettus rx_samples_to_file.cpp Example (Marcus D. Leech)
       3. Re: x310 with twin rx uhd_usrp probe issue (Marcus M?ller)
    
    
    ----------------------------------------------------------------------
    
    Message: 1
    Date: Fri, 18 Aug 2017 12:42:14 -0400
    From: Jason Matusiak <jason@gardettoengineering.com>
    To: "Torres Figueroa, Luis Angel"
    	<luis.torres.figueroa@rwth-aachen.de>,	"usrp-users@lists.ettus.com"
    	<usrp-users@lists.ettus.com>
    Subject: Re: [USRP-users] Building FPGA image
    Message-ID:
    	<f8335acb-e28a-0539-33c4-3349825327a6@gardettoengineering.com>
    Content-Type: text/plain; charset="utf-8"; Format="flowed"
    
    I'm glad you got it working.  There are a lot of critical warnings and 
    things of that ilk that scroll by, but as long as you don't get any 
    errors and your project meets timing, I wouldn't worry too much about them.
    
    Happy FPGAing.
    
    
    On 08/18/2017 09:26 AM, Torres Figueroa, Luis Angel wrote:

Hi Jason,

It worked. I downloaded the source files from rfnoc-devel branch in
the repository again and build it without choosing the option you
mentioned.

I have still some critical warnings, but the image has been correctly
generated and I could use it in the URSP. Also, all the timing
constraints were now met. Thanks for the advice!

ImplementationDesign Initialization

[Designutils 20-1280] Could not find module 'fifo_4k_2clk'. The XDC
file
/home/rfnoc-devel/source/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/fifo_4k_2clk/fifo_4k_2clk/fifo_4k_2clk.xdc
will not be read for any cell of this module.

[Designutils 20-1280] Could not find module 'axi_hb31'. The XDC file
/home/rfnoc-devel/source/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/axi_hb31/fir_compiler_v7_2_5/constraints/fir_compiler_v7_2.xdc
will not be read for any cell of this module.

[Designutils 20-1280] Could not find module 'fifo_4k_2clk'. The XDC
file
/home/rfnoc-devel/source/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/fifo_4k_2clk/fifo_4k_2clk/fifo_4k_2clk_clocks.xdc
will not be read for any cell of this module.

[Common 17-55] 'set_property' expects at least one object.
["/home/rfnoc-devel/source/uhd/fpga-src/usrp3/top/x300/timing.xdc":293]

[Common 17-55] 'set_property' expects at least one object.
["/home/rfnoc-devel/source/uhd/fpga-src/usrp3/top/x300/timing.xdc":294]

[Common 17-55] 'set_property' expects at least one object.
["/home/rfnoc-devel/source/uhd/fpga-src/usrp3/top/x300/timing.xdc":295]

Best,

Luis

*Von: *Jason Matusiak jason@gardettoengineering.com
*Datum: *Mittwoch, 16. August 2017 um 17:09
*An: *"Torres Figueroa, Luis Angel"
luis.torres.figueroa@rwth-aachen.de, "usrp-users@lists.ettus.com"
usrp-users@lists.ettus.com
*Betreff: *Re: [USRP-users] Building FPGA image

I've done it many times.  When you open it and you do a save-as of the
project, make sure that you don't check the option box to copy the
files over, you want to leave them in their current location.

On 08/16/2017 10:15 AM, Torres Figueroa, Luis Angel via USRP-users wrote:

 Hi folks,

 Has someone of you loaded the whole usrp_x310_fpga_RFNOC_HG design
 into Vivado 2015.4 and created the FPGA image using its graphical
 Interface? I am still unable to do so.

 I want to create a standard FPGA image using Vivado GUI.

 I have first run the command /?make X310_RFNOC_HG GUI=1?/, saved
 the whole RTS design and reopened it as project mode, and then
 tried to create the bitstream from the GUI itself but it doesn?t work.

 I have also tried adding the x300.v file, the constraints and all
 its dependent files into the design, and then done the synthesis,
 implementation and generated the bitstream, but when I loaded it
 onto the USRP I can?t recognize any block using the command
 uhd_usrp_probe. This is the error I get:

 [ERROR] [UHD] Exception caught in safe-call.

   in virtual ctrl_iface_impl::~ctrl_iface_impl()

   at ~/uhd/host/lib/rfnoc/ctrl_iface.cpp:76

 this->peek32(0); -> EnvironmentError: IOError: Block ctrl
 (CE_04_Port_70) no response packet - AssertionError: bool(buff)

   in uint64_t ctrl_iface_impl::wait_for_ack(bool)

   at ~/uhd/host/lib/rfnoc/ctrl_iface.cpp:197

 Best,

 Luis A. Torres




 _______________________________________________

 USRP-users mailing list

 USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>

 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170818/f8693cb7/attachment-0001.html>
    
    ------------------------------
    
    Message: 2
    Date: Fri, 18 Aug 2017 13:08:56 -0400
    From: "Marcus D. Leech" <mleech@ripnet.com>
    To: usrp-users@lists.ettus.com
    Subject: Re: [USRP-users] How is Resolution and Type Determined From
    	ADC - Using Ettus rx_samples_to_file.cpp Example
    Message-ID: <59971F28.2050801@ripnet.com>
    Content-Type: text/plain; charset="windows-1252"; Format="flowed"
    
    On 08/18/2017 11:24 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN 
    TECHNOLOGIES INC] via USRP-users wrote:

Thanks for any help?

I ran the example file from Ettus called rx_samples_to_file.cpp.

I ran the file and it did extract a binary file that I named.

When I analyzed it in matlab using the function ?read_float_binary.m?,
I received much Nan?s and zeros with actual data?

When I ran the function ?read_cfloat_binary.m?, I received data that
makes sense.. but is it the correct way???

I realize the binary file has complex value that is interleaved?.

But when I looked at the code rx_samples_to_file.cpp at the end of it
as shown below?

 //recv to file

 if (type == "double") recv_to_file<std::complex<double> >(usrp, 

uhd::io_type_t::COMPLEX_FLOAT64, file, spb);

 else if (type == "float") recv_to_file<std::complex<float> >(usrp, 

uhd::io_type_t::COMPLEX_FLOAT32, file, spb);

 else if (type == "short") recv_to_file<std::complex<short> >(usrp, 

uhd::io_type_t::COMPLEX_INT16, file, spb);

 else throw std::runtime_error("Unknown type " + type);

Where is the type defined?  I could not find it in the code?  Is it in
a header file?  I could not find that either?

    Each of the UHD examples support a "--help" option.   For 
    rx_samples_to_file, you get:
    
    [INFO] [UHD] linux; GNU C++ version 4.8.3 20140911 (Red Hat 4.8.3-7); 
    Boost_105400; UHD_4.0.0.rfnoc-devel-239-g89427e8c
    UHD RX samples to file Allowed options:
       --help                         help message
       --args arg                     multi uhd device address args
       --file arg (=usrp_samples.dat) name of the file to write binary 
    samples to
       --type arg (=short)            sample type: double, float, or short
       --nsamps arg (=0)              total number of samples to receive
       --duration arg (=0)            total number of seconds to receive
       --time arg                     (DEPRECATED) will go away soon! Use 
    --duration
                                      instead
       --spb arg (=10000)             samples per buffer
       --rate arg (=1000000)          rate of incoming samples
       --freq arg (=0)                RF center frequency in Hz
       --gain arg                     gain for the RF chain
       --ant arg                      antenna selection
       --subdev arg                   subdevice specification
       --bw arg                       analog frontend filter bandwidth in Hz
       --ref arg (=internal)          reference source (internal, external, 
    mimo)
       --wirefmt arg (=sc16)          wire format (sc8 or sc16)
       --setup arg (=1)               seconds of setup time
       --progress                     periodically display short-term bandwidth
       --stats                        show average bandwidth on exit
       --sizemap                      track packet size and display 
    breakdown on
                                      exit
       --null                         run without writing to file
       --continue                     don't abort on a bad packet
       --skip-lo                      skip checking LO lock status
       --int-n                        tune USRP with integer-N tuning
    
    
    This application streams data from a single channel of a USRP device to 
    a file.
    
    You can see the default in parenthesis--which in the case of "--type" 
    defaults to "short".
    
    

There is this if then tree within the matlab finction?.

It seems that the Int16 was used because ?short? was used in the
Matlab complex function as shown below?.

if(f < 0)

 cv = 0;

else

 v = fread (f, count, 'short');

 fclose (f);

 cv = v(1:2:end)+v(2:2:end)*j;

end

This was the output of the constellation?. Thus, noting was over
+/-32 in the ineger side.  Since this kis a 16 bit representation do
we have 10 bits fractional resolution?  S5.10 ???


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

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170818/79b94a00/attachment-0001.html>
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: image/png
    Size: 24156 bytes
    Desc: not available
    URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170818/79b94a00/attachment-0001.png>
    
    ------------------------------
    
    Message: 3
    Date: Fri, 18 Aug 2017 19:13:58 +0200
    From: Marcus M?ller <marcus.mueller@ettus.com>
    To: usrp-users@lists.ettus.com
    Subject: Re: [USRP-users] x310 with twin rx uhd_usrp probe issue
    Message-ID: <efab4da1-3c60-256c-5a76-eb14ad8479bc@ettus.com>
    Content-Type: text/plain; charset="windows-1252"
    
    Hi Mark,
    
    the daughterboard EEPROMs are read and return 0x93 and 0x92 as type, and
    that's the type of the rev. B version of TwinRX. Support for that was
    added in 3.10.1 !
    
    Best regards,
    
    Marcus
    
    
    On 08/18/2017 05:49 PM, Mark Koenig via USRP-users wrote:

I am currently running CentOS 7.2, UHD rev 003.010.000, and GNU radio
version 3.7.11.  When I probe the USRP, it doesn?t read the
daughtercards and provide the correct output for frequency, gain,
bandwidth, etc.  Why would this occur?  I believe I have all the
revisions correct.  I have pasted the output I am seeing in the emil
below.

Any help is appreciated.

Thank you

Mark

When I perform uhd_find devices, I get the output below.

linux; GNU C++ version 4.8.5; Boost_105300;
UHD_003.010.000.git-249-gef57ffcb


-- UHD Device 0


Device Address:

 type: x300

 addr: 192.168.10.2

 fpga: HG

 name:

 serial: F4717C

 product: X310

When I perform uhd_usrp probe, I get the output below.

linux; GNU C++ version 4.8.5; Boost_105300;
UHD_003.010.000.git-249-gef57ffcb

-- X300 initialization sequence...

-- Determining maximum frame size... 1472 bytes.

-- Setup basic communication...

-- Loading values from EEPROM...

-- Setup RF frontend clocking...

-- Radio 1x clock:200

-- Detecting internal GPSDO.... Found an internal GPSDO

-- Initialize Radio0 control...

-- Performing register loopback test... pass

-- Initialize Radio1 control...

-- Performing register loopback test... pass


/

|      Device: X-Series Device

|    _____________________________________________________

|    /

|  |      Mboard: X310

|  |  revision: 4

|  |  product: 30410

|  |  mac-addr0: 00:80:2f:0a:e3:35

|  |  mac-addr1: 00:80:2f:0a:e3:36

|  |  gateway: 192.168.10.1

|  |  ip-addr0: 192.168.10.2

|  |  subnet0: 255.255.255.0

|  |  ip-addr1: 192.168.20.2

|  |  subnet1: 255.255.255.0

|  |  ip-addr2: 192.168.30.2

|  |  subnet2: 255.255.255.0

|  |  ip-addr3: 192.168.40.2

|  |  subnet3: 255.255.255.0

|  |  serial: F4717C

|  |  FW Version: 4.0

|  |  FPGA Version: 20.0

|  |

|  |  Time sources:  internal, external, gpsdo

|  |  Clock sources: internal, external, gpsdo

|  |  Sensors: gps_gpgga, gps_gprmc, gps_time, gps_locked,
gps_servo, ref_locked

|  |    _____________________________________________________

|  |    /

|  |  |      RX DSP: 0

|  |  |  Freq range: -100.000 to 100.000 MHz

|  |    _____________________________________________________

|  |    /

|  |  |      RX DSP: 1

|  |  |  Freq range: -100.000 to 100.000 MHz

|  |    _____________________________________________________

|  |    /

|  |  |      RX Dboard: A

|  |  |  ID: Unknown (0x0093)

|  |  |  Serial: 30F2039

|  |  |    _____________________________________________________

|  |  |    /

|  |  |  |      RX Frontend: 0

|  |  |  |  Name: Unknown (0x0093) - 0

|  |  |  |  Antennas:

|  |  |  |  Sensors:

|  |  |  |  Freq range: 0.000 to 0.000 MHz

|  |  |  |  Gain Elements: None

|  |  |  |  Bandwidth range: 0.0 to 0.0 step 0.0 Hz

|  |  |  |  Connection Type: IQ

|  |  |  |  Uses LO offset: No

|  |  |    _____________________________________________________

|  |  |    /

|  |  |  |      RX Codec: A

|  |  |  |  Name: ads62p48

|  |  |  |  Gain range digital: 0.0 to 6.0 step 0.5 dB

|  |    _____________________________________________________

|  |    /

|  |  |      RX Dboard: B

|  |  |  ID: Unknown (0x0093)

|  |  |  Serial: 30F2025

|  |  |    _____________________________________________________

|  |  |    /

|  |  |  |      RX Frontend: 0

|  |  |  |  Name: Unknown (0x0093) - 0

|  |  |  |  Antennas:

|  |  |  |  Sensors:

|  |  |  |  Freq range: 0.000 to 0.000 MHz

|  |  |  |  Gain Elements: None

|  |  |  |  Bandwidth range: 0.0 to 0.0 step 0.0 Hz

|  |  |  |  Connection Type: IQ

|  |  |  |  Uses LO offset: No

|  |  |    _____________________________________________________

|  |  |    /

|  |  |  |      RX Codec: B

|  |  |  |  Name: ads62p48

|  |  |  |  Gain range digital: 0.0 to 6.0 step 0.5 dB

|  |    _____________________________________________________

|  |    /

|  |  |      TX DSP: 0

|  |  |  Freq range: -100.000 to 100.000 MHz

|  |    _____________________________________________________

|  |    /

|  |  |      TX DSP: 1

|  |  |  Freq range: -100.000 to 100.000 MHz

|  |    _____________________________________________________

|  |    /

|  |  |      TX Dboard: A

|  |  |  ID: Unknown (0x0092)

|  |  |  Serial: 30F29BC

|  |  |    _____________________________________________________

|  |  |    /

|  |  |  |      TX Frontend: 0

|  |  |  |  Name: Unknown (0x0092) - 0

|  |  |  |  Antennas:

|  |  |  |  Sensors:

|  |  |  |  Freq range: 0.000 to 0.000 MHz

|  |  |  |  Gain Elements: None

|  |  |  |  Bandwidth range: 0.0 to 0.0 step 0.0 Hz

|  |  |  |  Connection Type: IQ

|  |  |  |  Uses LO offset: No

|  |  |    _____________________________________________________

|  |  |    /

|  |  |  |      TX Codec: A

|  |  |  |  Name: ad9146

|  |  |  |  Gain Elements: None

|  |    _____________________________________________________

|  |    /

|  |  |      TX Dboard: B

|  |  |  ID: Unknown (0x0092)

|  |  |  Serial: 30F2B48

|  |  |    _____________________________________________________

|  |  |    /

|  |  |  |      TX Frontend: 0

|  |  |  |  Name: Unknown (0x0092) - 0

|  |  |  |  Antennas:

|  |  |  |  Sensors:

|  |  |  |  Freq range: 0.000 to 0.000 MHz

|  |  |  |  Gain Elements: None

|  |  |  |  Bandwidth range: 0.0 to 0.0 step 0.0 Hz

|  |  |  |  Connection Type: IQ

|  |  |  |  Uses LO offset: No

|  |  |    _____________________________________________________

|  |  |    /

|  |  |  |      TX Codec: B

|  |  |  |  Name: ad9146

|  |  |  |  Gain Elements: None


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

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170818/5e0f62d2/attachment-0001.html>
    
    ------------------------------
    
    Subject: Digest Footer
    
    _______________________________________________
    USRP-users mailing list
    USRP-users@lists.ettus.com
    http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
    
    
    ------------------------------
    
    End of USRP-users Digest, Vol 84, Issue 19
    ******************************************
    


------------------------------

Message: 5
Date: Mon, 21 Aug 2017 15:42:32 +0200
From: Dominik Eyerly <d.eyerly@konrad-technologies.de>
To: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] ADC Overflow - B205i
Message-ID:
	<9cc4cc83-1b56-6563-76fd-f886303dbf6a@konrad-technologies.de>
Content-Type: text/plain; charset="utf-8"

Hello,

Is it possible to obtain a status of the ADC on the B205i using the UHD
driver? In particular, I am interested in detecting adc overflows, i.e.
too much power at the input.

Best regards,
Dominik

-- 



-- 

i.A. Dominik Eyerly
Head of RF Software

Tel:      +49 (0) 351 7958019 233
Fax:     +49 (0) 351 7958019 232
Email:   d.eyerly@konrad-technologies.de <mailto:d.eyerly@konrad-technologies.de>

*Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
www.konrad-technologies.de <http://www.konrad-technologies.de>
www.abexstandard.org <http://www.abexstandard.org>

*Support Telefon: +49 (0) 7732 9815 100*
support@konrad-technologies.de <mailto:support@konrad-technologies.de>
sig
Gesch?ftsleitung: Michael Konrad 
Handelsregisternr: HRB 550593 in Freiburg 
Ust-Id-Nr. DE 206693267

VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender bitte umgehend. Danke

CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it, contains information from Konrad GmbH, which is intended only for the use of the individual or entity to which it is addressed, and which may contain information that is privileged, confidential, and/or otherwise exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, any disclosure, dissemination, distribution, copying or other use of this communication or its substance is prohibited. If you have received this communication in error, please contact us immediately. Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170821/c52c1a05/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 43982 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170821/c52c1a05/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170821/c52c1a05/attachment-0001.asc>

------------------------------

Message: 6
Date: Mon, 21 Aug 2017 17:08:48 +0200
From: Marcus M?ller <marcus.mueller@ettus.com>
To: Dominik Eyerly <d.eyerly@konrad-technologies.de>,	Dominik Eyerly
	via USRP-users <usrp-users@lists.ettus.com>,
	"USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] ADC Overflow - B205i
Message-ID: <0E1F6D9A-086B-4D6F-89A3-4DDF8D8B2FAC@ettus.com>
Content-Type: text/plain; charset="utf-8"

Dear Mr. Eyerly,

Indeed, the AD9361 has an overload indicator register. (Ad9361 manual ug-570, page 76)

We don't directly expose that, but with modifications in our host/lib/usrp tree's ad9361_driver, you could expose that by publishing a register reader in the property_tree.

Does that sound like the direction you'd like to take this?

Best regards,
Marcus M

On 21 August 2017 3:42:32 PM GMT+02:00, Dominik Eyerly via USRP-users <usrp-users@lists.ettus.com> wrote:

Hello,

Is it possible to obtain a status of the ADC on the B205i using the UHD
driver? In particular, I am interested in detecting adc overflows, i.e.
too much power at the input.

Best regards,
Dominik

--

--

i.A. Dominik Eyerly
Head of RF Software

Tel:      +49 (0) 351 7958019 233
Fax:    +49 (0) 351 7958019 232
Email:  d.eyerly@konrad-technologies.de
mailto:d.eyerly@konrad-technologies.de

Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell
www.konrad-technologies.de http://www.konrad-technologies.de
www.abexstandard.org http://www.abexstandard.org

Support Telefon: +49 (0) 7732 9815 100
support@konrad-technologies.de mailto:support@konrad-technologies.de
sig
Gesch?ftsleitung: Michael Konrad
Handelsregisternr: HRB 550593 in Freiburg
Ust-Id-Nr. DE 206693267

VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen
Sie haftbar gemacht werden. Falls Sie nicht der Empf?nger sind,
benachrichtigen Sie den Absender bitte umgehend. Danke

CONFIDENTIALITY NOTICE: This e-mail and any documents which may
accompany it, contains information from Konrad GmbH, which is intended
only for the use of the individual or entity to which it is addressed,
and which may contain information that is privileged, confidential,
and/or otherwise exempt from disclosure under applicable law. If the
reader of this message is not the intended recipient, any disclosure,
dissemination, distribution, copying or other use of this communication
or its substance is prohibited. If you have received this communication
in error, please contact us immediately. Thank you.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170821/89bb4031/attachment-0001.html>

------------------------------

Message: 7
Date: Mon, 21 Aug 2017 17:31:11 +0200
From: Dominik Eyerly <d.eyerly@konrad-technologies.de>
To: Marcus M?ller <marcus.mueller@ettus.com>,	Dominik Eyerly via
	USRP-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] ADC Overflow - B205i
Message-ID:
	<8092ae0d-fd64-6ecb-ea0c-890c56435e55@konrad-technologies.de>
Content-Type: text/plain; charset="utf-8"

Hi Marcus,

Yes, I saw that in the AD datasheet :)

The answer you provided does sound promising. Would you be able to
provide some more detail on how this is accomplished? A simple example
would be great. If an example is too much work, an explanation of where
the modification takes place and how it would boil up to the user would
be very useful as well.

Also, is there another efficient solution or would this be the one you
recommend?

thanks,
Dominik


On 08/21/2017 05:08 PM, Marcus M?ller wrote:

Dear Mr. Eyerly,

Indeed, the AD9361 has an overload indicator register. (Ad9361 manual
ug-570, page 76)

We don't directly expose that, but with modifications in our
host/lib/usrp tree's ad9361_driver, you could expose that by
publishing a register reader in the property_tree.

Does that sound like the direction you'd like to take this?

Best regards,
Marcus M

On 21 August 2017 3:42:32 PM GMT+02:00, Dominik Eyerly via USRP-users
usrp-users@lists.ettus.com wrote:

 Hello,

 Is it possible to obtain a status of the ADC on the B205i using
 the UHD driver? In particular, I am interested in detecting adc
 overflows, i.e. too much power at the input.

 Best regards,
 Dominik

 -- 



 -- 

 i.A. Dominik Eyerly
 Head of RF Software

 Tel:      +49 (0) 351 7958019 233
 Fax:     +49 (0) 351 7958019 232
 Email:   d.eyerly@konrad-technologies.de
 <mailto:d.eyerly@konrad-technologies.de>

 *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
 www.konrad-technologies.de <http://www.konrad-technologies.de>
 www.abexstandard.org <http://www.abexstandard.org>

 *Support Telefon: +49 (0) 7732 9815 100*
 support@konrad-technologies.de <mailto:support@konrad-technologies.de>
 sig
 Gesch?ftsleitung: Michael Konrad 
 Handelsregisternr: HRB 550593 in Freiburg 
 Ust-Id-Nr. DE 206693267

 VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender bitte umgehend. Danke

 CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it, contains information from Konrad GmbH, which is intended only for the use of the individual or entity to which it is addressed, and which may contain information that is privileged, confidential, and/or otherwise exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, any disclosure, dissemination, distribution, copying or other use of this communication or its substance is prohibited. If you have received this communication in error, please contact us immediately. Thank you.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 



-- 

i.A. Dominik Eyerly
Head of RF Software

Tel:      +49 (0) 351 7958019 233
Fax:     +49 (0) 351 7958019 232
Email:   d.eyerly@konrad-technologies.de <mailto:d.eyerly@konrad-technologies.de>

*Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell*
www.konrad-technologies.de <http://www.konrad-technologies.de>
www.abexstandard.org <http://www.abexstandard.org>

*Support Telefon: +49 (0) 7732 9815 100*
support@konrad-technologies.de <mailto:support@konrad-technologies.de>
sig
Gesch?ftsleitung: Michael Konrad 
Handelsregisternr: HRB 550593 in Freiburg 
Ust-Id-Nr. DE 206693267

VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender bitte umgehend. Danke

CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it, contains information from Konrad GmbH, which is intended only for the use of the individual or entity to which it is addressed, and which may contain information that is privileged, confidential, and/or otherwise exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, any disclosure, dissemination, distribution, copying or other use of this communication or its substance is prohibited. If you have received this communication in error, please contact us immediately. Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170821/71c55624/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 43982 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170821/71c55624/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170821/71c55624/attachment-0001.asc>

------------------------------

Subject: Digest Footer

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


------------------------------

End of USRP-users Digest, Vol 84, Issue 21
******************************************
Just to follow up on this, I updated the UHD rev and am now getting the output below. It is showing the Connection Type as II and QQ for Rx front end 0 and 1. Is this correct? I would expect to see IQ……is this the problem? Below is my output. Thanks Mark linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-11); Boost_105300; UHD_003.010.001.000-0-unknown -- X300 initialization sequence... -- Determining maximum frame size... 1472 bytes. -- Setup basic communication... -- Loading values from EEPROM... -- Setup RF frontend clocking... -- Radio 1x clock:200 -- Detecting internal GPSDO.... Found an internal GPSDO: LC_XO, Firmware Rev 0.929a -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1182.8MB/s) -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1168.8MB/s) -- [RFNoC Radio] Performing register loopback test... pass -- [RFNoC Radio] Performing register loopback test... pass -- [RFNoC Radio] Performing register loopback test... pass -- [RFNoC Radio] Performing register loopback test... pass -- Performing timer loopback test... pass -- Performing timer loopback test... pass _____________________________________________________ / | Device: X-Series Device | _____________________________________________________ | / | | Mboard: X310 | | revision: 4 | | product: 30410 | | mac-addr0: 00:80:2f:0a:e3:35 | | mac-addr1: 00:80:2f:0a:e3:36 | | gateway: 192.168.10.1 | | ip-addr0: 192.168.10.2 | | subnet0: 255.255.255.0 | | ip-addr1: 192.168.20.2 | | subnet1: 255.255.255.0 | | ip-addr2: 192.168.30.2 | | subnet2: 255.255.255.0 | | ip-addr3: 192.168.40.2 | | subnet3: 255.255.255.0 | | serial: F4717C | | FW Version: 5.0 | | FPGA Version: 33.0 | | RFNoC capable: Yes | | | | Time sources: internal, external, gpsdo | | Clock sources: internal, external, gpsdo | | Sensors: gps_gpgga, gps_gprmc, gps_time, gps_locked, gps_servo, ref_locked | | _____________________________________________________ | | / | | | RX Dboard: A | | | ID: TwinRX v1.1 (0x0093) | | | Serial: 30F2039 | | | _____________________________________________________ | | | / | | | | RX Frontend: 0 | | | | Name: TwinRX RX0 | | | | Antennas: RX1, RX2 | | | | Sensors: lo_locked | | | | Freq range: 10.000 to 6000.000 MHz | | | | Gain range all: 0.0 to 95.0 step 1.0 dB | | | | Bandwidth range: 80000000.0 to 80000000.0 step 0.0 Hz | | | | Connection Type: II | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | RX Frontend: 1 | | | | Name: TwinRX RX1 | | | | Antennas: RX1, RX2 | | | | Sensors: lo_locked | | | | Freq range: 10.000 to 6000.000 MHz | | | | Gain range all: 0.0 to 95.0 step 1.0 dB | | | | Bandwidth range: 80000000.0 to 80000000.0 step 0.0 Hz | | | | Connection Type: QQ | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | RX Codec: A | | | | Name: ads62p48 | | | | Gain range digital: 0.0 to 6.0 step 0.5 dB | | _____________________________________________________ | | / | | | RX Dboard: B | | | ID: TwinRX v1.1 (0x0093) | | | Serial: 30F2025 | | | _____________________________________________________ | | | / | | | | RX Frontend: 0 | | | | Name: TwinRX RX0 | | | | Antennas: RX1, RX2 | | | | Sensors: lo_locked | | | | Freq range: 10.000 to 6000.000 MHz | | | | Gain range all: 0.0 to 95.0 step 1.0 dB | | | | Bandwidth range: 80000000.0 to 80000000.0 step 0.0 Hz | | | | Connection Type: II | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | RX Frontend: 1 | | | | Name: TwinRX RX1 | | | | Antennas: RX1, RX2 | | | | Sensors: lo_locked | | | | Freq range: 10.000 to 6000.000 MHz | | | | Gain range all: 0.0 to 95.0 step 1.0 dB | | | | Bandwidth range: 80000000.0 to 80000000.0 step 0.0 Hz | | | | Connection Type: QQ | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | RX Codec: B | | | | Name: ads62p48 | | | | Gain range digital: 0.0 to 6.0 step 0.5 dB | | _____________________________________________________ | | / | | | TX Dboard: A | | | ID: Unknown (0x0092) | | | Serial: 30F29BC | | | _____________________________________________________ | | | / | | | | TX Frontend: 0 | | | | Name: Unknown (0x0092) - 0 | | | | Antennas: | | | | Sensors: | | | | Freq range: 0.000 to 0.000 MHz | | | | Gain Elements: None | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | TX Codec: A | | | | Name: ad9146 | | | | Gain Elements: None | | _____________________________________________________ | | / | | | TX Dboard: B | | | ID: Unknown (0x0092) | | | Serial: 30F2B48 | | | _____________________________________________________ | | | / | | | | TX Frontend: 0 | | | | Name: Unknown (0x0092) - 0 | | | | Antennas: | | | | Sensors: | | | | Freq range: 0.000 to 0.000 MHz | | | | Gain Elements: None | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _____________________________________________________ | | | / | | | | TX Codec: B | | | | Name: ad9146 | | | | Gain Elements: None | | _____________________________________________________ | | / | | | RFNoC blocks on this device: | | | | | | * DmaFIFO_0 | | | * Radio_0 | | | * Radio_1 | | | * DDC_0 | | | * DDC_1 | | | * DUC_0 | | | * DUC_1 On 8/21/17, 12:01 PM, "USRP-users on behalf of usrp-users-request@lists.ettus.com" <usrp-users-bounces@lists.ettus.com on behalf of usrp-users-request@lists.ettus.com> wrote: Send USRP-users mailing list submissions to usrp-users@lists.ettus.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com or, via email, send a message with subject or body 'help' to usrp-users-request@lists.ettus.com You can reach the person managing the list at usrp-users-owner@lists.ettus.com When replying, please edit your Subject line so it is more specific than "Re: Contents of USRP-users digest..." Today's Topics: 1. Synchronised RX and TX control in X310 (Karan Suri) 2. Run Time Error in Sending MIMO on B210 (Masoud Naderpour) 3. Re: continues streaming with rx_multi_samps (Nicolas Cuervo) 4. Re: USRP-users Digest, Vol 84, Issue 19 (Mark Koenig) 5. ADC Overflow - B205i (Dominik Eyerly) 6. Re: ADC Overflow - B205i (Marcus M?ller) 7. Re: ADC Overflow - B205i (Dominik Eyerly) ---------------------------------------------------------------------- Message: 1 Date: Mon, 21 Aug 2017 00:17:15 -0400 From: Karan Suri <youngsuri@gmail.com> To: usrp-users <usrp-users@lists.ettus.com> Subject: [USRP-users] Synchronised RX and TX control in X310 Message-ID: <CAN+qiuPntGDfA9Q0jbojs3LpQ3_h1fBrGsUALz3fDkQtZj8sRg@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hello usrp-users. I was successfully using a source code capable of transmitting and Receiving OFDM packets in USRP X310. The anchor USRP transmits an OFDM packet at frequency f1 , it is received by a tag USRP which loops back the received OFDM packets at frequency f2. The same OFDM packet is then captured back at the RX of Anchor and dumped into a file. I was using version 3.10.1 until few days back when I shifted to 3.10.2 to allow the compatibility of Rev D UBX-160 daughter board. The code successfully builds but can no longer function as it used to in the previous version. I am using "uhd::get_time_now() and uhd::time_sepc_t(n)" to synchronise the start of transmit and receive. I need to transfer 20 such packets (so that the result can be averaged). Between each iteration of packet transfer the tx and RX of anchor USRP are put to sleep for specific duration. Do you have any idea what might be going wrong when i shifted to a newer version. Are the old codes no longer compatible, or do they function differently? Karan Suri -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170821/8eef2ec3/attachment-0001.html> ------------------------------ Message: 2 Date: Mon, 21 Aug 2017 13:48:18 +0430 From: Masoud Naderpour <naderpour.masoud@gmail.com> To: usrp-users@lists.ettus.com Subject: [USRP-users] Run Time Error in Sending MIMO on B210 Message-ID: <CACasZmQiyZcuZiwwspt=s9P-3XhKu8g+3zL0J1XZBWce=PnbeA@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Dear All, When I transmit on both channels on USRP b210, after some time I receive the following error: terminate called after throwing an instance of 'std::length_error' what(): basic_string::_S_create But, in SISO mode there is no problem. Please help me. Thanks, Masoud -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170821/9f9bb7d2/attachment-0001.html> ------------------------------ Message: 3 Date: Mon, 21 Aug 2017 12:18:53 +0200 From: Nicolas Cuervo <nicolas.cuervo@ettus.com> To: Snehasish Kar <snehasish.cse@live.com> Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com> Subject: Re: [USRP-users] continues streaming with rx_multi_samps Message-ID: <CAOuPCvhXTb2crNQ3seghGecO+QWJTsNkRY=GoZT67rtU1aggJQ@mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hello Snehasish, you can modify the example to get as many samples as you want, even if what you want is previously undefined. You might want to change the while loop condition in order to meet this [1] and add a stop signal (such as ctrl+c) with std::signal(SIGINT), which is used in other provided examples, so you can check how it is done. Analogously, other examples use continuous streaming either for send (like tx_samples_from_file) or receive (rx_samples_to_file). Adding the continuous streaming should functionality be straightforward. Regards, - Nicolas [1] https://github.com/EttusResearch/uhd/blob/maint/host/examples/rx_multi_samples.cpp#L162 On Sat, Aug 12, 2017 at 9:32 AM, Snehasish Kar via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello > > > I am able to receive data using rx_multi_samps from two daughter boards of > NI USRP 2954R, but now I nedd it to continuesly stream data, like in > gnuradio.How can i achieve that, Please help me > > with it. > > > BR > > Snehasish > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170821/555d6684/attachment-0001.html> ------------------------------ Message: 4 Date: Mon, 21 Aug 2017 12:08:59 +0000 From: Mark Koenig <mark.koenig@iubelttechnologies.com> To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com> Subject: Re: [USRP-users] USRP-users Digest, Vol 84, Issue 19 Message-ID: <ED93198C-19ED-466A-9E6F-67FB3DF45C95@iubelttechnologies.com> Content-Type: text/plain; charset="utf-8" Thank you Marcus, so I need to rev my UHD version to 003.010.001? Mark On 8/19/17, 12:02 PM, "USRP-users on behalf of usrp-users-request@lists.ettus.com" <usrp-users-bounces@lists.ettus.com on behalf of usrp-users-request@lists.ettus.com> wrote: Send USRP-users mailing list submissions to usrp-users@lists.ettus.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com or, via email, send a message with subject or body 'help' to usrp-users-request@lists.ettus.com You can reach the person managing the list at usrp-users-owner@lists.ettus.com When replying, please edit your Subject line so it is more specific than "Re: Contents of USRP-users digest..." Today's Topics: 1. Re: Building FPGA image (Jason Matusiak) 2. Re: How is Resolution and Type Determined From ADC - Using Ettus rx_samples_to_file.cpp Example (Marcus D. Leech) 3. Re: x310 with twin rx uhd_usrp probe issue (Marcus M?ller) ---------------------------------------------------------------------- Message: 1 Date: Fri, 18 Aug 2017 12:42:14 -0400 From: Jason Matusiak <jason@gardettoengineering.com> To: "Torres Figueroa, Luis Angel" <luis.torres.figueroa@rwth-aachen.de>, "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com> Subject: Re: [USRP-users] Building FPGA image Message-ID: <f8335acb-e28a-0539-33c4-3349825327a6@gardettoengineering.com> Content-Type: text/plain; charset="utf-8"; Format="flowed" I'm glad you got it working. There are a lot of critical warnings and things of that ilk that scroll by, but as long as you don't get any errors and your project meets timing, I wouldn't worry too much about them. Happy FPGAing. On 08/18/2017 09:26 AM, Torres Figueroa, Luis Angel wrote: > > Hi Jason, > > It worked. I downloaded the source files from rfnoc-devel branch in > the repository again and build it without choosing the option you > mentioned. > > I have still some critical warnings, but the image has been correctly > generated and I could use it in the URSP. Also, all the timing > constraints were now met. Thanks for the advice! > > ImplementationDesign Initialization > > [Designutils 20-1280] Could not find module 'fifo_4k_2clk'. The XDC > file > /home/rfnoc-devel/source/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/fifo_4k_2clk/fifo_4k_2clk/fifo_4k_2clk.xdc > will not be read for any cell of this module. > > [Designutils 20-1280] Could not find module 'axi_hb31'. The XDC file > /home/rfnoc-devel/source/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/axi_hb31/fir_compiler_v7_2_5/constraints/fir_compiler_v7_2.xdc > will not be read for any cell of this module. > > [Designutils 20-1280] Could not find module 'fifo_4k_2clk'. The XDC > file > /home/rfnoc-devel/source/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/fifo_4k_2clk/fifo_4k_2clk/fifo_4k_2clk_clocks.xdc > will not be read for any cell of this module. > > [Common 17-55] 'set_property' expects at least one object. > ["/home/rfnoc-devel/source/uhd/fpga-src/usrp3/top/x300/timing.xdc":293] > > [Common 17-55] 'set_property' expects at least one object. > ["/home/rfnoc-devel/source/uhd/fpga-src/usrp3/top/x300/timing.xdc":294] > > [Common 17-55] 'set_property' expects at least one object. > ["/home/rfnoc-devel/source/uhd/fpga-src/usrp3/top/x300/timing.xdc":295] > > Best, > > Luis > > *Von: *Jason Matusiak <jason@gardettoengineering.com> > *Datum: *Mittwoch, 16. August 2017 um 17:09 > *An: *"Torres Figueroa, Luis Angel" > <luis.torres.figueroa@rwth-aachen.de>, "usrp-users@lists.ettus.com" > <usrp-users@lists.ettus.com> > *Betreff: *Re: [USRP-users] Building FPGA image > > I've done it many times. When you open it and you do a save-as of the > project, make sure that you don't check the option box to copy the > files over, you want to leave them in their current location. > > On 08/16/2017 10:15 AM, Torres Figueroa, Luis Angel via USRP-users wrote: > > Hi folks, > > Has someone of you loaded the whole usrp_x310_fpga_RFNOC_HG design > into Vivado 2015.4 and created the FPGA image using its graphical > Interface? I am still unable to do so. > > I want to create a standard FPGA image using Vivado GUI. > > I have first run the command /?make X310_RFNOC_HG GUI=1?/, saved > the whole RTS design and reopened it as project mode, and then > tried to create the bitstream from the GUI itself but it doesn?t work. > > I have also tried adding the x300.v file, the constraints and all > its dependent files into the design, and then done the synthesis, > implementation and generated the bitstream, but when I loaded it > onto the USRP I can?t recognize any block using the command > uhd_usrp_probe. This is the error I get: > > [ERROR] [UHD] Exception caught in safe-call. > > in virtual ctrl_iface_impl::~ctrl_iface_impl() > > at ~/uhd/host/lib/rfnoc/ctrl_iface.cpp:76 > > this->peek32(0); -> EnvironmentError: IOError: Block ctrl > (CE_04_Port_70) no response packet - AssertionError: bool(buff) > > in uint64_t ctrl_iface_impl::wait_for_ack(bool) > > at ~/uhd/host/lib/rfnoc/ctrl_iface.cpp:197 > > Best, > > Luis A. Torres > > > > > _______________________________________________ > > USRP-users mailing list > > USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170818/f8693cb7/attachment-0001.html> ------------------------------ Message: 2 Date: Fri, 18 Aug 2017 13:08:56 -0400 From: "Marcus D. Leech" <mleech@ripnet.com> To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] How is Resolution and Type Determined From ADC - Using Ettus rx_samples_to_file.cpp Example Message-ID: <59971F28.2050801@ripnet.com> Content-Type: text/plain; charset="windows-1252"; Format="flowed" On 08/18/2017 11:24 AM, Matheou, Konstantin J. (GRC-LCI0)[ZIN TECHNOLOGIES INC] via USRP-users wrote: > > Thanks for any help? > > I ran the example file from Ettus called rx_samples_to_file.cpp. > > I ran the file and it did extract a binary file that I named. > > When I analyzed it in matlab using the function ?read_float_binary.m?, > I received much Nan?s and zeros with actual data? > > When I ran the function ?read_cfloat_binary.m?, I received data that > makes sense.. but is it the correct way??? > > I realize the binary file has complex value that is interleaved?. > > But when I looked at the code rx_samples_to_file.cpp at the end of it > as shown below? > > //recv to file > > if (type == "double") recv_to_file<std::complex<double> >(usrp, > uhd::io_type_t::COMPLEX_FLOAT64, file, spb); > > else if (type == "float") recv_to_file<std::complex<float> >(usrp, > uhd::io_type_t::COMPLEX_FLOAT32, file, spb); > > else if (type == "short") recv_to_file<std::complex<short> >(usrp, > uhd::io_type_t::COMPLEX_INT16, file, spb); > > else throw std::runtime_error("Unknown type " + type); > > Where is the type defined? I could not find it in the code? Is it in > a header file? I could not find that either? > Each of the UHD examples support a "--help" option. For rx_samples_to_file, you get: [INFO] [UHD] linux; GNU C++ version 4.8.3 20140911 (Red Hat 4.8.3-7); Boost_105400; UHD_4.0.0.rfnoc-devel-239-g89427e8c UHD RX samples to file Allowed options: --help help message --args arg multi uhd device address args --file arg (=usrp_samples.dat) name of the file to write binary samples to --type arg (=short) sample type: double, float, or short --nsamps arg (=0) total number of samples to receive --duration arg (=0) total number of seconds to receive --time arg (DEPRECATED) will go away soon! Use --duration instead --spb arg (=10000) samples per buffer --rate arg (=1000000) rate of incoming samples --freq arg (=0) RF center frequency in Hz --gain arg gain for the RF chain --ant arg antenna selection --subdev arg subdevice specification --bw arg analog frontend filter bandwidth in Hz --ref arg (=internal) reference source (internal, external, mimo) --wirefmt arg (=sc16) wire format (sc8 or sc16) --setup arg (=1) seconds of setup time --progress periodically display short-term bandwidth --stats show average bandwidth on exit --sizemap track packet size and display breakdown on exit --null run without writing to file --continue don't abort on a bad packet --skip-lo skip checking LO lock status --int-n tune USRP with integer-N tuning This application streams data from a single channel of a USRP device to a file. You can see the default in parenthesis--which in the case of "--type" defaults to "short". > There is this if then tree within the matlab finction?. > > It seems that the Int16 was used because ?short? was used in the > Matlab complex function as shown below?. > > if(f < 0) > > cv = 0; > > else > > v = fread (f, count, 'short'); > > fclose (f); > > cv = v(1:2:end)+v(2:2:end)*j; > > end > > This was the output of the constellation?. Thus, noting was over > +/-32 in the ineger side. Since this kis a 16 bit representation do > we have 10 bits fractional resolution? S5.10 ??? > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170818/79b94a00/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 24156 bytes Desc: not available URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170818/79b94a00/attachment-0001.png> ------------------------------ Message: 3 Date: Fri, 18 Aug 2017 19:13:58 +0200 From: Marcus M?ller <marcus.mueller@ettus.com> To: usrp-users@lists.ettus.com Subject: Re: [USRP-users] x310 with twin rx uhd_usrp probe issue Message-ID: <efab4da1-3c60-256c-5a76-eb14ad8479bc@ettus.com> Content-Type: text/plain; charset="windows-1252" Hi Mark, the daughterboard EEPROMs are read and return 0x93 and 0x92 as type, and that's the type of the rev. B version of TwinRX. Support for that was added in 3.10.1 ! Best regards, Marcus On 08/18/2017 05:49 PM, Mark Koenig via USRP-users wrote: > > I am currently running CentOS 7.2, UHD rev 003.010.000, and GNU radio > version 3.7.11. When I probe the USRP, it doesn?t read the > daughtercards and provide the correct output for frequency, gain, > bandwidth, etc. Why would this occur? I believe I have all the > revisions correct. I have pasted the output I am seeing in the emil > below. > > > > Any help is appreciated. > > > > Thank you > > > > Mark > > > > When I perform uhd_find devices, I get the output below. > > > > linux; GNU C++ version 4.8.5; Boost_105300; > UHD_003.010.000.git-249-gef57ffcb > > > > -------------------------------------------------- > > -- UHD Device 0 > > -------------------------------------------------- > > Device Address: > > type: x300 > > addr: 192.168.10.2 > > fpga: HG > > name: > > serial: F4717C > > product: X310 > > > > > > When I perform uhd_usrp probe, I get the output below. > > > > linux; GNU C++ version 4.8.5; Boost_105300; > UHD_003.010.000.git-249-gef57ffcb > > > > -- X300 initialization sequence... > > -- Determining maximum frame size... 1472 bytes. > > -- Setup basic communication... > > -- Loading values from EEPROM... > > -- Setup RF frontend clocking... > > -- Radio 1x clock:200 > > -- Detecting internal GPSDO.... Found an internal GPSDO > > -- Initialize Radio0 control... > > -- Performing register loopback test... pass > > -- Initialize Radio1 control... > > -- Performing register loopback test... pass > > _____________________________________________________ > > / > > | Device: X-Series Device > > | _____________________________________________________ > > | / > > | | Mboard: X310 > > | | revision: 4 > > | | product: 30410 > > | | mac-addr0: 00:80:2f:0a:e3:35 > > | | mac-addr1: 00:80:2f:0a:e3:36 > > | | gateway: 192.168.10.1 > > | | ip-addr0: 192.168.10.2 > > | | subnet0: 255.255.255.0 > > | | ip-addr1: 192.168.20.2 > > | | subnet1: 255.255.255.0 > > | | ip-addr2: 192.168.30.2 > > | | subnet2: 255.255.255.0 > > | | ip-addr3: 192.168.40.2 > > | | subnet3: 255.255.255.0 > > | | serial: F4717C > > | | FW Version: 4.0 > > | | FPGA Version: 20.0 > > | | > > | | Time sources: internal, external, gpsdo > > | | Clock sources: internal, external, gpsdo > > | | Sensors: gps_gpgga, gps_gprmc, gps_time, gps_locked, > gps_servo, ref_locked > > | | _____________________________________________________ > > | | / > > | | | RX DSP: 0 > > | | | Freq range: -100.000 to 100.000 MHz > > | | _____________________________________________________ > > | | / > > | | | RX DSP: 1 > > | | | Freq range: -100.000 to 100.000 MHz > > | | _____________________________________________________ > > | | / > > | | | RX Dboard: A > > | | | ID: Unknown (0x0093) > > | | | Serial: 30F2039 > > | | | _____________________________________________________ > > | | | / > > | | | | RX Frontend: 0 > > | | | | Name: Unknown (0x0093) - 0 > > | | | | Antennas: > > | | | | Sensors: > > | | | | Freq range: 0.000 to 0.000 MHz > > | | | | Gain Elements: None > > | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz > > | | | | Connection Type: IQ > > | | | | Uses LO offset: No > > | | | _____________________________________________________ > > | | | / > > | | | | RX Codec: A > > | | | | Name: ads62p48 > > | | | | Gain range digital: 0.0 to 6.0 step 0.5 dB > > | | _____________________________________________________ > > | | / > > | | | RX Dboard: B > > | | | ID: Unknown (0x0093) > > | | | Serial: 30F2025 > > | | | _____________________________________________________ > > | | | / > > | | | | RX Frontend: 0 > > | | | | Name: Unknown (0x0093) - 0 > > | | | | Antennas: > > | | | | Sensors: > > | | | | Freq range: 0.000 to 0.000 MHz > > | | | | Gain Elements: None > > | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz > > | | | | Connection Type: IQ > > | | | | Uses LO offset: No > > | | | _____________________________________________________ > > | | | / > > | | | | RX Codec: B > > | | | | Name: ads62p48 > > | | | | Gain range digital: 0.0 to 6.0 step 0.5 dB > > | | _____________________________________________________ > > | | / > > | | | TX DSP: 0 > > | | | Freq range: -100.000 to 100.000 MHz > > | | _____________________________________________________ > > | | / > > | | | TX DSP: 1 > > | | | Freq range: -100.000 to 100.000 MHz > > | | _____________________________________________________ > > | | / > > | | | TX Dboard: A > > | | | ID: Unknown (0x0092) > > | | | Serial: 30F29BC > > | | | _____________________________________________________ > > | | | / > > | | | | TX Frontend: 0 > > | | | | Name: Unknown (0x0092) - 0 > > | | | | Antennas: > > | | | | Sensors: > > | | | | Freq range: 0.000 to 0.000 MHz > > | | | | Gain Elements: None > > | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz > > | | | | Connection Type: IQ > > | | | | Uses LO offset: No > > | | | _____________________________________________________ > > | | | / > > | | | | TX Codec: A > > | | | | Name: ad9146 > > | | | | Gain Elements: None > > | | _____________________________________________________ > > | | / > > | | | TX Dboard: B > > | | | ID: Unknown (0x0092) > > | | | Serial: 30F2B48 > > | | | _____________________________________________________ > > | | | / > > | | | | TX Frontend: 0 > > | | | | Name: Unknown (0x0092) - 0 > > | | | | Antennas: > > | | | | Sensors: > > | | | | Freq range: 0.000 to 0.000 MHz > > | | | | Gain Elements: None > > | | | | Bandwidth range: 0.0 to 0.0 step 0.0 Hz > > | | | | Connection Type: IQ > > | | | | Uses LO offset: No > > | | | _____________________________________________________ > > | | | / > > | | | | TX Codec: B > > | | | | Name: ad9146 > > | | | | Gain Elements: None > > > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170818/5e0f62d2/attachment-0001.html> ------------------------------ Subject: Digest Footer _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ------------------------------ End of USRP-users Digest, Vol 84, Issue 19 ****************************************** ------------------------------ Message: 5 Date: Mon, 21 Aug 2017 15:42:32 +0200 From: Dominik Eyerly <d.eyerly@konrad-technologies.de> To: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com> Subject: [USRP-users] ADC Overflow - B205i Message-ID: <9cc4cc83-1b56-6563-76fd-f886303dbf6a@konrad-technologies.de> Content-Type: text/plain; charset="utf-8" Hello, Is it possible to obtain a status of the ADC on the B205i using the UHD driver? In particular, I am interested in detecting adc overflows, i.e. too much power at the input. Best regards, Dominik -- -- i.A. Dominik Eyerly Head of RF Software Tel: +49 (0) 351 7958019 233 Fax: +49 (0) 351 7958019 232 Email: d.eyerly@konrad-technologies.de <mailto:d.eyerly@konrad-technologies.de> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell* www.konrad-technologies.de <http://www.konrad-technologies.de> www.abexstandard.org <http://www.abexstandard.org> *Support Telefon: +49 (0) 7732 9815 100* support@konrad-technologies.de <mailto:support@konrad-technologies.de> sig Gesch?ftsleitung: Michael Konrad Handelsregisternr: HRB 550593 in Freiburg Ust-Id-Nr. DE 206693267 VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender bitte umgehend. Danke CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it, contains information from Konrad GmbH, which is intended only for the use of the individual or entity to which it is addressed, and which may contain information that is privileged, confidential, and/or otherwise exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, any disclosure, dissemination, distribution, copying or other use of this communication or its substance is prohibited. If you have received this communication in error, please contact us immediately. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170821/c52c1a05/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 43982 bytes Desc: not available URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170821/c52c1a05/attachment-0001.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170821/c52c1a05/attachment-0001.asc> ------------------------------ Message: 6 Date: Mon, 21 Aug 2017 17:08:48 +0200 From: Marcus M?ller <marcus.mueller@ettus.com> To: Dominik Eyerly <d.eyerly@konrad-technologies.de>, Dominik Eyerly via USRP-users <usrp-users@lists.ettus.com>, "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com> Subject: Re: [USRP-users] ADC Overflow - B205i Message-ID: <0E1F6D9A-086B-4D6F-89A3-4DDF8D8B2FAC@ettus.com> Content-Type: text/plain; charset="utf-8" Dear Mr. Eyerly, Indeed, the AD9361 has an overload indicator register. (Ad9361 manual ug-570, page 76) We don't directly expose that, but with modifications in our host/lib/usrp tree's ad9361_driver, you could expose that by publishing a register reader in the property_tree. Does that sound like the direction you'd like to take this? Best regards, Marcus M On 21 August 2017 3:42:32 PM GMT+02:00, Dominik Eyerly via USRP-users <usrp-users@lists.ettus.com> wrote: >Hello, > >Is it possible to obtain a status of the ADC on the B205i using the UHD >driver? In particular, I am interested in detecting adc overflows, i.e. >too much power at the input. > >Best regards, >Dominik > >-- > > > >-- > >i.A. Dominik Eyerly >Head of RF Software > >Tel: +49 (0) 351 7958019 233 >Fax: +49 (0) 351 7958019 232 >Email: d.eyerly@konrad-technologies.de ><mailto:d.eyerly@konrad-technologies.de> > >*Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell* >www.konrad-technologies.de <http://www.konrad-technologies.de> >www.abexstandard.org <http://www.abexstandard.org> > >*Support Telefon: +49 (0) 7732 9815 100* >support@konrad-technologies.de <mailto:support@konrad-technologies.de> >sig >Gesch?ftsleitung: Michael Konrad >Handelsregisternr: HRB 550593 in Freiburg >Ust-Id-Nr. DE 206693267 > >VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden >Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die >adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von >Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an >nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen >Sie haftbar gemacht werden. Falls Sie nicht der Empf?nger sind, >benachrichtigen Sie den Absender bitte umgehend. Danke > >CONFIDENTIALITY NOTICE: This e-mail and any documents which may >accompany it, contains information from Konrad GmbH, which is intended >only for the use of the individual or entity to which it is addressed, >and which may contain information that is privileged, confidential, >and/or otherwise exempt from disclosure under applicable law. If the >reader of this message is not the intended recipient, any disclosure, >dissemination, distribution, copying or other use of this communication >or its substance is prohibited. If you have received this communication >in error, please contact us immediately. Thank you. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170821/89bb4031/attachment-0001.html> ------------------------------ Message: 7 Date: Mon, 21 Aug 2017 17:31:11 +0200 From: Dominik Eyerly <d.eyerly@konrad-technologies.de> To: Marcus M?ller <marcus.mueller@ettus.com>, Dominik Eyerly via USRP-users <usrp-users@lists.ettus.com> Subject: Re: [USRP-users] ADC Overflow - B205i Message-ID: <8092ae0d-fd64-6ecb-ea0c-890c56435e55@konrad-technologies.de> Content-Type: text/plain; charset="utf-8" Hi Marcus, Yes, I saw that in the AD datasheet :) The answer you provided does sound promising. Would you be able to provide some more detail on how this is accomplished? A simple example would be great. If an example is too much work, an explanation of where the modification takes place and how it would boil up to the user would be very useful as well. Also, is there another efficient solution or would this be the one you recommend? thanks, Dominik On 08/21/2017 05:08 PM, Marcus M?ller wrote: > Dear Mr. Eyerly, > > Indeed, the AD9361 has an overload indicator register. (Ad9361 manual > ug-570, page 76) > > We don't directly expose that, but with modifications in our > host/lib/usrp tree's ad9361_driver, you could expose that by > publishing a register reader in the property_tree. > > Does that sound like the direction you'd like to take this? > > Best regards, > Marcus M > > On 21 August 2017 3:42:32 PM GMT+02:00, Dominik Eyerly via USRP-users > <usrp-users@lists.ettus.com> wrote: > > Hello, > > Is it possible to obtain a status of the ADC on the B205i using > the UHD driver? In particular, I am interested in detecting adc > overflows, i.e. too much power at the input. > > Best regards, > Dominik > > -- > > > > -- > > i.A. Dominik Eyerly > Head of RF Software > > Tel: +49 (0) 351 7958019 233 > Fax: +49 (0) 351 7958019 232 > Email: d.eyerly@konrad-technologies.de > <mailto:d.eyerly@konrad-technologies.de> > > *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell* > www.konrad-technologies.de <http://www.konrad-technologies.de> > www.abexstandard.org <http://www.abexstandard.org> > > *Support Telefon: +49 (0) 7732 9815 100* > support@konrad-technologies.de <mailto:support@konrad-technologies.de> > sig > Gesch?ftsleitung: Michael Konrad > Handelsregisternr: HRB 550593 in Freiburg > Ust-Id-Nr. DE 206693267 > > VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender bitte umgehend. Danke > > CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it, contains information from Konrad GmbH, which is intended only for the use of the individual or entity to which it is addressed, and which may contain information that is privileged, confidential, and/or otherwise exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, any disclosure, dissemination, distribution, copying or other use of this communication or its substance is prohibited. If you have received this communication in error, please contact us immediately. Thank you. > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -- -- i.A. Dominik Eyerly Head of RF Software Tel: +49 (0) 351 7958019 233 Fax: +49 (0) 351 7958019 232 Email: d.eyerly@konrad-technologies.de <mailto:d.eyerly@konrad-technologies.de> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315 Radolfzell* www.konrad-technologies.de <http://www.konrad-technologies.de> www.abexstandard.org <http://www.abexstandard.org> *Support Telefon: +49 (0) 7732 9815 100* support@konrad-technologies.de <mailto:support@konrad-technologies.de> sig Gesch?ftsleitung: Michael Konrad Handelsregisternr: HRB 550593 in Freiburg Ust-Id-Nr. DE 206693267 VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender bitte umgehend. Danke CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it, contains information from Konrad GmbH, which is intended only for the use of the individual or entity to which it is addressed, and which may contain information that is privileged, confidential, and/or otherwise exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, any disclosure, dissemination, distribution, copying or other use of this communication or its substance is prohibited. If you have received this communication in error, please contact us immediately. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170821/71c55624/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 43982 bytes Desc: not available URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170821/71c55624/attachment-0001.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170821/71c55624/attachment-0001.asc> ------------------------------ Subject: Digest Footer _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ------------------------------ End of USRP-users Digest, Vol 84, Issue 21 ******************************************