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: Fwd: Daugther Board Manager Error - USRP2 - N210
(Riccardo Pace S231105)
2. Re: Fwd: Daugther Board Manager Error - USRP2 - N210
(Marcus M?ller)
3. B200mini: Rx-Gain from uhd_usrp_probe and manual differ
([email protected])
4. Re: E310 does not start after battery supply (Francois Quitin)
5. LFRX daughterboard with radio block (Barker, Douglas W.)
6. Re: USRP N210 + UBX 40 Daughterboard - Tx Power Issue
(Diez Victor)
7. USRP processing limits (Disco Daniele)
8. Re: USRP processing limits (Philip Balister)
9. Porting UHD to Zedboard w/Petalinux 2016.4 (Daryl Lee)
----------------------------------------------------------------------
Message: 1
Date: Mon, 08 May 2017 09:57:36 +0200
From: Riccardo Pace S231105 <[email protected]>
To: Marcus M?ller <[email protected]>, Usrp Users
<[email protected]>
Subject: Re: [USRP-users] Fwd: Daugther Board Manager Error - USRP2 -
N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
I tried to recompile and reinstall UHD, but the error persists. If I
change the daugther board with the BasicRx the uhd_usrp_probe command
works perfectly and also Gnuradio.
I checked also the library versions and are ok.
Do you know which libraries I have to check in particular?
Il 2017-05-04 16:40 Marcus M?ller via USRP-users ha scritto:
> If you built UHD yourself: Recompile, reinstall. I saw exactly that error
> when someone was mixing different library versions.
>
> On 05/03/2017 11:41 AM, Riccardo Pace S231105 via USRP-users wrote:
>
>> Hello,
>>
>> I'm trying to perform simply with Gnuradio a FFT using the USRP2 N210 with
>> the RFX2400.
>>
>> I encountered with this error but I don't know how to resolve it.
>>
>> [INFO] [UHD] linux; GNU C++ version 4.8.4; Boost_105400;
>> UHD_3.11.0.git-94-g5964adcd
>> N210
>> [INFO] [USRP2] Opening a USRP2/N-Series device...
>> [INFO] [USRP2] Current recv frame size: 1472 bytes
>> [INFO] [USRP2] Current send frame size: 1472 bytes
>> [ERROR] [DBMGR] The daughterboard manager encountered a recoverable error in
>> init.
>> Loading the "unknown" daughterboard implementations to continue.
>> The daughterboard cannot operate until this error is resolved.
>> LookupError: KeyError: key "0" not found in dict(i,
>> N14adf4360_regs_t17prescaler_value_tE) e until this error is resolved.
>>
>> Is it a problem of UHD version?
>>
>> Can anyone help me?
>>
>> Thanks in advance.
>>
>> Regards,
>>
>> Riccardo.
>>
>> _______________________________________________
>> 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/20170508/5a4f9809/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 8 May 2017 10:22:44 +0200
From: Marcus M?ller <[email protected]>
To: Riccardo Pace S231105 <[email protected]>, Usrp Users
<[email protected]>
Subject: Re: [USRP-users] Fwd: Daugther Board Manager Error - USRP2 -
N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Ricardo,
the error that I saw with another user was simply that the linker linked
together .o files from different compilation runs, and that presumably
led to confusion with regards to function parameters.
I'll look into your case separately. Will be getting in touch with you
off-list.
Best regards,
Marcus
On 08.05.2017 09:57, Riccardo Pace S231105 wrote:
>
> I tried to recompile and reinstall UHD, but the error persists. If I
> change the daugther board with the BasicRx the uhd_usrp_probe command
> works perfectly and also Gnuradio.
>
> I checked also the library versions and are ok.
>
> Do you know which libraries I have to check in particular?
>
> Il 2017-05-04 16:40 Marcus M?ller via USRP-users ha scritto:
>
>> If you built UHD yourself: Recompile, reinstall. I saw exactly that
>> error when someone was mixing different library versions.
>>
>>
>>
>> On 05/03/2017 11:41 AM, Riccardo Pace S231105 via USRP-users wrote:
>>>
>>> Hello,
>>>
>>> I'm trying to perform simply with Gnuradio a FFT using the USRP2
>>> N210 with the RFX2400.
>>>
>>> I encountered with this error but I don't know how to resolve it.
>>>
>>> [INFO] [UHD] linux; GNU C++ version 4.8.4; Boost_105400;
>>> UHD_3.11.0.git-94-g5964adcd
>>> N210
>>> [INFO] [USRP2] Opening a USRP2/N-Series device...
>>> [INFO] [USRP2] Current recv frame size: 1472 bytes
>>> [INFO] [USRP2] Current send frame size: 1472 bytes
>>> [ERROR] [DBMGR] The daughterboard manager encountered a recoverable
>>> error in init.
>>> Loading the "unknown" daughterboard implementations to continue.
>>> The daughterboard cannot operate until this error is resolved.
>>> LookupError: KeyError: key "0" not found in dict(i,
>>> N14adf4360_regs_t17prescaler_value_tE) e until this error is resolved.
>>>
>>> Is it a problem of UHD version?
>>>
>>> Can anyone help me?
>>>
>>> Thanks in advance.
>>>
>>> Regards,
>>>
>>> Riccardo.
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>> _______________________________________________
>> 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/20170508/df1bb0eb/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 8 May 2017 09:38:30 +0000
From: <[email protected]>
To: <[email protected]>
Subject: [USRP-users] B200mini: Rx-Gain from uhd_usrp_probe and manual
differ
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello to everyone,
I had a look at the B200mini manual and knowledge base (KB) for the maximum
RX-Gain: the manual states +73dB as maximum, as well as the KB. However,
uhd_usrp_probe returns a maximum RX-gain of +76dB.
Does someone know where this difference comes from? Maybe a typo?
Regards,
Emanuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170508/01dbfd22/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 08 May 2017 13:43:47 +0200
From: Francois Quitin <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] E310 does not start after battery supply
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Philip,
We reflashed the SD card, and everything worked fine again.
Thanks!
Fran?ois
On 05.05.2017 16:56, Philip Balister via USRP-users wrote:
> On 05/05/2017 07:46 AM, gauthier duchene via USRP-users wrote:
>> Hi,
>>
>> I have a problem with my E310 since my last experiment. I was taking
>> measurements outside so I used a battery ( 7.2V 4000mAh) to supply the
>> radio. The tests were longer than expected and the battery was
>> completely
>> discharged. I used the radio as an emitter with an autorun code so no
>> computer was plugged in.
>>
>> Since then, the radio is not working, even with the original power
>> supply. The leds are lit at the beginning but I do not have anything
>> after
>> that. My autorun code is not working and I can not connect by
>> ethernet.
>>
>> Has anyone ever had a similar problem? Or an idea of how I could solve
>> it?
>
> Do the LED's "blink" when you turn it on? If so it means the safe fpga
> image is loading, which means lots of stuff is working. If they stay
> on,
> it means no fsbl.
>
> In both cases, I'd try with a new card from the current factory image.
>
> Philip
>
>>
>>
>>
>> Thanks and Regards
>>
>>
>> Gauthier
>>
>>
>>
>>
>> _______________________________________________
>> 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
---
Francois QUITIN
Assistant Professor
BEAMS Dpt. ? Embedded Electronics
Brussels School of Engineering
Universit? Libre de Bruxelles (ULB)
Web https://sites.google.com/site/fquitin2/
Phone +32 2 650 2829
------------------------------
Message: 5
Date: Mon, 8 May 2017 14:25:46 +0000
From: "Barker, Douglas W." <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] LFRX daughterboard with radio block
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hello,
I'm using the LFRX daughterboard on the X310. In gnuradio I connect the rfnoc
radio block to my custom rfnoc block and from there to the host. The sample
rate of the radio block is set to 200M. In my custom noc block I connect the
output of noc_shell -> chdr_deframer. On the output of the chdr_deframer I'm
expecting 200 Msps data, thus the 'o_tvalid' signal should be continuously high
(I've got the 'o_tready' tied high).
That's not what I get though. The rate coming in is only a small fraction of
200 Msps. When I monitor the transactions at the input to the noc block
(i_tdata, i_tvalid, etc) I see the same behavior. The AXI packets are all in
sequence so none are discarded. Can anyone tell me what is going on??
Thanks
Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170508/6c764e14/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 8 May 2017 14:29:36 +0000
From: Diez Victor <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP N210 + UBX 40 Daughterboard - Tx Power
Issue
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Yes, I have done it and the same result has been obtained. I?m going to send a
support request to [email protected]<mailto:[email protected]> .
Thanks all of you for your help,
V?ctor
De: [email protected] [mailto:[email protected]]
Enviado el: viernes, 5 de mayo de 2017 16:13
Para: Diez Victor
CC: [email protected]
Asunto: Re: [USRP-users] USRP N210 + UBX 40 Daughterboard - Tx Power Issue
One last question:
Have you tried a simple narrowband CW carrier instead, using tx_waveforms?
The next step after that would be to create a support request by sending an
email to [email protected]<mailto:[email protected]>.
On 2017-05-05 02:17, Diez Victor via USRP-users wrote:
Yes, I have done it. I have replaced the wires too and I have bypassed it
connecting directly the tx output of the daughterboard to the spectrum
analyzer, but nothing changes.
De: Marcus D. Leech [mailto:[email protected]]
Enviado el: jueves, 4 de mayo de 2017 17:18
Para: Diez Victor
Asunto: Re: [USRP-users] USRP N210 + UBX 40 Daughterboard - Tx Power Issue
Have you checked the internal cabling between the daughtercard and front panel?
Sent from my iPhone
On May 4, 2017, at 10:15 AM, Diez Victor via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hello,
I'm trying to generate white gaussian noise with GNU Radio and a USRP N210+UBX
40 Daughterboard. I've observed that transmission power is constant at
approximately -53dBm, regardless of the transmission gain value and the
wireless band. In reception, all works fine.
I have checked my usrp according to the steps indicated in
https://kb.ettus.com/Verifying_the_Operation_of_the_USRP_Using_UHD_and_GNU_Radio.
I've executed in the console the" tx_samples_c" and the "tx_samples_from_file"
scripts located at "/usr/local/lib/uhd/examples". In both cases, I've obtained
the same transmission power. The modification of the transmission gain, the
carrier frequency and the transmission rate values didn't cause any change.
Looking for a solution, I read another post about the powersave mode but if I
execute the command "uhd_usrp_probe --string
/mboards/0/dboards/A/tx_frontends/0/power_mode/value", the console returns
"performance" so I suppose the energy mode isn't the problem.
The issue persist independently of the operating system. I have used a machine
with Ubunu 16.04 installed, a GNU-Radio live USB pendrive and Matlab/Simulink
in a Windows 10 machine. I've tried 2 different version of UHD driver, the
UHD_003.009.006-0-g122d5f8e and the UHD_003.010.001.HEAD-0-gc705922a. Also I
have flashed the USRP, firmware and FPGA image, and I continue with the same
problem. The physical connections of the USRP and the daughterboard have been
checked as well.
Could someone help me to solve this issue with the transmission power of my
device?
Thanks in advance,
V?ctor
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
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/20170508/c87fab35/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 8 May 2017 14:39:06 +0000
From: Disco Daniele <[email protected]>
To: "[email protected] ([email protected])"
<[email protected]>
Subject: [USRP-users] USRP processing limits
Message-ID:
<cd4b4cde04a84913816f3f6f280f0bfe@TELMBXD07BA020.telecomitalia.local>
Content-Type: text/plain; charset="iso-8859-1"
Hi to all!
There is a way to understand if an USRP is unable to provide more resources?
In other words, I'm trying to implement on E310 a multi threads process and
what I would to know is if the device is giving all what it can or there is
space for tuning some parameters.
Could be the profiling a possibility to understand better the behavior of the
USRP?
The procedure to profile is similar to that of another linux box or I have to
do some specific operations?
Thank you in advance
_____________________________________________
[logo1]
Daniele Disco
Engeenering & Tilab - Wireless Access
Wireless Innovation
Via Reiss Romoli, 274 - 10148 Torino
tel . +39 011 228 7271
cell. +39 331 600 1113
Fax. +39 06 4186 5196
Tim Official: Facebook<https://www.facebook.com/TimOfficialPage> -
Twitter<https://twitter.com/tim_official>
www.tim.it<http://www.tim.it/>
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate
ricevuto questo documento per errore siete cortesemente pregati di darne
immediata comunicazione al mittente e di provvedere alla sua distruzione,
Grazie.
This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the sender
by return e-mail, Thanks.
Rispetta l'ambiente. Non stampare questa mail se non ? necessario.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170508/204be3c2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2519 bytes
Desc: image001.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170508/204be3c2/attachment-0001.jpg>
------------------------------
Message: 8
Date: Mon, 8 May 2017 08:51:32 -0600
From: Philip Balister <[email protected]>
To: Disco Daniele <[email protected]>,
"[email protected] ([email protected])"
<[email protected]>
Subject: Re: [USRP-users] USRP processing limits
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 05/08/2017 08:39 AM, Disco Daniele via USRP-users wrote:
> Hi to all!
> There is a way to understand if an USRP is unable to provide more resources?
> In other words, I'm trying to implement on E310 a multi threads process and
> what I would to know is if the device is giving all what it can or there is
> space for tuning some parameters.
>
> Could be the profiling a possibility to understand better the behavior of the
> USRP?
> The procedure to profile is similar to that of another linux box or I have to
> do some specific operations?
perf top should help.
Philip
>
> Thank you in advance
>
> _____________________________________________
> [logo1]
> Daniele Disco
> Engeenering & Tilab - Wireless Access
> Wireless Innovation
> Via Reiss Romoli, 274 - 10148 Torino
> tel . +39 011 228 7271
> cell. +39 331 600 1113
> Fax. +39 06 4186 5196
> Tim Official: Facebook<https://www.facebook.com/TimOfficialPage> -
> Twitter<https://twitter.com/tim_official>
> www.tim.it<http://www.tim.it/>
>
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
>
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
> printing or use by anybody else is unauthorised. If you are not the intended
> recipient, please delete this message and any attachments and advise the
> sender by return e-mail, Thanks.
>
> Rispetta l'ambiente. Non stampare questa mail se non ? necessario.
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 9
Date: Mon, 8 May 2017 09:03:29 -0600
From: Daryl Lee <[email protected]>
To: [email protected]
Subject: [USRP-users] Porting UHD to Zedboard w/Petalinux 2016.4
Message-ID:
<caeu-dvj7ux487k6x78dmv_xhnxcei7dxeuujpjc03umlmxm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
When I first started my UHD-on-Zynq journey in November, I was using
Petalinux 2015.4. This meant that I was using Xilinx's proprietary tools,
and it turns out that porting UHD to the Zedboard was straightforward: just
build libusb, Boost, and UHD with the right compiler and copy the finished
product to the target environment. Now that I have upgraded to Petalinux
2016.4, which is based on Yocto, the process seems a bit more obscure. I
have no doubt it will be better once I make the transition, but getting
there is a challenge. Can someone point me to a good resource for
implementing UHD (which means also libusb-1.0 and Boost) to a Zedboard
using Petalinux 2016.4?
--
*Daryl O. Lee*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170508/4871a98e/attachment-0001.html>
------------------------------
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 81, Issue 8
*****************************************
