usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsRe: [USRP-users] B210 severe distortion on In-phase data for some gain settings.
Hey Jacob,
first, apologies for the delayed feedback. Also, thanks a lot for the
amazing amount of detail you provided in the bug report.
From the conversation, I'm not sure if you tried disabling IQ balance
correction entirely -- if not, can you please give that a shot?
(set_rx_iq_balance(false, 0), btw).
You can also go ahead and set_rx_iq_balance(std::complex<double>(0, 0))
for good measure.
Cheers,
Martin
On 28.05.2015 06:32, Jacob Gilbert wrote:
Thanks for looking into this guys. We are actively looking also, without
resolve. The registers for DC and IQ correction seem to be set
identically (as does just about every other 9361 register) between the
FX3 (3.7.x) and host (3.8.x) configuration methods. The only difference
I see is what appears to be some LVDS interface support to the 9361.
Let me know if we can speed up troubleshoot this on your end by doing
anything.
Thanks,
Jacob
On Wed, May 27, 2015 at 3:32 PM, Julian Arnold <julian.arnold@ettus.com
mailto:julian.arnold@ettus.com> wrote:
Hi Jacob,
We are still trying to figure out what the issue could be and what
might be causing it.
I'll let you know as soon as we have new information, hopefully by
the end of next week.
Regards,
Julian
On Tuesday, May 26, 2015, Jacob Gilbert via USRP-users
<usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
Martin or other Ettus Folks,
Is this something you can reproduce or believe is an actual
issue? I am having trouble figuring out what exactly has changed
and where the actual problem is. Can you provide any additional
information?
Thanks,
Jacob
On Fri, May 22, 2015 at 8:54 PM, Martin Braun via USRP-users
<usrp-users@lists.ettus.com> wrote:
On 22.05.2015 13 <tel:22.05.2015%2013>:02, Marcus D. Leech
via USRP-users wrote:
On 05/22/2015 03:18 PM, Jacob Gilbert wrote:
Thanks for the suggestion Marcus. It makes sense that could be the
cause, though I am having trouble figuring out why this behavior would
be different between UHD 3.7.1 and 3.8.x (same GR version - 3.7.6.1).
I am unable to find any default setting for this value in the UHD
source, just the method to do it, though perhaps I am missing
something. It looks like jarn0ld committed some changes to how the IQ
imbalance correction works on February 20th
(https://github.com/EttusResearch/uhd/commit/4602ea9148e5e36fefca6402b7dcc5a1104e7410).
Jacob
The control logic for the AD9361 migrated away from the FX3 firmware and
into host-side UHD as well.
This is probably the more relevant change -- Julian's
changes add
features, but don't touch a lot of the old ones (except for
DC offset
and IQ imbalance stuff).
Cheers,
M
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Julian Arnold
Hi Martin,
I previously tried disabling IQ correction and got an odd "not implemented
in this version" or something like that python error. I just ran a fresh
pybombs install (GR v3.7.7.1-131-g71ab508d, UHD_003.009.git-171-g51bc00ee)
and confirmed that the issue is still present with the default uhd_fft,
however when adding the line (this is in python so it's a little different
than the call you provided):
self.u.set_auto_iq_balance(False, 0)
the issue is no longer reproducible; I haven't tested exhaustively though.
I also tried "self.u.set_iq_balance((0+0j), 0)" however UHD warns "Setting
IQ balance is not possible on this device."
Was whatever 'auto IQ balance' does (I assume it's something on the 9361?)
used prior to UHD 3.8.0? I'd feel more comfortable knowing what the impact
to my RF performance will be by disabling this. Is the IQ balance
configurable other than on/off for the B2xx?
Thanks,
Jacob
On Thu, Jun 4, 2015 at 4:18 PM, Martin Braun martin.braun@ettus.com wrote:
Hey Jacob,
first, apologies for the delayed feedback. Also, thanks a lot for the
amazing amount of detail you provided in the bug report.
From the conversation, I'm not sure if you tried disabling IQ balance
correction entirely -- if not, can you please give that a shot?
(set_rx_iq_balance(false, 0), btw).
You can also go ahead and set_rx_iq_balance(std::complex<double>(0, 0))
for good measure.
Cheers,
Martin
On 28.05.2015 06:32, Jacob Gilbert wrote:
Thanks for looking into this guys. We are actively looking also, without
resolve. The registers for DC and IQ correction seem to be set
identically (as does just about every other 9361 register) between the
FX3 (3.7.x) and host (3.8.x) configuration methods. The only difference
I see is what appears to be some LVDS interface support to the 9361.
Let me know if we can speed up troubleshoot this on your end by doing
anything.
Thanks,
Jacob
On Wed, May 27, 2015 at 3:32 PM, Julian Arnold <julian.arnold@ettus.com
mailto:julian.arnold@ettus.com> wrote:
Hi Jacob,
We are still trying to figure out what the issue could be and what
might be causing it.
I'll let you know as soon as we have new information, hopefully by
the end of next week.
Regards,
Julian
On Tuesday, May 26, 2015, Jacob Gilbert via USRP-users
<usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>>
wrote:
Martin or other Ettus Folks,
Is this something you can reproduce or believe is an actual
issue? I am having trouble figuring out what exactly has changed
and where the actual problem is. Can you provide any additional
information?
Thanks,
Jacob
On Fri, May 22, 2015 at 8:54 PM, Martin Braun via USRP-users
<usrp-users@lists.ettus.com> wrote:
On 22.05.2015 13 <tel:22.05.2015%2013>:02, Marcus D. Leech
via USRP-users wrote:
On 05/22/2015 03:18 PM, Jacob Gilbert wrote:
Thanks for the suggestion Marcus. It makes sense that
could be the
cause, though I am having trouble figuring out why this
behavior would
be different between UHD 3.7.1 and 3.8.x (same GR version
- 3.7.6.1).
I am unable to find any default setting for this value in
the UHD
source, just the method to do it, though perhaps I am
missing
something. It looks like jarn0ld committed some changes
to how the IQ
imbalance correction works on February 20th
(
Jacob
The control logic for the AD9361 migrated away from the
FX3 firmware and
into host-side UHD as well.
This is probably the more relevant change -- Julian's
changes add
features, but don't touch a lot of the old ones (except for
DC offset
and IQ imbalance stuff).
Cheers,
M
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
--
Julian Arnold
On 06/04/2015 08:23 PM, Jacob Gilbert via USRP-users wrote:
Hi Martin,
I previously tried disabling IQ correction and got an odd "not
implemented in this version" or something like that python error. I
just ran a fresh pybombs install (GR v3.7.7.1-131-g71ab508d,
UHD_003.009.git-171-g51bc00ee) and confirmed that the issue is still
present with the default uhd_fft, however when adding the line (this
is in python so it's a little different than the call you provided):
self.u.set_auto_iq_balance(False, 0)
the issue is no longer reproducible; I haven't tested exhaustively
though. I also tried "self.u.set_iq_balance((0+0j), 0)" however UHD
warns "Setting IQ balance is not possible on this device."
Was whatever 'auto IQ balance' does (I assume it's something on the
9361?) used prior to UHD 3.8.0? I'd feel more comfortable knowing what
the impact to my RF performance will be by disabling this. Is the IQ
balance configurable other than on/off for the B2xx?
Thanks,
Jacob
The AD9361 doesn't have any way of manually setting the phase/amplitude
corrections, only turning the automated-in-the-chip I/Q "tracking"
(ADI's term) ON or OFF.
In other USRP models, I/Q balance correction is implemented in the DSP
logic in the FPGA, and uses a utility program to laboriously step
through the
frequency range of the card, and make estimates of the imbalance
using a CAL setting in the TX/RX switching, it records its finding, and
suggested
corrections in a file in your ~/.uhd/cal directory. Then, when you
go to tune/setup a "session" with a device, it looks up the I/Q balance
corrections
in the appropriate file, and tells the DSP in the FPGA to apply those
corrections. But there's no "automated tracking" of I/Q balance--it is a
statically-determined estimate based on a UHD-directed calibration run.
In the AD9361, they track phase/amplitude balance in real-time in the
hardware. There has been much debate in the direct-conversion world about
the best approaches to dynamic I/Q balance correction, and indeed
whether automated estimation is even possible in the fully-general
case. The
ADI approach, according to their datasheet, is to dynamically measure
the I vs Q phase difference, and make certain that the average difference
is always 90deg, when measured over some "useful" timescale. My
personal suspicion is that at low signal levels, and with noise-like
signals, that
estimator approach may fail.
On Thu, Jun 4, 2015 at 4:18 PM, Martin Braun <martin.braun@ettus.com
mailto:martin.braun@ettus.com> wrote:
Hey Jacob,
first, apologies for the delayed feedback. Also, thanks a lot for the
amazing amount of detail you provided in the bug report.
From the conversation, I'm not sure if you tried disabling IQ balance
correction entirely -- if not, can you please give that a shot?
(set_rx_iq_balance(false, 0), btw).
You can also go ahead and
set_rx_iq_balance(std::complex<double>(0, 0))
for good measure.
Cheers,
Martin
On 28.05.2015 06:32, Jacob Gilbert wrote:
Thanks for looking into this guys. We are actively looking also,
without
resolve. The registers for DC and IQ correction seem to be set
identically (as does just about every other 9361 register)
between the
FX3 (3.7.x) and host (3.8.x) configuration methods. The only
difference
I see is what appears to be some LVDS interface support to the 9361.
Let me know if we can speed up troubleshoot this on your end by
doing
anything.
Thanks,
Jacob
On Wed, May 27, 2015 at 3:32 PM, Julian Arnold
<julian.arnold@ettus.com <mailto:julian.arnold@ettus.com>
<mailto:julian.arnold@ettus.com mailto:julian.arnold@ettus.com>> wrote:
Hi Jacob,
We are still trying to figure out what the issue could be
and what
might be causing it.
I'll let you know as soon as we have new information,
hopefully by
the end of next week.
Regards,
Julian
On Tuesday, May 26, 2015, Jacob Gilbert via USRP-users
<usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>
<mailto:usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>>> wrote:
Martin or other Ettus Folks,
Is this something you can reproduce or believe is an actual
issue? I am having trouble figuring out what exactly has
changed
and where the actual problem is. Can you provide any
additional
information?
Thanks,
Jacob
On Fri, May 22, 2015 at 8:54 PM, Martin Braun via USRP-users
<usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>> wrote:
On 22.05.2015 13 <tel:22.05.2015%2013>
<tel:22.05.2015%2013>:02, Marcus D. Leech
via USRP-users wrote:
On 05/22/2015 03:18 PM, Jacob Gilbert wrote:
Thanks for the suggestion Marcus. It makes sense
that could be the
cause, though I am having trouble figuring out
why this behavior would
be different between UHD 3.7.1 and 3.8.x (same GR
version - 3.7.6.1).
I am unable to find any default setting for this
value in the UHD
source, just the method to do it, though perhaps
I am missing
something. It looks like jarn0ld committed some
changes to how the IQ
imbalance correction works on February 20th
(https://github.com/EttusResearch/uhd/commit/4602ea9148e5e36fefca6402b7dcc5a1104e7410).
Jacob
The control logic for the AD9361 migrated away
from the FX3 firmware and
into host-side UHD as well.
This is probably the more relevant change -- Julian's
changes add
features, but don't touch a lot of the old ones
(except for
DC offset
and IQ imbalance stuff).
Cheers,
M
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
--
Julian Arnold
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Thanks for the information and Marcus; we use the mentioned calibration on
all the USRPN/X work we do and it seems to work pretty well. We had
originally suspected very low level signals to be responsible for driving a
correction loop unstable on the B2xx until we observed the behavior in the
original post with moderate power signals which left us puzzled and
suspecting a more serious issue. I am still a little confused as to why it
works fine in 3.7.x, the IQ balance function for the 9361 seems to be
configured the same. I also seem to remember some user-configurable
registers related to IQ correction coefficients, but I might be mistaken.
On Thu, Jun 4, 2015 at 8:35 PM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:
On 06/04/2015 08:23 PM, Jacob Gilbert via USRP-users wrote:
Hi Martin,
I previously tried disabling IQ correction and got an odd "not
implemented in this version" or something like that python error. I just
ran a fresh pybombs install (GR v3.7.7.1-131-g71ab508d,
UHD_003.009.git-171-g51bc00ee) and confirmed that the issue is still
present with the default uhd_fft, however when adding the line (this is in
python so it's a little different than the call you provided):
self.u.set_auto_iq_balance(False, 0)
the issue is no longer reproducible; I haven't tested exhaustively
though. I also tried "self.u.set_iq_balance((0+0j), 0)" however UHD warns
"Setting IQ balance is not possible on this device."
Was whatever 'auto IQ balance' does (I assume it's something on the
9361?) used prior to UHD 3.8.0? I'd feel more comfortable knowing what the
impact to my RF performance will be by disabling this. Is the IQ balance
configurable other than on/off for the B2xx?
Thanks,
Jacob
The AD9361 doesn't have any way of manually setting the phase/amplitude
corrections, only turning the automated-in-the-chip I/Q "tracking"
(ADI's term) ON or OFF.
In other USRP models, I/Q balance correction is implemented in the DSP
logic in the FPGA, and uses a utility program to laboriously step through
the
frequency range of the card, and make estimates of the imbalance using a
CAL setting in the TX/RX switching, it records its finding, and suggested
corrections in a file in your ~/.uhd/cal directory. Then, when you go
to tune/setup a "session" with a device, it looks up the I/Q balance
corrections
in the appropriate file, and tells the DSP in the FPGA to apply those
corrections. But there's no "automated tracking" of I/Q balance--it is a
statically-determined estimate based on a UHD-directed calibration run.
In the AD9361, they track phase/amplitude balance in real-time in the
hardware. There has been much debate in the direct-conversion world about
the best approaches to dynamic I/Q balance correction, and indeed
whether automated estimation is even possible in the fully-general case.
The
ADI approach, according to their datasheet, is to dynamically measure
the I vs Q phase difference, and make certain that the average difference
is always 90deg, when measured over some "useful" timescale. My
personal suspicion is that at low signal levels, and with noise-like
signals, that
estimator approach may fail.
On Thu, Jun 4, 2015 at 4:18 PM, Martin Braun martin.braun@ettus.com
wrote:
Hey Jacob,
first, apologies for the delayed feedback. Also, thanks a lot for the
amazing amount of detail you provided in the bug report.
From the conversation, I'm not sure if you tried disabling IQ balance
correction entirely -- if not, can you please give that a shot?
(set_rx_iq_balance(false, 0), btw).
You can also go ahead and set_rx_iq_balance(std::complex<double>(0, 0))
for good measure.
Cheers,
Martin
On 28.05.2015 06:32, Jacob Gilbert wrote:
Thanks for looking into this guys. We are actively looking also, without
resolve. The registers for DC and IQ correction seem to be set
identically (as does just about every other 9361 register) between the
FX3 (3.7.x) and host (3.8.x) configuration methods. The only difference
I see is what appears to be some LVDS interface support to the 9361.
Let me know if we can speed up troubleshoot this on your end by doing
anything.
Thanks,
Jacob
On Wed, May 27, 2015 at 3:32 PM, Julian Arnold <julian.arnold@ettus.com
mailto:julian.arnold@ettus.com> wrote:
Hi Jacob,
We are still trying to figure out what the issue could be and what
might be causing it.
I'll let you know as soon as we have new information, hopefully by
the end of next week.
Regards,
Julian
On Tuesday, May 26, 2015, Jacob Gilbert via USRP-users
<usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>>
wrote:
Martin or other Ettus Folks,
Is this something you can reproduce or believe is an actual
issue? I am having trouble figuring out what exactly has changed
and where the actual problem is. Can you provide any additional
information?
Thanks,
Jacob
On Fri, May 22, 2015 at 8:54 PM, Martin Braun via USRP-users
<usrp-users@lists.ettus.com> wrote:
On 22.05.2015 13 <22.05.2015%2013>
tel:22.05.2015%2013:02, Marcus D. Leech
via USRP-users wrote:
On 05/22/2015 03:18 PM, Jacob Gilbert wrote:
Thanks for the suggestion Marcus. It makes sense that
could be the
cause, though I am having trouble figuring out why this
behavior would
be different between UHD 3.7.1 and 3.8.x (same GR
version - 3.7.6.1).
I am unable to find any default setting for this value
in the UHD
source, just the method to do it, though perhaps I am
missing
something. It looks like jarn0ld committed some changes
to how the IQ
imbalance correction works on February 20th
(
Jacob
The control logic for the AD9361 migrated away from the
FX3 firmware and
into host-side UHD as well.
This is probably the more relevant change -- Julian's
changes add
features, but don't touch a lot of the old ones (except for
DC offset
and IQ imbalance stuff).
Cheers,
M
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
--
Julian Arnold
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
On 06/04/2015 09:03 PM, Jacob Gilbert wrote:
Thanks for the information and Marcus; we use the mentioned
calibration on all the USRPN/X work we do and it seems to work pretty
well. We had originally suspected very low level signals to be
responsible for driving a correction loop unstable on the B2xx until
we observed the behavior in the original post with moderate power
signals which left us puzzled and suspecting a more serious issue. I
am still a little confused as to why it works fine in 3.7.x, the IQ
balance function for the 9361 seems to be configured the same. I also
seem to remember some user-configurable registers related to IQ
correction coefficients, but I might be mistaken.
Hmmm, reading the ADI online forums, you may be right about there being
registers that can be used to manually adjust the I/Q phase offsets. It's
a fiendishly complex chip.
On Thu, Jun 4, 2015 at 8:35 PM, Marcus D. Leech via USRP-users
<usrp-users@lists.ettus.com mailto:usrp-users@lists.ettus.com> wrote:
On 06/04/2015 08:23 PM, Jacob Gilbert via USRP-users wrote:
Hi Martin,
I previously tried disabling IQ correction and got an odd "not
implemented in this version" or something like that python error.
I just ran a fresh pybombs install (GR v3.7.7.1-131-g71ab508d,
UHD_003.009.git-171-g51bc00ee) and confirmed that the issue is
still present with the default uhd_fft, however when adding the
line (this is in python so it's a little different than the call
you provided):
self.u.set_auto_iq_balance(False, 0)
the issue is no longer reproducible; I haven't tested
exhaustively though. I also tried "self.u.set_iq_balance((0+0j),
0)" however UHD warns "Setting IQ balance is not possible on this
device."
Was whatever 'auto IQ balance' does (I assume it's something on
the 9361?) used prior to UHD 3.8.0? I'd feel more comfortable
knowing what the impact to my RF performance will be by disabling
this. Is the IQ balance configurable other than on/off for the B2xx?
Thanks,
Jacob
The AD9361 doesn't have any way of manually setting the
phase/amplitude corrections, only turning the
automated-in-the-chip I/Q "tracking"
(ADI's term) ON or OFF.
In other USRP models, I/Q balance correction is implemented in the
DSP logic in the FPGA, and uses a utility program to laboriously
step through the
frequency range of the card, and make estimates of the imbalance
using a CAL setting in the TX/RX switching, it records its
finding, and suggested
corrections in a file in your ~/.uhd/cal directory. Then, when
you go to tune/setup a "session" with a device, it looks up the
I/Q balance corrections
in the appropriate file, and tells the DSP in the FPGA to apply
those corrections. But there's no "automated tracking" of I/Q
balance--it is a
statically-determined estimate based on a UHD-directed
calibration run.
In the AD9361, they track phase/amplitude balance in real-time in
the hardware. There has been much debate in the direct-conversion
world about
the best approaches to dynamic I/Q balance correction, and
indeed whether automated estimation is even possible in the
fully-general case. The
ADI approach, according to their datasheet, is to dynamically
measure the I vs Q phase difference, and make certain that the
average difference
is always 90deg, when measured over some "useful" timescale. My
personal suspicion is that at low signal levels, and with
noise-like signals, that
estimator approach may fail.
On Thu, Jun 4, 2015 at 4:18 PM, Martin Braun
<martin.braun@ettus.com <mailto:martin.braun@ettus.com>> wrote:
Hey Jacob,
first, apologies for the delayed feedback. Also, thanks a lot
for the
amazing amount of detail you provided in the bug report.
From the conversation, I'm not sure if you tried disabling IQ
balance
correction entirely -- if not, can you please give that a shot?
(set_rx_iq_balance(false, 0), btw).
You can also go ahead and
set_rx_iq_balance(std::complex<double>(0, 0))
for good measure.
Cheers,
Martin
On 28.05.2015 06:32, Jacob Gilbert wrote:
Thanks for looking into this guys. We are actively looking
also, without
resolve. The registers for DC and IQ correction seem to be set
identically (as does just about every other 9361 register)
between the
FX3 (3.7.x) and host (3.8.x) configuration methods. The
only difference
I see is what appears to be some LVDS interface support to
the 9361.
Let me know if we can speed up troubleshoot this on your
end by doing
anything.
Thanks,
Jacob
On Wed, May 27, 2015 at 3:32 PM, Julian Arnold
<julian.arnold@ettus.com <mailto:julian.arnold@ettus.com>
<mailto:julian.arnold@ettus.com mailto:julian.arnold@ettus.com>> wrote:
Hi Jacob,
We are still trying to figure out what the issue could
be and what
might be causing it.
I'll let you know as soon as we have new information,
hopefully by
the end of next week.
Regards,
Julian
On Tuesday, May 26, 2015, Jacob Gilbert via USRP-users
<usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>
<mailto:usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>>> wrote:
Martin or other Ettus Folks,
Is this something you can reproduce or believe is
an actual
issue? I am having trouble figuring out what
exactly has changed
and where the actual problem is. Can you provide
any additional
information?
Thanks,
Jacob
On Fri, May 22, 2015 at 8:54 PM, Martin Braun via
USRP-users
<usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>> wrote:
On 22.05.2015 13 <tel:22.05.2015%2013>
<tel:22.05.2015%2013>:02, Marcus D. Leech
via USRP-users wrote:
On 05/22/2015 03:18 PM, Jacob Gilbert wrote:
Thanks for the suggestion Marcus. It makes
sense that could be the
cause, though I am having trouble figuring
out why this behavior would
be different between UHD 3.7.1 and 3.8.x
(same GR version - 3.7.6.1).
I am unable to find any default setting for
this value in the UHD
source, just the method to do it, though
perhaps I am missing
something. It looks like jarn0ld committed
some changes to how the IQ
imbalance correction works on February 20th
(https://github.com/EttusResearch/uhd/commit/4602ea9148e5e36fefca6402b7dcc5a1104e7410).
Jacob
The control logic for the AD9361 migrated
away from the FX3 firmware and
into host-side UHD as well.
This is probably the more relevant change --
Julian's
changes add
features, but don't touch a lot of the old ones
(except for
DC offset
and IQ imbalance stuff).
Cheers,
M
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
--
Julian Arnold
_______________________________________________
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 <mailto:USRP-users@lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
So I looked through UG-671 and noticed something interesting. But first,
when enabled by UHD it appears Rx Quadrature Calibration "Free Run Mode",
"Corr Word Decimation", and "Tracking Mode" CH1 and CH2 are enabled. The
Correction Words do not appear to be set directly (I assume automatically
by the 9361, which I believe is good), but that is probably what I was
thinking when I mentioned configurable IQ correction registers.
The interesting thing is that [at least rev0] of UG-671 I have indicates
Quadrature Calibration registers 0x16A and 0x16B "MUST BE SET" to 0x75 and
0x95 respectively however UHD sets 0x16B to 0x15. That being said, I am not
sure this is related to my current issue as this is set identically in all
versions of UHD I have checked. Furthermore, it looks like even 3.7
versions of UHD use the 9361's Rx Quadrature Tracking continuously except
for when doing TX calibration, so I am suspicious that this is the sole
reason for this behavior, and I am concerned RF performance will suffer
with this disabled.
But I am not an expert in the 9361... so I have to defer to Ettus here.
Jacob
On Thu, Jun 4, 2015 at 9:14 PM, Marcus D. Leech mleech@ripnet.com wrote:
On 06/04/2015 09:03 PM, Jacob Gilbert wrote:
Thanks for the information and Marcus; we use the mentioned calibration on
all the USRPN/X work we do and it seems to work pretty well. We had
originally suspected very low level signals to be responsible for driving a
correction loop unstable on the B2xx until we observed the behavior in the
original post with moderate power signals which left us puzzled and
suspecting a more serious issue. I am still a little confused as to why it
works fine in 3.7.x, the IQ balance function for the 9361 seems to be
configured the same. I also seem to remember some user-configurable
registers related to IQ correction coefficients, but I might be mistaken.
Hmmm, reading the ADI online forums, you may be right about there being
registers that can be used to manually adjust the I/Q phase offsets. It's
a fiendishly complex chip.
On Thu, Jun 4, 2015 at 8:35 PM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:
On 06/04/2015 08:23 PM, Jacob Gilbert via USRP-users wrote:
Hi Martin,
I previously tried disabling IQ correction and got an odd "not
implemented in this version" or something like that python error. I just
ran a fresh pybombs install (GR v3.7.7.1-131-g71ab508d,
UHD_003.009.git-171-g51bc00ee) and confirmed that the issue is still
present with the default uhd_fft, however when adding the line (this is in
python so it's a little different than the call you provided):
self.u.set_auto_iq_balance(False, 0)
the issue is no longer reproducible; I haven't tested exhaustively
though. I also tried "self.u.set_iq_balance((0+0j), 0)" however UHD warns
"Setting IQ balance is not possible on this device."
Was whatever 'auto IQ balance' does (I assume it's something on the
9361?) used prior to UHD 3.8.0? I'd feel more comfortable knowing what the
impact to my RF performance will be by disabling this. Is the IQ balance
configurable other than on/off for the B2xx?
Thanks,
Jacob
The AD9361 doesn't have any way of manually setting the
phase/amplitude corrections, only turning the automated-in-the-chip I/Q
"tracking"
(ADI's term) ON or OFF.
In other USRP models, I/Q balance correction is implemented in the DSP
logic in the FPGA, and uses a utility program to laboriously step through
the
frequency range of the card, and make estimates of the imbalance using
a CAL setting in the TX/RX switching, it records its finding, and suggested
corrections in a file in your ~/.uhd/cal directory. Then, when you go
to tune/setup a "session" with a device, it looks up the I/Q balance
corrections
in the appropriate file, and tells the DSP in the FPGA to apply those
corrections. But there's no "automated tracking" of I/Q balance--it is a
statically-determined estimate based on a UHD-directed calibration run.
In the AD9361, they track phase/amplitude balance in real-time in the
hardware. There has been much debate in the direct-conversion world about
the best approaches to dynamic I/Q balance correction, and indeed
whether automated estimation is even possible in the fully-general case.
The
ADI approach, according to their datasheet, is to dynamically measure
the I vs Q phase difference, and make certain that the average difference
is always 90deg, when measured over some "useful" timescale. My
personal suspicion is that at low signal levels, and with noise-like
signals, that
estimator approach may fail.
On Thu, Jun 4, 2015 at 4:18 PM, Martin Braun martin.braun@ettus.com
wrote:
Hey Jacob,
first, apologies for the delayed feedback. Also, thanks a lot for the
amazing amount of detail you provided in the bug report.
From the conversation, I'm not sure if you tried disabling IQ balance
correction entirely -- if not, can you please give that a shot?
(set_rx_iq_balance(false, 0), btw).
You can also go ahead and set_rx_iq_balance(std::complex<double>(0, 0))
for good measure.
Cheers,
Martin
On 28.05.2015 06:32, Jacob Gilbert wrote:
Thanks for looking into this guys. We are actively looking also,
without
resolve. The registers for DC and IQ correction seem to be set
identically (as does just about every other 9361 register) between the
FX3 (3.7.x) and host (3.8.x) configuration methods. The only difference
I see is what appears to be some LVDS interface support to the 9361.
Let me know if we can speed up troubleshoot this on your end by doing
anything.
Thanks,
Jacob
On Wed, May 27, 2015 at 3:32 PM, Julian Arnold <
mailto:julian.arnold@ettus.com> wrote:
Hi Jacob,
We are still trying to figure out what the issue could be and what
might be causing it.
I'll let you know as soon as we have new information, hopefully by
the end of next week.
Regards,
Julian
On Tuesday, May 26, 2015, Jacob Gilbert via USRP-users
<usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>>
wrote:
Martin or other Ettus Folks,
Is this something you can reproduce or believe is an actual
issue? I am having trouble figuring out what exactly has
changed
and where the actual problem is. Can you provide any additional
information?
Thanks,
Jacob
On Fri, May 22, 2015 at 8:54 PM, Martin Braun via USRP-users
<usrp-users@lists.ettus.com> wrote:
On 22.05.2015 13 <22.05.2015%2013>
tel:22.05.2015%2013:02, Marcus D. Leech
via USRP-users wrote:
On 05/22/2015 03:18 PM, Jacob Gilbert wrote:
Thanks for the suggestion Marcus. It makes sense that
could be the
cause, though I am having trouble figuring out why this
behavior would
be different between UHD 3.7.1 and 3.8.x (same GR
version - 3.7.6.1).
I am unable to find any default setting for this value
in the UHD
source, just the method to do it, though perhaps I am
missing
something. It looks like jarn0ld committed some changes
to how the IQ
imbalance correction works on February 20th
(
Jacob
The control logic for the AD9361 migrated away from the
FX3 firmware and
into host-side UHD as well.
This is probably the more relevant change -- Julian's
changes add
features, but don't touch a lot of the old ones (except for
DC offset
and IQ imbalance stuff).
Cheers,
M
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
--
Julian Arnold
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
On 04.06.2015 17:23, Jacob Gilbert wrote:
Hi Martin,
I previously tried disabling IQ correction and got an odd "not
implemented in this version" or something like that python error. I just
ran a fresh pybombs install (GR v3.7.7.1-131-g71ab508d,
UHD_003.009.git-171-g51bc00ee) and confirmed that the issue is still
present with the default uhd_fft, however when adding the line (this is
in python so it's a little different than the call you provided):
self.u.set_auto_iq_balance(False, 0)
Hey Jacob,
this was, in fact, what I meant. We didn't always have this feature, and
it was also updated in the past. This does align with the versions
you're seeing.
the issue is no longer reproducible; I haven't tested exhaustively
though. I also tried "self.u.set_iq_balance((0+0j), 0)" however UHD
warns "Setting IQ balance is not possible on this device."
Was whatever 'auto IQ balance' does (I assume it's something on the
9361?) used prior to UHD 3.8.0? I'd feel more comfortable knowing what
the impact to my RF performance will be by disabling this. Is the IQ
balance configurable other than on/off for the B2xx?
Right now, it's not. As Marcus says, the 9361 is a highly complex beast,
and even the reference codes by ADI still change around. Unfortunately,
with stock UHD, the only option you have right now is to disable IQ
balance tracking, but we're continuously working on improving the AD9361
controls.
I don't have a timeline for the feature you asked for (specifically
setting IQ balance settings), because frankly, you're the first to ever
ask about this.
Cheers,
Martin
Thanks,
Jacob
On Thu, Jun 4, 2015 at 4:18 PM, Martin Braun <martin.braun@ettus.com
mailto:martin.braun@ettus.com> wrote:
Hey Jacob,
first, apologies for the delayed feedback. Also, thanks a lot for the
amazing amount of detail you provided in the bug report.
From the conversation, I'm not sure if you tried disabling IQ balance
correction entirely -- if not, can you please give that a shot?
(set_rx_iq_balance(false, 0), btw).
You can also go ahead and set_rx_iq_balance(std::complex<double>(0, 0))
for good measure.
Cheers,
Martin
On 28.05.2015 06:32, Jacob Gilbert wrote:
Thanks for looking into this guys. We are actively looking also, without
resolve. The registers for DC and IQ correction seem to be set
identically (as does just about every other 9361 register) between the
FX3 (3.7.x) and host (3.8.x) configuration methods. The only difference
I see is what appears to be some LVDS interface support to the 9361.
Let me know if we can speed up troubleshoot this on your end by doing
anything.
Thanks,
Jacob
On Wed, May 27, 2015 at 3:32 PM, Julian Arnold <julian.arnold@ettus.com mailto:julian.arnold@ettus.com
<mailto:julian.arnold@ettus.com mailto:julian.arnold@ettus.com>> wrote:
Hi Jacob,
We are still trying to figure out what the issue could be and what
might be causing it.
I'll let you know as soon as we have new information, hopefully by
the end of next week.
Regards,
Julian
On Tuesday, May 26, 2015, Jacob Gilbert via USRP-users
<usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>
<mailto:usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>>> wrote:
Martin or other Ettus Folks,
Is this something you can reproduce or believe is an actual
issue? I am having trouble figuring out what exactly has changed
and where the actual problem is. Can you provide any additional
information?
Thanks,
Jacob
On Fri, May 22, 2015 at 8:54 PM, Martin Braun via USRP-users
<usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
On 22.05.2015 13 <tel:22.05.2015%2013>
<tel:22.05.2015%2013>:02, Marcus D. Leech
via USRP-users wrote:
On 05/22/2015 03:18 PM, Jacob Gilbert wrote:
Thanks for the suggestion Marcus. It makes sense
that could be the
cause, though I am having trouble figuring out why
this behavior would
be different between UHD 3.7.1 and 3.8.x (same GR
version - 3.7.6.1).
I am unable to find any default setting for this
value in the UHD
source, just the method to do it, though perhaps I
am missing
something. It looks like jarn0ld committed some
changes to how the IQ
imbalance correction works on February 20th
(https://github.com/EttusResearch/uhd/commit/4602ea9148e5e36fefca6402b7dcc5a1104e7410).
Jacob
The control logic for the AD9361 migrated away from
the FX3 firmware and
into host-side UHD as well.
This is probably the more relevant change -- Julian's
changes add
features, but don't touch a lot of the old ones
(except for
DC offset
and IQ imbalance stuff).
Cheers,
M
_______________________________________________
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
--
Julian Arnold
On Fri, Jun 5, 2015 at 7:40 AM, Jacob Gilbert via USRP-users
usrp-users@lists.ettus.com wrote:
The interesting thing is that [at least rev0] of UG-671 I have indicates
Quadrature Calibration registers 0x16A and 0x16B "MUST BE SET" to 0x75 and
0x95 respectively however UHD sets 0x16B to 0x15. That being said, I am not
sure this is related to my current issue as this is set identically in all
versions of UHD I have checked. Furthermore, it looks like even 3.7 versions
of UHD use the 9361's Rx Quadrature Tracking continuously except for when
doing TX calibration, so I am suspicious that this is the sole reason for
this behavior, and I am concerned RF performance will suffer with this
disabled.
Bit 7 on register 0x16B relates to quadrature tracking loop gain. I
wouldn't rule it out, but I don't think it's the direct cause.
I suspect the relationship with older UHD versions is the change in
gain tables. Unstable quadrature tracking against a constant input
implies some other dependent factor being on the margin. The tracking
algorithm is dependent on low DC offset, which is directly tied to
gain settings.
The critical point is around 33-34 dB of receive gain. That's when the
LNA comes up and there's a large change in the analog filter gain.
Being on one side or the other of that point greatly affects noise and
calibration performance. That point shifted by 1 dB with the updated
gain tables, so if you were testing right at the margin, you could
seen major differences between versions.
-TT
-TT
On Fri, Jun 5, 2015 at 11:15 AM, Tom Tsou tom.tsou@ettus.com wrote:
I suspect the relationship with older UHD versions is the change in
gain tables. Unstable quadrature tracking against a constant input
implies some other dependent factor being on the margin. The tracking
algorithm is dependent on low DC offset, which is directly tied to
gain settings.
I can confirm that large discontinuities on the in-phase component
only are related to quadrature tracking, though that part should not
be surprising. What tends to instigate the instability is the presence
of large DC offset. To handle DC offset, the AD9361 has another
tracking loop which may itself go unstable.
Like any tracking loop, the active baseband DC offset correction is
dependent on loop gain and the operating rate. Rate is directly tied
to clock rate and the loop gain is currently fixed at midpoint. These
parameters determine attack/settle time on DC offset tracking. The
ideal settings will be application dependent, and what we're finding
out now is that default combinations may lead to instability under
certain conditions.
For those inclined to explore, the parameter "BB DC Shift M" in
register 0x190 controls DC offset loop gain. Basically, we've outgrown
the default setting.
Regarding the effect of changing gain setting at start vs. runtime,
there is a second form of DC offset correction for front end RF
components (BB tracking corrects the analog LPF). This second
correction is table based and gain changes at runtime will force an
update on the table values. Those updates coupled with unstable
tracking loops may lead to non-deterministic behavior.
We're working on an approach to manage these parameters in a general
way that doesn't limit applicability under different scenarios. In the
meantime, I'll look into creating some test cases and example code
next week that people can try.
-TT