PlutoSDR IQ correction doesn't connect to hardware

[rgetz]

In the GUI, there is a button for I/Q correction and DC offset correction, but it doesn't like it is connected to anything....

In :
https://github.com/f4exb/sdrangel/blob/master/plugins/samplesource/plutosdrinput/plutosdrinputgui.cpp#L223

   m_settings.m_iqCorrection = checked;

but then I eventually get lost in all the OO,

There is something in
devices/plutosdr/deviceplutosdrbox.cpp void DevicePlutoSDRBox::setTracking()
but they are always turned on there...

but I don't see any change in the hardware when I change things.

On the pluto, these should change when I toggle the button in the GUI. (they don't):

# iio_attr  -c ad9361-phy voltage0 bb_dc_offset_tracking_en 
dev 'ad9361-phy', channel 'voltage0' (input), attr 'bb_dc_offset_tracking_en', value '1'
# iio_attr -c ad9361-phy voltage0 rf_dc_offset_tracking_en 
dev 'ad9361-phy', channel 'voltage0' (input), attr 'rf_dc_offset_tracking_en', value '1'
# iio_attr -c ad9361-phy voltage0 quadrature_tracking_en 
dev 'ad9361-phy', channel 'voltage0' (input), attr 'quadrature_tracking_en', value '1'

[f4exb]

The I/Q and DC corrections are done in software. Controlling the correction inside the Pluto would be a new set of controls.
Is there any point of not having the hardware DC and I/Q corrections on permanently anyway?

[rgetz]

Thanks- that makes sense.

If the signal isn’t Quadrature (is purely real) - the on-chip IQ correction can cause what looks like amplitude modulation, as the on chip IQ correction kicks in, tries to suppress the “image” (which isn’t an image - the signal is real). I will make a test, and do some screen captures, so you can better see the issues.

[f4exb]

How comes the signal wouldn't be in quadrature?

[rgetz]

If you send a real signal.

Normally any decoder which isn't interested in phase between I&Q might do better with the correction turned off. Some satellite comms. ADSB, even FM radio. If you have exactly the same signal on the "real" and "imaginary" side of the Rx LO - it isn't quadrature, and may do better for the user to control when I/Q correction is on/off (independent of DC correction).

Example might be easier. I will write up something, and point to it.

[f4exb]

Then my question is how do you send a real signal? If you only use the antenna input it will get converted in a complex signal by the hardware and the pair of ADCs. Do you mean opening the case and inject the signal directly somewhere on the board?

[rgetz]

You can send a real signal by sending the same CW signal (amplitude and phase) into I & Q DACs. They get mixed (at the modulator), and your CW will end up on both sides of the Tx LO (at the air interface).

Your Rx (if tuned to the same LO) gets confused, since it sees what it thinks is an image, and IQ calibration tries to suppress it. (it causes some slow amplitude descreases in the terms of ~50ms; until the state machine realizes it's not converging, and then resets, where it starts over - this super confuses the ACG at the same time, so it's easier to isolate things by setting the gain to manual mode).

There are lots of ways to solve it - including offset tuning, and turning I/Q correction off.

Sorry - picture is worth 1000 words - will try to do this as soon as possible.

[f4exb]

So it would work best if you connect the Rx to the Tx directly since I suppose there is a single LO reference in the AD chip. I think I can get the theory but not the practicality. What is the point if you do not send this signal over the air to another device? I still don't see clearly what you are trying to achieve here.

[rgetz]

No, it can be on two different devices (as you indicated - there is a single reference clock on the AD936x devices, but there are two PLLs for Tx and Rx that can be at different phases (can't control) and frequencies (which you can control)).

If you send out a "real" signal on one device. (CW only on I, all zeros on Q is a way that some users do it by mistake), you will end up with a over the air interface that has an "image" as large as the signal that you are sending. (Euler says 1/2 the power on each side of the LO).

The separate receiver sees the signal on the positive side of the LO as the signal, and on the negative side of the LO as an image. Since images are bad, the IQ correction tries to suppress it - which it eventually fails at; The on-chip IQ correction is a state machine that gives things a try, when it determines it has failed, and gone out of bounds, resets, and tries again. This can cause amplitude perturbations on either I or Q, or both (which appear as amplitude moving down, and snapping back up). Normally - this is bad for digital demodulators, and many people actually turn the on-chip IQ correction off after tuning to a frequency, to stop the perturbations.

That's why people normally need a knob to control the hardware. (3 buttons , IQ on/off, RF DC on/off, BB DC on/off). Most of the time it makes the signals better, some times it makes them worse. The only person who knows that is sitting between the chair and the keyboard.

[f4exb]

Actually I can reproduce a similar case between a HackRF as the transmitter and a Lime mini as the receiver (so completely different devices). It is easy to inject the exact same signal on I and Q with the SSB modulator in DSB mode. The tuning has to be very precise however. The artifacts (deep fades and sideband noise increase) due to I/Q correction (the soft I/Q also produces them) would disappear if frequencies are more than ~10 Hz away. It is funny I have never encountered the case in practice.

[rgetz]

Thanks for testing & sticking with me - I would imagine that it will be a problem on all modern architectures (Lime, Maxim, TI, and ADI) - everyone does a different implementation of similar things.

The amount that offset tuning will help is dependent on the device, sample rate, bandwidth, implementation, etc. I haven't looked at that too much, but can take some measurements. (tuning resolution on Pluto is about ~4.768 Hz (40 MHz (refclk) / 8388593 (pll modulus). I'm guessing that you have to move HackRF and Lime to get 10 Hz offset? According to the datasheet, LMS7002 has Frequency Resolution on the RF PLL of 24.8 Hz with refclock of 52 MHz. (if I'm reading things right - https://github.com/myriadrf/LMS7002M-docs/blob/master/LMS7002M_Data_Sheet_v3.2r00.pdf - which is a pll modulus of 2096774 - so I don't think you can make a 10 Hz step with Lime mini? - even if the software says you are).

As more and more people are using GPSDO (to solve carrier offset issues), their carriers are closer, and they run into the problems with specific modulation schemes; and can not figure out what is going on, or how to make the problem go away.

The devices can make it go away (offset tune some amount (sub 100 MHz on ADI), turn IQ correction off, and then tune back). Things will be IQ corrected, but you won't run into the problem, no matter how close you are. You just need to turn it back on if you tune off more than 100 MHz.

[f4exb]

For very fine offset tuning this is done in software by tuning the modulator center frequency offset rather than the device frequency for which it is done in 1 kHz steps anyway. I have tried with the software I/Q correction that is sensitive to the resulting center frequency.

[rgetz]

Ok - our wiki is back up - I wrote up things at:

https://wiki.analog.com/university/tools/pluto/users/non_quad

As you found - it doesn't take much offset (~10 Hz) to fix things. Comments / Feedback on doc is welcome/appreciated if you want.

-Robin

[rgetz]

Which - now that we can both replicate things - goes back to the original question:

Can we (or did you want to clutter the GUI to) add additional 3 device controls for hardware (1) Quadrature correction (2) BB DC correction, and (3) RF DC correction on/off.

-Robin

[f4exb]

Nice explanation on the Wiki. Something few people know and understand about SDR but as you mentioned it is rare to run into this situation however it is puzzling if you don't know.

As I always wanted to give user maximum control I think I can spend the screen real estate for these 3 additional buttons.

[rgetz]

Thanks for adding something.

[f4exb]

I have coded the change and the BBDC and IQ hardware controls seems to have an effect so I suppose this works. I could not see any change with the RFDC but maybe I need to push the gain close to overload. This is the example of a fairly big Tetra signal:

Actions from bottom to top:

• BBDC is on IQ is off. No ghost image still.
• BBDC is off IQ is off. A big DC spike appears
• BBDC is off IQ is on. A similar effect as you describe takes place: there is a ghost image slowly going up and down
• BBDC is off IQ is off. The ghost image is still present and fixed
• BBDC is on IQ is off. The DC spike disappears but the ghost image is still present
• BBDC is on IQ is on. Both DC and ghost image disappear. Back to normal.

I will soon push on dev.

[f4exb]

On a strong signal the IQ correction is significant but I still fail to see anything changing with RFDC on/off

[rgetz]

Thanks - I will test out once committed.

The easiest way to tell is if you have a signal coming in, make sure Quad tracking is turned on, tune LO off over 100MHz, turn quad cal off, and tune back. You should see large images until quad call is turned on again....

95% of the time, you need to turn it on, and leave it alone. But for that 5%!of the time - you need to turn it off.

[rgetz]

confirmed that the dev branch is working for me.

checked by turning the buttons off, and then, checking status:

rgetz@brain:~/github$ iio_attr -u ip:pluto.local -c ad9361-phy voltage0 bb_dc_offset_tracking_en 
dev 'ad9361-phy', channel 'voltage0' (input), attr 'bb_dc_offset_tracking_en', value '0'
rgetz@brain:~/github$ iio_attr -u ip:pluto.local -c ad9361-phy voltage0 rf_dc_offset_tracking_en 
dev 'ad9361-phy', channel 'voltage0' (input), attr 'rf_dc_offset_tracking_en', value '0'
rgetz@brain:~/github$ iio_attr -u ip:pluto.local -c ad9361-phy voltage0 quadrature_tracking_en 
dev 'ad9361-phy', channel 'voltage0' (input), attr 'quadrature_tracking_en', value '0'

turn the BBDC button on

rgetz@brain:~/github$ iio_attr -u ip:pluto.local -c ad9361-phy voltage0 bb_dc_offset_tracking_en 
dev 'ad9361-phy', channel 'voltage0' (input), attr 'bb_dc_offset_tracking_en', value '1'

turn the RFDC button on

rgetz@brain:~/github$ iio_attr -u ip:pluto.local -c ad9361-phy voltage0 rf_dc_offset_tracking_en 
dev 'ad9361-phy', channel 'voltage0' (input), attr 'rf_dc_offset_tracking_en', value '1'

turn the IQ button on

rgetz@brain:~/github$ iio_attr -u ip:pluto.local -c ad9361-phy voltage0 quadrature_tracking_en 
dev 'ad9361-phy', channel 'voltage0' (input), attr 'quadrature_tracking_en', value '1'

I updated:
https://wiki.analog.com/university/tools/pluto/users/non_quad#sdrangel

Closing this - Thanks for your help.

[beta-tester]

hello @rgetz ...

thank you for the interesting wiki...
at Receiving a "real" signal

but we can see that the amplitude is jumping up and down by a few dB. (which is impossible to show in a static picture like this)

why not using an animated GIF ?
the animation loop only needs 3 or 5 frames to visualize what you mean.
the picture doesn't have many colors - so shouldn't be an quality issue.

EDIT: oh, and thank you @f4exb, for implementing new features for my favorite SDR to my favorite SDR-software ... ;)