Open radonnachie opened 1 year ago
Oh, see a76e263, there was a bug in buildFilterbank.
@lacker
I am not following the point of this change. Why do you want to change EXTRA_COLUMNS?
I want to be able to control it. I'm constructing debug hits that have filterbank data that overall covers the full BW of the beamformed data. This allows me to stitch together a filterbank file from the hits that contains the data exactly as the dedoppler module saw it. I can in this way verify that the data is intact.
For this to be seamless, I need the hits writer to not pad the channels of the filterbank data.
I also patched the code so that it doesn't miss the last 2 channels of a hit (would amount to 40-2 padding-channels on the upper channel boundary).
Hmm, okay, well that kind of makes sense to me, but at any rate it is reasonable to have the caller able to specify the # of extra columns. So is it missing the last 2 channels right now? It kind of looks like there's a bug with a needless -1 and it's not necessary but here you say -2 so perhaps I'm still missing something.
The needless -1 is what I'm talking about. Last I looked at it (considering the number of channels in my debug hits before a76e263) I noted 2 fewer channels. I think I might've been looking at 0-indexed numbers at the time. Either way, we're talking about the same patch
I'm in the midst of a debug mode that spoofs hits such that the exhaustive beamformed data is available across all of the filterbank data in the .hits file.
The static 'extra_columns' was messing me around. I'll be tuning it to zero in this debug mode.