added alternative radial stub model

[michal777]

Hi,
First of all, I'm neither a software developer nor scientist, probably I need feedback about the model, the code and using github.

I'm trying to change the microstrip radial stub model to something more accurate. While playing with microstrip filters I found out that dimensions in qucs must be much bigger than in openEMS and real life to get the same result.
I found some available papers in the internet and modified radial stub model according to them.

The first paper I found is [2]. It presents a simple closed form model, another more difficult model and a third one which is mix of the two. Unfortunately some needed variables are not explained in the paper. I chose the simplest model and went to another work: [1] which explains calculations of some variables for the simplest formula from [2] (dimensions corrections for fringing field). The [1] contains also explanation of a more difficult model but I can't implement that (the problem is I don't know how to obtain k_mn acc. formula 5.2). The [1] also mentions that there is another model of corrections of dimensions that differs by the term epsilon_r (Giannini's), I guess it's something like quoted in [3] (although this work seems to contain some errors, I'm not sure I can rely on that but the original work is not available for free).

Please let me know what you think. This model seems to be working. If you think I can proceed with that I can try some simulations in openEMS and build some models (although I've got only some random FR4 and nanoVNA v2 clone to do the tests).

[1] Design of a rectenna for wireless low-power transmission, Akkermans, J.A.G.
[2] A New Simple and Accurate Formula for Microstrip Radial Stub, Roberto Sorrentino, Luca Roselli
[3] A Crooked U-Slot Dual-Band Antenna With RadialStub Feeding, Hyo Rim Bae, Soon One So, Choon Sik Cho, Member, IEEE, Jae W. Lee, Member, IEEE, and Jaeheung Kim, Member, IEEE
[4] Performance Characterization of Radial Stub Microstrip Bow-Tie Antenna, B.T.P.Madhav, 2S.S.Mohan Reddy, 3Neha Sharma, 3J. Ravindranath Chowdary 3Bala Rama Pavithra, 3K.N.V.S. Kishore, 3G. Sriram, 3B. Sachin Kumar 1Associate Professor, Department of ECE, K L University, Guntur DT, AP, India 2Associate Professor, Department of ECE, SRKR Engineering College, Bhimavaram, AP, India 3Project Students, Department of ECE, K L University, Guntur DT, AP, India

[felix-salfelder]

On Fri, Oct 22, 2021 at 02:04:24PM -0700, michal777 wrote: I'm trying to change the microstrip radial stub model to something more accurate.

Thanks. Maintainance-wise it is easier to add new models than to modify existing ones. I would prefer an rstub2, and leave rstub intact, regardless of how bad or inaccurate it is. This will retain and guarantee compatibility with old versions of Qucsator. (Your commit message, "add...", looks misleading.) (Alternatively, Can you justify why the additions should be mixed up with existing code?)

Please let me know what you think. This model seems to be working. If you think I can proceed with that I can try some simulations in openEMS and build some models (although I've got only some random FR4 and nanoVNA v2 clone to do the tests).

I can add your model to Qucsator once I have convinced myself that it works as intended. When adding a new model, there should be a test ("netlist.txt" + desired output) that makes use of it. I do no't have time to read the papers you cited. NB: I am not actively maintaining Qucsator, nor am I using it. Also, not entirely sure in what shape the Qucsator test suite is. All I would want before a merge is that "make check" does something nontrivial involving the new model. There's the option to add rstub2 to Gnucsator, same procecure. Gnucsator does not actually need modifications in order to load/run additional models... It ought to be clear why adding user models is required, yet the process needs some streamlining.

[michal777]

Thanks for the comment, I continue my attempts (not ready yet). The model from my first commit seems to be not better (actually worse acc. openEMS simulations but it's tricky to do it right so I'm still not sure). I added another one to test it. I hope to make some measurements soon to check if any of them can be a good alternative.

I actually kept the original model and added others as options possible to select from drop-down list (for convenience) but I agree that making new component is better to be sure old projects are safe.
I'm not sure I understand the difference between adding models to qucsator and gnucsator, I'll try both if my tests will show some reasonable results.

[felix-salfelder]

On Mon, Nov 01, 2021 at 03:29:36PM -0700, michal777 wrote: I actually kept the original model and added others as options possible to select from drop-down list (for convenience) but I agree that making new component is better to be sure old projects are safe.

The drop-down exposes unnecessary complexity in the component model. Currently this is not even configurable. The best option is not to touch it at all.

I'm not sure I understand the difference between adding models to qucsator and gnucsator, I'll try both if my tests will show some reasonable results.

Gnucsator (essentially Gnucap) is configurable. It has a configuration file that defines most available features including components. Currently, some devices from Qucsator are bulk loaded through the microstrip_wrap plugin. The line "load qucs/microstrip_wrap.so" in gnucsator.rc essentially hardwires this and ... ... would ideally look more like load_qucsator_device microstrip/bondwire.cpp load_qucsator_device microstrip/mscoupled.cpp load_qucsator_device microstrip/msrstub.cpp load_qucsator_device microstrip/msopen.cpp [..], so the addition of more models or variants looks straightforward. It needs to be implemented, or scraped together from code that does very similar stuff, the urgency of this is moderate -- it would be better to move on (use Verilog-A models, for example).

[michal777]

A short update:
I did a prototype, it's handmade on FR4 but the dimensions are ok and I roughly measured permittivity so it should be good enough.
The first conclusions: the original qucs model is not much worse than these alternative that I'm testing. Reactance below resonance is not far from measured in all cases but resonance is much below the measured in all cases (error 10-20%).
Other observations:

• The most complicated model seems to be a little better and it includes losses.
• In the tested cases correction of dimensions for fringing field don't really matter.
• There's some assumption in [1] which is not proven to be valid, maybe that's a problem

I'll maybe check the models again, maybe try another model [2].
I wonder if I can blame dispersion of FR4 for that inaccuracy. The model (as presented in [1]) includes infinite series with wavenumbers corresponding to very high frequencies but no correction for FR4 eps_r drop, although I've no idea how the mathematical abstraction relates to physics (just guess).

Attached below some more details (not finished yet), if anyone interested (kicad PCB and measurement with a decent VNA included).
radial_stub_tests_20211109.zip