Replies: 11 comments 39 replies
-
one reason might be: I am using "best-practice" imports, e.g. I am not using this is using https://pypi.org/project/black/ and some more stuff. I am also running on a CPython compiled and built from upstream sources. None of above should be a bummer, and it is arguably best practice in Python in general. Anyways, if you have issues with Python related things, I can certainly help! Need some logs, errors dump, whatever, plus system (OS) and Python details. I should also note, above script shared via GitHub Gists is deliberately written to be complete and self-contained. This is just to make cross-testing and discussions easier. At least that's what I hope;) Personally, I am running code actually from a proper command line tool, classes etc containing very similar code, but structured differently, and I can run this stuff from the command line like: and so on .. but this code has already grown quite a bit bigger, and it includes automated tests:
those warnings come from MyPy, a static type checker for Python, and they are due to the fact that openEMS (the Python bits) is sadly not type annotated. anyways, Python details;) |
Beta Was this translation helpful? Give feedback.
-
|
Ok, I got your model up and running, there was an issue with my Visual Studio Code environment. But when I tried to fix the mistake with xy plane meshing (your calculated resonance is far off the expected value) your model automation no longer finds the resonance and that's where it gets nasty. I propose to start simple and use a fixed length, use a wideband excitation from DC to 600 MHz, remove all your automation and decoration stuff and create a very basic S11 plot. That will make the model code much easier to work with, until we have reached a state where results can be trusted. |
Beta Was this translation helpful? Give feedback.
-
ok, makes sense, agreed. I will create a minimal example like you say and post again. |
Beta Was this translation helpful? Give feedback.
-
|
ok, 100 lines of code https://gist.github.com/oberstet/8f0b8da6ffe3e33e8118d338525cce8a but it doesn't work :( this is pretty frustrating. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Tobias, But while trying to fix the issues, and improve a few other details, I am struggling with a trivial issue: I can't get your model code to plot dB(S11), and that is really a requirement here. No lookup if minima, just plain plot of the S11 data! Can you help me out? I can plot from my own Python models, but your code doesn't like my plotting attempts. Best regards |
Beta Was this translation helpful? Give feedback.
-
|
Hi Tobias, I now investigated your model and applied a few changes. One change was to reduce the distance to the simulation boundary from 2 wavelengths to 1/2 wavelength. For the FDTD tools that I use in my day job for antenna design, a distance of 1/4 wavelength to the boundary is enough. The near-field-to-far-field transformation will take of calculating the far field pattern, you don't need to place the field sensor itself at far field distance. I'm pretty sure that the same is true for openEMS. I added export for *.s1p S-parameter files, so that I could easily compare results in an external S-parameter viewer. There is some effect from meshing the wire diameter in xy-plane, as expected, and there is a strong effect of the boundary condition. The MUR boundary is much worse than the PML for absorbing waves at steep angles, it is essentially a resistive sheet only. When I changed the model to PML, simulated S11 was much better, as you can see from the attached comparison plot. The model with PML and somewhat finer mesh in the xy-plane to resolve the wire diameter is attached. For all models, I used the gaussian pulse excitation, this is really the best solution for S-parameter simulation. Dirac does not have the smooth spectrum that we need! Best regards edit: fixed one mistake in S-parameter export, which had used hard coded 50 Ohm reference impedance and ignored your port impedance parameter. That is why the plot below shows 50 Ohm as Z0, that label is wrong. Ref impedance is 70.8 ohm as defined in your model. minimal_dipole_volker_finemeshxy_pml.zip
|
Beta Was this translation helpful? Give feedback.
-
|
awesome! still in the middle of sth, but I will study your comments and code in detail today!
sure, that's what you said, and I thought Dirac would therefor be the right excitation, since a Dirac pulse (isn't that basically one rect wave with raise time zero? and hence have waves of all frequencies?) would create a broad spectrum? anyways, I'll revisit this aspect .. |
Beta Was this translation helpful? Give feedback.
-
|
great, I get it! please don't get me wrong .. I have almost no RF know how or experience, so definitely, let's do what you know should work! having said that, I'm nevertheless tempted for a few comments .. since even though I lack RF, I do have some math and signal processing background: any time domain function that has at least one non-continuous, non-differentiable location will have infinite bandwidth in the frequency domain rectangles, saw tooth, etc are all good. they have finite number (countable many) locations where they are non-continuous / differentiable the gaussian pulse has finite spectral density all of above are "event like" .. in the temporal domain .. but are unsuitable if one needed a continuous stream of waves of defined spectrum a sinus signal is continuous and differentiable everywhere, and its of infinite duration, hence a continuous stream of (a single) wave white noise is nowhere continuous or differentiable, has infinite bandwidth, with a flat power spectrum and pink noise reduces the power spectrum from flat to a power law ... so it has limited energy for higher frequencies .. given any power spectral density threshold T, there always is a largest finite frequency so that all higher ones have less power anyways, details, let's do exactly what you know and suggest! |
Beta Was this translation helpful? Give feedback.
-
|
Hi Tobias, the "continous stream of waves" that you mentioned is exactly the point: we don't want that! For FDTD we want to send a signal for a limited time, and the software then calculates propagation of the signal inside the model, until the energy in the model (excitation + residual signal due to resonances) has decayed to almost zero. That "almost zero" limit is the energy limit that you set in the solver parameters: Not sure if you saw the picture above that I added for Gaussian pulse: that is the desired limited time signal that decreases smoothly towards high frequencies. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Volker, thank you so much for your explanation! love it=) This level of information "connecting the dots" involved is exactly what I was missing (and very sadly isn't in the openEMS docs). In fact, this was in the back of my head .. as some dissonance .. because, sure, for scenarios where "one time limited duration signals" are wanted (because of the energy thing), a one gaussian pulse is perfect, I get that! if one wanted to use white or pink noise in such a scenario, then the raw signal isn't cutting it, but one would need to time-shape it using maybe a gaussian envelope. But anyways, that's a different thing, and not what you clearly say is established practice, which is just the single gaussian pulse. Sure, one "rect step pulse" or "one sawtooth pulse" also has a lot of spectrum, but it'll be more complicated, and then why? ;) fwiw, for the "directivity" or "3d radiation plots" .. I don't have a full picture yet .. because naively, a "continous stream of waves" might be ok too, or even better than a single pulse. But as mentioned, I am not here to criticize, modify or reinvent established and working practices in RF, to the contrary, ideally, I just want to know how to learn the established methods, compute established numbers using models .. geometries .. which I can then tweak .. knowing the numbers resulting can be well understood and compared! awesome! anyways, I was again interrupted by other stuff, but I hope I'll be able to catch up later, and then post again. |
Beta Was this translation helpful? Give feedback.
-
I'd like to add that all signals with abrupt transitions are problematic in FDTD (and possibly all numerical simulations in general), including the Dirac pulse or the Heaviside step. If used, they must be used with caution. The problem is that computer simulations have limited numerical precision. The use of sharp edges will stress the algorithm in the worst possible way, creating significant signal distortion like overshoot, overshoot, and numerical dispersion. Here's an example, from Wikipedia, of the numerical dispersion of a square pulse signal in a simple 1D FDTD scheme. The pulse distorts as it propagates in a vacuum media. Numerical_dispersion_of_a_pulse_signal_in_1D_FDTD.ogv.360p.webmAnother problem is that many RF structures have erratic resonances at very high frequencies that are not usually encountered in daily use. The use of an impulse or a step means the spectrum will often contain unwanted high frequencies outside of the intended operating frequency of a structure, creating invalid results. For example, a coaxial cable eventually becomes a waveguide. In the waveguide regime, the propagated waves are no longer single-mode TEM waves, but a strange multi-mode mixture of TEM, TE00, and other waveguide modes. When this happens, the coaxial cable becomes useless for most purposes. Similar phenomena also exist for other transmission lines like microstrips. These waveguide-like resonances also exist in 3D structures like different planes in a circuit board. This is why a Gaussian pulse is used for excitation, it's still a broadband signal, but it's smooth in the time domain without abrupt transitions, and the overall bandwidth of the pulse can also be easily limited. |
Beta Was this translation helpful? Give feedback.
-
thanks for underlining! I kinda expected that. any non-differentiable function, regardless of only countably many abrupt changes (step, dirac, sawtooth, ..) or non-countably many (white noise), and regardless of only spatial (-inf to +inf in many timesteps) or only temporal (-A to +A in 1 timestep) will be a problem.
very interesting, thanks for this example! this looks bad. essentially it is "all fake". the pulse isn't doing the step instantaneously, and the vacuum isn't a vacuum (a passive space). the over/undershoot at the end of a rect cycle is entirely an artifact of simulation. analyzing the artifacts and limits of the simulation doesn't help with antenna design. looking at this immediately triggers side questions .. likely irrelevant, so don't bother: a) why does it show at the end, not the begin of rect cycle? b) how would a ideal/perfect setup look like that produces the same results? I would have expected some setup (also real world) to exist that exhibits over/undershoot at the begin of a rect cycle .. but not at the end. anyways, I'm just a newbie, have no clue, and ask a lot of dumb questions;) thank you a lot for your comments and the material you posted!
alright. got it! this is clearly an advantage over white noise with gaussian shaped envelope or not. just one Q: a single gaussian pulse is broadband, but doesn't provide a continuous long time excitation .. one that runs for say 5min all the time on all frequencies. I guess RF engineers don't need that? and hence the question doesn't come up. which still puzzles me. or is more like: yes, it would be nice to have a continuous long time excitation which is broadband, but not using non-differentiable functions? |
Beta Was this translation helpful? Give feedback.
-
|
Hi Volker, alright, please find the adjusted https://gist.github.com/oberstet/2fa832d542e5bf2590d9cab344f827d4 I've copied all your changes, left NOTES and QUESTIONS in the source, and tried to keep the length etc to the bare minimum and fully self-contained. you corrected some issues that apparently were in and it does "work". though I don't trust the tool I guess at this point. the results are not repeatable. pls see my NOTES so in a way, I am more puzzled than before:( the touchstone file for 1 run is here: https://gist.github.com/oberstet/594f684eb362b5e7b13fbb9668ce2bcb - I haven't checked that file as I do not have any tool that is able to read it. is there an OSS tool that can digest this format? the matplot plot for that same run is here:
the results printed for the that run: |
Beta Was this translation helpful? Give feedback.
-
Don't worry ... we guys have spent many years at the university to learn (and understand) these things, and many more years in industry, just for one purpose: to make your busy life easier, so that you can request ready-made solutions.
Don't worry ... only the stupid companies pay for a consultant to do the design work, but you are smart and try to offload the work in the OSS community. |
Beta Was this translation helpful? Give feedback.
-
|
just to leave no wrong impression:
|
Beta Was this translation helpful? Give feedback.
-
What I described is the bare minimum of RF design, it basically just rephrases the following fact - "if you want to know whether a component is the right part to buy, you can download its S-parameters from the vendor's website and try connecting it to a matching network using a simulator and see how well it works." It only takes 5 minutes to do a simple simulation, but you obviously have to know what S-parameters are in order to do this.
Well, if you're doing it for fun, I would say that simulations can always be ignored in favor of the old-fashioned trial and error using real-world measurements of several prototypes. The only difference is that each iteration takes weeks instead of days as making PCB and shipping them takes time. I'd even argue that spending a few hours on soldering and desoldering components, screwing and unscrewed SMA connectors from a network analyzer is a necessary learning experience for every newcomer in electronics. My first RF project was a multi-stage filter, I translated the filter directly onto a breadboard, and it took me several hours of head-scratching before I realized that all my stages were misaligned and a filter simply won't work without tuning...
Regardless of whether simulations or pure experiments are used, it won't be a "quick" process. But after finishing this process, at least you would have some working knowledge about RF circuits by then, such as knowing the definition of a 2-port network. |
Beta Was this translation helpful? Give feedback.
-
simulation sounds more fun;)
long ago I've done PCB hand assembly of SMD parts on notebook prototypes as a summer job for a German office machine company. required steady hand and good eyes. which didn't get better over the years;) anyways, I don't feel the desire, and I am happy that I already found a professional PCB(A) house in Germany which does small numbers, and basically everything I ever wished for, for small money. anyways, thank you so much for your professional perspective, hints and tips! |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, this seems very useful indeed! My idea is to use this for de-embedding the port imperfections for on-wafer modelling, where lumped ports are attached between signal and ground polygons of GSG probe pads. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Volker, fantastic!! thank you very much. fwiw, it'll take a bit to digest and work in all your comments, and also to come up with results using scikit-rf (which looks pretty good so far), so the following are just a couple of replies to aspects where I do know about (mostly, SW arch/eng)
yes, that's what I assumed .. also the "+1" thing ... and now I'm wondering: should we use
yes, unavoidably (the temporal length of a single gaussian pulse is already defined by the minimum/maximum frequency it is limited to, as that determines the rise time etc), and I was also worried about that, which is why the single gaussian pulse always seemed a bit questionable to me and a gaussian shaped (over a multi-second time scale) continuous white noise excitation seemed preferrable .. but that's not in openEMS .. and it is not what RF engineers are commonly doing you say (and I believe that of course). catch 22 :(
yes, I like having stuff written in the proper system location (the tempfile area), and I like them to be overwritten so no crap is accumulating, and if I want to keep stuff, I just copy it from the tmp folder to wherever, but I can easily add some "run serial" or "run date" to the folders, but I really dislike storing crap in my Git working directory;) I am working with working directory == git repo working directory.
This is the most important hint and advice for me. Thank you! I am coming from a world where "identical" means: identical, to arbitrary precision, not limited even by finite bits in IEEE floats or what.
I will use
as a definition and work from there, but I can outline how a "proper/exact" solution would look like:
then a simulation using multiple threads would need to properly partition the workload .. e.g. have all threads run from different seeds but the same geometry and meshes wouldn't really accelerate things I guess .. so the workload partitioning is actually the harder problem, but rgd "repeatable random numbers", above approach is scalable and allows you to recompute simulation results exactly ... today, tomorrow and next week
aaahhh, I got it! thank you=) I wasn't aware at all.
oh yes, a lot!! thanks again=) Cheers, |
Beta Was this translation helpful? Give feedback.
-
yes, I would want to, but how do I do that in openEMS? [EDIT: posted as an issue https://github.com//issues/153] asking doesn't help:
because, yes, I know that of course, but it doesn't help me. I need code. also it doesn't help being offered hallucinations;)
and so on ... |
Beta Was this translation helpful? Give feedback.
-
|
rgd the mesh generation and such, I've now studied your fixes for my obviously lack of sufficient meshing in detail. I think I got it. wherever the material is changing abruptly, in one, two or three axis at the same position, a full volumetric fine mesh is required. fwiw, I think it could still be improved, specifically in XY plane. rather than fiddling around with setting some mesh lines manually and then using "smooth mesh", I'd rather create all mesh lines explicitly. is that a valid strategy? XY plane cut through center (middle of lumped port). it is obviously asymmetric. it also only uses very few mesh lines to cut the lumped port. and the resulting volumetric elements (I guess cells in the simulation) are of uneven size, out of (lumped port) axis
how is this stuff done in commercial/professional tools? is there some "auto-mesh all" magic that just does the right thing? |
Beta Was this translation helpful? Give feedback.
-
You are right, I should have checked than in more detail in AppCSXCAD. I was expecting a different mesh here, based on my code. Not sure what is going on here. EDIT: stupid mistake, not the sign in the code below. Shame on me!
If you understand what a proper meshing strategy is, sure! There are also some projects for openEMS on automatic meshing, but I am not familar with those. The difficulty is that you want a mesh that is fine enough to resolve fine geometry detail, but no finer than necessary. The smallest mesh cell will detemine what time step can be used in FDTD calculation, and by creating very small mesh cells you enforce a small timestep which will slow down your simulation. And besides the timestep, you also increase the total number of mesh cells, which you solve at a given MCells/s rate. So efficient meshing is really the key here. Fine enough, but no finer than that. For your meander antenna cases, it should be not too difficult to implement that. For a generic case, it is a challenge.
Yes, there is automatic meshing that gets in right in many cases. I have sent you a link for tutorial video on FDTD meshing with a commercial solver, which gives a lot of background information what mesh structure we would like to create, and why. |
Beta Was this translation helpful? Give feedback.
-
|
thank you so much for all your hints one more time! and thanks specifically for the links you've sent. impressive! it will surely take me some days to digest, I think it is spot on, highly appreciated=)
ahh, yes! indeed here is the meshing after fixing. looks perfect for me, nothing to do for me;)
fwiw, I've baked your wisdom above into code. please see below. did I make stupid mistakes, does it make sense anyways? I mean from a RF engineering perspective. code wise, I'm pretty sure it'll come in handy, but that's on me to make sure, no worries.
even though this package is completely private at this point, pls let me know if you want your quote removed or changed or linked or what - as you like, just drop me a line. |
Beta Was this translation helpful? Give feedback.
-
|
rgd the "perfect" meshing of a simple dipole, there is I guess only one question left at my current state of understanding. the meshing of the change of end of dipole arm material to air is covered by a fine mesh with the fine mesh spreading across both the air volume and the end of arm at the same fine resolution. cool! I get that. however, the lumped port is only covered by the fine mesh itself, whereas the other material next to it (the dipole arms) is not finely meshed (with a resolution identical to lumped port mesh) question: is that something to improve? IOW: should the mesh resolution along an axis be a "smooth" (differentiable) function of position on that axis? easy to fix of course, I am just asking whether it makes sense from an RF PoV ..
put differently, which meshing is "the best": A, B or C? (current code after fix above is B)
and just to be sure, the volumetric elements (aka cells) resulting after meshing do not need to be actual cubes, but are allowed to be cubicles, of arbitrary aspect ratio, right? I mean, "ideally" == "RF practically good enough";)
|
Beta Was this translation helpful? Give feedback.
-
Reality is continuous, but for FDTD we discretize the model (and resulting fields) into small boxes. This means an approximated model geometry, and limited degrees of freedom for the solver to put the correct field values. So for accuracy, dense mesh is better. But dense mesh means a larger model, which takes longer to solve. So the answer what is "best" really depends on the goal: ultimate accuracy, or fastest simulation, or some reasonable compromise. If we don't know what the is best compromise for our needs, we usually try different mesh density and compare results, and then decide what difference in results is "good enough". By doing this on a many geometries, we then learn to estimate a suitable mesh upfront. Side note: there is another solver method (FEM, finite elements in frequency domain) where local mesh refinement in areas of high energy/fields is part of the solution process. But openEMS uses FDTD, so we neet to set the mesh upfront.
Yes, correct. The aspect ratio should not be too extreme, but cell size is allowed to be quite different in x,y,z, if that is appropriate for the model geometry. One more detail that will be relevant to your work: For PCB stuff where we have lines that are very thin compared to the xy dimensions, it is also possible (and common!) to simulate the metal as zero thickness sheet, and not resolve the 17µm metal thickness at all. The losses are then handled by openEMS with a surface impedance mapped onto the thin sheet, you will find this in the openEMS transmission line examples. So for your meander antenna work, your mesh-from-edges code can be limited to xy plane, and use a single mesh line for teh conductor in z direction. (If you look up the transmission lines examples, you will also note that they do not put the mesh lines exactly on the edge, and instead use the "thirds rule" to offset the mesh line from the conductor edge. This helps to model the correct transmission line impedance with only a few mesh cells across the line. Google search should give some more info on that. For your PCB antenna, I think it's totally ok to put the mesh lines on the conductor edges, the resulting error is not critical for that case.) |
Beta Was this translation helpful? Give feedback.
-
alright, got it! so it's really about trying to tinker around, and lots of experience which knobs to turn. there are indeed quite a lot of variables, like geometry, mesh, excitation, .. and all seem to impact results.
it's pretty quick even with some 100,000's cells. my patience for poking around is like 5min, otherwise an hour is ok. anyways, I don't have time for it, but of course this could be massively parallelized if needed, and firing up 100 VMs with 800 cores on cloud for 1 hour would go a long way. I don't need it now, I have more fundamental problems, eg the bandwidth thing .. and antenna size ..
awesome!! thanks for making this explicit!
alright, I wasn't aware at all, but it sounds pretty much what I want/should do! so again: thank you so much for making me aware! in the meantime, I've optimized the parametrized meshing, fixed a number of small things, including the "differentiable" function of axis position for mesh resolution. turns out, the resulting model (which I also optimized) is working pretty stable
I could now analyze higher order harmonics. DC-7GHz. without changing anything else it converges "good enough" on a fixed point "close enough" to my main frequency of interest it is borderline working at 10GHz, which makes sense, as the wire perimeter (~10mm) is on the order of lambda/4 of 10GHz. so I guess other effects kick in I should probably say: I wasn't aware at all of the apparent (and it seems universal, at least I checked couple of dipoles) fact that every dipole exhibits higher order k-harmonics only where k is odd. There will be a deep reason for this I guess. understanding why this happens, and how, would obviously be quite useful. do you happen to have a reference that might go into this aspect? And it is "odd", not "prime". I checked that;) and of course I am wondering: can I have an antenna type with even harmonics? with power2 harmonics? with prime harmonics? obviously, this k-odd harmonics thing (if it would apply to all antenna types, which I don't know) will make it impossible to cover 446MHz at fundamental resonance, and 869MHz at a harmonic .. not even with "some bandwidth". just from the numbers, I would need to go much lower with fundamental resonance, and then have both 446 and 869 being k-order harmonics for some odd k's. like 29MHz. of course it doesn't help that 869 ~ 2* 446. unless I had an antenna type with even or power2 harmonics. I begin to get a feeling for the problems in antenna design .. maybe .. I think;) sub-ghzfundamental resonance only:
up to 7Ghz3th, 5th, .. 15th harmonic:
up to 10GHzartifacts (I think) become stronger .. actually, I would only trust it up to and including 7th harmonic (~3GHz)
|
Beta Was this translation helpful? Give feedback.
-
|
Hi Tobias, it's not really tinker around, there are mostly expected effects and dependencies, but it depends on the user's simulation experience and understanding of the device under test. When I give FDTD hands-on classes for the commercial solver, these are 2 days seminars because the users already have an RF design background and understanding of their devices that they want to simulate. Regarding simulation speed: what I mentioned becomes important when you go to more complex models. Just now I am simulating an antenna model with 3D stuff around it, which is 11M mesh cells, and other models are much larger. And to be prepared for such large models, you need to understand that simulation time depends not only on the number of cells, but also on the smallest mesh cell dimension. If the smallest mesh cell in your model is shrinked by factor 10, the simulation will take 10x longer, because the FDTD timestep is reduced to resolve field propagation across that small dimension. That's why we don't want mesh into 17µm metal thickniss if all other dimensions are much larger. Antenna harmonics: That's really the wavelength-dependecy which you can't change. We have zero current at the open end of the radiator, and that occurs when the dipole arm is lambda/4, or lambda/4 plus multiples of lambda/2. To learn some basics, try to get an introductory university textbook on RF. "Hochfrequenztechnik" by Frank Gustrau is one example, it covers the basics and many practical applications. There are scripts from RF classes online as well. Regarding artifacts: if you mean the low frequency ripple for your more wideband simulations, this looks like artefacts from stopping the FDTD simulation too early, before it is converged at low frequencies. This might be from running into the number-of-steps limit (not sure what the openEMS default value is, have a look at the comments in the sources) or from residual enery limit (EndCriteria=1e-4). You can check if EndCriteria=1e-5 reduces the ripple, otherwise it is the number-of-steps limit that stops simulation to early. |
Beta Was this translation helpful? Give feedback.
-
I am really glad for your support, and I am fully aware that your tips and hints are "expert level", and that it is in a way quite unusual to receive such support in a forum of a OSS package. I highly appreciate your help! But if you don't have the time or for any other reason, I can fully understand, if you want to limit your time or would rather redirect me or similar. No problem, I get it.
ahh, ok! I wasn't aware of these connections. this is quite important to know, so thank you one more time for your spot on, perfect hint!
Yeah, that could be helpful;) Thanks for the concrete book recommendation as well!
Yeah, your picture, and in the meantime, I've figured out my mistake with the odd-order harmonics thing: my mistake was thinking of EM only in terms of magnitude, but of course currents are vectors, have a direction, and as such, can cancel out - which explains why there are only odd, not even harmonics. I haven't looked into how this cancellations looks in EM vector space or electromagnetic waves at the Physics level or what, I guess I would really need "more basics" and dig into EM theory etc;) But I can grok the cancellation at a general level as a consequence of math in vector spaces in general. And I am soon going back to "Far-field vs Near-field" and "Paraview" and all that. rendering the current distribution within the dipole in time should make such effects visible. E.g. the other "effect" I'd love to look at visually is what happens at >7GHz .. around 10GHz ... when dipole perimeter approaches quarter wavelength, I would expect this to be visible in a current/time view on the dipole surface. Maybe I need a super fine mesh, will see.
Yes, the ripples around DC in wideband analysis is 1/3 of the artifacts/questions I meant. I am using an upper bound of 4.1GHz to catch 7th harmonics, and those ripples disappear when using 1GHz, it is perfectly flat around DC then. I tested your hint decreasing EndCriteria to 1e-5: it works!! the ripples are (almost completely) gone, here:
so your EndCriteria tip clearly answers "Q2: yes, artifact" in the following summary of my remaining puzzlement the other questions Q1 and Q3 are also unclear to me at this point. I would more lean towards or expect: "Q1: yes, always (for any dipole)." and "Q3: yes, always (for any dipole)" .. but I'm not sure .. don't know ..
|
Beta Was this translation helpful? Give feedback.
-
|
I think (not sure) that the relative bandwidth at harmonics is rather similar, but the absolute bandwidth increases due to the high frequencies. |
Beta Was this translation helpful? Give feedback.
-
|
thanks! I see. the nasty radiation pattern does not sound nice. I'm curious whether I can see that in an 3D FF plot .. which comes back to the "how to do that, including paraview" ... the other issue from which this one was split;) fwiw, here is chatgpt .. it "sounds" right .. it makes sense .. gonna read the paper you posted better over christmas.
|
Beta Was this translation helpful? Give feedback.
-
|
here is when using end criteria of -60dB: ripples are completely gone. after running for an 1 hour:
|
Beta Was this translation helpful? Give feedback.
-
|
here is the consolidated/minimal code: https://gist.github.com/oberstet/ec9858cd4ba38ce7a9e37cea25e16a67 |
Beta Was this translation helpful? Give feedback.
-
|
alright, making some progress, I now have both standard dipole and monopole models with meshing and lumped port working, and reproducing theoretical values pretty closely (close enough), and with parametrized meshing granularity which allows to trade off cpu time vs precision. I'm gonna close this issue, thank you both again a lot for all your help and tips! I am obviously still digesting;) if you think a PR with a dipole example would be welcome, pls let me know, I can create a simple script similar to existing examples
|
Beta Was this translation helpful? Give feedback.
-
|
this discussion has become quite extensive/unwieldly, and the original issue (like in the title) has been resolved (thanks again for helping!), hence I closed the discussion, but now that I am slowly digesting all the tips, I would like to come back to 2 specific comments by @biergaizi :
I think I'm on a good track rgd simulation, and I plan to have a prototype PCB manufactured soon, because I want to verify the simulation results in the real world. now here is my next newbie problem;) the simulation gives my S11 and S21 depending on frequency for my antenna. I've done some research, and it seems I would need a VNA to analyze the prototype PCB in the real world and verify results are close to simulation. is that correct? I have also looked at some VNAs, and obviously, I cannot afford industry leading state-of-the-art kit. simple as that. then I've looked at USB3 based VNAs, which tbh, seems attractive both price-wise, and because I can do all the work on my notebook, which has better display / UI controls than a bench top kit anyways;) do you know / what do you think of : https://www.zeenko.tech/librevna ? it's ~500 bucks, OSS/OHW, fits in a notebook bag, tech specs seem good and sufficient for my sub-Ghz antenna thing anyways. makes sense?
in the meantime, it became obvious to me that I won't be able to avoid it:( in addition to antenna, I need RF switches, impedance matching and external connectors before even reaching a LNA/PA. I might also want to try PIN diodes to adjust the electrical length of my antenna .. the bandwidth I want is a challenge .. I can do 80MHz (simulated), but not the ~600MHz. maybe one unswitched fractal antenna would work .. will see .. but maybe not .. and if so, maybe PIN diodes can do the trick anyways, I had a look a Qucs. it is pretty much unmaintained for years, and is built on Qt4 .. which is EOL for some time already and not in distros by standard anymore Qucs-S is somewhat maintained ... at least more than Qucs. Do I really need "Qucs's unique RF simulation features" for my simple stuff (sub-ghz)? Would Qucs-S be my best bet (I can't afford pro, non OSS tools)? I could wrap for current distros or even update Qucs for newer Qt ... but that would be significant work I'd rather not do;) |
Beta Was this translation helpful? Give feedback.
-
I already told you the solution, if you refuse to accept my perfecting working solutions, I can not advise you further. I shall repeat it one more time: Qucs-S is great for general circuit simulation, but because it replaced Qucs's own simulation engine designed for RF and microwave circuits with ngSPICE, RF simulation is NOT supported, which means it has lost the RF features from Qucs. There's no option of doing any S-parameter simulation at all. So yes, using the original Qucs is absolutely required. Thus, you're forced to make a choice between the original Qucs which is unusable due to obsolesce, OR the new Qucs-S fork, which is modernized but does not support RF simulations. Thus, Qucs remains the most powerful FOSS circuit simulation and there's currently no replacement. What's the workaround? As a stop-gap measure, the best way of doing it is running the obsolete Qucs in a container separated from the host system, this way it can keep using its own legacy Qt4 runtime without polluting the main system. A ready-made self-contained AppImage executable is already provided here: https://rmano.github.io/qucsAppImagesBuild/ If you don't trust the binary, use the source script to build one yourself: https://github.com/Rmano/qucsAppImagesBuild/blob/master/compile_qucs.sh You can also do it in a chroot of a old Debian system or something. |
Beta Was this translation helpful? Give feedback.
-
If it doesn't have to be OSS, you can also have a look at QUCSStudio. Created by the same guy who also started QUCS, but closed source and Windows only. |
Beta Was this translation helpful? Give feedback.
-
thank you! crystal clear. I'm gonna use Qucs because without S11 it's pointless, and work around / get around Qt4 somehow.
ok, I see. that's unfortunate, cannot use then. I've left windows ten years ago, I think it was called windows 7? and while I'm still occasionally forced to use windows when doing consulting gigs for companies, I will not use it privately or in my own company, even not indirectly in a VM or what, period. but nevertheless, thanks for bringing it (QUCSStudio) up! good to know in principle. |
Beta Was this translation helpful? Give feedback.
-
the discussion split out is about how to create a most simple, center-fed half-wave dipole model using openEMS in Python.
I'm gonna repost link to the latest code
https://gist.github.com/oberstet/8877417387c622f59700612818a1484d
which includes all improvements and corrections suggested in #151 by @VolkerMuehlhaus
results from running above self-contained complete script using
is:
Beta Was this translation helpful? Give feedback.
All reactions