Antenna port power turns on unexpectedly during HackRF power-on

[miek]

When powering on a HackRF One, the antenna port power turns on briefly without being enabled by the user:

This shows that the port power turns on as soon as VAA is enabled, and stays on until !ANT_BIAS is raised ~150ms later.

#955 proposed a solution to this but didn't end up fixing the problem. A change has been pushed to portapack-mayhem that is reported to fix it: https://github.com/eried/portapack-mayhem/pull/413.

Version information

Operating system: Ubuntu 20.04

hackrf_info output:

hackrf_info version: git-c8695e0
libhackrf version: git-c8695e0 (0.6)
Found HackRF
Index: 0
Serial number: 0000000000000000909864c8345451cf
Board ID Number: 2 (HackRF One)
Firmware Version: git-26c0f70 (API:1.05)
Part ID Number: 0xa000cb3c 0x004e4f5c
Opera Cake found, address: 0

[miek]

@jboone and I did some troubleshooting on this on Discord when it was first reported and found a few things:

1. The ~150ms on-time corresponds to this delay in the firmware main: https://github.com/greatscottgadgets/hackrf/blob/master/firmware/hackrf_usb/hackrf_usb.c#L216
2. This is caused by the default power-on register settings in the RFFC5072 as it happens before the firmware applies any register changes.
3. It should be fixable by running rffc5071_setup to apply the correct register settings before enabling VAA, assuming the digital portion of the RFFC5072 works while only powered by VCC.

[mossmann]

Additionally, that delay could be moved to the RAD10-specific enable_rf_power() as it is not needed for HACKRF_ONE.

[schneider42]

Apparently that delay was introduced in 62799d4158a29c0d3254d1df5aae462ac8238644 and can safely be moved to the rad1o specific part of the code.

[martinling]

Moving the delay to the rad1o-specific enable_rf_power function reduces the bias pulse at power on from ~150ms to ~80ms. The remaining figure is presumably the time between VAA turn-on and the RFFC5071 being reconfigured.

It should be fixable by running rffc5071_setup to apply the correct register settings before enabling VAA, assuming the digital portion of the RFFC5072 works while only powered by VCC.

Unfortunately this doesn't seem to work: I tried putting a call to mixer_setup(&mixer) before enable_rf_power(), but there was no effect on the bias pulse.

My changes are on this branch.

[martinling]

It turned out that mixer_setup wasn't sufficient because the default register settings it loads do not include the necessary GPO setting; that comes later in rf_path_init. After modifying the default register values accordingly this now works.