Characteristic Impedance mismatch with Keysight ADS calculator
I suspect it has to do with correction for metal thickness. I'm curious about what ADS would say with a thin metal, say 0.1 mil. That said I'm going to close this bug and refer to the current tracker on github where I do have an open issue on this topic (coplanar waveguide and thick metal). If you don't mind, please add any updates there (trying to keep consolidated in one spot). In the mean time I'd go with the ADS result. https://github.com/dmcmahill/wcalc/issues/16
The "Tmet" parameter is ignored for coupled microstrips
https://github.com/dmcmahill/wcalc/pull/22 has added some correction for Tmet. I also think it remains to be fully verified. I was looking at the original references and also at what transcalc did. I think they may have a factor of 2 bug in one of their equations for the correction (one of the references uses space between traces as "2s" as opposed to just "s"). Unfortunately the primary reference for coupled microstrip does not give full details on how the thickness correction should be applied....
Comparing Microstrip and Coplanar Waveguide calculations
closing here and moving to https://github.com/dmcmahill/wcalc/issues/19
My apologies for the very very slow response. I've moved development over to github, https://github.com/dmcmahill/wcalc and am going through all the bugs over here on sf to address them before turning off the sf trackers. I've copied this to issue https://github.com/dmcmahill/wcalc/issues/19 and will have some more to add to the issue shortly.
10% error
Marking as closed, will continue at https://github.com/dmcmahill/wcalc/issues/16
I agree that 10% is pretty large. I've moved development over to github, https://github.com/dmcmahill/wcalc If you are able to share the dimensions you used for this case and maybe add to an issue here: https://github.com/dmcmahill/wcalc/issues I'd appreciate it. I'm guessing that the metal is relatively thicker compared to the width and spacing than what was typical during the development of the equations used by wcalc and others. As I'm looking at the source code for wcalc, I see this note I left...
stripline_calc returns odd values for lc and ld
Good catch. Sorry for the extremely late reply. I've moved development over to github. This is now fixed in https://github.com/dmcmahill/wcalc/pull/18 If you have what it took for the matlab compile, I'd be interested. I have not had access to matlab in many years and have to rely on octave.
bt <= at
My sincere apologies for having missed this for a very very long time. I expanded on that message in this: https://github.com/dmcmahill/wcalc/pull/15 and created an issue to review all warnings: https://github.com/dmcmahill/wcalc/issues/17 at and bt are the notation in the Wadell reference. at is the thickness corrected width and bt is the thickness corrected width + 2*space. You'll note that bt should be greater than at or nonsense will come out of the rest. Essentially what it means is that the...
Output from stripline_calc in stdio mode does not match documentation
Sorry for the very very late reply. I've moved development from a private CVS repo to a public github repo. I've fixed this issue in https://github.com/dmcmahill/wcalc/pull/14
500% error in K value Wcalc rect bar analysis
Marked as pending because I don't believe this is incorrect. Could you elaborate on why you think it should be ~0.05?
Sorry, I know this is an extremely late response but k = M / sqrt(L1 * L2) and so in fact 3.947 / sqrt(17.24 * 11.62) = 0.2788 as the tool reports. I have moved development over to github, https://github.com/dmcmahill/wcalc and plan on using the bug tracker there. I also hope that I'll keep a bit more on top of them. My apologies for the extremely long delay.
Microstrip rho documentation clarification
Fixed in https://github.com/dmcmahill/wcalc/pull/13
Sorry for the long delay. I have moved development from a private CVS repo to a public github repo. I'll be moving the bug tracking there as well. Thanks for the bug report. Fixed in https://github.com/dmcmahill/wcalc/pull/13
clean is incomplete
With my apologies for such a late reply, is this for latexmk (a different utility that unfortunately has a very similar name) or LaTeX-Mk (this utility)? It sounds like the former.
Nonoptimal rules
bug report for a different tool
With my sincere apologies for missing this report, I'm also sorry to let you know that it appears you are using "latexmk" and not "latex-mk". It is unfortunate that these two tools ended up with very similar names and do a similar function but with a totally different implementation. -Dan
No worries. It was a good discussion. I'd rather spend time and find it was ok than...
4π-factor mismatch
I think we both have bugs in our python code. You are indeed correct that ellipk...
Hi, Thanks for the bug report. I'm always interested in them because it is quite...
iconv issues on non-gnu systems