Send USRP-users mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: UBX Tx-to-Rx interference, Performance and Power-Save
modes (hanwen)
2. Having a problem with ABI to UHD compatibility (Arthur Brodsky)
3. Re: Custom UHD Program terminate during set_clock_ref
(Patrick Berger)
4. USRP X310 not compatible with host code
([email protected])
5. Re: Connecting TX/RX and RX2 internally (Sylvain Munaut)
6. Re: USRP X310 not compatible with host code (Marcus M?ller)
7. Re: AddSub example port not connected error (Kieran Lea)
8. Re: Having a problem with ABI to UHD compatibility (Marcus M?ller)
9. Re: E310 micro SD card (Jason Matusiak)
10. Re: Custom Board (Joshua Monson)
11. Re: Connecting TX/RX and RX2 internally (Marcus D. Leech)
----------------------------------------------------------------------
Message: 1
Date: Sun, 12 Jun 2016 21:04:51 +0200
From: hanwen <[email protected]>
To: Michael West <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] UBX Tx-to-Rx interference, Performance and
Power-Save modes
Message-ID:
<CABjUSe268x40Km5=EkaHSKpn32VLUt5zXgQYRP=x5zobihs...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Michael,
Any new progress in improving UBX support in UHD? Thanks.
Br, Hanwen
2016-05-26 12:50 GMT+02:00 hanwen <[email protected]>:
> Hi Michael,
>
> No difference with this patch. The transmitted signal is too weak,
> confirmed by an additional spectrum analyzer as receiver.
> I noticed that in the patch, many "FORCEON" are set to 0 in the
> performance, could it be the reason that the Tx power is so low?
>
> Br, Hanwen
>
> 2016-05-24 22:14 GMT+02:00 Michael West <[email protected]>:
>
>> Hi Hanwen,
>>
>> Thanks for the feedback. Can you remove the previous patches and apply
>> the new one attached? It is slightly different than the previous one. I
>> tested and had no issues with it.
>>
>> Regards,
>> Michael
>>
>> On Tue, May 24, 2016 at 12:48 PM, hanwen <[email protected]> wrote:
>>
>>> HI Michael,
>>>
>>> I tested your new patch today. At the Rx side, yes, the noise floor low
>>> and doesn't affected by Tx. BUT, the Tx power is also low and it looks like
>>> the same as with the powersave mode in my TDMA/TDD system configuration.
>>> Thanks.
>>>
>>> Br, Hanwen
>>>
>>> 2016-05-24 0:43 GMT+02:00 Michael West <[email protected]>:
>>>
>>>> Hi Hanwen,
>>>>
>>>> We see the same results. Further investigation into the issue has
>>>> yielded the attached updated patch. We are still working on the issue, but
>>>> please try the patch and let me know if it improves the noise figure for
>>>> you. It should work well in performance or powersave mode.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>> On Mon, May 23, 2016 at 1:35 PM, hanwen <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Michael,
>>>>>
>>>>> Thanks for the patch. I tried today and it fixed the issue that the Rx
>>>>> noise floor raises along with the increasing Tx gain.
>>>>> But it seems in the default performance mode, the noise floor is
>>>>> higher than in the powersave mode and the actual noise figure is also
>>>>> poorer. I'll do some further test tomorrow and try to tweak the CPLD field
>>>>> options in db_ubx.cpp.
>>>>>
>>>>> Br, Hanwen
>>>>>
>>>>> 2016-05-19 19:47 GMT+02:00 Michael West <[email protected]>:
>>>>>
>>>>>> Hi Hanwen,
>>>>>>
>>>>>> There is an issue for UBX in TDD mode of which we are aware and in
>>>>>> the process of fixing. In the meantime, apply the attached patch and use
>>>>>> the default (performance) power mode and let me know if it helps.
>>>>>>
>>>>>> Regards,
>>>>>> Michael
>>>>>>
>>>>>> On Wed, May 18, 2016 at 9:03 PM, hanwen <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> Dear USRP users and experts,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Instructed by Michael in:
>>>>>>> https://www.mail-archive.com/[email protected]/msg01766.html
>>>>>>>
>>>>>>> I tried the switching between powersave and performance mode for the
>>>>>>> new UBX and did some further test.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Basic config: 11.42MS/s, Carrier: 2.6GHz, TDMA mode with 1ms time
>>>>>>> slot and one device switches between Tx and Rx every 1ms; UHD and
>>>>>>> firmware
>>>>>>> are the fresh 3.9.4 release.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *Power Save*
>>>>>>>
>>>>>>> *Performance*
>>>>>>>
>>>>>>> *Tx*
>>>>>>>
>>>>>>> The transmitted signal is very weak no matter what Tx gain is chosen
>>>>>>>
>>>>>>> The transmission is fine, but the maximum Tx power is 2~3dB lower
>>>>>>> than SBX
>>>>>>>
>>>>>>> The device is getting very hot
>>>>>>>
>>>>>>> *Rx*
>>>>>>>
>>>>>>> The noise floor not affected by Tx
>>>>>>>
>>>>>>> Noise floor rising up by c.a. 7dB by setting to higher Tx gain
>>>>>>> (>21.5), EVEN WHEN no transmission in Tx slot
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> In the attachment you could see some screenshots:
>>>>>>>
>>>>>>> ? Tg_1.5~31.5.png: showing the rising Rx noise floor in the
>>>>>>> default Performance mode
>>>>>>>
>>>>>>> ? Cst_performance/powersave.png: showing in the Powersave
>>>>>>> mode: the constellation demodulated at another device is very poor due
>>>>>>> to
>>>>>>> weak transmit power.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> For both powersave and performance mode we observed unacceptable
>>>>>>> problems for our system, but using the older SBX-40 and SBX 120 boards
>>>>>>> we
>>>>>>> didn?t observe these problems.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Bests, Hanwen
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [image: ???? 7][image: ???? 8][image: ???? 9][image: ???? 10][image:
>>>>>>> ???? 11][image: ???? 12]
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160612/f3ce0f0f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg_21.5.png
Type: image/png
Size: 25015 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160612/f3ce0f0f/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg_31.5.png
Type: image/png
Size: 25055 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160612/f3ce0f0f/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cst_performance.png
Type: image/png
Size: 21136 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160612/f3ce0f0f/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg_11.5.png
Type: image/png
Size: 24955 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160612/f3ce0f0f/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cst_powersave.png
Type: image/png
Size: 31677 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160612/f3ce0f0f/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg_1.5.png
Type: image/png
Size: 24942 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160612/f3ce0f0f/attachment-0011.png>
------------------------------
Message: 2
Date: Sun, 12 Jun 2016 11:21:48 +0000
From: Arthur Brodsky <[email protected]>
To: "[email protected]" <[email protected]>
Cc: Eli Sabag <[email protected]>, "Eran EC. Castiel"
<[email protected]>
Subject: [USRP-users] Having a problem with ABI to UHD compatibility
Message-ID:
<db4pr06mb0960198e3d09930ded99a21da...@db4pr06mb096.eurprd06.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I'm a fresh user of gnuradio system - less then a week [?]
I have installed uhd and gnuradio packages using pyBOMBS, "build
gnuradio-script" didn't work for me. Now I'm trying to run gnuradio built in
examples.
When I'm trying to run the flow-graph I receive an error :
"
RuntimeError:
GR-UHD detected ABI compatibility mismatch with UHD library.
GR-UHD was build against ABI: 3.9.0-0,
but UHD library reports ABI: 3.10.0-0
Suggestion: install an ABI compatible version of UHD,
or rebuild GR-UHD component against this ABI version.
"
Here are my system parameters
OS - Linux Ubunutu 14.04 LTS
Installed uhd and gnuradio versions:
ii libgnuradio-uhd3.7.2.1:i386 3.7.2.1-5ubuntu0.1
i386 gnuradio universal hardware driver
functions
ii libuhd-dev
3.9.4-0ubuntu1~trusty1 i386 universal
hardware driver for Ettus Research products
ii libuhd003:i386
3.9.4-0ubuntu1~trusty1 i386 hardware
driver for Ettus Research products
ii uhd-host
3.9.4-0ubuntu1~trusty1 i386 hardware
driver for Ettus Research products
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-0-b1c2d4bb
UHD device info (using command uhd_find_devices)
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
type: x300
addr: 192.168.10.2
fpga: HGS
name:
serial: 307A5C8
product: X310
As I noticed, after browsing through support-mailing, I am not the only one who
recieved this error, but I couldn't find detailed explanation about solving
that issue.
Any support regarding my next steps will be kindly appreciated.
Best Regards,
Arthur Brodsky
[1455488933843_unnamed.jpg]
[1455490060484_unnamed.png]
Cell: 972-54-7651126
www.sk-advanced.com<http://www.sk-advanced.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160612/65ab0e5d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OutlookEmoji-1455488933843_unnamed.jpg.jpg
Type: image/jpeg
Size: 4229 bytes
Desc: OutlookEmoji-1455488933843_unnamed.jpg.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160612/65ab0e5d/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OutlookEmoji-1455490060484_unnamed.png.png
Type: image/png
Size: 26343 bytes
Desc: OutlookEmoji-1455490060484_unnamed.png.png
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160612/65ab0e5d/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OutlookEmoji-?.png
Type: image/png
Size: 390 bytes
Desc: OutlookEmoji-?.png
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160612/65ab0e5d/attachment-0003.png>
------------------------------
Message: 3
Date: Mon, 13 Jun 2016 09:36:01 +0200
From: Patrick Berger <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Custom UHD Program terminate during
set_clock_ref
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Marcus
I've managed it with a clean linux installation. I think there was something
wrong with the uhd installation (building from source with boost). Some time
ago I had also the rfnoc installed (with pybombs).
Now I'm able to communicate with the USRP X310 Device (setting up the
registers).
But I've an additional question: How is the data transport format? On the
fpga-image I've added a custom block before rx_framer with following data
configuration:
assign rx_data[30:0] = psd_flaot;
assign rx_data[31] = framestart;
on the host I get the data with (Frame_length = 1024):
std::vector< u_int32_t > buff(2*FRAME_LENGTH);
rx_stream->issue_stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
size_t num_rx_samps = rx_stream->recv(&buff.front(), buff.size(), md);
if (num_rx_samps != buff.size())
{
continue;
}
So I'm expecting the flag-bit only at the 1024th sample (simple 32 Bit data
transmitted). But if I check the buff variable for the number of framestarts
(bit 31) I get various numbers from 1 to 26 till 1 or 2. Same if the buffer is
complex short (wireformat is sc16 in the initialisation) and I create a new 32
bit variable with the real and imaginary part.
If I initialize the wireformat like this
uhd::stream_args_t stream_args("sc16");
rx_stream = usrp->get_rx_stream(stream_args);
aren't the buffer date in the I[15:0]Q[15:0]I[15:0]Q[15:0]I[15:0]Q[15:0] format
(I've read this in an other post)? So if I say the buffer is from type uint32 I
expect the same data I propagate to the rx_framer on the usrp.
Best regards
Patrick
> To: [email protected]
> Date: Fri, 10 Jun 2016 11:55:00 -0700
> Subject: Re: [USRP-users] Custom UHD Program terminate during set_clock_ref
> From: [email protected]
>
> That depends, where did you install your UHDs and how?
>
> M
>
> On 06/09/2016 11:25 PM, Patrick Berger via USRP-users wrote:
> > Hi Martin
> >
> > No, there is actualy only one thread (the main app). All other stuff is
> > removed.
> >
> > Mhm, it could be that there is also the rfnoc version from uhd parallel
> > to version 3.9.1 on the system. Is there a proper way to remove all uhd
> > stuff for a clean reinstall, without to setup a clean linux?
> >
> > Best regards
> > Patrick
> >
> >> To: [email protected]
> >> Date: Thu, 9 Jun 2016 09:10:24 -0700
> >> Subject: Re: [USRP-users] Custom UHD Program terminate during
> > set_clock_ref
> >> From: [email protected]
> >>
> >> My first guess is ABI mismatch. You're segfaulting when you mean to call
> >> usrp->set_clock_source(ref);, but your segfault happens in
> >> get_fe_rx_freq_range(). After that, all bets are off. I recommend
> >> checking the version you linked against is the version you're running.
> >>
> >> Also, do you have multiple threads in this app?
> >>
> >> M
> >>
> >>
> >> On 06/09/2016 06:58 AM, Patrick Berger via USRP-users wrote:
> >> > Hi
> >> >
> >> > I've managed to set breakpoints inside the function:
> >> >
> >> >
> >> > With a breakpoint on usrp->get_rx_freq() I could inspect the usrp
> > pointer.
> >> > usrp @0x10148b0
> >> > uhd::usrp::multi_usrp::sptr
> >> > data @0x1015280
> >> > boost::shared_ptr<uhd::usrp::multi_usrp>::element_type
> >> > usecoutnt 1 int
> >> > weadkcount 1 int
> >> >
> >> > Checking the pointer against NULL is successful (so that isn't the
> > problem).
> >> >
> >> > If I try to step over this function call the app crashes, or debuging is
> >> > terminated with following error message. Against my programming
> >> > expierence this indicates a bad pointer or something like this.
> >> > The inferior stopped because it received a signal from the Operating
> > System.
> >> > Signal name: SIGSEGV
> >> > Signal meaning: Segmentation fault
> >> >
> >> > During stepping through the instruction code in the disassembler, I get
> >> > till the function _ZN15multi_usrp_impl14rx_chan_to_mcpEm:
> >> > Function: _ZN15multi_usrp_impl14rx_chan_to_mcpEm
> >> > 0x7f649e20a14c <+0x003c> movl $0x0,0x8(%rsp)
> >> > 0x7f649e20a154 <+0x0044> mov %rax,0x20(%rsp)
> >> > 0x7f649e20a159 <+0x0049> nopl 0x0(%rax)
> >> > 0x7f649e20a160 <+0x0050> mov (%r15),%rax
> >> > On the last line I get the segmentation fault! So I think there is
> >> > something inside the uhd library wrong (accessing protected memory).
> >> >
> >> > The stack view at the crash moment looks like this:
> >> > Level Function
> >> > 0 multi_usrp_impl::rx_chan_to_mcp(unsinged long)
> >> > 1 multi_usrp_impl::rx_rf_fe_roo(unsinged long)
> >> > 2 multi_usrp_impl::get_fe_rx_freq_range(unsigned long)
> >> > 3 USDP_SDR::Init_USRP
> >> > 4 main
> >> >
> >> > So there must be something wrong in the function *rx_chan_to_mcp*
> >> >
> >> > Platform is Linux Mint 17.2, IDE is Qt Creator, linked UHD version is
> >> > 3.9.1 (what I have to use for communicate also with matlab)
> >> >
> >> > Best regards
> >> > Patrick
> >> >
> >> >
> >> >> Date: Wed, 8 Jun 2016 09:28:45 -0700
> >> >> To: [email protected]
> >> >> Subject: Re: [USRP-users] Custom UHD Program terminate during
> >> > set_clock_ref
> >> >> From: [email protected]
> >> >> CC: [email protected]
> >> >>
> >> >> Patrick,
> >> >>
> >> >> Is 'ref' being properly set before it is called in
> >> > usrp->set_clock_source(ref) ? A simple sanity check is to print it out
> >> > before it is called:
> >> >>
> >> >> std::cout << boost::format("Lock mboard clocks: %f") % ref <<
> > std::endl;
> >> >> usrp->set_clock_source(ref);
> >> >>
> >> >>
> >> >> - Nate
> >> >>
> >> >> > On Jun 8, 2016, at 9:05 AM, Martin Braun via USRP-users
> >> > <[email protected]> wrote:
> >> >> >
> >> >> > Patrick,
> >> >> >
> >> >> > I have a hunch something is hiding some error message, and that error
> >> >> > message would clue us in. The last line ("Press Return") is
> > coming from
> >> >> > where exactly? Is it your dev environment? Maybe there's a hidden
> >> >> > segfault there. GRC is a bit like that, too.
> >> >> >
> >> >> > M
> >> >> >
> >> >> > On 06/08/2016 12:17 AM, Patrick Berger via USRP-users wrote:
> >> >> >> Hi all
> >> >> >>
> >> >> >> I'm trying to create my own program to communicate with an X310
> > USRP.
> >> >> >> Host is Linux (Mint 17.2) with uhd version 3.9.1 and boost 1.57.0
> >> >> >>
> >> >> >> During the build process in Qt Creator I've no errors or warnings
> >> >> >> (libraries are all correct linked). The device is correctly
> > found and
> >> >> >> the initialization with uhd::usrp::multi_usrp::make(dev_adr) works
> >> > also.
> >> >> >> In the second step I would set the mboard clocks, but there is
> >> > something
> >> >> >> going bad.
> >> >> >>
> >> >> >> This is my current code (cross-checked with rx_samples_to_file,
> >> >> >> rx_samples_to_udp, rx_ascii_art_dft):
> >> >> >> int USRP_SDR::Init_USRP()
> >> >> >> {
> >> >> >> //create a usrp device
> >> >> >> uhd::device_addr_t dev_adr;
> >> >> >> dev_adr.set("addr", addr);
> >> >> >> usrp = uhd::usrp::multi_usrp::make(dev_adr);
> >> >> >>
> >> >> >> std::cout << "Hallo1" << std::endl;
> >> >> >> //Lock mboard clocks
> >> >> >> usrp->set_clock_source(ref);
> >> >> >> std::cout << "Hallo2" << std::endl;
> >> >> >>
> >> >> >> //always select the subdevice first, the channel mapping affects the
> >> >> >> other settings
> >> >> >> if (vm.count("subdev")) usrp->set_rx_subdev_spec(subdev);
> >> >> >>
> >> >> >> std::cout << boost::format("Using Device: %s") %
> >> >> >> usrp->get_pp_string() << std::endl;
> >> >> >>
> >> >> >> //set the sample rate
> >> >> >> if (rate <= 0.0){
> >> >> >> std::cerr << "Please specify a valid sample rate" << std::endl;
> >> >> >> return 0;
> >> >> >> }
> >> >> >> std::cout << boost::format("Setting RX Rate: %f Msps...") %
> >> >> >> (rate/1e6) << std::endl;
> >> >> >> usrp->set_rx_rate(rate);
> >> >> >> std::cout << boost::format("Actual RX Rate: %f Msps...") %
> >> >> >> (usrp->get_rx_rate()/1e6) << std::endl << std::endl;
> >> >> >>
> >> >> >> return 1;
> >> >> >> }
> >> >> >>
> >> >> >> And this is the resulting terminal output (the Hello2 is
> > missing, and
> >> >> >> also the rest of the initialization process):
> >> >> >> linux; GNU C++ version 4.8.4; Boost_105400;
> > UHD_003.009.001-0-unknown
> >> >> >>
> >> >> >> UHD Warning:
> >> >> >> Unable to set the thread priority. Performance may be negatively
> >> >> >> affected.
> >> >> >> Please see the general application notes in the manual for
> >> > instructions.
> >> >> >> EnvironmentError: OSError: error in pthread_setschedparam
> >> >> >> -- X300 initialization sequence...
> >> >> >> -- Determining maximum frame size... 1472 bytes.
> >> >> >> -- Setup basic communication...
> >> >> >> -- Loading values from EEPROM...
> >> >> >> -- Setup RF frontend clocking...
> >> >> >> -- Radio 1x clock:200
> >> >> >> -- Initialize Radio0 control...
> >> >> >> -- Performing register loopback test... pass
> >> >> >> -- Initialize Radio1 control...
> >> >> >> -- Performing register loopback test... pass
> >> >> >> Hallo1
> >> >> >> Press <RETURN> to close this window...
> >> >> >>
> >> >> >> Does anyone see the fault?
> >> >> >>
> >> >> >> Best regards
> >> >> >> Patrick
> >> >> >>
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> USRP-users mailing list
> >> >> >> [email protected]
> >> >> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >> >> >>
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > USRP-users mailing list
> >> >> > [email protected]
> >> >> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> USRP-users mailing list
> >> >> [email protected]
> >> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >> >
> >> >
> >> > _______________________________________________
> >> > USRP-users mailing list
> >> > [email protected]
> >> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >> >
> >>
> >>
> >> _______________________________________________
> >> USRP-users mailing list
> >> [email protected]
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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/20160613/903d05cf/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 13 Jun 2016 08:13:12 -0400
From: [email protected]
To: "[email protected]" <[email protected]>
Subject: [USRP-users] USRP X310 not compatible with host code
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
HI,
I just assembled the USRP X310 and connect to my host computer. When I run
uhd_find_devices it finds the devices correctly, however, when running
uhd_usrp_probe, it shows "Error: RuntimeError: Expected FPGA compatibility
number 19, but got 13:
The FPGA image on your device is not compatible with this host code build", and
I followed the instruction to download FPGA images and burn to on-board flash
storage.
However, when I run the command again, it still shows the same error. I did
that process twice but didn't work. Is there anything I can do to fix that?
Thank you.
Best regards,
Zinag.
Sent from my iPhone
------------------------------
Message: 5
Date: Mon, 13 Jun 2016 14:39:36 +0200
From: Sylvain Munaut <[email protected]>
To: Michael West <[email protected]>
Cc: NIKOLOV <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Connecting TX/RX and RX2 internally
Message-ID:
<cahl+j0-fyltu4mpjdtglwcs37ersnadapithhgw7pwm2tr2...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
> Good points, Sylvain. Yes, connecting TX directly to RX can damage the LNA.
> A 30 dB attenuator is sufficient to protect it. There is actually only one
> RF switch between the TX and RX paths and it provides ~30 dB of isolation.
Mmm, if you're setup for full duplex, you should have two swiches in the path.
The TX/RX switch will connect the TX side to TX/RX connector, with a
-30 dB leakage going to the RX switch, which should be setup to
connect the RX side to the RX2 and will provide another -30 dB from
the leakage coming from the TX switch.
Cheers,
Sylvain
------------------------------
Message: 6
Date: Mon, 13 Jun 2016 14:40:17 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP X310 not compatible with host code
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Have you tried turning the X300 off and on again? The Firmware and FPGA
image are only being loaded on device startup.
Best regards,
Marcus
On 13.06.2016 14:13, Ziang gao via USRP-users wrote:
> HI,
> I just assembled the USRP X310 and connect to my host computer. When I
> run uhd_find_devices it finds the devices correctly, however, when running
> uhd_usrp_probe, it shows "Error: RuntimeError: Expected FPGA compatibility
> number 19, but got 13:
> The FPGA image on your device is not compatible with this host code build",
> and I followed the instruction to download FPGA images and burn to on-board
> flash storage.
> However, when I run the command again, it still shows the same error. I
> did that process twice but didn't work. Is there anything I can do to fix
> that?
> Thank you.
> Best regards,
> Zinag.
>
> Sent from my iPhone
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 7
Date: Mon, 13 Jun 2016 13:18:00 +0000
From: Kieran Lea <[email protected]>
To: Martin Braun <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] AddSub example port not connected error
Message-ID:
<sn2pr04mb2304ebe6cac4d9d473bccedff3...@sn2pr04mb2304.namprd04.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
I am on rfnoc-devel on an X310
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160613/a9e759e1/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 13 Jun 2016 15:39:50 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Having a problem with ABI to UHD
compatibility
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
If you use the build-gnuradio script you *must not* install gnuradio or
UHD via Ubuntu's apt-get. That's bound to end up two versions of the
same software conflicting, which is exactly what you're seeing here.
So,
sudo apt-get remove libgnuradio\* libuhd\* uhd\*
./build-gnuradio
would be the way to go here.
Best regards,
Marcus
On 12.06.2016 13:21, Arthur Brodsky via USRP-users wrote:
>
> Hi all,
>
> I'm a fresh user of gnuradio system - less then a week ?
>
>
> I have installed uhd and gnuradio packages using pyBOMBS, *"build
> gnuradio-script"* didn't work for me. Now I'm trying to run gnuradio
> built in examples.
>
> When I'm trying to run the flow-graph I receive an error :
>
> "
>
> RuntimeError:
>
> GR-UHD detected ABI compatibility mismatch with UHD library.
> GR-UHD was build against ABI: 3.9.0-0,
> but UHD library reports ABI: 3.10.0-0
> Suggestion: install an ABI compatible version of UHD,
> or rebuild GR-UHD component against this ABI version.
> "
>
> *Here are my system parameters *
>
> OS - Linux Ubunutu 14.04 LTS
>
>
> Installed uhd and gnuradio versions:
>
>
> ii libgnuradio-uhd3.7.2.1:i386
> 3.7.2.1-5ubuntu0.1 i386
> gnuradio universal hardware driver functions
> ii libuhd-dev
> 3.9.4-0ubuntu1~trusty1 i386
> universal hardware driver for Ettus Research products
> ii libuhd003:i386
> 3.9.4-0ubuntu1~trusty1 i386
> hardware driver for Ettus Research products
> ii uhd-host
> 3.9.4-0ubuntu1~trusty1 i386
> hardware driver for Ettus Research products
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-0-b1c2d4bb
>
> *UHD device info (using command uhd_find_devices)*
> --------------------------------------------------
> -- UHD Device 0
> --------------------------------------------------
> Device Address:
> type: x300
> addr: 192.168.10.2
> fpga: HGS
> name:
> serial: 307A5C8
> product: X310
>
>
>
> As I noticed, after browsing through support-mailing, I am not the
> only one who recieved this error, but I couldn't find detailed
> explanation about solving that issue.
>
> Any support regarding my next steps will be kindly appreciated.
>
>
> Best Regards,
>
> Arthur Brodsky
>
>
> 1455488933843_unnamed.jpg
>
>
> 1455490060484_unnamed.png
>
>
> Cell: 972-54-7651126
>
> www.sk-advanced.com <http://www.sk-advanced.com>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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/20160613/40610599/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 390 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160613/40610599/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 4229 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160613/40610599/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 26343 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160613/40610599/attachment-0003.png>
------------------------------
Message: 9
Date: Mon, 13 Jun 2016 10:18:22 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 micro SD card
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>/I see for newer images, an 8 GB card is required. />>//>>/Is there a
>>limitation to the size that is accepted? />>//>>/If I get a 16 or 32 GB card,
>>will they function properly within the
E310? > /Yes. The image only will use the first 8GB, but people have built their
>own images that use all the larger cards.
/I am using 128GB cards with success. After loading the image over to it,
I use gparted to extend the partition to take advantage of the 120GB
that is unused./
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160613/8f542ccd/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 13 Jun 2016 11:12:43 -0400
From: "Joshua Monson" <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] Custom Board
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
From: Joshua Monson [mailto:[email protected]]
Sent: Thursday, June 9, 2016 3:17 PM
To: 'Matt Ettus' <[email protected]>
Subject: RE: [USRP-users] Custom Board
Matt,
I agree whole-heartedly with you and that is what I attempted to do initially.
Unfortunately, I ran into a roadblock in which Vivado would not export the PS
configuration and address mappings to the SDK unless the Zynq processing system
was declared in a top-level IP integrator design. How did you guys get around
this Vivado restriction? It seems to me that even though you?re using Linux you
would still need that Vivado to generate the device tree source and PS
configuration files.
Thanks,
Josh
From: Matt Ettus [mailto:[email protected]]
Sent: Thursday, June 9, 2016 2:39 PM
To: Joshua Monson <[email protected] <mailto:[email protected]> >
Cc: [email protected] <mailto:[email protected]>
Subject: Re: [USRP-users] Custom Board
Joshua,
While you are welcome to try this, you have chosen an extremely difficult path.
There is a lot of complexity in a board like this. You would be far better
off if you started with our top level design an removed the parts you don't
want, rather than try to recreate everything in a vacuum. Otherwise, you'll
need to look at the schematics to make sure every pin is driven properly.
Matt
On Thu, Jun 9, 2016 at 8:43 AM, Joshua Monson via USRP-users
<[email protected] <mailto:[email protected]> > wrote:
Hi,
We?re developing a custom bare-metal FPGA design for the USRP E310. The plan is
to have the FPGA configured with this design via an SDCard image when the board
powers up. To begin our development we?d like to start with minimal FPGA design
that can bring the board up safely without damaging the other components. To
this end I?ve created an initial design in Xilinx Vivado by importing the PS
configurations (presets) from the E3XX_idle design in UHD. On the FPGA side
(PL), I?ve imported and integrated the AXI PMU and constant logic values
connected to external I/O (also from E3XX_idle). I?ve also imported the
constraint files from E3XX_idle to ensure the I/O voltage levels are configured
properly.
Is there anything else that I need to do to ensure that the board and FPGA
powers on properly?
Thanks,
Josh
_______________________________________________
USRP-users mailing list
[email protected] <mailto:[email protected]>
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/20160613/22ab30f9/attachment-0001.html>
------------------------------
Message: 11
Date: Mon, 13 Jun 2016 11:27:33 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Connecting TX/RX and RX2 internally
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 06/13/2016 08:39 AM, Sylvain Munaut via USRP-users wrote:
> Hi,
>
>> Good points, Sylvain. Yes, connecting TX directly to RX can damage the LNA.
>> A 30 dB attenuator is sufficient to protect it. There is actually only one
>> RF switch between the TX and RX paths and it provides ~30 dB of isolation.
> Mmm, if you're setup for full duplex, you should have two swiches in the path.
>
> The TX/RX switch will connect the TX side to TX/RX connector, with a
> -30 dB leakage going to the RX switch, which should be setup to
> connect the RX side to the RX2 and will provide another -30 dB from
> the leakage coming from the TX switch.
>
>
> Cheers,
>
> Sylvain
>
>
Yes, except that it's fairly hard to get two microstrip traces inside
the same enclosure to be isolated by more than 40dB or so unless they're
isolated inside their own sub-enclosure, so simply adding the isolation
of the two switches seems right, but isn't.
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 70, Issue 13
******************************************
