Right now this requires editing the materials.json file (which is very easy actually), but I'm planning to make a user interface for this to make it easier. Unfortunately it's hard to get good data for most materials - many manufacturers only spec their FR4-like materials at 1 MHz, which isn't very useful when you're working in the 1 GHz to 10 GHz range (cheap materials are usually highly frequency-dependent).
Yeah, free data is a mess.
Maybe if you partnered with some manufacturers to get the actual test data or something... but needless to say that's a heck of a stretch!
Rolloff is based on the Djordjevic-Sarkar model, i.e. it is extrapolated from the loss tangent in a way that satisfies the Kramers-Kronig relations, such that the resulting material model is causal. This basically means that the loss tangent is proportional to the slope of the permittivity as a function of frequency. In other words, low-loss materials also have a very nice near-constant permittivity, whereas cheap materials have a lot more roll-off.
I've noticed that manufacturers often specify combinations of permittivity and loss tangent that seem to violate this requirement, I don't really know what to do with that. Either the permittivity or the loss tangent must be wrong. If I override the loss tangent based on the permittivity slope, I get completely nonsensical results for some materials, such as negative loss tangent (because some manufacturers claim that their permittivity increases with frequency - presumably just measurement errors, but it ended up in the datasheets anyway). So I usually trust the loss tangent values given in the datasheet over the slope of the permittivity, which means that one permittivity value is enough to determine the rest.
Ah.. just lovely.
FYI, note that loss tangent is just that, the tangent. If it were negative, well, that'd be weird of course, but the loss factor is still |delta|, and it could be they're reporting that. Or their data is presented inconsistently, so they give so-and-so curve but tan delta is actually at 1MHz and has basically nothing to do with the rest.
Where mu or epsilon is a function of frequency, you can build an equivalent circuit to arbitrary precision; for example, typical reasonably-complete* inductor models have a skin effect term, a core loss term (if applicable), and the overall dominant terms of resistance, inductance and capacitance.
*The completeness being, I would guess, 10% or better accuracy in most parameters (R, L and C), over >3 decades range.
Which would be handy enough for PCBs, say from 10MHz to 10GHz, if you could extract such data, and make use of it.
This perspective is rather more useful to me -- I mostly work with circuits and their simulations -- than to a field solver, but if it's useful, hey.
Not really a bug, but a known limitation. The solver assumes that the skin depth is significantly smaller than the conductor itself (which is generally true for frequencies above 100 MHz for most PCBs). I actually have an alternative solver which can simulate this properly, but it requires a lot more processing power. I've used it to simulate Litz wire to see how it affects losses:
Ahhh.... so this isn't a full solver, but it's using a sheet conductor model (I guess), and approximating losses as... well, as given, I guess, since you'd plug in a complex permittivity and go with it.
So the trick would be, modeling the conductor's complex conductivity (or mostly-imaginary permeability and/or permittivity, if better), and doing so without grinding to a halt..
Or even better, doing the full sim, if you can afford the computation time of course.
The problem with this type of solver is that it requires way more processing power than the idealized solver, because:
- Once you introduce non-ideal conductors, the matrix you need to solve becomes complex instead of real.
- Since the resulting matrix is non-Hermitian, you can't use Cholesky decomposition anymore, instead you have to use LU decomposition (which requires about 2 times more processing power). Right now the program doesn't even include an LU solver yet, so this will also increase the size of the executable.
- In order to make the solver work at high frequencies, you need to add tiny cells near the surface of all conductors (much smaller than the skin effect itself). But in order to make it work at lower frequencies, you need to fill the entire conductor with cells, you can't leave the center empty. This results in a huge increase in the total number of cells, especially with the simplistic mesh generator which I'm using now. I could also re-generate the mesh for each frequency independently, but this is also pretty slow.
Ahh.
Well, a factor of 2 isn't bothersome to me -- if you recast this more as a field solver (for simplified extruded geometries) than an impedance calculator, a few seconds is no trouble.
As is, it takes I think a bit under a second to do a run, on my computer, which isn't a particularly special machine. If you want people to run this on Android, say, you might have a harder time justifying that (but, who needs to calculate fields on the go, anyway?
).
A progress bar, compute time estimate, and choice of solver options might be cool.
Maybe I can make it an option once I have a better mesh generator, but for now I think it's just too slow. Most users don't care about loss at low frequencies, since you don't need transmission lines in that frequency range anyway.
Hey, don't tell me what I don't need!
It might not be a transmission line down there (i.e., much less than a sizable fraction of a wavelength in length), but a quick tool that can solve for loss and skin effect can still be a very useful engineering tool.
I suppose I could throw in a crude hack that basically prevents the AC equivalent resistance from becoming lower than the DC resistance (calculated based on the area of the conductor). Not very accurate, but it would avoid the unrealistically low loss figures at low frequencies.
And one can always do curve fitting to spackle over the hack. Instead of max(DCR, ACR), use a smoothing function, etc.
I'm making the assumption that permeability drops off at a rate inversely proportional to the frequency. It's a very crude approximation, but it's the best I could find. The 'unity frequency' is the frequency at which the permeability becomes equal to 1. So if you have a DC permeability of 4000, it will start dropping off at 250kHz. Maybe this is indeed too optimistic, I'm not sure. I could switch to a model where you can set both the frequency where the roll-off starts, and the frequency where it ends. But again, I'm having a really hard time finding reliable data for this.
Ah.
Yeah, reliable data isn't something you're going to find -- it depends on the alloy (e.g., AISI 1020 low carbon (mild) steel, or a hundred other common varieties?), and condition (grain size, mechanical working, hardness (annealed vs. quenched), and so on.
I believe I've ran across a few papers that talk about the gyromagnetic moment running out in the GHz, so that would be the ultimate limit, at least for iron atoms. I'm not sure what you do inbetween, aside from measuring precisely the material you're about to use in an application -- clearly, powdered iron cores are useful into the VHF range, so it's not an absolute cutoff. Real measurements will be frustrated by eddy currents, grain size (one thing that powdered iron has to its advantage: fine crystallites, and also weird structures where applicable, like concentric spheres with carbonyl iron), dielectric environment (powdered iron cores use a resin binder; one could imagine ferrite or dielectric loaded PCB materials that would have similar concerns) and so on.
Steel is included mostly to demonstrate that ferromagnetic materials are a bad idea for RF applications. Fun fact: ENIG coatings actually contain mostly Nickel, which is ferromagnetic (the gold layer on top is extremely thin). So if you remove the solder mask on an ENIG-coated board in an attempt to get more predictable transmission line performance, you are actually making things a lot worse.
Yup! I've heard tales of waveguides accidentally being ENIG plated, instead of silver. Whoops.
On the upside: plating is on the side and top of the conductor, away from most of the field (which is in the laminate). And this only matters if it's plated before, not after, soldermask. A SMOBC + ENIG board might have lower RF losses if it's left coated with soldermask!
The material list includes a lot of stuff that's not very realistic for PCBs, but I'm also planning to use the same solver for other applications, such as IC design. Tungsten is actually a very common material for vias inside ICs. It's also used as a diffusion barrier I believe, to prevent the copper from contaminating the silicon substrate.
Ah, true -- and, at least there, you have the expectation that the tungsten will be chemically pure (hmm, I don't offhand know what process they use to deposit it -- sputtering?), or at least a consistent alloy, and grain structure.
Why would the numbers be wrong? Resistivity is relatively easy to measure, and AFAIK it's not very frequency-dependent or even manufacturer-dependent. Permeability is a different story, getting good data for this is a real problem. A warning may be a good idea in those cases.
About alloys, and conditions, I mean -- how often are you going to use analytically pure, vacuum annealed anything in an assembly?
Example, copper is more or less copper at room temperature, but at cryogenic temperatures, impurities make a tremendous difference in the residual resistance ratio (RRR).
Which, well, not that many people are doing cryogenic PCBs either, but then, some are -- another reason to have that flexibility, I guess.
I noticed something else: the window always opens in the same place, on whichever monitor it was opened from. I have asymmetrical monitors, so when I open it on the main screen, it shows up in the bottom-right corner (more or less), which seems like the intended location. On my other monitor, it gets pushed off screen a little bit! Most programs remember their screen locations on exit. So, yet another little thing to toss in a new config file.
Tim
Home
Help
Search
Login
Register
