RF Leak when sample rate set to 4MS/s or lower even if no receive or transmit occurs

[MartinHerren]

Steps to reproduce

#!/bin/bash

# Step 1: Receive
# Receive for 10 seconds 145MHz @ 8MS/s
hackrf_transfer -s 8000000 -p 0 -a 0 -l 0 -g 0 -f 145000000 -n 80000000 -r /dev/null
sleep 10

# Step 2: Transmit
# Transmit for 10 seconds 145MHz @ 8MS/s
hackrf_transfer -s 8000000 -p 0 -a 0 -x 0 -f 145000000 -n 80000000 -w /dev/zero
sleep 10

# Step 3: Set samplerate to 4MS/s
# Receive 1 sample 145MHz @ 4MS/s
hackrf_transfer -s 4000000 -p 0 -a 0 -l 0 -g 0 -f 145000000 -n 1 -r /dev/null
sleep 10

# Step 4: Set samplerate to 8MS/s
# Receive 1 sample 145MHz @ 8MS/s
hackrf_transfer -s 8000000 -p 0 -a 0 -l 0 -g 0 -f 145000000 -n 1 -r /dev/null
sleep 10

# Step 5: Transmit with 4MS/s for drift comparision
# Transmit CW for 60 seconds 28000500Hz @ 4MS/s
hackrf_transfer -s 4000000 -p 0 -a 0 -x 6 -f 28000500 -n 240000000 -c 100
sleep 20

# Step 6: Set samplerate back to 8MS/s to stop RF leak
# Receive 1 sample 145MHz @ 8MS/s
hackrf_transfer -s 8000000 -p 0 -a 0 -l 0 -g 0 -f 145000000 -n 1 -r /dev/null

Expected behaviour

No additional RF should occur with 4MS/s than with 8MS/s. Especially not when only receiving.

Actual behaviour

RF leak is found around 28MHz, perhaps at other frequencies too.

Version information

Operating system:
Debian 9 on RaspberryPi 3

hackrf_info output:
martin@pi3:~ $ hackrf_info
Found HackRF board 0:
USB descriptor string: 0000000000000000406464c82335144b
Board ID Number: 2 (HackRF One)
Firmware Version: 2017.02.1
Part ID Number: 0xa000cb3c 0x006a4757
Serial Number: 0x00000000 0x00000000 0x406464c8 0x2335144b

Output

The steps correspond to the above script, in addition step 0 is when the HackRF gets plugged into the USB port:

0. HackRF plugged in: weak USB leaks appear
1. 10 seconds of receive 145MHz 8MS/s followed by 10 seconds pause: USB leaks change due to data transfer
2. 10 seconds of transmit 145MHz 8MS/s followed by 10 seconds pause: USB leaks change due to data transfer
3. Sample rate set to 4MS/s by receiving a single sample followed by 10 seconds pause: new stronger and persistent RF signal appears
4. Sample rate set back to 8MS/s by receiving a single sample followed by 10 seconds pause: RF signal disappears
5. 60 seconds CW signal transmitted on 28000500Hz at 4MS/s followed by 20 seconds pause: RF leak appears again, following the same frequency drift than the transmitted CW signal above. Signal persists again after transmission terminated.
6. Sample rate set back to 8MS/s by receiving a single sample. RF signal disappears

The USB leak is not critical and can probably be reduced or eliminated by using a shorter and better shielded USB cable with ferrite beads and not running it in parallel and close to the receiver's antenna coax. The strange RF leak even when not receiving nor transmitting is more annoying.

The presence or the frequency of this RF Leak seems unaffected by other settings of the HackRF like the transmit/receive frequency (In the example it uses 145MHz and 28MHz).

I understand sample rates lower than 8MS/s are out of spec for the ADC but they shouldn't occur anyway. Or setting out of spec sample rates should be prevented.

Note: neither the HackRF's nor the test receiver's oscillator are properly calibrated, so the 28000500 signal appears 200-300Hz higher.

[MartinHerren]

After some more analysis it seems it is the ADC that leaks. 28 MHz is a harmonic of 2 and 4 MS/s but not of 8MS/s.
Did some tests monitoring around 32MHz and i got the same leak for 4, 8 and 16 MS/s but not with 10MS/s.

Just strange that it follows the same frequency drift than the transmitted signal, would that mean that the frequency drift of the transmitted signal is mainly caused by drift in the ADC sampling frequency and not by drift of the LO ? So using a stable and accurate external clock as source would not even help a lot in having a stable frequency ?

Also strange that i receive a stronger signal leaking from the ADC than from the transmitted output.

Looking forward to receive my RF shields for the board and a metal case.

So i guess we can close this issue. Perhaps mention the leak in the 'tips & tricks' ?

[Dinsmoor]

@MartinHerren Nice catch and analysis. Although it isn't optimal to have any sort of leakage, the only thing that can help now is good shielding. If you haven't gotten 'the can' yet, I'd recommend it, although it only covers the RF portion. A good metal case may help with the rest of the board.

[dominicgs]

@MartinHerren As @Dinsmoor said, this was great analysis.

I agree that this can be closed, but I really don't want it to be lost in the archive of issues in this project. Would you mind if I copied it to some documentation somewhere? Perhaps on the wiki?

[MartinHerren]

No problem, you are correct it is more something to be documented than an issue so it can be closed.

I received my RF shied, just have to find time to install it. Change to the metal case will also help.

What bugs me more than the leak itself it that the RF drift might come more from drift in the sample rate than drift in the LO. I'll experiment more once I installed a TCXO. I ordered heatsinks that will probably help to keep the sample rate drift to a minimum.

Thanks for your work on HackRF !