-
-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Potential error in cauer band(pass|stop) center frequency calculation #716
Comments
It's always best if a tool uses the same definition for variables for all choices. As I stated before about this tool, in real life, you can't buy components with the values calculated by the tool. Also component "Q" and package parasitics isn't taken into account so the analysis will be flawed. The higher the frequency and narrower the bandwidth, the more the measured results will deviate. The only way to have accurate simulations is to measure every component on a LCR meter capable of measuring at the actual filter frequency. Components must be measured using a jig replicating the PCB or circuit parasitics. Measured component data is then used to update the schematic. Manufacturers data is always suspect. Attached is a filter I designed decades ago for an Intelsat satellite receiver. 70MHz BPF with amplitude and group delay equalization. |
I am unsure what source was used for Qucs-filter tool design. The Handbuch zum Filterentwurf by R.Saal recommends to use geometric mean for the center frequency of the band pass filter. You can find some notes in the Qucs technical manual section 14.2 https://qucs.sourceforge.net/docs/technical/technical.pdf |
Context:
Issue:
Basically, the center frequency is computed as the arithmetic mean between the two corner frequencies, although I really though we shall use the geometric mean here.
Looking at the transfer function of a generated filter, we can see a slight shift in frequency (1GHz to 2GHz band-pass):
With a small patch implementing a geometric mean, I obtain the following results:
This looks much more satisfying.
I'll prepare a pull request, but in the meantime, I'd be happy to have some confirmation by an RF expert.
The text was updated successfully, but these errors were encountered: