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: Phase variations in B210 at particular center frequencies
(Ian Buckley)
2. USRP-n210: Expected FPGA compatibility number 10, but got 16 (???)
3. Re: [USRP B210] explanation of "U", "L", "S"and "O", etc.
(Neel Pandeya)
4. Re: A question about temperature sensor on USRP-B200mini?
(Michael West)
5. Re: A question about temperature sensor on USRP-B200mini?
(Marcus D. Leech)
6. Re: A question about temperature sensor on USRP-B200mini?
(Michael West)
7. Re: Phase variations in B210 at particular center frequencies
(Jeremy Hershberger)
8. Re: Windows UHD BInary --> FPGA Compatibility Number 14
(Beaudoin, Christopher J)
9. Re: Phase variations in B210 at particular center frequencies
(Martin Braun)
10. Re: Reg : nsamps_per_buff in UHD (Martin Braun)
11. Waveform received from USRP2 freezes (Nik B.)
----------------------------------------------------------------------
Message: 1
Date: Thu, 7 Jul 2016 10:13:14 -0700
From: Ian Buckley <i...@ionconcepts.com>
To: Jeremy Hershberger <jeremy.l.hershberger...@nd.edu>
Cc: Ron Economos <w...@comcast.net>, usrp-users
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Phase variations in B210 at particular
center frequencies
Message-ID:
<CAM_0ocFZx8Mt0GBO8OKOfb6YrgXDBnFo=-ggmm0qxa-qros...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
FWIW I've seen stuff like this before related to this particular RFIC, and
my tendency is to look to the (in built) DC offset and IQ balance functions
which are real-time adaptive in nature...IQ balance in particular in this
case given that has a direct affect on phase.
There's a few test's I might run to learn a little more.
I've seen the gain settings directly relate to effects like this, so I
might try walking through a few gains with all else constant.
Another thing that might be interesting is rather than slowly slew the
center frequency, instead ping-pong it to a value thats "far" away
(>100MHz) then back to your desired next step...the reason for this is that
subtle retunings do not cause all IQ balance routines to be rerun, but
large retuning ranges do....so something like 915.0 -> 2000.0 -> 915.01
might be informative.
Lastly it might be wise to use a full manual tuning policy and explicitly
control use of the CORDIC (force it to zero)...this will increase tuning
granularity but you will be able to record what actual frequency the RF
synthesizer is programmed to.
my 1 cents...
-Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160707/0f7abd35/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 7 Jul 2016 18:10:55 +0800
From: ??? <wang...@outlook.com>
To: <usrp-users@lists.ettus.com>
Subject: [USRP-users] USRP-n210: Expected FPGA compatibility number
10, but got 16
Message-ID: <blu404-eas409af9c4bc5558abb341943a3...@phx.gbl>
Content-Type: text/plain; charset="gb2312"
Hello community,
There seems to be software compatibility issue between the host (ubuntu
16.04) uhd build and USRP N210 FPGA image.
The Runtime errors are captured as:------------------------------
wsn1@wsn1-ThinkPad-X200 ~> uhd_usrp_probe
linux; GNU C++ version 5.3.1 20160413; Boost_105800;
UHD_003.010.000.git-249-gef57ffcb
-- Opening a USRP2/N-Series device...
Error: RuntimeError:
Please update the firmware and FPGA images for your device.
See the application notes for USRP2/N-Series for instructions.
Expected FPGA compatibility number 10, but got 16:
The FPGA build is not compatible with the host code build.
But when I download images by running uhd_images_downloader, then run
uhd_image_loader ,the error is captured as :-----------
wsn1@wsn1-ThinkPad-X200 ~> uhd_image_loader --args="type=usrp2,addr=192.
168.10.2"
linux; GNU C++ version 5.3.1 20160413; Boost_105800;
UHD_003.010.000.git-249-gef57ffcb
Error: RuntimeError: Received invalid reply 32 from device.
----------------------------------------------------------------------------
---------------
I don't know what the reason is. Can youhelp me!
Thanks,
Wangerw
------------------------------
Message: 3
Date: Thu, 7 Jul 2016 11:09:04 -0700
From: Neel Pandeya <neel.pand...@ettus.com>
To: "David Yu ( III )" <w...@iii.org.tw>
Cc: usrp-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] [USRP B210] explanation of "U", "L", "S"and
"O", etc.
Message-ID:
<CACaXmv8+9FstaEK=vynLUgbcvim-zcVLEyfaFp3gNfwRxeyV=g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello David:
Let's please keep this conversation on the mailing list.
Yes, those single-letter error codes apply to the B200/B210 too, as well as
to the N200/N210 and X300/X310.
--Neel
On 6 July 2016 at 20:16, David Yu ( III ) <w...@iii.org.tw> wrote:
> Hi Neel,
> Thank you.
> But I saw that this page is for X3x0 series.
> Is it suitable for B2x0 series too?
>
> David Yu
>
> -----Original Message-----
> From: Neel Pandeya [mailto:neel.pand...@ettus.com]
> Sent: Thursday, July 07, 2016 11:01 AM
> To: David Yu ( III )
> Cc: usrp-users
> Subject: Re: [USRP-users] [USRP B210] explanation of "U", "L", "S"and "O",
> etc.
>
> There is documentation at the bottom of this page:
> http://files.ettus.com/manual/page_usrp_x3x0_config.html
>
>
> --Neel
>
>
>
>
> On 6 July 2016 at 16:57, David Yu ( III ) via USRP-users <
> usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com> > wrote:
>
>
> Hi Ettus,
> When used USRP B210, we sometimes get "U", "L", "S", "O" letters
> printed in
> screen.
> Could you explain what these letters mean for detail? Any
> documents can be
> provided to me about these and other possible letters
> explanation/definition
> we could get from USRP B210?
> Thanks a lot.
>
> Best Regards,
> David Yu
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160707/38322f2a/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 7 Jul 2016 11:46:51 -0700
From: Michael West <michael.w...@ettus.com>
To: Charlie Von <charlie_...@msn.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] A question about temperature sensor on
USRP-B200mini?
Message-ID:
<cam4xkrpz0y0gp04ijsqiuwesu9uws_bfstw--h6ts-y1fdi...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Something like this should work:
double temp =
usrp->get_device()->get_tree()->access<sensor_value_t>("/mboards/0/dboards/A/rx_frontends/A/sensors/temp").get().to_real();
Regards,
Michael
On Thu, Jul 7, 2016 at 12:07 AM, Charlie Von via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Dear customer service of Ettus,
>
>
>
> I have a question for consultation about programming on USRP-B200mini.
>
> I program for USRP-B200mini on Microsoft Viusal Studio 2010 using UHD API
> which downloaded from Github.
>
>
>
> Is there any temperature sensor on USRP-B200mini board or AD9361/AD9364?
>
> How can I get the temperature by UHD API?
>
> Could you give me the program example code?
>
>
>
> I will be very grateful if you can give me a feedback.
>
>
>
> sincerely Charlie
>
> China National Institution of Radio and Spectrum Management
>
>
> sincerely Charlie
>
> _______________________________________________
> 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/20160707/f0d71f15/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 07 Jul 2016 14:54:09 -0400
From: "Marcus D. Leech" <mle...@ripnet.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] A question about temperature sensor on
USRP-B200mini?
Message-ID: <577ea551....@ripnet.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 07/07/2016 02:46 PM, Michael West via USRP-users wrote:
> Something like this should work:
>
> double temp =
> usrp->get_device()->get_tree()->access<sensor_value_t>("/mboards/0/dboards/A/rx_frontends/A/sensors/temp").get().to_real();
>
> Regards,
> Michael
That sensor is inside the AD9361, rather than on the board?
Presumably, it's there to guide some of its calibration algorithms, both
for the charge-pump, and the gain settings?
>
> On Thu, Jul 7, 2016 at 12:07 AM, Charlie Von via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>
> Dear customer service of Ettus,
>
> I have a question for consultation about programming on USRP-B200mini.
>
> I program for USRP-B200mini on Microsoft Viusal Studio 2010 using
> UHD API which downloaded from Github.
>
> Is there any temperature sensor on USRP-B200mini board or
> AD9361/AD9364?
>
> How can I get the temperature by UHD API?
>
> Could you give me the program example code?
>
> I will be very grateful if you can give me a feedback.
>
> sincerely Charlie
>
> China National Institution of Radio and Spectrum Management
>
>
>
> sincerely Charlie
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> 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/20160707/9779a08a/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 7 Jul 2016 12:19:39 -0700
From: Michael West <michael.w...@ettus.com>
To: "Marcus D. Leech" <mle...@ripnet.com>
Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] A question about temperature sensor on
USRP-B200mini?
Message-ID:
<CAM4xKrpUbCpDyj_E+CTKx=5vBvTxbxY5+WBFD=rzo8-3+i1...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Yes, the sensor is inside the AD9361. I don't know the exact purpose, but
I'm sure it is there for some type of calibration.
Regards,
Michael
On Thu, Jul 7, 2016 at 11:54 AM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:
> On 07/07/2016 02:46 PM, Michael West via USRP-users wrote:
>
> Something like this should work:
>
> double temp =
> usrp->get_device()->get_tree()->access<sensor_value_t>("/mboards/0/dboards/A/rx_frontends/A/sensors/temp").get().to_real();
>
> Regards,
> Michael
>
> That sensor is inside the AD9361, rather than on the board?
>
> Presumably, it's there to guide some of its calibration algorithms, both
> for the charge-pump, and the gain settings?
>
>
>
> On Thu, Jul 7, 2016 at 12:07 AM, Charlie Von via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Dear customer service of Ettus,
>>
>>
>>
>> I have a question for consultation about programming on USRP-B200mini.
>>
>> I program for USRP-B200mini on Microsoft Viusal Studio 2010 using UHD API
>> which downloaded from Github.
>>
>>
>>
>> Is there any temperature sensor on USRP-B200mini board or AD9361/AD9364?
>>
>> How can I get the temperature by UHD API?
>>
>> Could you give me the program example code?
>>
>>
>>
>> I will be very grateful if you can give me a feedback.
>>
>>
>>
>> sincerely Charlie
>>
>> China National Institution of Radio and Spectrum Management
>>
>>
>> sincerely Charlie
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
> _______________________________________________
> USRP-users mailing
> listUSRP-users@lists.ettus.comhttp://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/20160707/2aad5cbf/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 7 Jul 2016 15:25:37 -0400
From: Jeremy Hershberger <jeremy.l.hershberger...@nd.edu>
To: Ian Buckley <i...@ionconcepts.com>
Cc: Ron Economos <w...@comcast.net>, usrp-users
<usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Phase variations in B210 at particular
center frequencies
Message-ID:
<CAMZiKLo7aMXLtz=p-balzmj7+nh8vlwtabcaaabfnnxhwan...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Ian,
My first thought was the IQ and DC corrections. In my application I
actually turn these off after letting the chip run for a second or two, but
before I collect data. However, this phase variation problem is preset in
the data regardless of whether I leave the corrections on or off.
I have also tried disabling the CORDIC blocks by setting the
uhd::tune_request.dsp_freq_policy = uhd::tune_reqeuest_t::POLICY_NONE. No
change.
I am unsure how to disable the IQ/DC corrections and CORDIC tuning in
GNUradio, but I can confirm using C++ that these attributes don't make any
difference.
As far as the gain is concerned, I tried adjusting the tx gain up while
also adjusting the rx gain down (to prevent loss of SNR) and still found no
improvement.
Any other thoughts?
-Jeremy
On Thu, Jul 7, 2016 at 1:13 PM, Ian Buckley <i...@ionconcepts.com> wrote:
> FWIW I've seen stuff like this before related to this particular RFIC, and
> my tendency is to look to the (in built) DC offset and IQ balance functions
> which are real-time adaptive in nature...IQ balance in particular in this
> case given that has a direct affect on phase.
>
> There's a few test's I might run to learn a little more.
>
> I've seen the gain settings directly relate to effects like this, so I
> might try walking through a few gains with all else constant.
>
> Another thing that might be interesting is rather than slowly slew the
> center frequency, instead ping-pong it to a value thats "far" away
> (>100MHz) then back to your desired next step...the reason for this is that
> subtle retunings do not cause all IQ balance routines to be rerun, but
> large retuning ranges do....so something like 915.0 -> 2000.0 -> 915.01
> might be informative.
>
> Lastly it might be wise to use a full manual tuning policy and explicitly
> control use of the CORDIC (force it to zero)...this will increase tuning
> granularity but you will be able to record what actual frequency the RF
> synthesizer is programmed to.
>
> my 1 cents...
> -Ian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160707/bf24fc27/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 7 Jul 2016 19:38:55 +0000
From: "Beaudoin, Christopher J" <christopher_beaud...@uml.edu>
To: "ti...@comcast.net" <ti...@comcast.net>
Cc: usrp-users <usrp-users@lists.ettus.com>, "Beaudoin, Christopher J"
<christopher_beaud...@uml.edu>, Derek Kozel <derek.ko...@ettus.com>
Subject: Re: [USRP-users] Windows UHD BInary --> FPGA Compatibility
Number 14
Message-ID:
<80d3bcacc0d6c740bc6df9c4df5f0a8f479a8...@lexus.fs.uml.edu>
Content-Type: text/plain; charset="utf-8"
That's probably true if you have a purchased copy of VS 2015 but my free
version will not start or "sign in" without an internet connection not that the
evaluation period has ended. If you are indeed referring to the free version, I
would be grateful if you could tell me what I am missing or if there is a work
around.
Chris
On Jul 7, 2016 9:02 AM, ti...@comcast.net wrote:
VS 2015 does not require an internet connection.
If you have one, you can store personal settings within the cloud and access
them remotely, but it is not required...
________________________________
From: "Derek Kozel via USRP-users" <usrp-users@lists.ettus.com>
To: "Christopher J Beaudoin" <christopher_beaud...@uml.edu>
Cc: "usrp-users" <usrp-users@lists.ettus.com>
Sent: Wednesday, July 6, 2016 6:02:32 PM
Subject: Re: [USRP-users] Windows UHD BInary --> FPGA Compatibility Number 14
Hi Chris,
I hadn't looked into it, but it does seem that Visual Studio 2015 requires an
internet connection, that's unfortunate. I know that others have gone the
Cygwin/MinGW path successfully, but I have not tried it. If you are going to
compile a Windows application you will need to get one of these build systems
working though and linking between compilers is usually unsuccessful. The free
versions of Visual Studio all require occasional internet access to extend
their activation license unfortunately to the best of my knowledge. If never
having an internet connection to your build environment is a hard requirement
then you may have to consider building your application on a different machine
using Visual Studio or hopefully someone will comment with experience building
UHD in Cygwin.
The B2x0 checks are implemented here. The B200 series USRPs have both firmware
and FPGA images so both are checked.
https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/b200/b200_impl.cpp#L943<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_EttusResearch_uhd_blob_master_host_lib_usrp_b200_b200-5Fimpl.cpp-23L943&d=CwMFaQ&c=lqHimbpwJeF7VTDNof4ddl8H-RbXeAdbMI2MFE1TXqA&r=FFv-Tkks2JDS32C5YcfWwV5muqJKHZT4w4ADbsqe3VE&m=bW3EOXExjw4xCIjtpT_QJoR_OkBxWD4Wci1d0Xcbh60&s=LrCRVwWRlshcLSjo2vO-TLboS5bSjseMQ-wkWfOHVj4&e=>
Cheating the compatibility check is a quick way to potentially major problems.
UHD deals very directly with the hardware and peripherals and if it doesn't
know what version of the firmware/FPGA it is communicating with it will likely
not work (we change the compat versions when we make breaking changes) and may
misconfigure various systems.
I certainly recommend using a specific stable release version for doing custom
HDL development. The last thing you want is something changing in the UHD code
and breaking your customizations.
Regards,
Derek
On Wed, Jul 6, 2016 at 1:58 PM, Beaudoin, Christopher J
<christopher_beaud...@uml.edu<mailto:christopher_beaud...@uml.edu>> wrote:
Hi Derek,
Thanks for the reply. Also forgot to mention I'm working with the B210.
It's been a while since I was attempting to compile the UHD software on
Windows. I found the Linux dev path more straightforward so that's what I've
been doing until recently; I'm faced with the need for a Windows application.
When I was trying to build on Windows, I was going down the minGW path because
it has a bit of Linux feel and the free version of Visual Studio (unless I'm
mistaken) requires an internet connection. Our compilation machine doesn't have
an internet connection.
I can't recall the problem exactly but I was unable to get Cmake to interface
with minGW. I think it was some sort of syntax issue or I didn't have one of
the settings g in minGW configured properly. Anyhow, I resorted to a pure Linux
build and that was very straightforward.
I guess I'll just download the last tagged release and modify that Verilog code
with my customizations so the latest Windows UHD binary will digest it.
Out of curiosity, is the COMPAT_MAJOR Verilog parameter in b200_core.v the sole
check that the UHD software confirms? I ask because I tried to cheat (mainly to
confirm my understanding of the compatibility issue) the UHD software by
decrementing this parameter and recompiling the image but the UHD software
wasn't fooled.
Thanks again,
Chris
Sent from my Verizon Wireless 4G LTE DROID
On Jul 6, 2016 4:34 PM, Derek Kozel
<derek.ko...@ettus.com<mailto:derek.ko...@ettus.com>> wrote:
Hello Chris,
We produce binary installers for each stable release. The latest, 3.9.4, is
located here:
http://files.ettus.com/binaries/uhd/latest_stable/<https://urldefense.proofpoint.com/v2/url?u=http-3A__files.ettus.com_binaries_uhd_latest-5Fstable_&d=CwMFaQ&c=lqHimbpwJeF7VTDNof4ddl8H-RbXeAdbMI2MFE1TXqA&r=FFv-Tkks2JDS32C5YcfWwV5muqJKHZT4w4ADbsqe3VE&m=y43TUyv3U8a--lpYyrf9XMvStKEgZ7rNI7fgKreLUJE&s=QPbTRCoTrXgHyJOit0-EYGVkgdjvMz2YPGAwfKVyer8&e=>
What problems were you having with CMake? What version of Windows and Visual
Studio are you using? We have our Windows build guide here:
https://kb.ettus.com/Building_and_Installing_the_USRP_Open_Source_Toolchain_(UHD_and_GNU_Radio)_on_Windows<https://urldefense.proofpoint.com/v2/url?u=https-3A__kb.ettus.com_Building-5Fand-5FInstalling-5Fthe-5FUSRP-5FOpen-5FSource-5FToolchain-5F-28UHD-5Fand-5FGNU-5FRadio-29-5Fon-5FWindows&d=CwMFaQ&c=lqHimbpwJeF7VTDNof4ddl8H-RbXeAdbMI2MFE1TXqA&r=FFv-Tkks2JDS32C5YcfWwV5muqJKHZT4w4ADbsqe3VE&m=y43TUyv3U8a--lpYyrf9XMvStKEgZ7rNI7fgKreLUJE&s=SQVWOSXC5D-uB2yAT8ySQaw1zijyavc64LRWnF1MXE4&e=>
However we know it isn't perfect and are always looking for reports on where it
isn't correct for a certain combination of OS and Visual Studio versions.
Regards,
Derek
On Wed, Jul 6, 2016 at 12:11 PM, Beaudoin, Christopher J via USRP-users
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote:
Hi,
It appears that the latest version of the FPGA source code is at
compatibility number 14 as is the UHD source code but not the Windows 32-bit
UHD binary/installer. I gave up trying to set up the MSVC environment to build
the UHD binary from source (couldn?t get Cmake to play nicely) so I?m hoping
there is a later version of the Windows binary coming.
-Chris
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com&d=CwMFaQ&c=lqHimbpwJeF7VTDNof4ddl8H-RbXeAdbMI2MFE1TXqA&r=FFv-Tkks2JDS32C5YcfWwV5muqJKHZT4w4ADbsqe3VE&m=y43TUyv3U8a--lpYyrf9XMvStKEgZ7rNI7fgKreLUJE&s=qTrKU3jEo5WHJd3BJVCk0YLtcxNsw43tUm5LYRDrN-I&e=>
_______________________________________________
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/20160707/a9b7b674/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 7 Jul 2016 17:03:39 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Phase variations in B210 at particular
center frequencies
Message-ID: <577eeddb.1060...@ettus.com>
Content-Type: text/plain; charset=windows-1252
Have you tried tuning far off from the synthesizer (large CORDIC value)?
M
On 07/07/2016 12:25 PM, Jeremy Hershberger via USRP-users wrote:
> Ian,
>
> My first thought was the IQ and DC corrections. In my application I
> actually turn these off after letting the chip run for a second or two,
> but before I collect data. However, this phase variation problem is
> preset in the data regardless of whether I leave the corrections on or off.
>
> I have also tried disabling the CORDIC blocks by setting the
> uhd::tune_request.dsp_freq_policy = uhd::tune_reqeuest_t::POLICY_NONE.
> No change.
>
> I am unsure how to disable the IQ/DC corrections and CORDIC tuning in
> GNUradio, but I can confirm using C++ that these attributes don't make
> any difference.
>
> As far as the gain is concerned, I tried adjusting the tx gain up while
> also adjusting the rx gain down (to prevent loss of SNR) and still found
> no improvement.
>
> Any other thoughts?
>
> -Jeremy
>
> On Thu, Jul 7, 2016 at 1:13 PM, Ian Buckley <i...@ionconcepts.com
> <mailto:i...@ionconcepts.com>> wrote:
>
> FWIW I've seen stuff like this before related to this particular
> RFIC, and my tendency is to look to the (in built) DC offset and IQ
> balance functions which are real-time adaptive in nature...IQ
> balance in particular in this case given that has a direct affect on
> phase.
>
> There's a few test's I might run to learn a little more.
>
> I've seen the gain settings directly relate to effects like this, so
> I might try walking through a few gains with all else constant.
>
> Another thing that might be interesting is rather than slowly slew
> the center frequency, instead ping-pong it to a value thats "far"
> away (>100MHz) then back to your desired next step...the reason for
> this is that subtle retunings do not cause all IQ balance routines
> to be rerun, but large retuning ranges do....so something like 915.0
> -> 2000.0 -> 915.01 might be informative.
>
> Lastly it might be wise to use a full manual tuning policy and
> explicitly control use of the CORDIC (force it to zero)...this will
> increase tuning granularity but you will be able to record what
> actual frequency the RF synthesizer is programmed to.
>
> my 1 cents...
> -Ian
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 10
Date: Thu, 7 Jul 2016 17:05:16 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Reg : nsamps_per_buff in UHD
Message-ID: <577eee3c.1030...@ettus.com>
Content-Type: text/plain; charset=windows-1252
That's one reason, another would be if you have an overrun. There's no
strong guarantee on the number of samples recv() will return.
M
On 07/07/2016 08:25 AM, Dave NotTelling via USRP-users wrote:
> The first thing that comes to mind is the timeout getting hit so it only
> returns up to the number of samples it got up to that point.
>
> On Thu, Jul 7, 2016 at 7:18 AM, Sumit Kumar via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>
> *I am using UHD_003.009.002-0-gf18abe54*
>
> Is it common that the receive streamer sometimes returns lesser
> number of samples than we ask.
>
> I have set nsamps_per_buff = 4096
>
> but sometimes the samples received are less than 4096.
>
> What can be the reason for that ?
>
> Sumit
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 11
Date: Fri, 8 Jul 2016 12:07:19 +0000
From: Nik B. <nikke...@outlook.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] Waveform received from USRP2 freezes
Message-ID:
<kl1pr02mb13682c6d88f3e36930b123b3d0...@kl1pr02mb1368.apcprd02.prod.outlook.com>
Content-Type: text/plain; charset="iso-2022-jp"
My guess is it is about the graphics hardware or software of my laptop.
Working environment is windows 7.-64.
I have a C# program that calls the sample program (rx_sample_to_file.cpp) to
read data from the usrp, and using NPlot (a free cahrting library for .NET),
the C# program plots the waveform.
I have been using Thinkpad X201, and the plot comes out alright, I mean it
shows *some* waveform.
Today, I got a shiny new X1 Carbon.
I went through the same routine: installed UHD driver ( the latest) for
Windows, installed and configured boost (1.60). Installed Visual Studio 2015
(CE) and compiled and built the above program, just I had done with the X201
few months back.
Now when I click the exe file, I see a GUI and I see that the program starts
to fetch data, but within seconds, the GUI freezes.
The X1 Carbon has Intel HD graphics 520, built-into the CPU.
I don't have the graphics spec of the X201, right now.
I downloaded and installed X1 Carbon's graphics driver just to make sure that I
have the latest.
I visited this page:
https://www.youtube.com/watch?v=1-UdWS4RAA4
and I can see the movie/graphics all smooth and cool.
Yet, the waveform (just random noise from the usrp2, as there is no input to
the device and there is no antenna) freezes for this test.
And the old, old, X201 shows the same waveform smoothly.
Knowlege is power.
How sweet it is to have this knowlege why things don't work as expected.
The X1 Carbon does not have a wired lan ( how I wished that I knew it before I
bought it!) , so I am using USB to ethernet converter to connect to the usrp.
Could it be the cause?
Of course, the X201 does have a wired lan.
Video memory of the X1 was set at 256MB, I changed it to 512MB, but no
improvement.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160708/97708538/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WaveformFreeze.PNG
Type: image/png
Size: 43768 bytes
Desc: WaveformFreeze.PNG
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160708/97708538/attachment-0001.PNG>
------------------------------
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 71, Issue 7
*****************************************
