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. E310 micro SD card ([email protected])
2. Re: E310 micro SD card (Philip Balister)
3. RFNoC on the E310 (devin kelly)
4. Re: Custom UHD Program terminate during set_clock_ref
(Martin Braun)
5. Unbricking USRP N210 (Filippo Camuglia)
6. multibts osmobts using B210 (robert)
7. Re: Unbricking USRP N210 (James Humphries)
8. Re: AddSub example port not connected error (Martin Braun)
----------------------------------------------------------------------
Message: 1
Date: Fri, 10 Jun 2016 17:04:22 +0000 (UTC)
From: [email protected]
To: usrp-users <[email protected]>
Subject: [USRP-users] E310 micro SD card
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
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?
Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160610/d2b50daa/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 10 Jun 2016 13:07:30 -0400
From: Philip Balister <[email protected]>
To: [email protected], usrp-users <[email protected]>
Subject: Re: [USRP-users] E310 micro SD card
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 06/10/2016 01:04 PM, tilla--- via USRP-users wrote:
> 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.
Philip
>
> Thanks,
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 3
Date: Fri, 10 Jun 2016 14:44:33 -0400
From: devin kelly <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] RFNoC on the E310
Message-ID:
<CAANLyuaHQysz=f9hDX7r7=-egqgmgwa1uksfau49cs69oz7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I'd like to use RFNoC on the E310 with the Release 4 image, a somewhat new
version of GNU Radio and the UHD.
As I understand it there are a few things I need to get right.
The FPGA bit image file (have the same version as the installed UHD, must
have RFNoC enabled)
The UHD library install (consistent version and RFNoC enabled)
GNU Radio (compiled against the same version of the UHD and with some E310
flags?)
The UHD and GNU Radio installs on the release 4 image are UHD_003.009.002
and 3.7.9 respectively. Neither of them are enabled for use with RFNoC as
far as I can tell.
So does this mean that to get UHD+GR working on the release 4 image I would
have to cross-compile UHD and GR and then install them over the existing
UHD+GR installs on the E310? Is there an easier way or should I just use
the fido-rfnoc-test image? Is there a more up to date RFNoC image coming
out anytime in the next week or two?
Devin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160610/eca4304f/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 10 Jun 2016 11:55:00 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Custom UHD Program terminate during
set_clock_ref
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
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
>
------------------------------
Message: 5
Date: Fri, 10 Jun 2016 15:00:43 +0200
From: Filippo Camuglia <[email protected]>
To: [email protected]
Subject: [USRP-users] Unbricking USRP N210
Message-ID:
<CAMO_YXeT42Q=j55vruherfsvjaoo5s792fp-b3+axry+jr_...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I have an USRP N210.
I burned a wrong fw and FPGA and reading this thread
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-February/000686.html
I think you can explain me the procedure for unbricking it.
Thanks in advance,
Filippo
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160610/cd6f1d81/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 10 Jun 2016 16:47:58 +0300
From: robert <[email protected]>
To: [email protected]
Subject: [USRP-users] multibts osmobts using B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi,
has anyone tried following the tutorial
http://umtrx.org/multi-bts-with-osmocom-and-a-single-umtrx/ using a USRP b210 ?
I keep getting a warning that an "internal receive buffer has filled?. Any
suggestions ?
Best regards,
Robert,
------------------------------
Message: 7
Date: Fri, 10 Jun 2016 15:43:47 -0400
From: James Humphries <[email protected]>
To: Filippo Camuglia <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Unbricking USRP N210
Message-ID:
<CAEwGFhVds=wjw0nug7vdq8pkhefrd2adl9v_gmho7t-jvv8...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Filippo,
Here is a guide from our App Notes that covers this scenario:
https://kb.ettus.com/N200/N210_Device_Recovery
You can boot into a safe mode and then burn the correct images.
-Trip
On Fri, Jun 10, 2016 at 9:00 AM, Filippo Camuglia via USRP-users <
[email protected]> wrote:
> Hi,
>
> I have an USRP N210.
>
> I burned a wrong fw and FPGA and reading this thread
>
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2011-February/000686.html
>
> I think you can explain me the procedure for unbricking it.
>
> Thanks in advance,
>
> Filippo
>
> _______________________________________________
> 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/20160610/d8fe03be/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 10 Jun 2016 14:11:47 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] AddSub example port not connected error
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Is this on rfnoc-devel, or rfnoc-radio-redo?
M
On 06/07/2016 07:18 AM, Kieran Lea wrote:
> Hi,
>
>
> Both input ports are the same as the example too, so they're both coming
> from GNU Radio blocks. I have tried other configurations too for input
> blocks and none of them have solved the error yet.
>
> ------------------------------------------------------------------------
> *From:* USRP-users <[email protected]> on behalf of
> Martin Braun via USRP-users <[email protected]>
> *Sent:* Monday, June 6, 2016 7:00:27 PM
> *To:* [email protected]
> *Subject:* Re: [USRP-users] AddSub example port not connected error
>
> Is port 0 connected to an RFNoC block, but 1 to a GNU Radio block?
>
> -- Martin
>
> On 06/06/2016 06:44 AM, Kieran Lea via USRP-users wrote:
>> Hi,
>>
>>
>> I tried using the addsub example here:
>> https://github.com/EttusResearch/gr-ettus/tree/master/examples/rfnoc
>>
>>
>> and I get an error:
>>
>>
>> thread[thread-per-block[3]: <block uhd_rfnoc_AddSub (1)>]: RuntimeError:
>> On node 0/AddSub_0, input port 0 is already connected.
>>
>>
>> I saw another person on the list ask this question earlier and you guys
>> had said it was GNURadio getting confused with an output to a regular
>> block and an RFNoC block, but I'm wondering if that's the case, because
>> it seems both ports are connected to a regular block? I also tried a few
>> other configurations and they resulted in the same error. I'm on the
>> devel branch with an X310, any idea how to get it working?
>>
>>
>> Thanks
>>
>>
>>
>> _______________________________________________
>> 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
------------------------------
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 11
******************************************
