Slow retuning?

[adampbeardsley]

@Dachelemma and I are looking at the lost dutchman data from 2019 and noticed an RFI line that doesn't shift as expected between files. Recall that our observing script would tune the SDR, take some data, then shift up by 1 MHz and continue taking data. Each tuning is a separate file.

Here is a waterfall from one tuning, centered at 1.410 GHz.

There is a very bright RFI line at about 1.41075 GHz. The astute observer will notice the line does not start at time = 0, but there are actually a few integrations with no line.

The next file, centered at 1.411 GHz

and zoomed in on the first few integrations...

We see that after the retuning, the line started at 1.41075 GHz + 1 MHz, then in the middle of integration 3 it switched to the correct frequency. I think this is because the radio didn't actually retune until the third integration.

Perhaps we need to put in a delay to be sure the radio has time to retune? Even better would be if it's possible to query the radio to ensure it's ready.

[adampbeardsley]

Updating with a few references that might be helpful (or not).
I started to wonder if the RTL-SDR might have a way to check if it's ready to start collecting data - e.g. a "data ready" flag somewhere.
RTL-SDRv3 datasheet - doesn't have a ton of useful info about interfacing with it. But it does tell us the tuning chip is R820T2. I'm curious if the tuner itself tells us if it's ready.
R820T2 datasheet
R820T2 register description - I haven't found anything yet, and even if the chip has a "ready" flag, it doesn't mean it's exposed to the RTL-SDR USB interface...

Along another line, I started looking at gnuradio code to see if they've exposed anything there. The documentation is rough. However, I noticed in our own top block, in our set_c_freq function we do sleep to "allow the radio to settle."

CHART/src/chart/blocks.py

Line 137 in 889996e

sleep: Time to sleep to allow the radio to settle. Default 0.5 seconds.

I'm not sure what motivated us to put that in, or how we chose 0.5s as the default (I was the one that put it in, and don't know why). So an easy test will be to try a longer wait. Would be nice to know why it takes so long to retune, if that is the culprit.

[adampbeardsley]

Some more evidence. We see this in data from a different run as well. I don't recall the exact setup here, but I think it was on the roof at ASU (data from July 31, 2019. It was probably hot.)