search

Qucs / qucs

Qucs Project official mirror
http://qucs.sourceforge.net/
GNU General Public License v2.0
1.16k stars 213 forks source link

Coupled lines filters size units #892

Closed simo-zz closed 5 years ago

simo-zz commented 5 years ago

Hello,

Using the filter synthesis tool I noticed that the size units are incomplete:

screenshot_2019-01-09_21-05-54 screenshot_2019-01-09_21-06-43 screenshot_2019-01-09_21-07-31

I understand that the units are referred to meters, so u should be um and m should be mm.

From what I see here https://electronics.stackexchange.com/questions/197455/coupled-line-filter-design-in-qucs in version 0.0.18 units are printed correctly.

Regards, g.

andresmmera commented 5 years ago

It's highly likely that's my fault. I'm writing a fix for that. @guitorri , @felix-salfelder : Should I target the PR to "release-0.0.20-2"?

guitorri commented 5 years ago

Yes, target release-0.0.20-2. I was about to tag and release -rc1. I wait for your fix.

in3otd commented 5 years ago

um, we accidentally opened a can of worms here... As well know to the many Qucs users that were already bitten by this, when a length is specified as "1 m" in Qucs it's interpreted as one millimeter, not one meter (it's also documented, page 16). So when lengths happen to be expressed in meters no unit should be added. We already have a function for this in the Qucs GUI, maybe you can link to that. So you are now back to the initial solution - sorry.

And BTW, spaces between number and prefix/units should be used for all the units, not only ohm.

andresmmera commented 5 years ago

And BTW, spaces between number and prefix/units should be used for all the units, not only ohm

Yes, that was done by adding the space at num2str()

felix-salfelder commented 5 years ago

On Fri, Jan 11, 2019 at 12:35:55AM -0800, in3otd wrote:

um, we accidentally opened a can of worms here...

I remember having tried to fix this a couple of years back. and it doesn't seem obvious. as a strategy I suggest to look at how others do it, see what works & replicate.

FWIW, the only way ive seen others dealing with units is just sticking to numbers, while implying the unit from a sensible collection. the usual default choice is SI units. with those, 1m is 1e-3, no matter if it is a voltage (in volts) or a distance (in meters).

does anyone need yards and inches? verilog can represent that, but 1m still means 1e-3. (we do not have disciplines in qucs..)

struct qucsValue{ double magnitude; qucsDiscipline const& what; };

andresmmera commented 5 years ago

I see your point. However, I think #895 should be a hot-fix for the release. Honestly, IMHO, the best approach is to duplicate misc::num2str() in qucs-filter.

I wanted to mention that from my point of view, the issue mentioned by @in3otd is not so problematic. In practice, if you're in the VHF&down you'll use a ladder or direct-coupled implementation (or elliptic highpass/lowpass filters), but not a transmission line filter.

Rmano commented 5 years ago

The clash between m = milli and m = meters is a classical :-). I think that there are just two kinds of possible solution to avoid any doubt: always force the use the unit (so "1 m" is 1 meter), or never use it (so "1 m" is 1 milli-whatever). Obviously, the correct way under the SI system is the first one, but it is a PITA when entering values. A possible workaround is to allow entering "1 m" for, for example, a resistor and adding "Ohm" (or better, UTF-8 Ω) before storing the value, and asking the user in case of length (be lenient in the input, but store and show always the correct full string).

Which I think is overkill, so just deciding which one has precedence in case of length should suffice...

in3otd commented 5 years ago

yes, forcing to always enter the units would be the most correct thing but would really be a PITA; even if I recommend that the schematics produced by the Qucs tools always specify the units for clarity, personally I often omit them in my schematics and only enter the prefixes. Qucs has always interpreted "1 m" as 1e-3 and, as said, it's even documented (!) so I don't think we should change this behavior. The option to have the GUI automatically adding the unit is interesting, maybe after the Qt5 refactor we could think about that...

It's true that for the filter tool very rarely you will end up with lines expressed in meters but I'd avoid leaving a known bug in the tool, even if it does not occur often.

felix-salfelder commented 5 years ago

On Fri, Jan 11, 2019 at 11:14:00AM -0800, in3otd wrote:

Qucs has always interpreted "1 m" as 1e-3 and, as said, it's even documented (!) so I don't think we should change this behavior.

how about putting an "m" right next to the input field? this will help remembering the documented behaviour, and do no other harm.

The option to have the GUI automatically adding the unit is interesting, maybe after the Qt5 refactor we could think about that...

could mean to always print the unit right next to the input widget. would only require a volunteer.

guitorri commented 5 years ago

Splitting the value and unit fields might help in many cases, say avoid promoting meter to mili. But still there might be cases where dimensional analysis might be necessary. Please open another issue to discuss it further.