You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
I have been using sckit-rf to successfully time gate calibrated data from a quasi-optic system (50-750GHz).
I noticed today on line 266 of Time.py:
265 #IFFT the gate, so we have it's frequency response, aka kernel
266 kernel=fft.fftshift(fft.ifft(fft.ifftshift(gate, axes=0), axis=0))
267 kernel =abs(kernel).flatten() # take mag and flatten
268 kernel=kernel/sum(kernel) # normalize kernel
An inverse Fast Fourier transform is being used to transform from the time domain to the frequency domain. This should be a Fast Fourier Transform and not the inverse.
I have tested this change and it makes no difference to the results especially as only the magnitude is used and the kernel is normalized on the following line. In that sense it is not a bug but is incorrect!
Regards
Roger Appleby
The text was updated successfully, but these errors were encountered:
Hi,
I checked the latest version of the code and it works fine with negative start time and positive end time. Therefore I did not include this as an issue.
I can see looking at the commit for 221 97ac281 that ifftshift was corrected and the sign changed from - to + . I can confirm that + works fine in my case. I dont believe that I was using scikit-rf before this commit so it has always been this way during the time I have been using it.
Let me know if I can help further.
Regards
Roger Appleby
Hi,
I have been using sckit-rf to successfully time gate calibrated data from a quasi-optic system (50-750GHz).
I noticed today on line 266 of Time.py:
An inverse Fast Fourier transform is being used to transform from the time domain to the frequency domain. This should be a Fast Fourier Transform and not the inverse.
I have tested this change and it makes no difference to the results especially as only the magnitude is used and the kernel is normalized on the following line. In that sense it is not a bug but is incorrect!
Regards
Roger Appleby
The text was updated successfully, but these errors were encountered: