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-requ...@lists.ettus.com" <usrp-users-boun...@lists.ettus.com on
behalf of usrp-users-requ...@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-requ...@lists.ettus.com
You can reach the person managing the list at
usrp-users-ow...@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 <youngs...@gmail.com>
To: usrp-users <usrp-users@lists.ettus.com>
Subject: [USRP-users] Synchronised RX and TX control in X310
Message-ID:
<can+qiupntgdfa9q0jbojs3lpq3_h1fbrgsualz3fdkqtzj8...@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.mas...@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=pn...@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.cue...@ettus.com>
To: Snehasish Kar <snehasish....@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=gozt67rtu1ag...@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.koe...@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-67fb3df45...@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-requ...@lists.ettus.com" <usrp-users-boun...@lists.ettus.com on
behalf of usrp-users-requ...@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-requ...@lists.ettus.com
You can reach the person managing the list at
usrp-users-ow...@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 <ja...@gardettoengineering.com>
To: "Torres Figueroa, Luis Angel"
<luis.torres.figue...@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-334982532...@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 <ja...@gardettoengineering.com>
> *Datum: *Mittwoch, 16. August 2017 um 17:09
> *An: *"Torres Figueroa, Luis Angel"
> <luis.torres.figue...@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" <mle...@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.2050...@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.muel...@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-eb14ad847...@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.eye...@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-f886303db...@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.eye...@konrad-technologies.de
<mailto:d.eye...@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*
supp...@konrad-technologies.de <mailto:supp...@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.muel...@ettus.com>
To: Dominik Eyerly <d.eye...@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-4ddf8d8b2...@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.eye...@konrad-technologies.de
><mailto:d.eye...@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*
>supp...@konrad-technologies.de <mailto:supp...@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.eye...@konrad-technologies.de>
To: Marcus M?ller <marcus.muel...@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-890c56435...@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.eye...@konrad-technologies.de
> <mailto:d.eye...@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*
> supp...@konrad-technologies.de <mailto:supp...@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.eye...@konrad-technologies.de
<mailto:d.eye...@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*
supp...@konrad-technologies.de <mailto:supp...@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
******************************************
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
