Quick Tune not being applied

[chasebad8]

I am having an issue with quick tune and it's respective functions.

I have downloaded https://github.com/Nuand/bladeRF/blob/master/host/libraries/libbladeRF/doc/examples/quick_tune.c from github and compiled/ran it.

The program runs with no issues however when I add a printf statement with "bladerf_get_frequency(...)" it returns the last frequency that it was tuned to using normal (bladerf_set_frequency( ..)) tuning technique.

The quick tune seems to have no actual effect.

Versions: bladeRF-cli version: 1.8.0-git-5cf9fd29 libbladeRF version: 2.2.1-git-5cf9fd29

Firmware version: 2.3.2 FPGA version: 0.11.0 (configured from SPI flash)

[takeshi87]

I've started experimenting with quick re-tune in bladerf2, in fpga mode. From what I observed it's (usually*) not the issue with re-tune not happening, but rather with bladerf_get_frequency. It seems like it returns only those values that were set by bladerf_set_frequency - not taking into account the scheduled frequency changes.

• another issue is bladerf_set_frequency doesn't seem to always work properly anymore after first scheduled frequency change. It seems like if all "slow" tunes should happen between any "quick" tune... but it doesn't make much sense, as there should be possibility to refresh the tuning parameters. Some calls to bladerf_set_frequency result in frequency change - but with I/Q data of some other frequency probably. I've been also able to get "Calibration TIMEOUT (0x247, 0x2)" issue when invoking it too often, sometimes interleaved with fast tune attempt...

On my side: bladeRF-cli version: 1.8.0-0.2019.07-4build1 libbladeRF version: 2.2.1-0.2019.07-4build1

Firmware version: 2.3.2 FPGA version: 0.11.0 (configured by USB host)

[takeshi87]

I made wrong assumption, stating that I tested it in FPGA mode. Docs state it should be the default mode, however, with proper libbladeRF and FPGA version, it still chooses HOST for some reason:

[DEBUG @ host/libraries/libbladeRF/src/board/bladerf2/common.c:263] Default tuning mode: Host
[DEBUG @ host/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:2276] bladerf2_set_tuning_mode: New tuning mode: Host

Verifying it in both HOST and FPGA mode gives very similar result, with FPGA mode sometimes giving additional error prints:

[ERROR @ host/libraries/libbladeRF/src/board/bladerf2/rfic_fpga.c:384] _rfic_fpga_get_frequency: _rfic_cmd_read(dev, ch, BLADERF_RFIC_COMMAND_FREQUENCY, &freq) failed: An FPGA operation reported a failure

Simplifying my program I noticed the issue happens even in such case:

• bladerf_set_frequency to freq A [OK]
• bladerf_get_quick_tune -> quicktune#1 [OK]
• bladerf_schedule_retune using quicktune#1 [OK]
• bladerf_set_frequency to freq B [Not OK]

Looking at I/Q data after last step there seems to be a very short distortion at the moment when frequency change should happen, but no actual change.

Any ideas how to troubleshoot it further? I can provide +/- short example program revealing such behaviour.

[takeshi87]

OK, if anyone is interested - I found the issue and some (hackish as of now) workaround. Both problems with get_frequency after quick tune (showing invalid frequency - the one of the last set_frequency), and the one with set_frequency not working after quicktune schedule are related to how both normal tune and quick tune functionalities are connected together.

For normal tune, at least in host mode, frequency setting utilizes ad9361_set_rx_lo_freq. This has some clean-up bult-in, related to quick tune functionality disabling (especially calling ad9361_fastlock_prepare with prepare=false). This doesn't work in libbladeRF, as it has it doesn't use standard API for quick tune setup. Forcing "unprepare" part of ad9361_fastlock_prepare seems to fix the situation, at least regarding to invalid slow tuning after quick tune.

There also seems to be an additional workaround applied in AD code for making sure "ALC" changes between profiles, it seems to be missing in bladeRF implementation.

For workaround, calling something like below before frequency change seems to work:

int32_t ad9361_fastlock_force_unprepare(struct ad9361_rf_phy *phy, bool tx)
{
	uint32_t offs, ready_mask;
	if (tx) {
		offs = REG_TX_FAST_LOCK_SETUP - REG_RX_FAST_LOCK_SETUP;
		ready_mask = TX_SYNTH_READY_MASK;
	}
	else {
		offs = 0;
		ready_mask = RX_SYNTH_READY_MASK;
	}
	ad9361_spi_write(phy->spi, REG_RX_FAST_LOCK_SETUP + offs, 0);

	/* Workaround: Exiting Fastlock Mode */
	ad9361_spi_writef(phy->spi, REG_RX_FORCE_ALC + offs, FORCE_ALC_ENABLE, 1);
	ad9361_spi_writef(phy->spi, REG_RX_FORCE_VCO_TUNE_1 + offs, FORCE_VCO_TUNE, 1);
	ad9361_spi_writef(phy->spi, REG_RX_FORCE_ALC + offs, FORCE_ALC_ENABLE, 0);
	ad9361_spi_writef(phy->spi, REG_RX_FORCE_VCO_TUNE_1 + offs, FORCE_VCO_TUNE, 0);

	ad9361_trx_vco_cal_control(phy, tx, true);
	ad9361_spi_writef(phy->spi, REG_ENSM_CONFIG_2, ready_mask, 0);
	return 0;
}

[KarlL2]

I agree it seems that bladerf_get_frequency doesn't take into account bladerf_schedule_retune, possibly because you can schedule it in the future and it could be messy to track the exact current frequency.

Note also that bladerf_set_frequency is always blocking while bladerf_schedule_retune may not be.