Fix recently-introduced mixed-mode bug#268
Conversation
| # Tone-rank always needs swaths, while ST-EVD/FDNF only need it | ||
| # for dithered modes | ||
| swaths if (using_tone_rank or not uniform_pri) else None, | ||
| dop[frequency], |
There was a problem hiding this comment.
Should not one rescale the Doppler values per center frequency of input raw data channel_in.freq_id where RFI is mitigated prior to filtering to a common frequency band frequency? perhaps the Doppler's sensitivity to relative bandwidth less than 5% is negligible in entire workflow.
There was a problem hiding this comment.
Yes, I had the same thought about the Doppler centroid (DC) here. The presummer has the same issue. By the time we get to azcomp the data have been filtered, so the usage there is obviously correct.
Thinking about these azimuth interpolation steps a little more, since we're going to filter the range spectrum in a later step, maybe it's actually better to use the corresponding DC for centering the azimuth spectrum in earlier steps. That is, if we had put the range-filtering first, we'd obviously want to use the DC for that band. But they're linear operations that should commute, so the order shouldn't actually matter.
Following that train of thought, why are we using the unmodified center frequency here? Alas, it's only being used to label the frequency axis of the range spectra, so that's the correct behavior.
Like you say, it's a small effect anyhow.
3 participants
I should know better by now, but when adding the tone-rank RFI suppression feature I messed up the bookkeeping of the subband frequency ID. This causes problems in mixed-mode processing, particularly when mixing 77 MHz with any dual-frequency mode. In that case we downsample the 77 MHz data twice, so there's one iteration where the output RSLC data will be labeled "B" but we're using L0B data from "A".
This PR changes the code to use the correct label for querying the source L0B.