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: USRP-users Digest, Vol 75, Issue 26 (Mark Napier)
2. Re: 802.11 Timings : What are the challenges with SDR
implementation ? (Ron Economos)
3. Re: Setting up RFNOC development environment & running
gr-ettus/rfnoc examples (Jonathon Pendlum)
4. Regarding understanding non linearity in N210 (Steve Gough)
5. Re: Regarding understanding non linearity in N210
(Marcus D. Leech)
6. Re: 802.11 Timings : What are the challenges with SDR
implementation ? (Tom Tsou)
7. Re: libuhd issue on OpenBTS (Michael West)
8. Re: B210 C-API dual channel (Martin Braun)
9. Re: B205mini-i overfow error (Martin Braun)
10. Re: B210 C-API dual channel (Michael West)
11. Re: B205mini-i overfow error (Vladica Sark)
12. CUSTOM FIFO (liu Jong)
13. change the master clock rate on X310 (Paolo Palana)
14. Re: libuhd issue on OpenBTS (ty)
----------------------------------------------------------------------
Message: 1
Date: Tue, 29 Nov 2016 12:22:36 -0500
From: Mark Napier <napierdm...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP-users Digest, Vol 75, Issue 26
Message-ID:
<CAFS2mBdcnNL6h+K5jqVQ2F27EeOm3ODB=bfjcpsk2zu+gam...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello carry,
We have just finished implementing an OFDM transceiver in a B205mini for a
customer.
Getting the custom register read/writes working and the data pipe debugged
is a challenge.
You are correct, the C code methods needed to access the the custom
registers is in the N210 code. You have to modify the UHD to add them into
B200 code.
You also need to have a simulation test-bench environment for the
radio_b200 (or radio_legacy) to verify the custom RTL is working in the
system. BTW, Icarus Verilog is a perfectly capable simulator. I kept
expecting to run into a limitation but no, it has worked perfectly.
Best regards,
Mark Napier
> ------------------------------
>
> Message: 15
> Date: Tue, 29 Nov 2016 16:43:19 +0000
> From: carry chen <artestp...@outlook.com>
> To: usrp-users <usrp-users@lists.ettus.com>
> Subject: [USRP-users] b205mini fpga modify
> Message-ID:
> <SG2PR06MB08056F212C131F94347FABF4DD8D0@SG2PR06MB0805.
> apcprd06.prod.outlook.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> I need to make Some modify in b205mini fpga (before duc do some dsp, for
> example ofdm mod),but i can not find some custom_dsp* in b205mini fpga
> codes(they lay in usrp n210 fpga code). can any body give some tips?
>
> thank you very much!
>
> carry
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161129/cd9402d8/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 29 Nov 2016 09:50:31 -0800
From: Ron Economos <w...@comcast.net>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] 802.11 Timings : What are the challenges
with SDR implementation ?
Message-ID: <9b0e17f4-74c4-be2b-ad78-6f74b49d9...@comcast.net>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
I've been doing some experiments with IP over DVB, and have measured
some round trip delays by just using the Linux ping utility. I haven't
fully characterized the individual sources of all the latency, but it
would seem that it's at least 3 to 4 orders of magnitude too slow for
802.11 ACK timing.
I'm measuring round trip delays of around 100 milliseconds with a B210
and a commercial DVB-S2 receiver, and 802.11 has ACK timing in the tens
of microseconds.
Ron
On 11/25/2016 06:59 AM, Sumit Kumar via USRP-users wrote:
> Ok, understood. Is there any method to measure the round trip delay
> for B210.
>
> tx_file from cpu --> usb --> fpga --> tx --> rx --> fpga --> usb -->
> rx_file to cpu ?
>
>
>
> On Fri, Nov 25, 2016 at 3:25 PM, Marcus M?ller
> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> wrote:
>
> Hi Sumit,
>
> I must admit that I can't really help you at this point with the
> choice of USRP ? after all, you have insight into the software
> you're going to use that nobody else has, so I can't really guess
> what of the DSP chain this software implies needs to run on an FPGA.
>
> Certainly, starting to prototype on an FPGA which is probably
> oversized and that supports RFNoC is going to be easier than
> working with an FPGA that might or might not be a little small.
> But, there's too many variables in your design that I can't really
> assess.
>
> I hope that helps,
>
> Marcus
>
> On 25.11.2016 15:19, Sumit Kumar wrote:
>> Ahh (Facepalm).. Yes that "m" was a typo which I copy pasted all
>> the time and it got populated. Yes we are talking about the same
>> stuff. Apology again :) Its
>> https://github.com/bastibl/gr-ieee802-11
>> <https://github.com/bastibl/gr-ieee802-11> only.
>>
>> Yes OAI is openairinterface. The 80211 module is under
>> development. Once it is stable, it will be open source.
>>
>> It will be great if you could shed some light on the choice of
>> USRP :)
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Nov 25, 2016 at 2:34 PM, Marcus M?ller
>> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> wrote:
>>
>> Hello Sumit,
>>
>> I'm a bit confused:
>>
>> where did the "m" in gr-ieee802-11 come from? I first thought
>> it was a typo, but you use it multiple times. I only know
>> gr-ieee802-11 [1] , which _does_ implement 11g. I'm not
>> familiar with gr-ieee802-11m. So, are we talking about the
>> same thing?
>>
>> And, in the context of OFDM-systems in general-purpose
>> computer-based SDR, I only know "OAI" to stand for
>> OpenAirInterface, and that, to my knowledge, implements 4G
>> cellular, not IEEE802.11; so could you share a reference to
>> "your" OAI?
>>
>> Best regards,
>>
>> Marcus
>>
>>
>> [1] https://github.com/bastibl/gr-ieee802-11
>> <https://github.com/bastibl/gr-ieee802-11>
>>
>> On 25.11.2016 13:30, Sumit Kumar wrote:
>>> Hello Marcus, I appreciate your detailed reply.
>>>
>>> Yes gr-ieee802-11m . Its an excellent implementation.
>>>
>>> However I am more concerned about talking to a commercial
>>> access point.
>>>
>>> The application which I am working(OAI), is also doing the
>>> same(using fixed point maths) as gr-ieee802-11m, but only
>>> for 11g.
>>>
>>> I am at a point where I have to decide whether to touch the
>>> FPGA or not. I see, off course yes, I have to touch it.
>>>
>>> So next question is which USRP I shall choose. As of now I
>>> am using B210, but ...
>>>
>>> Does B210 has enough FPGA resources left (with current FPGA
>>> images of UHD) to put some of the base band processing there
>>> for example *preamble search* and *ACK frame generation*.
>>>
>>> Or shall I choose X310 which will enable me to use RfNoc
>>> also for developing FPGA.
>>>
>>> Regards
>>>
>>> Sumit
>>>
>>> On Fri, Nov 25, 2016 at 12:17 PM, Marcus M?ller via
>>> USRP-users <usrp-users@lists.ettus.com
>>> <mailto:usrp-users@lists.ettus.com>> wrote:
>>>
>>> Hi Sumit,
>>>
>>> On 25.11.2016 02:09, Sumit Kumar via USRP-users wrote:
>>> > I need some suggestions for implementing MAC layer of
>>> 802.11a/g on USRP.
>>> Use Bastian Bloessl's excellent gr-ieee802-11m, which is
>>> a working
>>> implementation of 802.11a/g/p.
>>>
>>> >
>>> > I did some survey and found that there can't be any
>>> solution unless
>>> > FPGA resources are used. GPU based solution not possible.
>>> Well, a "halfway standards-compliant" implementation
>>> existing, I'd say
>>> your statement is half true. It's only
>>> halfway-compliant, because it
>>> can't keep every timing constraint, due to running on a PC.
>>> >
>>> > I see there are very few solutions to the date. One
>>> from Microsoft
>>> > SORA and another (recently) from NI. Both of them used
>>> FPGA resources
>>> > for meeting the timings constraints of 802.11.
>>> Well, the problem with any type of reactive MAC is that
>>> both the
>>> interfaces to PCs are too "high latency" and that PCs
>>> are just that ?
>>> personal computers, designed for anything, but not for
>>> guaranteeing a
>>> specific latency in reaction to some MAC event.
>>>
>>> > I see both these solutions are from industry.
>>> Well, the boundary between research, university and
>>> industry is kind of
>>> blurry when it comes to things like this... In fact,
>>> you'll find that
>>> atheros and intel WiFi chipsets (and probably, all other
>>> WiFi chipsets)
>>> are internally SDRs, though they are fixed-purpose. They
>>> certainly arose
>>> from things that were researched in university labs, too!
>>> > I was wondering what prevents such development in
>>> academics ? Is it
>>> > way too complicated for students ?
>>> Well, "too complicated for students" depends on your
>>> definition of
>>> "too", and of "student", and of course your individual
>>> student. I don't
>>> generally assume students are less clever than non-students?
>>> If you count PhD candidates as students: well, guess
>>> what: Bastian wrote
>>> gr-ieee802-11 as part of his PhD. If you count master
>>> theses: I'm sure
>>> you'll find a lot of master students that were assigned
>>> to do a specific
>>> part of a standards implementation on an FPGA ? and yes,
>>> MAC layer stuff
>>> is a prime candidate for this.
>>>
>>> Now, it's definitely possible to distribute the work
>>> between FPGA and
>>> host PC differently than it's done in a N210 with Ettus'
>>> stock FPGA
>>> image. In fact, if you search IEEExplore, you'll find a
>>> lot of papers on
>>> nowadays outdated approaches on MAC on the FPGA of the
>>> USRP2 (which is
>>> very similar to the N210).
>>>
>>> By modern standards, maybe the N210 isn't the easiest
>>> platform to modify
>>> the FPGA to include things like let's say a preamble
>>> detector and a
>>> simple MAC layer. RFNoC on the X300 / X310 does make
>>> such tasks easier.
>>>
>>> Best regards,
>>> Marcus
>>>
>>> _______________________________________________
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161129/31652140/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 29 Nov 2016 12:50:09 -0600
From: Jonathon Pendlum <jonathon.pend...@ettus.com>
To: Eddie Fung <ef...@appcomsci.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Setting up RFNOC development environment &
running gr-ettus/rfnoc examples
Message-ID:
<CAGdo0uRYWLYGXEioLKkaeh2xhhGOrWKu0ZL=uvb1bw3jzxf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Eddie,
You'll need to generate a FPGA image with the RFNoC blocks you want. There
is information on how to do this in the knowledge base:
https://kb.ettus.com/RFNoC_Getting_Started_Guides. Also, soon I will be
updating the image package with an image that has various RFNoC blocks in
it.
Jonathon
On Mon, Nov 28, 2016 at 12:41 PM, Eddie Fung via USRP-users <
usrp-users@lists.ettus.com> wrote:
> I am trying to set up and baseline a development environment for RFNOC by
> testing it using the examples under gr-ettus and
> am running into an error. I have set up my environment by following the
> instructions given at
> https://kb.ettus.com/Getting_Started_with_RFNoC_Development.
>
> The following is an abbreviated transcript of what I did:
> ---------------Begin Transcript--------------------
> ------------------------------------------------------------
> -------------------------------
> $ sudo pip install git+https://github.com/gnuradio/pybombs.git
> $ pybombs recipes add gr-recipes git+https://github.com/gnuradi
> o/gr-recipes.git
> $ pybombs recipes add ettus git+https://github.com/EttusRe
> search/ettus-pybombs.git
> $ pybombs prefix init ./rfnoc -R rfnoc -a rfnoc
> $ cd ./rfnoc
> $ . ./setup_env.sh
> $ uhd_images_downloader
> Images destination: ..../rfnoc/share/uhd/images
> Downloading images from: http://files.ettus.com/binarie
> s/images/uhd-images_003.010.000.000-36-g967897e0.zip
> Downloading images to: /tmp/tmpuCXKMR/uhd-images_003.
> 010.000.000-36-g967897e0.zip
> $ uhd_images_loader --args="type=x300,addr=192.168.20.2"
> $ uhd_usrp_probe
> [text deleted for brevity]
> | | _____________________________________________________
> | | /
> | | | RFNoC blocks on this device:
> | | |
> | | | * DmaFIFO_0
> | | | * Radio_0
> | | | * Radio_1
> | | | * DDC_0
> | | | * DDC_1
> | | | * DUC_0
> | | | * DUC_1
>
> $ ./rfnoc/src/gr-ettus/examples/rfnoc/rfnoc_dma_fifo.py
> [text deleted for brevity]
> RuntimeError: Cannot find a block for ID: FIFO
> -----------------End Transcript--------------------
> ------------------------------------------------------------
> -----------------------------
>
> Based upon the output of the 'uhd_usrp_probe', I'm not surprised by the
> runtime error messsage.
> So my questions are as follows:
> 1. Did I miss any steps in setting up my environment that would have made
> the example run?
> 2. Is there a specific FPGA image I could have downloaded that would have
> worked with the gr-ettus examples?
> 3. (And most importantly), Are there build instructions for an RFNOC FPGA
> image that would have worked for the gr-ettus examples?
>
> Thanks,
> Eddie
>
> _______________________________________________
> 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/20161129/65bf019d/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 29 Nov 2016 15:23:51 -0500
From: Steve Gough <sgough1...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Regarding understanding non linearity in N210
Message-ID:
<CAFq1tbyq45HHMCp8xvW7LHE7=c8CDGCJriT+C=vuurck+mo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi All,
I have a USRP N210 with the CBX daughterboard, that transmits a 0.5KHz tone
at 5.8GHz. The tone has a baseband peak amplitude of 1 and gain equal to
maximum gain of 31.5dB.
I read that the N-210 exhibits non-linearities at high transmit gain[1].
Could someone please help explain this non linearity relation ? Such a
non-linear relationship exists between what and what ?
What might be the cons of sending such a tone with baseband peak amplitude
of 1, and gain equal to the maximum transmit gain of 31.5dB? Where does the
non-linearity affect such a transmission ?
Thanks again!
Steve
[1]:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-May/014296.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161129/bfe09345/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 29 Nov 2016 16:34:20 -0500
From: "Marcus D. Leech" <mle...@ripnet.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Regarding understanding non linearity in
N210
Message-ID: <583df45c.4000...@ripnet.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 11/29/2016 03:23 PM, Steve Gough via USRP-users wrote:
> Hi All,
>
> I have a USRP N210 with the CBX daughterboard, that transmits a 0.5KHz
> tone at 5.8GHz. The tone has a baseband peak amplitude of 1 and gain
> equal to maximum gain of 31.5dB.
>
> I read that the N-210 exhibits non-linearities at high transmit
> gain[1]. Could someone please help explain this non linearity relation
> ? Such a non-linear relationship exists between what and what ?
>
> What might be the cons of sending such a tone with baseband peak
> amplitude of 1, and gain equal to the maximum transmit gain of 31.5dB?
> Where does the non-linearity affect such a transmission ?
>
> Thanks again!
> Steve
>
> [1]:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-May/014296.html
>
>
>
>
In the case of the TX, it means that you can get clipping, or waveform
distortion--this is bad both because your signal won't "look" to your
receiver like it should, and because it will have unpleasant unintended
spectral artifacts.
Consider the limiting case of non-linearity, in which a pure-tone
sinusoid is limited and clipped so that it looks like a square-wave. Your
"pure" sinusoid now has effective both the fundamental and all
possible odd harmonics in it.
So, with smaller amounts of non-linearity, the unwanted emissions are
somewhere between "hardly any" and our above worst-case
represented by a square wave.
------------------------------
Message: 6
Date: Tue, 29 Nov 2016 14:09:19 -0800
From: Tom Tsou <tom.t...@ettus.com>
To: Sumit Kumar <cog...@gmail.com>
Cc: Marcus M?ller <marcus.muel...@ettus.com>,
"usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] 802.11 Timings : What are the challenges
with SDR implementation ?
Message-ID:
<cagniu+fpumxer7tthihppeupcxc8kvwmb10d_mgfm_ebak5...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Fri, Nov 25, 2016 at 6:59 AM, Sumit Kumar via USRP-users
<usrp-users@lists.ettus.com> wrote:
> Ok, understood. Is there any method to measure the round trip delay for B210.
>
> tx_file from cpu --> usb --> fpga --> tx --> rx --> fpga --> usb --> rx_file
> to cpu ?
There are a variety of methods of measuring latency, which will yield
different results. Generally speaking, expect round trip latency on
the order of milliseconds without burst processing.
The most basic approach is to inject a pulsed signal into a Rx-Tx
loopback configuration and measure the delay offset on an
oscilloscope. This method will yield the lowest latency measurement,
but does not reflect the 802.11 use case as there is no packet
handling.
A closer approach to 802.11 is to use sample timestamps with timed
bursts. UHD reports the arrival time of a received burst of samples.
>From that timestamp, you can calculate a target transmit time and send
an appropriate delayed response burst. The FPGA will notify through
UHD if the burst is late. The goal is to find the lowest Rx-Tx delay
that the FPGA allows; that yields the round trip packet latency.
802.11 compliance requires meeting SIFS time of 10 or 16 us depending
on frequency band whereas LTE has more relaxed requirements due to the
slotted architecture and larger interval size of 1 ms. 802.11 is not
possibly with host processing; LTE can be fully implemented on the
host and has been thoroughly demonstrated by multiple parties.
-TT
------------------------------
Message: 7
Date: Tue, 29 Nov 2016 16:49:00 -0800
From: Michael West <michael.w...@ettus.com>
To: ty <tyrus...@gmail.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] libuhd issue on OpenBTS
Message-ID:
<CAM4xKrpJcZcEjKkRnaoXLaQ-RLAB=bv8y2h+sn2exyeq6-p...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Tyrus,
The call stack indicates that gethostid() is failing. That is a Linux
system level error.
The good news is that there are a couple workarounds:
1) Disable X300 support and re-build UHD. The failure is happening when
trying to discover X300 devices, so you can simply disable that part of UHD
if you do not plan on using X300 devices.
2) Add "type=usrp2" to the device arguments when creating the multi_usrp
object. This will isolate the discovery to only N200 devices and skip
running the X300 discovery. I am not familiar with the OpenBTS code, but
it may require a OpenBTS code change.
Hope this helps.
Regards,
Michael
On Tue, Nov 29, 2016 at 2:35 AM, ty via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Good evening. My name is tyrus and I have the following set up;
>
> OpenBTS 5.0 build and installed
>
> I have Ubuntu 14.04 LTS installed and *UHD_003.010.git-34-g90b88a27*
> installed. I am running this on a USRP N200 with a WRX Daughter board.
>
> Now, after following all the steps, I ran the following command getting
> the following error:
>
> tyrus@the-jedi-council:/OpenBTS$ sudo ./transceiver
>
> **** Error in `./transceiver': free(): invalid pointer: 0x083cda64 ****
>
> I ran gdb against the transceiver and this was the output
>
> gdb) where
> #0 0xb7fdd428 in __kernel_vsyscall ()
> #1 0xb72d101b in poll () at ../sysdeps/unix/syscall-template.S:81
> #2 0xb455f0a9 in send_dg (ansp2_malloced=0x0, resplen2=0x0, anssizp2=0x0,
> ansp2=0x0, anscp=0xbfffded8, gotsomewhere=<synthetic pointer>,
> v_circuit=<synthetic pointer>, ns=0, terrno=0xbfffcee8,
> anssizp=0xbfffcfa8, ansp=0xbfffcedc, buflen2=0, buf2=0x0, buflen=34,
> buf=0xbfffcfc0 "X\354\001",
> statp=0xb73a1fc0 <_res>) at res_send.c:1206
> #3 __libc_res_nsend (statp=statp@entry=0xb73a1fc0 <_res>,
> buf=buf@entry=0xbfffcfc0
> "X\354\001", buflen=34, buf2=buf2@entry=0x0, buflen2=buflen2@entry=0,
> ans=ans@entry=0xbfffdab0 "`7\374\260\001", anssiz=anssiz@entry=1024,
> ansp=ansp@entry=0xbfffded8, ansp2=ansp2@entry=0x0, nansp2=nansp2@entry
> =0x0,
> resplen2=resplen2@entry=0x0, ansp2_malloced=ansp2_malloced@entry=0x0)
> at res_send.c:576
> #4 0xb455ce05 in __GI___libc_res_nquery (statp=statp@entry=0xb73a1fc0
> <_res>, name=name@entry=0xbfffd1bb "the-jedi-council.", class=class@entry
> =1,
> type=type@entry=1, answer=answer@entry=0xbfffdab0 "`7\374\260\001",
> anslen=anslen@entry=1024, answerp=answerp@entry=0xbfffded8,
> answerp2=answerp2@entry=0x0,
> nanswerp2=nanswerp2@entry=0x0, resplen2=resplen2@entry=0x0,
> answerp2_malloced=answerp2_malloced@entry=0x0) at res_query.c:227
> #5 0xb455d46b in __libc_res_nquerydomain (statp=statp@entry=0xb73a1fc0
> <_res>, name=name@entry=0xbfffe80f "the-jedi-council",
> domain=domain@entry=0xb73a2020 <_res+96> "", class=class@entry=1,
> type=type@entry=1, answer=answer@entry=0xbfffdab0 "`7\374\260\001",
> anslen=anslen@entry=1024, answerp=answerp@entry=0xbfffded8,
> answerp2=answerp2@entry=0x0, nanswerp2=nanswerp2@entry=0x0,
> resplen2=resplen2@entry=0x0,
> answerp2_malloced=answerp2_malloced@entry=0x0) at res_query.c:591
> #6 0xb455d97f in __GI___libc_res_nsearch (statp=0xb73a1fc0 <_res>,
> name=name@entry=0xbfffe80f "the-jedi-council", class=class@entry=1,
> type=type@entry=1,
> answer=answer@entry=0xbfffdab0 "`7\374\260\001", anslen=anslen@entry=1024,
> answerp=answerp@entry=0xbfffded8, answerp2=answerp2@entry=0x0,
> nanswerp2=nanswerp2@entry=0x0, resplen2=resplen2@entry=0x0,
> answerp2_malloced=answerp2_malloced@entry=0x0) at res_query.c:421
> #7 0xb7fc5222 in __GI__nss_dns_gethostbyname3_r (name=name@entry=0xbfffe80f
> "the-jedi-council", af=af@entry=2, result=result@entry=0xbfffe7f8,
> buffer=buffer@entry=0xbfffe3c0 "\377\002", buflen=buflen@entry=1024,
> errnop=errnop@entry=0xb559f6a8, h_errnop=h_errnop@entry=0xbfffe7f4,
> ttlp=ttlp@entry=0x0, canonp=canonp@entry=0x0) at
> nss_dns/dns-host.c:192
> #8 0xb7fc5591 in _nss_dns_gethostbyname_r (name=0xbfffe80f
> "the-jedi-council", result=0xbfffe7f8, buffer=0xbfffe3c0 "\377\002",
> buflen=1024, errnop=0xb559f6a8,
> h_errnop=0xbfffe7f4) at nss_dns/dns-host.c:273
> #9 0xb72f272b in __gethostbyname_r (name=0xbfffe80f "the-jedi-council",
> resbuf=0xbfffe7f8, buffer=buffer@entry=0xbfffe3c0 "\377\002",
> buflen=buflen@entry=1024,
> result=0xbfffe7e8, h_errnop=0xbfffe7f4) at ../nss/getXXbyYY_r.c:266
> #10 0xb72d8685 in gethostid () at ../sysdeps/unix/sysv/linux/get
> hostid.c:104
> #11 0xb7b647d4 in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003
> #12 0xb7b7f20a in uhd::usrprio_rpc::usrprio_rpc_
> client::usrprio_rpc_client(std::string, std::string) () from
> /usr/lib/i386-linux-gnu/libuhd.so.003
> #13 0xb7b835c4 in uhd::niusrprio::niusrprio_session::enumerate(std::string
> const&, std::vector<uhd::usrprio_rpc::usrprio_device_info,
> std::allocator<uhd::usrprio_rpc::usrprio_device_info> >&) () from
> /usr/lib/i386-linux-gnu/libuhd.so.003
> #14 0xb7a73d98 in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003
> #15 0xb799f7f9 in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003
> #16 0xb7bf68c4 in uhd::device::find(uhd::device_addr_t const&,
> uhd::device::device_filter_t) () from /usr/lib/i386-linux-gnu/libuhd
> .so.003
> #17 0x0806ed69 in uhd_device::open (this=0x80f5cd0, args="", extref=false)
> at UHDDevice.cpp:537
> #18 0x0805586f in main (argc=1, argv=0xbffff7f4) at runTransceiver.cpp:158
>
> Anyone else experienced this?
>
> Thanks
>
>
>
>
>
> _______________________________________________
> 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/20161129/cd9069b6/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 29 Nov 2016 17:05:27 -0800
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] B210 C-API dual channel
Message-ID: <e048c8fd-bc15-e33d-1d73-2d25f2d09...@ettus.com>
Content-Type: text/plain; charset=UTF-8
Andrew,
status 10 is a index_error, and I can't see a path in B210 that would
throw that. Can you use uhd_get_last_error() to get a string
representation of the error, and post that?
Thanks,
Martin
On 11/24/2016 06:51 AM, ?????? 1 via USRP-users wrote:
>
>
> Hello
>
> In previous post I published my code for dual channel receive.
> Its not work.
> I have Status=10 when i call uhd_usrp_set_time_now and num_rx_samps = 0
> after uhd_rx_streamer_recv Can anyone answer me where the error.
>
> Thanks
> Andrew
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 9
Date: Tue, 29 Nov 2016 17:07:32 -0800
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] B205mini-i overfow error
Message-ID: <637d4b4a-dda5-4fbb-114d-b1d1c628b...@ettus.com>
Content-Type: text/plain; charset=windows-1252
If you're doing NUM_SAMPS_AND_DONE (which you are), you need to
re-trigger a stream command on overruns.
Cheers,
Martin
On 11/23/2016 02:28 AM, Vladica Sark via USRP-users wrote:
> Hi Martin,
>
> Should I only issue a stream command in order to recover forom this
> situation?
>
> The thing is that I can live with one overflow each few minutes, but I
> didn't succeed to recover from the situation.
>
> Anyway, I would try again to find a way for recovering.
>
> BR,
> Vladica
>
>
> On 23.11.2016 02:49, Martin Braun via USRP-users wrote:
>> Vladica,
>>
>> we are confirming there are issues with these rates. However, it
>> shouldn't be unrecoverable. You can try reducing the OTW format to sc8
>> to reduce your USB bandwidth.
>>
>> Cheers,
>> M
>>
>> On 11/15/2016 02:38 AM, Vladica Sark via USRP-users wrote:
>>> Hi there,
>>>
>>> Anyone having experience with the overflow error in B205mini, when
>>> sampling with 50 MSps?
>>>
>>> How to recover from it?
>>>
>>> BR,
>>> Vladica
>>>
>>>
>>>
>>> -------- Forwarded Message --------
>>> Subject: B205mini-i overfow error
>>> Date: Fri, 11 Nov 2016 22:23:30 +0100
>>> From: Vladica Sark <vladicas...@gmail.com>
>>> To: usrp-users@lists.ettus.com <usrp-users@lists.ettus.com>
>>>
>>> Hi there,
>>>
>>> I have the following problem:
>>> I schedule a reception of 550000 samples, every 20 ms. The code is:
>>>
>>> time_current = usrp->get_time_now();
>>>
>>> uhd::stream_cmd_t stream_cmd(
>>> uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
>>> stream_cmd.num_samps = 550000;
>>> stream_cmd.stream_now = false;
>>> stream_cmd.time_spec = time_current + uhd::time_spec_t(0.02);
>>> rx_stream->issue_stream_cmd(stream_cmd);
>>>
>>> Further I wait for reception of the samples with:
>>>
>>> uhd::rx_metadata_t md;
>>>
>>> size_t num_rx_samps = rx_stream->recv(buffer,
>>> 550000, md, 0.2, false);
>>>
>>> This runs in an infinite loop. The problem is that after some random
>>> time, tens to thousands of seconds an overflow is detected.
>>> First, between scheduling the reception and receiving the samples, I get
>>> "O" on the screen, and than, I receive less than 550000 samples. No
>>> error is reported at this time, and all flags in md (start_of_burst,
>>> end_of_burst, more_fragments) are 0. I schedule next transmission by
>>> issuing command, and when I try to receive the samples, rx_stream->recv
>>> returns 0 samples and in md error I find error number 8 and
>>> out_of_sequence is 0. There is no recovery from this situation, and I
>>> must restart the program.
>>>
>>> When I detect this situation, my thread executes
>>>
>>> boost::this_thread::sleep(boost::posix_time::seconds(0.5));
>>>
>>> and waits for user input. Anyway, one CPU core is used 100%.
>>>
>>> I use 50 MSps, and the machine I use is intel core i5. Everything is
>>> executed on Ubuntu 16.04.
>>>
>>> BR,
>>> Vladica
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 10
Date: Tue, 29 Nov 2016 17:46:00 -0800
From: Michael West <michael.w...@ettus.com>
To: ?????? 1 <andrew4...@rambler.ru>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] B210 C-API dual channel
Message-ID:
<CAM4xKroL299Cu=DVyZWh2qmUS2L1yWu3ssXRu1Tz=rjxh9o...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Andrew,
First, I recommend you avoid the subdev spec altogether if possible. The A
and B sides are enumerated as channels 0 and 1 by default, so just use them
as is unless you have good reason to change it. If you have multiple
devices, they will enumerate in the order they are discovered. You can
specify the serial numbers in the desired order to get the channels to
enumerate the way you want. For example, let's say you have devices with
serial numbers 1111 and 2222. Use the device arguments
"serial0=1111,serial1=2222" and the channels will enumerate as follows:
Channel 0: A on 1111
Channel 1: B on 1111
Channel 2: A on 2222
Channel 3: B on 2222
Second, I noticed that you are setting the time on the device to the same
time as you plan on starting streaming. This will cause the stream command
to be late and no samples will be received. Try putting the start time for
the streaming a significant time into the future. I believe this may be
why you saw no samples.
I hope this helps.
Regards,
Michael
On Wed, Nov 16, 2016 at 1:59 AM, ?????? 1 via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi
>
> Sory accidentally erased.
>
> That full text.
>
> int main(int argc, char* argv[])
>
> {
>
> int option = 0;
>
> double freq = 500e6;
>
> double freqR = 500e6;
>
> double rate = 1e6;
>
> double gain = 5.0;
>
> char* device_args = "";
>
> size_t channel;
>
> char* filename = "out.dat";
>
> size_t n_samples = 1000;//000;
>
> bool verbose = false;
>
> int return_code = EXIT_SUCCESS;
>
> bool custom_filename = false;
>
> char error_string[512];
>
> uhd_usrp_handle usrp;
>
> uhd_rx_streamer_handle rx_streamer;
>
> uhd_rx_metadata_handle md;
>
> uhd_tune_request_t tune_request;
>
> uhd_tune_result_t tune_result;
>
> uhd_stream_args_t stream_args;
>
> uhd_stream_cmd_t stream_cmd;
>
> uhd_rx_metadata_error_code_t error_code;
>
> size_t samps_per_buff;
>
> void **buffs_ptr = NULL;
>
> FILE *fp = NULL;
>
> size_t num_acc_samps = 0;
>
> size_t i;
>
> UHD_API uhd_error Status;
>
> size_t mboard=0;
>
> uhd_subdev_spec_handle subdev=NULL;
>
> uhd_subdev_spec_pair_t subdev1={"A","A:A A:B"};
>
> uhd_subdev_spec_pair_t subdev2={"A","A:A A:B"};
>
> char markup[256]={0,0,0};
>
> time_t full_secs=1;
>
> double frac_secs=0.5;
>
> size_t count_channel=2; //!!!
>
> size_t channel_list[2];
>
> float *buff = NULL;
>
> float *buff1= NULL;
>
> float *buffers[2];
>
> memset((void*)&tune_request,0,sizeof(tune_request));
>
> channel_list[0]=0;
>
> channel_list[1]=1;
>
> if(*uhd_set_thread_priority*(uhd_default_thread_priority, true)){
>
> fprintf(stderr, "Unable to set thread priority. Continuing
> anyway.\n");
>
> }
>
> // Create USRP
>
> fprintf(stderr, "Creating USRP with args \"%s\"...\n", device_args);
>
> if(*uhd_usrp_make*(&usrp, device_args)!=UHD_ERROR_NONE)
>
> goto free_option_strings;
>
> if(subdev==NULL)
>
> Status=*uhd_subdev_spec_make*(&subdev, markup );
>
> if(subdev)
>
> {
>
> //! Get the RX frontend specification for the given device
>
> Status=*uhd_usrp_get_rx_subdev_spec*(usrp, mboard, subdev);
>
> //! Check how many subdevice specifications are in this list
>
> Status=*uhd_subdev_spec_size*(subdev,&i);
>
> if(i>=2)
>
> {
>
> //! Get a string representation of the given list
>
> Status=*uhd_subdev_spec_to_pp_string*(subdev, markup,
> sizeof(markup) );
>
> //! Get the subdevice specification at the given index
>
> Status=*uhd_subdev_spec_at*(subdev,0,&subdev1);
>
> Status=*uhd_subdev_spec_at*(subdev,1,&subdev2);
>
> }
>
> else Status=*uhd_subdev_spec_push_back*(subdev,"A:A A:B");
>
> //! Map the given device's RX frontend to a channel
>
> Status=*uhd_usrp_set_rx_subdev_spec*(usrp, (uhd_subdev_spec_handle)subdev,
> mboard);
>
> //! Get a string representation of the given list
>
> Status=*uhd_subdev_spec_to_pp_string*(subdev, markup, sizeof(markup)
> );
>
> fprintf(stderr, "Setting subdev: %s...\n", markup);
>
> }
>
> // Create RX streamer
>
> if(*uhd_rx_streamer_make*(&rx_streamer)!=UHD_ERROR_NONE)
>
> goto free_usrp;
>
> // Create RX metadata
>
> if(*uhd_rx_metadata_make*(&md)!=UHD_ERROR_NONE)
>
> goto free_rx_streamer;
>
> // Create other necessary structs
>
> tune_request.target_freq = freq;
>
> tune_request.rf_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO;
>
> tune_request.dsp_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO;
>
> for(channel=0;channel<count_channel;channel++)
>
> {
>
> fprintf(stderr, " Setting Channel%d\n",channel);
>
> // Set rate
>
> fprintf(stderr, "Setting RX Rate: %f...\n", rate);
>
> if(*uhd_usrp_set_rx_rate*(usrp, rate, channel)!=UHD_ERROR_NONE)
>
> goto free_rx_metadata;
>
> // See what rate actually is
>
> if(*uhd_usrp_get_rx_rate*(usrp, channel, &rate)!=UHD_ERROR_NONE)
>
> goto free_rx_metadata;
>
> fprintf(stderr, "Actual RX Rate: %f...\n", rate);
>
> // Set gain
>
> fprintf(stderr, "Setting RX Gain: %f dB...\n", gain);
>
> if(*uhd_usrp_set_rx_gain*(usrp, gain, channel,
> "")!=UHD_ERROR_NONE)
>
> goto free_rx_metadata;
>
> // See what gain actually is
>
> if(*uhd_usrp_get_rx_gain*(usrp, channel, "",
> &gain)!=UHD_ERROR_NONE)
>
> goto free_rx_metadata;
>
> fprintf(stderr, "Actual RX Gain: %f...\n", gain);
>
> // Set frequency
>
> fprintf(stderr, "Setting RX frequency: %f MHz...\n", freq/1e6);
>
> if(*uhd_usrp_set_rx_freq*(usrp, &tune_request, channel,
> &tune_result)!=UHD_ERROR_NONE)
>
> goto free_rx_metadata;
>
> // See what frequency actually is
>
> if(*uhd_usrp_get_rx_freq*(usrp, channel, &freqR)!=UHD_ERROR_NONE)
>
> goto free_rx_metadata;
>
> fprintf(stderr, "Actual RX frequency: %f MHz...\n", freqR / 1e6);
>
> }
>
> // Set up streamer
>
> stream_args.cpu_format = "fc32";
>
> stream_args.otw_format = "sc16";
>
> stream_args.args = "";
>
> stream_args.channel_list = &channel_list[0];
>
> stream_args.n_channels = count_channel;
>
> if(*uhd_usrp_get_rx_stream*(usrp, &stream_args,
> rx_streamer)!=UHD_ERROR_NONE)
>
> goto free_rx_streamer;
>
> // Set up buffer
>
> if(*uhd_rx_streamer_max_num_samps*(rx_streamer,
> &samps_per_buff)!=UHD_ERROR_NONE)
>
> goto free_rx_streamer;
>
> fprintf(stderr, "Buffer size in samples: %zu\n", samps_per_buff);
>
> buff = malloc(samps_per_buff * 2 * sizeof(float));
>
> buff1 = malloc(samps_per_buff * 2 * sizeof(float));
>
> buffers[0]=buff;
>
> buffers[1]=buff1;
>
> buffs_ptr = (void**)buffers;
>
> stream_cmd.stream_mode = UHD_STREAM_MODE_NUM_SAMPS_AND_DONE;
>
> stream_cmd.num_samps = n_samples;
>
> stream_cmd.stream_now =true;
>
> //stream_cmd.stream_now =false; //With multiple devices false;
>
> stream_cmd.time_spec_full_secs=full_secs; //time_t //! If
> not now, then full seconds into future to stream
>
> stream_cmd.time_spec_frac_secs=frac_secs; //timeout; //! If not
> now, then fractional seconds into future to stream
>
> Status=*uhd_usrp_set_time_now*(usrp,full_secs, frac_secs, 0); //
> Status=10 ???
>
> // Issue stream command
>
> fprintf(stderr, "Issuing stream command.\n");
>
> if(*uhd_rx_streamer_issue_stream_cmd*(rx_streamer,
> &stream_cmd)!=UHD_ERROR_NONE)
>
> goto free_buffer;
>
> // Set up file output
>
> fp = fopen(filename, "wb");
>
> // Actual streaming
>
> while (num_acc_samps < n_samples) {
>
> size_t num_rx_samps = 0;
>
> if(*uhd_rx_streamer_recv*(rx_streamer, buffs_ptr, samps_per_buff,
> &md, 3.0, false, &num_rx_samps)!=UHD_ERROR_NONE)
>
> goto close_file;
>
> if(*uhd_rx_metadata_error_code*(md, &error_code)!=UHD_ERROR_NONE)
>
> goto close_file;
>
> if(error_code != UHD_RX_METADATA_ERROR_CODE_NONE){
>
> fprintf(stderr, "Error code 0x%x was returned during
> streaming. Aborting.\n", error_code);//return_code);
>
> goto close_file;
>
> }
>
> // Handle data
>
> fwrite(buff, sizeof(float) * 2, num_rx_samps, fp);
>
> fwrite(buff1, sizeof(float) * 2, num_rx_samps, fp);
>
> if (verbose) {
>
> time_t full_secs;
>
> double frac_secs;
>
> *uhd_rx_metadata_time_spec*(md, &full_secs, &frac_secs);
>
> fprintf(stderr, "Received packet: %zu samples, %zu full secs,
> %f frac secs\n",
>
> num_rx_samps,
>
> full_secs,
>
> frac_secs);
>
> }
>
> num_acc_samps += num_rx_samps;
>
> }
>
> // Cleanup
>
> close_file:
>
> fclose(fp);
>
> free_buffer:
>
> if(buff){
>
> if(verbose){
>
> fprintf(stderr, "Freeing buffer_0.\n");
>
> }
>
> free(buff);
>
> }
>
> buff = NULL;
>
> if(buff1){
>
> if(verbose){
>
> fprintf(stderr, "Freeing buffer_1.\n");
>
> }
>
> free(buff1);
>
> }
>
> buff1 = NULL;
>
> buffs_ptr = NULL;
>
> free_rx_streamer:
>
> if(verbose){
>
> fprintf(stderr, "Cleaning up RX streamer.\n");
>
> }
>
> uhd_rx_streamer_free(&rx_streamer);
>
> free_rx_metadata:
>
> if(verbose){
>
> fprintf(stderr, "Cleaning up RX metadata.\n");
>
> }
>
> uhd_rx_metadata_free(&md);
>
> free_usrp:
>
> if(verbose){
>
> fprintf(stderr, "Cleaning up USRP.\n");
>
> }
>
> if(return_code != EXIT_SUCCESS && usrp != NULL){
>
> uhd_usrp_last_error(usrp, error_string, 512);
>
> fprintf(stderr, "USRP reported the following error: %s\n",
> error_string);
>
> }
>
> uhd_usrp_free(&usrp);
>
> free_option_strings:
>
> if(strcmp(device_args,"")){
>
> free(device_args);
>
> }
>
> if(custom_filename){
>
> free(filename);
>
> }
>
> if(subdev) uhd_subdev_spec_free(&subdev);
>
> subdev=NULL;
>
> fprintf(stderr, (return_code ? "Failure\n" : "Success\n"));
>
> return return_code;
>
> }
>
> Regards,
>
> Andrew.
>
> ---------- ??????????? ????????? ----------
>
> ?? ????: (mle...@ripnet.com)
>
> ????: 15.11.2016, 17:48:07
>
> ????: Re: [USRP-users] B210 C-API dual channel
>
> ????: ?????? 1 (andrew4...@rambler.ru)
>
> Re: [USRP-users] B210 C-API dual channel
>
> I don't see anywhere in the attached code where you actually call
> uhd_usrp_set_rx_subdev_spec()
>
>
>
>
>
>
> On 2016-11-14 10:39, ?????? 1 via USRP-users wrote:
>
> Hello
>
>
>
> In that code I'm trying to get phase-aligned 2-channel RX
>
> In that code something is wrong becose after uhd_usrp_set_time_now have an
> error and num_rx_samps = 0
>
>
>
> int main(int argc, char* argv[])
>
> {
>
> int option = 0;
>
> double freq = 500e6;
>
> double freqR = 500e6;
>
> double rate = 1e6;
>
> double gain = 5.0;
>
> char* device_args = "";
>
> size_t channel;
>
> char* filename = "out.dat";
>
> size_t n_samples = 1000;//000;
>
> bool verbose = false;
>
> int return_code = EXIT_SUCCESS;
>
> bool custom_filename = false;
>
> char error_string[512];
>
>
>
> uhd_usrp_handle usrp;
>
> uhd_rx_streamer_handle rx_streamer;
>
> uhd_rx_metadata_handle md;
>
> uhd_tune_request_t tune_request;
>
> uhd_tune_result_t tune_result;
>
> uhd_stream_args_t stream_args;
>
> uhd_stream_cmd_t stream_cmd;
>
> uhd_rx_metadata_error_code_t error_code;
>
> size_t samps_per_buff;
>
> void **buffs_ptr = NULL;
>
> FILE *fp = NULL;
>
> size_t num_acc_samps = 0;
>
>
>
> size_t i;
>
> UHD_API uhd_error Status;
>
> uhd_subdev_spec_handle subdev=NULL;
>
> uhd_subdev_spec_pair_t subdev1={"A","A:A A:B"};
>
> uhd_subdev_spec_pair_t subdev2={"A","A:A A:B"};
>
> char markup[256]={0,0,0};
>
>
>
> time_t full_secs=1;
>
> double frac_secs=0.5;
>
>
>
> size_t count_channel=2; //!!!
>
> size_t channel_list[2];
>
> float *buff = NULL;
>
> float *buff1= NULL;
>
> float *buffers[2];
>
> memset((void*)&tune_request,0,sizeof(tune_request));
>
> channel_list[0]=0;
>
> channel_list[1]=1;
>
> if(uhd_set_thread_priority(uhd_default_thread_priority, true)){
>
> fprintf(stderr, "Unable to set thread priority. Continuing
> anyway.\n");
>
> }
>
>
>
> // Create USRP
>
> fprintf(stderr, "Creating USRP with args \"%s\"...\n", device_args);
>
> if(uhd_usrp_make(&usrp, device_args)!=UHD_ERROR_NONE)
>
> goto free_option_strings;
>
>
>
> if(subdev==NULL)
>
> Status=uhd_subdev_spec_make(&subdev, markup );
>
> if(subdev)
>
> {
>
> //! Check how many subdevice specifications are in this list
>
> Status=uhd_subdev_spec_size(subdev,&i);
>
> markup[0]=0;
>
> if(i) //! Get the subdevice specification at the given index
>
> {
>
> //! Get a string representation of the given list
>
> Status=uhd_subdev_spec_to_pp_string(subdev, markup, sizeof(markup)
> );
>
> //! Get the subdevice specification at the given index
>
> Status=uhd_subdev_spec_at(subdev,0,&subdev1);
>
> if(i>1)
>
> Status=uhd_subdev_spec_at(subdev,1,&subdev2);
>
> }
>
> //! Add a subdevice specification to this list
>
> //if(strstr(markup,"A:A A:B")==0)
>
> // Status=uhd_subdev_spec_push_back(subdev,"A:A A:B"); //Only One
> Channel after uhd_subdev_spec_to_pp_string
>
> if(strstr(markup,"A:A")==0)
>
> Status=uhd_subdev_spec_push_back(subdev,"A:A");
>
> if(strstr(markup,"A:B")==0)
>
> Status=uhd_subdev_spec_push_back(subdev,"A:B");
>
> //! Get a string representation of the given list
>
> Status=uhd_subdev_spec_to_pp_string(subdev, markup, sizeof(markup) );
>
> fprintf(stderr, "Setting subdev: %s...\n", markup);
>
> }
>
>
>
> // Create RX streamer
>
> if(uhd_rx_streamer_make(&rx_streamer)!=UHD_ERROR_NONE)
>
> goto free_usrp;
>
>
>
> // Create RX metadata
>
>
>
> if(uhd_rx_metadata_make(&md)!=UHD_ERROR_NONE)
>
> goto free_rx_streamer;
>
>
>
> // Create other necessary structs
>
> tune_request.target_freq = freq;
>
> tune_request.rf_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO;
>
> tune_request.dsp_freq_policy = UHD_TUNE_REQUEST_POLICY_AUTO;
>
>
>
> for(channel=0;channel<count_channel;channel++)
>
> {
>
> fprintf(stderr, " Setting Channel%d\n",channel);
>
> // Set rate
>
> fprintf(stderr, "Setting RX Rate: %f...\n", rate);
>
> if(uhd_usrp_set_rx_rate(usrp, rate, channel)!=UHD_ERROR_NONE)
>
> goto free_rx_metadata;
>
>
>
> // See what rate actually is
>
> if(uhd_usrp_get_rx_rate(usrp, channel, &rate)!=UHD_ERROR_NONE)
>
> goto free_rx_metadata;
>
> fprintf(stderr, "Actual RX Rate: %f...\n", rate);
>
>
>
> // Set gain
>
> fprintf(stderr, "Setting RX Gain: %f dB...\n", gain);
>
> if(uhd_usrp_set_rx_gain(usrp, gain, channel, "")!=UHD_ERROR_NONE)
>
> goto free_rx_metadata;
>
>
>
> // See what gain actually is
>
> if(uhd_usrp_get_rx_gain(usrp, channel, "", &gain)!=UHD_ERROR_NONE)
>
> goto free_rx_metadata;
>
> fprintf(stderr, "Actual RX Gain: %f...\n", gain);
>
>
>
> // Set frequency
>
> fprintf(stderr, "Setting RX frequency: %f MHz...\n", freq/1e6);
>
> if(uhd_usrp_set_rx_freq(usrp, &tune_request, channel,
> &tune_result)!=UHD_ERROR_NONE)
>
> goto free_rx_metadata;
>
>
>
> // See what frequency actually is
>
> if(uhd_usrp_get_rx_freq(usrp, channel, &freqR)!=UHD_ERROR_NONE)
>
> goto free_rx_metadata;
>
> fprintf(stderr, "Actual RX frequency: %f MHz...\n", freqR / 1e6);
>
> }
>
>
>
> // Set up streamer
>
> stream_args.cpu_format = "fc32";
>
> stream_args.otw_format = "sc16";
>
> stream_args.args = "";
>
> stream_args.channel_list = &channel_list[0];
>
> stream_args.n_channels = count_channel;
>
>
>
> if(uhd_usrp_get_rx_stream(usrp, &stream_args,
> rx_streamer)!=UHD_ERROR_NONE)
>
> goto free_rx_streamer;
>
>
>
> // Set up buffer
>
> if(uhd_rx_streamer_max_num_samps(rx_streamer,
> &samps_per_buff)!=UHD_ERROR_NONE)
>
> goto free_rx_streamer;
>
> fprintf(stderr, "Buffer size in samples: %zu\n", samps_per_buff);
>
> buff = malloc(samps_per_buff * 2 * sizeof(float));
>
> buff1 = malloc(samps_per_buff * 2 * sizeof(float));
>
> buffers[0]=buff;
>
> buffers[1]=buff1;
>
> buffs_ptr = (void**)buffers;
>
>
>
>
>
> stream_cmd.stream_mode = UHD_STREAM_MODE_NUM_SAMPS_AND_DONE;
>
> stream_cmd.num_samps = n_samples;
>
> //stream_cmd.stream_now =true;
>
> stream_cmd.stream_now =false; //With multiple devices false;
>
> stream_cmd.time_spec_full_secs=full_secs; //time_t //! If
> not now, then full seconds into future to stream
>
> stream_cmd.time_spec_frac_secs=frac_secs; //timeout; //! If not
> now, then fractional seconds into future to stream
>
> Status=uhd_usrp_set_time_now(usrp,full_secs, frac_secs, 0); //
> Status=10 ???
>
>
>
> // Issue stream command
>
> fprintf(stderr, "Issuing stream command.\n");
>
> if(uhd_rx_streamer_issue_stream_cmd(rx_streamer,
> &stream_cmd)!=UHD_ERROR_NONE)
>
> goto free_buffer;
>
>
>
> // Set up file output
>
> fp = fopen(filename, "wb");
>
>
>
> // Actual streaming
>
> while (num_acc_samps < n_samples) {
>
> size_t num_rx_samps = 0;
>
> if(uhd_rx_streamer_recv(rx_streamer, buffs_ptr, samps_per_buff,
> &md, 3.0, false, &num_rx_samps)!=UHD_ERROR_NONE)
>
> goto close_file;
>
> if(uhd_rx_metadata_error_code(md, &error_code)!=UHD_ERROR_NONE)
>
> goto close_file;
>
> if(error_code != UHD_RX_METADATA_ERROR_CODE_NONE){
>
> fprintf(stderr, "Error code 0x%x was returned during
> streaming. Aborting.\n", error_code);//return_code);
>
> goto close_file;
>
> }
>
>
>
> // Handle data
>
> fwrite(buff, sizeof(float) * 2, num_rx_samps, fp);
>
> fwrite(buff1, sizeof(float) * 2, num_rx_samps, fp);
>
> if (verbose) {
>
> time_t full_secs;
>
> double frac_secs;
>
> uhd_rx_metadata_time_spec(md, &full_secs, &frac_secs);
>
> fprintf(stderr, "Received packet: %zu samples, %zu full secs,
> %f frac secs\n",
>
> num_rx_samps,
>
> full_secs,
>
> frac_secs);
>
> }
>
>
>
> num_acc_samps += num_rx_samps;
>
> }
>
>
>
> // Cleanup
>
> close_file:
>
> fclose(fp);
>
>
>
> free_buffer:
>
> if(buff){
>
> if(verbose){
>
> fprintf(stderr, "Freeing buffer_0.\n");
>
> }
>
> free(buff);
>
> }
>
> buff = NULL;
>
> if(buff1){
>
> if(verbose){
>
> fprintf(stderr, "Freeing buffer_1.\n");
>
> }
>
> free(buff1);
>
> }
>
> buff1 = NULL;
>
> buffs_ptr = NULL;
>
>
>
> free_rx_streamer:
>
> if(verbose){
>
> fprintf(stderr, "Cleaning up RX streamer.\n");
>
> }
>
> uhd_rx_streamer_free(&rx_streamer);
>
>
>
> free_rx_metadata:
>
> if(verbose){
>
> fprintf(stderr, "Cleaning up RX metadata.\n");
>
> }
>
> uhd_rx_metadata_free(&md);
>
>
>
> free_usrp:
>
> if(verbose){
>
> fprintf(stderr, "Cleaning up USRP.\n");
>
> }
>
> if(return_code != EXIT_SUCCESS && usrp != NULL){
>
> uhd_usrp_last_error(usrp, error_string, 512);
>
> fprintf(stderr, "USRP reported the following error: %s\n",
> error_string);
>
> }
>
> uhd_usrp_free(&usrp);
>
>
>
> free_option_strings:
>
> if(strcmp(device_args,"")){
>
> free(device_args);
>
> }
>
> if(custom_filename){
>
> free(filename);
>
> }
>
>
>
> if(subdev) uhd_subdev_spec_free(&subdev); //Exception!!!
>
> subdev=NULL;
>
>
>
> fprintf(stderr, (return_code ? "Failure\n" : "Success\n"));
>
> return return_code;
>
> }
>
>
>
> Regards,
>
> Andrew.
>
>
>
> ---------- ??????????? ????????? ----------
>
> ?? ????: (mle...@ripnet.com)
>
> ????: 11.11.2016, 18:06:02
>
> ????: Re: [USRP-users] B210 C-API dual channel
>
> ????: ?????? 1 (andrew4...@rambler.ru)
>
> Re: [USRP-users] B210 C-API dual channel
>
> I think we're going to need to see the entirety of the part of your code
> that sets up the USRP to help spot the problem.
>
>
>
>
>
>
> On 2016-11-11 09:19, ?????? 1 via USRP-users wrote:
>
> Hello
>
>
>
> I call uhd_usrp_set_rx_subdev_spec after uhd_usrp_make with this
> arguments
>
> uhd_subdev_spec_pair_t subdev={"0","A:A A:B"};
>
> Status=uhd_usrp_set_rx_subdev_spec(usrp, (uhd_subdev_spec_handle*)&subdev,
> mboard);
>
> and have status = 0.
>
> But before this call i had
>
> get_rx_num_channels return num_channel = 2
>
> after uhd_usrp_set_rx_subdev_spec i have num_channel = 1
>
> Is it right for a phase-aligned channels rx with a single B210 ?
>
>
>
> Regards,
>
> Andrew.
>
>
>
> ---------- ??????????? ????????? ----------
>
> ?? ????: (mle...@ripnet.com)
>
> ????: 10.11.2016, 18:03:07
>
> ????: Re: [USRP-users] B210 C-API dual channel
>
> ????: ?????? 1 (andrew4...@rambler.ru)
>
> Re: [USRP-users] B210 C-API dual channel
>
> You'll also need to specify subdev of "A:A A:B"
>
>
>
>
>
>
> On 2016-11-10 09:18, ?????? 1 via USRP-users wrote:
>
>
> Hello
>
> I using C-API and rx_samples_c example by start point for
> write dual channel receiver(B210).
> I set size_t channels[2] = {0,1};
> uhd_stream_args_t stream_args = {
> .cpu_format = "fc32",
> .otw_format = "sc16",
> .args = "",
> .channel_list = &channels,
> .n_channels = 2
> };
> and setup frequency and gain in channels.
> But when I call uhd_rx_streamer_recv I have num_rx_samps = 0
> What other settings are needed to dual mode received
> except changes in the structure of stream_args.
>
> Regards,
> Andrew
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com <usrp-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com <usrp-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com <usrp-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161129/a4abee59/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 30 Nov 2016 09:10:42 +0100
From: Vladica Sark <vladicas...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] B205mini-i overfow error
Message-ID: <aa8e3e41-bcb9-5bd7-ee73-93d9784e4...@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Thanks Martin
On 30.11.2016 02:07, Martin Braun via USRP-users wrote:
> If you're doing NUM_SAMPS_AND_DONE (which you are), you need to
> re-trigger a stream command on overruns.
>
> Cheers,
> Martin
>
> On 11/23/2016 02:28 AM, Vladica Sark via USRP-users wrote:
>> Hi Martin,
>>
>> Should I only issue a stream command in order to recover forom this
>> situation?
>>
>> The thing is that I can live with one overflow each few minutes, but I
>> didn't succeed to recover from the situation.
>>
>> Anyway, I would try again to find a way for recovering.
>>
>> BR,
>> Vladica
>>
>>
>> On 23.11.2016 02:49, Martin Braun via USRP-users wrote:
>>> Vladica,
>>>
>>> we are confirming there are issues with these rates. However, it
>>> shouldn't be unrecoverable. You can try reducing the OTW format to sc8
>>> to reduce your USB bandwidth.
>>>
>>> Cheers,
>>> M
>>>
>>> On 11/15/2016 02:38 AM, Vladica Sark via USRP-users wrote:
>>>> Hi there,
>>>>
>>>> Anyone having experience with the overflow error in B205mini, when
>>>> sampling with 50 MSps?
>>>>
>>>> How to recover from it?
>>>>
>>>> BR,
>>>> Vladica
>>>>
>>>>
>>>>
>>>> -------- Forwarded Message --------
>>>> Subject: B205mini-i overfow error
>>>> Date: Fri, 11 Nov 2016 22:23:30 +0100
>>>> From: Vladica Sark <vladicas...@gmail.com>
>>>> To: usrp-users@lists.ettus.com <usrp-users@lists.ettus.com>
>>>>
>>>> Hi there,
>>>>
>>>> I have the following problem:
>>>> I schedule a reception of 550000 samples, every 20 ms. The code is:
>>>>
>>>> time_current = usrp->get_time_now();
>>>>
>>>> uhd::stream_cmd_t stream_cmd(
>>>> uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
>>>> stream_cmd.num_samps = 550000;
>>>> stream_cmd.stream_now = false;
>>>> stream_cmd.time_spec = time_current + uhd::time_spec_t(0.02);
>>>> rx_stream->issue_stream_cmd(stream_cmd);
>>>>
>>>> Further I wait for reception of the samples with:
>>>>
>>>> uhd::rx_metadata_t md;
>>>>
>>>> size_t num_rx_samps = rx_stream->recv(buffer,
>>>> 550000, md, 0.2, false);
>>>>
>>>> This runs in an infinite loop. The problem is that after some random
>>>> time, tens to thousands of seconds an overflow is detected.
>>>> First, between scheduling the reception and receiving the samples, I get
>>>> "O" on the screen, and than, I receive less than 550000 samples. No
>>>> error is reported at this time, and all flags in md (start_of_burst,
>>>> end_of_burst, more_fragments) are 0. I schedule next transmission by
>>>> issuing command, and when I try to receive the samples, rx_stream->recv
>>>> returns 0 samples and in md error I find error number 8 and
>>>> out_of_sequence is 0. There is no recovery from this situation, and I
>>>> must restart the program.
>>>>
>>>> When I detect this situation, my thread executes
>>>>
>>>> boost::this_thread::sleep(boost::posix_time::seconds(0.5));
>>>>
>>>> and waits for user input. Anyway, one CPU core is used 100%.
>>>>
>>>> I use 50 MSps, and the machine I use is intel core i5. Everything is
>>>> executed on Ubuntu 16.04.
>>>>
>>>> BR,
>>>> Vladica
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> USRP-users@lists.ettus.com
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 12
Date: Wed, 30 Nov 2016 18:06:30 +0800
From: liu Jong <jongliu1...@gmail.com>
To: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] CUSTOM FIFO
Message-ID:
<caeui2n0qgtifioenkjqgakb-6h-npvjrf_pwdfrrq-pzbc_...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
We build a grc file:file source??custom_rfnoc_fifo??file sink.
The file.bat over file sink saving was right,but the size missing about
40%.For example,the file source read a file.which was 600byte?but the file
sink saving file only about 360 byte.
something should set but we did not?
thank you.
best regards
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161130/2d8ae7b5/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 30 Nov 2016 11:57:29 +0100
From: Paolo Palana <p.pal...@itsystems.it>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] change the master clock rate on X310
Message-ID: <25377a38-c608-0d45-882b-7871faa06...@itsystems.it>
Content-Type: text/plain; charset=utf-8
Good morning to all the mailing list.
In two projects of mine I need in one case a 128 Mhz sample rate, why in
the other 64Mhz (decimation is not an option in this stage).
As far as I can understand looking at the schematics and looking through
the code,
the ADC clocks (I'm not interest in DACs) are provided from the output 8
and 9 of the lmk04816 chip.
The setup of this component is performed in the x300_clock_ctrl.cpp file.
I was able, reading x300_clock_ctrl.cpp and the lmk04816 datasheet, to
obtain the 128 Mhz I desired.
I tested it and it works. With this setup the variable master_clock_div
is 20.
Now I thought "Well I need 64Mhz? Just set the master_clock_div to 40".
I made my calculations and on the paper... that is so.
The problem is that with master_clock_div=40 I got the following error:
Error: RuntimeError: ADC Calibration Clock in FPGA failed to lock to
internal source.
Reading again the lmk04816 datasheet I discovered a difference within
the two divide values. Namely the former (master_clock_div=20) cause the
chip
to operate in normal mode, while the latter (master_clock_div=40) cause
the chip to operate in extended mode. As far as I can understand the
extended mode require some "precaution" during the setup and I think
this could be the source of my problem.
What I would ask is:
1) is my guess correct?
2) how can I setup the chip in extended mode?
Thank you for your attention.
------------------------------
Message: 14
Date: Wed, 30 Nov 2016 18:07:38 +0300
From: ty <tyrus...@gmail.com>
To: Michael West <michael.w...@ettus.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] libuhd issue on OpenBTS
Message-ID:
<cao-q7j7broumc2tv6344xxlkneesfzrctz-zgppzc5owcji...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Michael.
Thank you for your quick revert. Now, I installed from the binaries
provided by Ettus via ppa.
Should I grab the source instead and remove the pre-compiled installation?
I found it easier to work with the binaries.
Much appreciated.
On Wed, Nov 30, 2016 at 3:49 AM, Michael West <michael.w...@ettus.com>
wrote:
> Hi Tyrus,
>
> The call stack indicates that gethostid() is failing. That is a Linux
> system level error.
>
> The good news is that there are a couple workarounds:
>
> 1) Disable X300 support and re-build UHD. The failure is happening when
> trying to discover X300 devices, so you can simply disable that part of UHD
> if you do not plan on using X300 devices.
> 2) Add "type=usrp2" to the device arguments when creating the multi_usrp
> object. This will isolate the discovery to only N200 devices and skip
> running the X300 discovery. I am not familiar with the OpenBTS code, but
> it may require a OpenBTS code change.
>
> Hope this helps.
>
> Regards,
> Michael
>
>
>
> On Tue, Nov 29, 2016 at 2:35 AM, ty via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Good evening. My name is tyrus and I have the following set up;
>>
>> OpenBTS 5.0 build and installed
>>
>> I have Ubuntu 14.04 LTS installed and *UHD_003.010.git-34-g90b88a27*
>> installed. I am running this on a USRP N200 with a WRX Daughter board.
>>
>> Now, after following all the steps, I ran the following command getting
>> the following error:
>>
>> tyrus@the-jedi-council:/OpenBTS$ sudo ./transceiver
>>
>> **** Error in `./transceiver': free(): invalid pointer: 0x083cda64 ****
>>
>> I ran gdb against the transceiver and this was the output
>>
>> gdb) where
>> #0 0xb7fdd428 in __kernel_vsyscall ()
>> #1 0xb72d101b in poll () at ../sysdeps/unix/syscall-template.S:81
>> #2 0xb455f0a9 in send_dg (ansp2_malloced=0x0, resplen2=0x0,
>> anssizp2=0x0, ansp2=0x0, anscp=0xbfffded8, gotsomewhere=<synthetic
>> pointer>,
>> v_circuit=<synthetic pointer>, ns=0, terrno=0xbfffcee8,
>> anssizp=0xbfffcfa8, ansp=0xbfffcedc, buflen2=0, buf2=0x0, buflen=34,
>> buf=0xbfffcfc0 "X\354\001",
>> statp=0xb73a1fc0 <_res>) at res_send.c:1206
>> #3 __libc_res_nsend (statp=statp@entry=0xb73a1fc0 <_res>,
>> buf=buf@entry=0xbfffcfc0
>> "X\354\001", buflen=34, buf2=buf2@entry=0x0, buflen2=buflen2@entry=0,
>> ans=ans@entry=0xbfffdab0 "`7\374\260\001", anssiz=anssiz@entry=1024,
>> ansp=ansp@entry=0xbfffded8, ansp2=ansp2@entry=0x0, nansp2=nansp2@entry
>> =0x0,
>> resplen2=resplen2@entry=0x0, ansp2_malloced=ansp2_malloced@entry=0x0)
>> at res_send.c:576
>> #4 0xb455ce05 in __GI___libc_res_nquery (statp=statp@entry=0xb73a1fc0
>> <_res>, name=name@entry=0xbfffd1bb "the-jedi-council.", class=class@entry
>> =1,
>> type=type@entry=1, answer=answer@entry=0xbfffdab0 "`7\374\260\001",
>> anslen=anslen@entry=1024, answerp=answerp@entry=0xbfffded8,
>> answerp2=answerp2@entry=0x0,
>> nanswerp2=nanswerp2@entry=0x0, resplen2=resplen2@entry=0x0,
>> answerp2_malloced=answerp2_malloced@entry=0x0) at res_query.c:227
>> #5 0xb455d46b in __libc_res_nquerydomain (statp=statp@entry=0xb73a1fc0
>> <_res>, name=name@entry=0xbfffe80f "the-jedi-council",
>> domain=domain@entry=0xb73a2020 <_res+96> "", class=class@entry=1,
>> type=type@entry=1, answer=answer@entry=0xbfffdab0 "`7\374\260\001",
>> anslen=anslen@entry=1024, answerp=answerp@entry=0xbfffded8,
>> answerp2=answerp2@entry=0x0, nanswerp2=nanswerp2@entry=0x0,
>> resplen2=resplen2@entry=0x0,
>> answerp2_malloced=answerp2_malloced@entry=0x0) at res_query.c:591
>> #6 0xb455d97f in __GI___libc_res_nsearch (statp=0xb73a1fc0 <_res>,
>> name=name@entry=0xbfffe80f "the-jedi-council", class=class@entry=1,
>> type=type@entry=1,
>> answer=answer@entry=0xbfffdab0 "`7\374\260\001",
>> anslen=anslen@entry=1024,
>> answerp=answerp@entry=0xbfffded8, answerp2=answerp2@entry=0x0,
>> nanswerp2=nanswerp2@entry=0x0, resplen2=resplen2@entry=0x0,
>> answerp2_malloced=answerp2_malloced@entry=0x0) at res_query.c:421
>> #7 0xb7fc5222 in __GI__nss_dns_gethostbyname3_r (name=name@entry=0xbfffe80f
>> "the-jedi-council", af=af@entry=2, result=result@entry=0xbfffe7f8,
>> buffer=buffer@entry=0xbfffe3c0 "\377\002", buflen=buflen@entry=1024,
>> errnop=errnop@entry=0xb559f6a8, h_errnop=h_errnop@entry=0xbfffe7f4,
>> ttlp=ttlp@entry=0x0, canonp=canonp@entry=0x0) at
>> nss_dns/dns-host.c:192
>> #8 0xb7fc5591 in _nss_dns_gethostbyname_r (name=0xbfffe80f
>> "the-jedi-council", result=0xbfffe7f8, buffer=0xbfffe3c0 "\377\002",
>> buflen=1024, errnop=0xb559f6a8,
>> h_errnop=0xbfffe7f4) at nss_dns/dns-host.c:273
>> #9 0xb72f272b in __gethostbyname_r (name=0xbfffe80f "the-jedi-council",
>> resbuf=0xbfffe7f8, buffer=buffer@entry=0xbfffe3c0 "\377\002",
>> buflen=buflen@entry=1024,
>> result=0xbfffe7e8, h_errnop=0xbfffe7f4) at ../nss/getXXbyYY_r.c:266
>> #10 0xb72d8685 in gethostid () at ../sysdeps/unix/sysv/linux/get
>> hostid.c:104
>> #11 0xb7b647d4 in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003
>> #12 0xb7b7f20a in uhd::usrprio_rpc::usrprio_rpc_
>> client::usrprio_rpc_client(std::string, std::string) () from
>> /usr/lib/i386-linux-gnu/libuhd.so.003
>> #13 0xb7b835c4 in uhd::niusrprio::niusrprio_session::enumerate(std::string
>> const&, std::vector<uhd::usrprio_rpc::usrprio_device_info,
>> std::allocator<uhd::usrprio_rpc::usrprio_device_info> >&) () from
>> /usr/lib/i386-linux-gnu/libuhd.so.003
>> #14 0xb7a73d98 in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003
>> #15 0xb799f7f9 in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003
>> #16 0xb7bf68c4 in uhd::device::find(uhd::device_addr_t const&,
>> uhd::device::device_filter_t) () from /usr/lib/i386-linux-gnu/libuhd
>> .so.003
>> #17 0x0806ed69 in uhd_device::open (this=0x80f5cd0, args="",
>> extref=false) at UHDDevice.cpp:537
>> #18 0x0805586f in main (argc=1, argv=0xbffff7f4) at runTransceiver.cpp:158
>>
>> Anyone else experienced this?
>>
>> Thanks
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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/20161130/20486c69/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 75, Issue 27
******************************************
