Help with Passive UHF RFID Tag Simulation

[TomJiX]

Hi everyone,

I'm currently working on simulating a passive UHF RFID tag antenna using openEMS. The goal is to model the tag, including a rectangular conducting patch with a central feed gap (where the chip is located), and observe its resonance behavior and input matching.

However, I'm encountering two key issues and would really appreciate a second set of eyes:

---

🔧 Simulation Summary

• Geometry:
  A conducting sheet (30 mm × 120 mm) with a centered 14 mm × 14 mm square hole. A 2 mm feed gap runs horizontally across the hole.
  The antenna sits on a 0.1 mm thick dielectric substrate (εr = 3.2).

• Chip position:
  A narrow 2 mm × 1 mm region represents the chip bridge across the feed gap. Lumped port is placed here.

• Feed impedance:
  Using a lumped port impedance of 50 Ω.

• Excitation:
  Gaussian pulse centered at 860 MHz with a bandwidth of 150 MHz.

• Materials:
  Conducting sheet conductivity = 70,000 S/m. Substrate is lossless for now (σ = 0).

---

Problem 1 – No Resonance in S11 Plot

After exporting and simulating the structure, the calculated S11 shows no clear resonance, the curve is relatively flat, and I don’t see a minimum that would indicate matching. I expected to see a dip around 860 MHz or nearby based on similar tag designs.

What I’ve tried:

• Adjusted feed gap width and length.
• Varying substrate εr and simulation box size.
• Verified mesh density and ensured fine meshing near the feed.

Despite this, no significant reflection dip appears, neither for 50 Ω nor for the chip impedance.
I'd appreciate if anyone could have a look, perhaps I’m missing something fundamental in the geometry or meshing strategy?

---

Problem 2 – Modeling the Complex Chip Impedance

I tried using to model the chip using two small capacitors placed symmetrically on either side of the gap (hoping to replicate reactive behavior), but that didn't lead to better matching either. And a the moment I am using a simple 50  Ω port and handling the complex impedance in the post processing.

Is there a better practice for modeling this kind of reactive chip load in openEMS?

---

What I’m Looking For

• Any tips on why my S11 shows no resonance, is the structure incorrect or something missing in excitation/meshing?
• Advice on best practices to model complex chip impedance, how to correctly simulate a real RFID chip load.

---

📎 Files & Environment Details

I’ve attached a ZIP archive containing:

• The full Python simulation script
• The generated .xml geometry file

➡️ Download sheet_antenna.zip

Environment:

• OS: Windows
• Python: 3.10.11
• openEMS: Latest available build (as of August 2025)

Let me know if you encounter any issues running the files, I'm happy to share screenshots or logs if needed.

---

Thanks in advance for your time and help, I’d be happy to provide any extra info or test ideas you might suggest !

[VolkerMuehlhaus]

• Any tips on why my S11 shows no resonance, is the structure incorrect or something missing in excitation/meshing?

It's a shame that you get no answers with this carefully designed question, which describes your issue very well.

I don't have advice on RFID complex impedance modelling, but some experience with PCB antennas using such a geometry. I haven't simulated your model, but expect input impedance to be inductive at the port. The port impedance that you defined in your code is also inductive, not conjugate match like many RFID antenna design guides suggest. Is this what you wanted to model?

That said, the coarse mesh in your model does not resolve geometry details well, you should add more mesh lines at the boundaries to ensure that metal and dielectric are included with the correct size.

The AddEdges2Grid() function that you used in your model does not evaluate polygons, so all those edges are missing!

[VolkerMuehlhaus]

Attached is a proposal how I would mesh this layout, model in the ZIP file. Extra mesh lines are coded because polygon doesn't support AddEdges2Grid()

sheet_antenna_sim.zip

[TomJiX]

Thanks for taking the time to go through my question in detail!

You’re absolutely right about the port impedance, after checking the datasheet again, I realised I wasn’t using the conjugate. I’ll correct that. I plan to try both approaches for modelling the port again.
(FYI, here’s the forum post where I found the tip for modelling complex impedance.)

I also see what you mean about the mesh resolution, and I didn’t realise that AddEdges2Grid() doesn’t evaluate polygons, great catch! I’ll refine the mesh and re-run the simulation.

As I’m still relatively new to modelling more complex geometries, do you know if there’s a rule of thumb or general logic for choosing mesh resolution? Perhaps based on the frequency I’m evaluating at? Or is it usually a case of refining until the results converge and make sense?

Really appreciate you highlighting these points and for providing the remeshed model, that’s extremely helpful. I'll post update on the progress.

[VolkerMuehlhaus]

@TomJiX Yes, the approach with explicit capacitor elements instead of complex port impedance sounds fine. I used that in other EM tools, but not yet in openEMS, so I can't guide you there.

Meshing: I have some intuition from extensive work with another FDTD tool that has automatic meshing, but the documentation by @biergaizi should give you many valuable hints:
https://fasterems.github.io/openEMS-Project/python/openEMS/Tutorials/First_Lessons.html
This also mentions the "rule of thirds" which I tend to ignore because I mostly work with thick metal models. But for thin sheets, the rule of thirds is a valuable concept.

[TomJiX]

Thanks a lot for the insights and the link, really appreciate it! I’ll check out the tutorial. Cheers!

[TomJiX]

Hi everyone,

Quick update on my progress, I received some helpful advice on refining the mesh (thanks @VolkerMuehlhaus!).

I think I’m getting closer. Based on several simulations with different parameters, it seems the issue might have been related to the bandwidth I chose for the excitation frequency.

Keeping all other parameters constant, I found that the resonance frequency appears to depend on the bandwidth of the excitation signal.
Here’s the plot showing the shift:

From my understanding, the resonance frequency of the antenna should be independent of the excitation’s center frequency and bandwidth (as long as the mesh and geometry remain unchanged), so this result is a bit puzzling.

Is this behavior expected in openEMS due to the way the excitation pulse is handled? Or is it more likely a sign that something in my simulation setup is incorrect (e.g., mesh resolution, boundary conditions, or feed definition)?

Thanks in advance for any insight!

[biergaizi]

Please post the full source code of your current experiment, otherwise it can't be replicated.

When you change fc, the excitation waveform and spectrum are changed. f0 is the center frequency of the carrier, fc is the 20 dB cutoff frequency of the lower/upper side bands due to Gaussian modulation, not the 3 dB cutoff, so the excitation rolls off rapidly. The exact mathematical expression is documented here: https://fasterems.github.io/openEMS-Project/concepts/signals.html#gaussian-pulse

     (0 dB)               f_0
                          / \
                         /   \
                        /     \
    (-20 dB)           /       \
                   f_0-f_c    f_0+f_c

So the first guess is too much spectral roll-offs due to pure excitation.

Furthermore, the resolution of FDTD depends on the shortest time interval and the shortest dimension, so changing fc can change the timesteps and durations of the simulation because the simulation needs to satisfy the CFL stability criteria. Due to both reasons, I believe the choice of fc can affect the resolution of the simulation. I'm not entirely sure, but the fact that your simulation has a "converging" behavior as fc increases (see how the resonance null becomes sharper) is suspicious.

The general practice in FDTD for wideband simulation is to set both f0 and fc to half the of upper measurement frequency, so the excitation is a DC (-20 dB) - f0/2 (0 dB) - fmax (-20 dB) spectrum. Perhaps you can try a 5 GHz excitation (f0 = 2.5 GHz, fc = 2.5 GHz) as an "extreme-value" test. The simulation result of this excitation should be the "right one" if the simulation runs as expected, openEMS has been used for numerous wideband simulations with proven results.

Some other things that you can try:

1. Extract the time-domain excitation waveform of the port (according to https://fasterems.github.io/openEMS-Project/python/openEMS/Tutorials/Parallel_Plate_Capacitor_Waveguide.html#plot-time-domain-waveforms-via-matplotlib), and run an FFT in numpy/scipy to view its spectrum, to see whether the waveforms are behaving as expected, and how much roll-offs exist near your frequency of interest.

2. Excite the structure with a sine wave, according to https://fasterems.github.io/openEMS-Project/concepts/signals.html. You should be able to detect resonance near predicted frequency by the wideband excitation, but it may take a long time due to the resonating structure.

3. Compute the TDR response of a pure transmission line terminated by a resistor, without the antenna, to see if the excitation port has a step discontinuity. The lumped excitation ports are not ideal, if the excitation itself is mismatched to the line, unexpected impedance transforms may occur. https://fasterems.github.io/openEMS-Project/python/openEMS/Tutorials/Parallel_Plate_Capacitor_Waveguide.html#time-domain-reflectometry

[TomJiX]

Thanks for the replies,

I attached the code and added the suggested plots at the end.
I am using a lumped port with a 50 Ω impedance and dealing with the complex part in the post-processing.

So if I understand this correctly:

• The smaller fc, the shorter the pulse and the finer the resolution.
• Wouldn't that mean that if I center the pulse around my resonance frequency, I should have better resolution and see the resonance peak more clearly?

I would understand if:

• A higher fc value might not be precise enough to capture the resonance, or
• The signal was centered at a frequency where there is no resonance.

Here are also the plots for:

• f0 = 2.5 GHz and fc = 2.5 GHz
• The sine excitation

so you don't have to run these yourself. (I hard coded the mesh resolution used in SmoothMeshLines for these plots and all the previous ones).

I have been reading a bit on FDTD simulations, but it's a bit complex to grasp in a short span, thanks for the help.

[VolkerMuehlhaus]

think I’m getting closer. Based on several simulations with different parameters, it seems the issue might have been related to the bandwidth I chose for the excitation frequency.

@TomJiX Did you check for energy convergence for ALL these cases? I firmly believe that is where things go wrong.

For my work, I require models to converge to at least -40dB. The latest model that you postet was set to -30dB only ...

FDTD = openEMS(NrTS=80000, EndCriteria=1e-3, TimeStepFactor=1)

... but even that was NOT reached because the tilmestep limit (80k steps) forced termination. Energy was only down to -22dB.

Having converged time signals is the basis for FFT that gives you the frequency response, so you really need to enable more time steps, and set energy limit to lower values. My suggestion: NrTS=500000, EndCriteria=1e-4

---

Comment on sine excitation: Why would you want to do that? Obviously, you can't to S-parameter sweep from a single frequency excitation.

[biergaizi]

Here's your problem:

openEMS(NrTS=50000, EndCriteria=1e-5, TimeStepFactor=1)

You should not limit the max number of timesteps or change the termination criteria manually, unless you know what you're really doing (e.g. you're using Dirac, Heaviside, or custom excitation, which doesn't have a maximum timestep by default - even then, the timestep should be large enough for excitation and convergence). By default, openEMS only terminates the simulation when energy has decayed below -60 dB to ensure accuracy. The example code limits the timestep because we want to demo the simulation process quickly (without waiting for the simulation to converge to save time). Some limits were hand-picked to be "good enough" only because the authors have seen the full results before.

This is why you see the warning:

Create FDTD operator (compressed SSE + multi-threading)
Operator::CalcGaussianPulsExcitation: Requested excitation pusle would be 92119 timesteps or 5.7296e-09 s long. Cutting to max number of timesteps!

If the energy in the system has not fully decayed, the simulation results are unreliable. But here the problem is actually even worse than that: if the maximum number of timestep is shorter than the excitation signal, the excitation signal didn't even have a chance to finish itself. This is why the simulation results are completely invalid.

When you remove this limitation:

openEMS()

Now the simulation runs as excepted. This is the simulation using f0 = 1000 MHz and fc = 150 MHz, the resonance frequency is correctly shown.

This is how long the real simulation takes:

Create FDTD operator (compressed SSE + multi-threading)
FDTD simulation size: 93x119x58 --> 641886 FDTD cells 
FDTD timestep is: 6.21978e-14 s; Nyquist rate: 6990 timesteps @1.15005e+09 Hz
openEMS::SetupFDTD: Warning, the timestep seems to be very small --> long simulation. Check your mesh!?
Excitation signal length is: 307063 timesteps (1.90986e-08s)
Max. number of timesteps: 1000000000 ( --> 3256.66 * Excitation signal length)
Create FDTD engine (compressed SSE + multi-threading)
Running FDTD engine... this may take a while... grab a cup of coffee?!?
[@        9s] Timestep:         1747 || Speed:  121.7 MC/s (5.273e-03 s/TS) || Energy: ~2.56e-22 (- 0.00dB)
[@    13m26s] Timestep:       291749 || Speed:  244.7 MC/s (2.624e-03 s/TS) || Energy: ~2.41e-20 (-60.37dB)

You see, the required timestep is 291749, not 50000, you're off by a factor by a factor of 6. Just don't use any limit, keep everything as default, openEMS terminates it automatically for you at -60 dB.

Before:

After:

Also, note how the low-frequency response is invalid because the bandwidth of the pulse is too small, so you need to adjust the limit of the X-axis in postprocessing based on fc to avoid invalid results.

The smaller fc, the shorter the pulse and the finer the resolution.

No, higher fc means a shorter excitation pulse, lower fc means a longer excitation pulse. The bandwidth of a pulse is inversely proportional to its duration. It's the Heisenburg-Gabor uncertainty principle at work.

For example,

• fc = 500 MHz

  FDTD timestep is: 6.21978e-14 s; Nyquist rate: 5359 timesteps @1.50007e+09 Hz
  Excitation signal length is: 92119 timesteps (5.7296e-09s)

• fc = 400 MHz

  FDTD timestep is: 6.21978e-14 s; Nyquist rate: 5742 timesteps @1.40001e+09 Hz
  Excitation signal length is: 115149 timesteps (7.16201e-09s)

• fc = 300 MHz

  FDTD timestep is: 6.21978e-14 s; Nyquist rate: 6183 timesteps @1.30016e+09 Hz
  Excitation signal length is: 153532 timesteps (9.54935e-09s)

This solves your original mystery. The lower fc is, excitation takes longer. But, since you have limited the maximum number of timesteps of the simulation, the excitation quality becomes progressively worse due to truncation.

The sine excitation

The sine excitation is not used correctly here. Because the sine excitation only contains a single frequency, it's meaningless the compute the whole spectrum, only the frequency point right at the excitation is meaningful. Since in previous simulations you've obtained difference resonance frequencies, you can try excite these frequencies one by one to see which one is correct, this is what I meant when I say it will take a long time.

But since we've already found the root cause, it's no longer needed.

[biergaizi]

Comment on sine excitation: Why would you want to do that? Obviously, you can't to S-parameter sweep from a single frequency excitation.

I suggested it, as an independent check since they got 4 difference resonance frequencies in the previous simulations (because the source code was not posted, the real reason was not understood by us until now). I suggested that they can try excite them one by one to see which one is "real". But this suggestion was not implemented correctly here, obviously. We've already found the root cause, it's no longer needed.

[TomJiX]

Thank you both for taking the time to go through this. You’re absolutely right, I thought I could shortcut the simulations to speed things up and at least capture the resonance peak position, but I didn’t realize this would affect the results so much. I’ll make sure to run the simulations longer to ensure the model converges.
Just to recap, the issues were first with mesh refinement and then with the number of timesteps. I feel like I have a better grasp of the FDTD fundamentals now. Apologies if these were trivial issues.
I suppose the next step is to find a good middle ground for the mesh to reduce computation time without compromising accuracy.
Thanks again for all the help, it really sped up the debugging process for this project!

[biergaizi]

I thought I could shortcut the simulations to speed things up and at least capture the resonance peak position

You can, but the problem here is that you've truncated the excitation signal by an undersized NrTS. For quick tests, you can truncate the simulation using a bigger EndCriteria, without changing NrTS:

openEMS(EndCriteria=1e-4)  # stops at -40 dB

This changes the depth of the resonance peak, but shouldn't affect the frequency itself too much.

Some other things you can try, besides the obvious thing to refine the meshing:

1. Use a wideband, high-frequency excitation with f0 = fc. A short pulse converges much faster.

2. PML is the most inefficient boundary condition in openEMS. Use Mur's ABC (MUR) for non-critical boundaries. For example, if the antenna is radiating towards the Z axis, use PML_8 only for Z axis, and use MUR for the rest.

3. If an "infinite" lossless ground plane is acceptable, you don't have to model the PCB ground explicitly. You can use x_min = PEC to use the boundary condition to create a ground plane implicitly (Example). This shortcuts the simulation.

4. Use AddMetal instead of AddConductingSheet to simulate the antenna traces using Perfect Electric Conductors, which has highest simulation performance because no additional calculations are needed.

5. Due to compiler-optimization related problems, in many cases Windows build has disastrous performance, slowing down by a factor of 100. Consider running openEMS inside WSL.

[TomJiX]

Thank you for the detailed suggestions, this is extremely valuable information. I’ll be implementing the recommended changes, particularly the adjustments to excitation, boundary conditions, and simulation truncation. Regarding the PEC substitution, I won’t be able to apply that step since the antenna I’m designing is not metallic on a PCB substrate, so the material properties need to reflect the actual conductive layer. Once the optimisation process is complete, I’ll share an update on how the results compare between the simulations and the fabricated antennas.
I really appreciate the clear explanations and practical guidance, it’s a huge help in refining my simulation workflow.