[bug] mm² to AWG tables are inaccurate

[brianjk66]

After designing a harness with WireViz and setting show_equiv to true for my wires, I noticed the conversion from 20 AWG to mm² was not correct. 20 AWG should be 0.5mm², but WireViz converted it to 0.75mm².

I took a look at wv_helper.py and noticed that awg_equiv_table seems to have incorrect values for 21AWG, 20AWG, & 18AWG. That's according to this table I found after a quick Google search: https://lexproducts.com/technical/wire-conversion. Other tables I looked at seem to agree as well though.

[kvid]

You are right, the automatic conversion between AWG and mm² is not perfect. The current AWG to mm² conversion does indeed deviate from some other conversion tables, but see my comments below on those deviations that seem to be due to rounding up for safety. IMHO, the current mm² to AWG conversion being unsafe is a greater problem. Based on the definitions described at Wikipedia, this code prints mathematical conversions with 3 digits precision, and compare it to the current conversion table:

from math import pi
for n in range(-3, 41):
  awg = n if n > 0 else '0'*(1-n) + f' or {1-n}/0'
  mm2 = pi * (0.005 * 25.4/2)**2 * 92**((36-n)/19.5)
  mm2tbl = mm2_equiv_table.get(str(n))
  info = f' [{100*float(mm2tbl)/mm2 - 100:+.1f} % = {mm2tbl} mm²]' if mm2tbl else ''
  print(f'{awg} AWG = {mm2:.3g} mm²{info}')

The code above prints this output that shows AWG to mm² mathematical conversion with 3-digits accuracy, and in brackets, the deviation from the mm² values in the current equivalent table:

0000 or 4/0 AWG = 107 mm²
000 or 3/0 AWG = 85 mm²
00 or 2/0 AWG = 67.4 mm²
0 or 1/0 AWG = 53.5 mm²
1 AWG = 42.4 mm² [+17.9 % = 50 mm²]
2 AWG = 33.6 mm² [+4.1 % = 35 mm²]
3 AWG = 26.7 mm²
4 AWG = 21.2 mm² [+18.2 % = 25 mm²]
5 AWG = 16.8 mm²
6 AWG = 13.3 mm² [+20.3 % = 16 mm²]
7 AWG = 10.5 mm²
8 AWG = 8.37 mm² [+19.5 % = 10 mm²]
9 AWG = 6.63 mm²
10 AWG = 5.26 mm² [+14.0 % = 6 mm²]
11 AWG = 4.17 mm²
12 AWG = 3.31 mm² [+20.9 % = 4 mm²]
13 AWG = 2.62 mm²
14 AWG = 2.08 mm² [+20.1 % = 2.5 mm²]
15 AWG = 1.65 mm²
16 AWG = 1.31 mm² [+14.6 % = 1.5 mm²]
17 AWG = 1.04 mm²
18 AWG = 0.823 mm² [+21.5 % = 1 mm²]
19 AWG = 0.653 mm²
20 AWG = 0.518 mm² [+44.9 % = 0.75 mm²]
21 AWG = 0.41 mm² [+21.8 % = 0.5 mm²]
22 AWG = 0.326 mm² [+4.4 % = 0.34 mm²]
23 AWG = 0.258 mm²
24 AWG = 0.205 mm² [+22.1 % = 0.25 mm²]
25 AWG = 0.162 mm²
26 AWG = 0.129 mm² [+8.7 % = 0.14 mm²]
27 AWG = 0.102 mm²
28 AWG = 0.081 mm² [+11.1 % = 0.09 mm²]
29 AWG = 0.0642 mm²
30 AWG = 0.0509 mm²
31 AWG = 0.0404 mm²
32 AWG = 0.032 mm²
33 AWG = 0.0254 mm²
34 AWG = 0.0201 mm²
35 AWG = 0.016 mm²
36 AWG = 0.0127 mm²
37 AWG = 0.01 mm²
38 AWG = 0.00797 mm²
39 AWG = 0.00632 mm²
40 AWG = 0.00501 mm²

The current equivalent table seems to represent a conversion from a selection of common AWG numbers into the closest common mm² value - always rounding up for safety (choosing an alternative wire should not result in a thinner wire that might get too hot when maximum current is applied).

The current code use the same table for converting mm² to AWG, and e.g. converting 0.75 mm² to 20 AWG is unsafe because it would result in a 0.518 mm² wire that has less than 70 % of the cross-section area, and hence will get hotter than the original wire when the same current is applied.

I suggest we instead use a table with mathematically conversions when converting from AWG to mm² (and let the user round up to the closest available wire when needed), but the same table cannot be used directly for converting the other way because the mm² values don't match common wire dimensions exactly. There are several alternatives when converting from mm² to AWG:

• Compute a decimal AWG value by doing the reverse mathematics and rounding to e.g. 3 digits precision, but decimal AWG numbers are highly unusual and might confuse the user - especially for AWG values < 1.
• Show the closest integer AWG value above or below. This might be unsafe because if a user actually use an AWG wire that is thinner than originally specified by mm², then the wire might get too hot when maximum current is applied.
• Show the closest integer AWG value below or equal (i.e. not thinner).

As long as rounding is needed, and rounding to a thinner wire is not safe, then it is impossible to convert in both directions using the same table as we do today.

[thestumbler]

I just ran into this today with some wire which appears to be uniquely specified in mm2 and there is no exact AWG equivalent. It is 0.12 mm2, closest to 26 AWG. I like using the formula instead of a table, and would add my preference to round to the nearest standard AWG vs always going up to the next largest size. I understand the issue, and that makes sense in many applications, but when making small cables, sometimes such rounding up could kick you out of the range of the crimp connectors, for example.

I would also like to see the equivalent value so-indicated, perhaps by parentheses. In my example, it would be 0.12 mm2 (26 AWG), or if you want to indicated a poor rounding match, something like 0.12 mm2 (~26 AWG)

[kvid]

When such a preference might differ between applications, maybe we should add some options to let the user decide, e.g. something like this:

options:
  gauge_equiv:
    show: true/false  # Default 'show_equiv' value for cables in this harness
    awg_rounding: nearest  # Or other strategies, e.g. named 'safe', 'thicker', 'not_thinner', 'not_thicker', 'thinner', ...
    mm2_digits: 3
    poor_match: (some tolerance limit for showing a leading '~')

Maybe (in the future) also an optional awg_available attribute to specify the allowed subset of AWG values, and maybe even a similar mm2_available attribute, but in the latter case, a rounding strategy is also needed for mm².

Maybe the show_equiv attribute of cables optionally also could contain similar attributes instead of just true/false to enable different values between cables when needed?

[thestumbler]

I thought of a parallel example with machine screws. If I have some mounting holes to attach feet to a prototype board, people can safely use either M3 or #4-40 screws as if they're equivalent. But if someone were designing a back porch or a pedestrian foot bridge, the screw sizes would be absolutely critical (not to say there couldn't be equivalents, but each option would have to be checked by the mechanical engineer).

I think this issue of equivalent wire gauges is quite similar. Heck, if Wikipedia can be believed, there are some "standard" metric wire sizes for which there is no AWG equivalent (interesting that my 0.12 mm2 wire doesn't seem to exactly belong in either category).

[kvid]

I agree your example illustrates why different applications might have different conversion rule preferences, but I still think my suggested new options can resolve such a need. Do you agree or not? Please suggest alternatives or variations to my suggested solution. How can we visualize the conversion rule in use to avoid misunderstandings whitout too space demanding annotations?

[thestumbler]

Oh. I should've been clearer. I do like your proposed solution very much.

I had suddenly thought of the machine screw analogy shortly after sending my original comment, and posted it as a second comment in case it helped anyone understand the logic behind this.

In my own recent design searches, I think there's a standard or convention for purely metric series of wire sizes -- wire whose diameters / cross sectional areas aren't intentionally aligned with the AWG series, but are themselves "normal" metric values. Kind of like a 2 mm pitch connector vs a 2.54 mm connector. The latter is metric, but clearly it's just the equivalent of part designed in inches. The former is a part made originally using the metric system.

I mention this because it would be nice to include such a table in the program alongside the list of AWG sizes.

[kvid]

Oh. I should've been clearer. I do like your proposed solution very much.

Thank's, but please also add variations that you find useful.

I had suddenly thought of the machine screw analogy shortly after sending my original comment, and posted it as a second comment in case it helped anyone understand the logic behind this.

Yes, I now understand it was not meant as an argument after reading my suggestion.

In my own recent design searches, I think there's a standard or convention for purely metric series of wire sizes -- wire whose diameters / cross sectional areas aren't intentionally aligned with the AWG series, but are themselves "normal" metric values. Kind of like a 2 mm pitch connector vs a 2.54 mm connector. The latter is metric, but clearly it's just the equivalent of part designed in inches. The former is a part made originally using the metric system.

IEC 60228 specifies the nominal cross-sectional areas, in the range 0.5 mm² to 2500 mm², for conductors in electric power cables, but the standard does not apply to conductors for telecommunication purposes.

I mention this because it would be nice to include such a table in the program alongside the list of AWG sizes.

In what way would you expect such a list to be used? Maybe an optional conversion preference to select the nearest equivalent in such a table, but then we ideally should also cover small dimensions, and I don't know a standard for that. Maybe something like the list attribute mm2_available that I suggested above is the best we can do if the actual list of dimensions depends heavily on your cable suppliers.

[thestumbler]

In what way would you expect such a list to be used?

Maybe "list" is the wrong term. I meant that the program should be aware of these wire sizes, too, in as much as it needs to be aware of any standard wire gauge information. Today that takes the form of a list. And upon further thought, I think that list is only used for conversion between AWG and metric. I assume any revised algorithm as outlined above would probably use a similar table to "know" the standard sizes. I'm just guessing that a purely mathematical approach to deriving the standard sizes is probably more hassle than using a tabulated approach (just think about the headaches of using equations to generate the E96 number series, for example). The total number of different (and commonly used in modern designs) standard wire sizes seems manageable and shouldn't be so large as to exclude the tabulated data approach, IMHO.

I'll dig around and see if I can figure out where those "pure metric" wire sizes come from that I found on Wikipedia last week -- if they are a standard or just made up for illustrative purposes on that chart. My first reaction to the notion of digging through wire manufacturers' data books is "oh no, that doesn't seem like a good idea". But on further thought, if indeed there is no standard but it's obvious that a major wire companies are using a single de-facto "standard" set of sizes, then it's not a bad idea. But if there are like four different private sets of wire sizes, I think that would become unwieldy.

Wild thought, how difficult would it be for an (advanced?) user to provide their own table of wire information to the program's algorithm? I'm not sure of the usefulness of such a facility, but if it turns out there are really a bunch of conflicting manufacturers' private wire standards when it comes to pure metric sizes in the small signal low voltage space, it might make sense.

As to your request for additional parameters to the prosed new way of specifying wire size, I'm not thinking of any at present. However, a kind of related size topic would be the wire's insulation size. I suspect that's more unclear than wire gauge sizes, but if there are some reasonable standards it might be helpful to include those in a manner similar to gauge? I'm just thinking out loud here, having recently worked on a design where the insulation diameter was also important for PCB strain relief purposes.

[kvid]

Variation 1:

options:
  gauge_equiv:
    show: true/false  # Default 'show_equiv' value for cables in this harness
    rounding: nearest  # Common strategy unless specified for each unit
    awg:
      rounding: nearest  # Or other rounding strategies, e.g. named 'thicker', 'thinner', ...
      available: [13, 15, 17, 19, 21, 23]  # Subset to use
    kcmil:  # Unit to use when thicker than 0000 AWG
      rounding: nearest  # Or other rounding strategies, e.g. named 'thicker', 'thinner', ...
      available: [250, 300, 350, 400, 500]  # Subset to use
    mm2:
      digits: 3  # Compute 3-digit equivalent
      available: [0.5, 0.75, 1, 1.5, 2.5, 4, 6, 10]  # Subset to use
      rounding: nearest  # Or other rounding strategies, e.g. named 'thicker', 'thinner', ...
    match:
      poor: 10 %  # Show a leading '~' unless rounding within ±10 %
      invalid: 50 %  # Don't show equivalent unless rounding within ±50 %

• Specifying both digits and available for mm2 should probably be illegal.
• Perhaps is a common rounding strategy always enough, and we can skip supporting rounding for each unit. If so, then the remaining attribute value for each unit could be specifyed for the unit directly to simplify the syntax, i.e. Variation 2:

options:
  gauge_equiv:
    show: true/false  # Default 'show_equiv' value for cables in this harness
    rounding: nearest  # Or other common rounding strategies, e.g. named 'thicker', 'thinner', ...
    awg: [13, 15, 17, 19, 21, 23]  # Subset to use
    kcmil: [250, 300, 350, 400, 500]  # Subset to use
    mm2: 3  # Compute 3-digit equivalent, or alternatively 
    mm2: [0.5, 0.75, 1, 1.5, 2.5, 4, 6, 10]  # Subset to use
    match:
      poor: 20 %  # Show a leading '~' unless rounding within ±20 %
      invalid: 60 %  # Don't show equivalent unless rounding within ±60 %

[kvid]

In what way would you expect such a list to be used?

Maybe "list" is the wrong term. I meant that the program should be aware of these wire sizes, too, in as much as it needs to be aware of any standard wire gauge information. Today that takes the form of a list. And upon further thought, I think that list is only used for conversion between AWG and metric. I assume any revised algorithm as outlined above would probably use a similar table to "know" the standard sizes. I'm just guessing that a purely mathematical approach to deriving the standard sizes is probably more hassle than using a tabulated approach (just think about the headaches of using equations to generate the E96 number series, for example). The total number of different (and commonly used in modern designs) standard wire sizes seems manageable and shouldn't be so large as to exclude the tabulated data approach, IMHO.

A full list of standard sizes could be the default values of the available list attributes in my variations 1 and 2 above.

I'll dig around and see if I can figure out where those "pure metric" wire sizes come from that I found on Wikipedia last week -- if they are a standard or just made up for illustrative purposes on that chart. My first reaction to the notion of digging through wire manufacturers' data books is "oh no, that doesn't seem like a good idea". But on further thought, if indeed there is no standard but it's obvious that a major wire companies are using a single de-facto "standard" set of sizes, then it's not a bad idea. But if there are like four different private sets of wire sizes, I think that would become unwieldy.

Yes, references to relevant standards (or de-facto "standards") are welcome.

Wild thought, how difficult would it be for an (advanced?) user to provide their own table of wire information to the program's algorithm? I'm not sure of the usefulness of such a facility, but if it turns out there are really a bunch of conflicting manufacturers' private wire standards when it comes to pure metric sizes in the small signal low voltage space, it might make sense.

Do you mean something like the available list attributes in my variations 1 and 2 above?

As to your request for additional parameters to the prosed new way of specifying wire size, I'm not thinking of any at present. However, a kind of related size topic would be the wire's insulation size. I suspect that's more unclear than wire gauge sizes, but if there are some reasonable standards it might be helpful to include those in a manner similar to gauge? I'm just thinking out loud here, having recently worked on a design where the insulation diameter was also important for PCB strain relief purposes.

This last suggestion about extra parameters might perhaps be resolved by something like additional_attributes as proposed in #222 (comment)

[thestumbler]

I'd say variation 2 is best, but then again I'm not a power user.

Not sure of the usefulness of specifying the closest match in such a fine-grained approach.

These proposed yaml directives are on a "per-invocation of the program" basis? Or could they be overridden on a per-cable basis? If the latter, that seems like it would take care of any situation where the user wanted to tweak the nearest-match tolerance.

[kvid]

I'd say variation 2 is best, but then again I'm not a power user.

I agree it looks better than variation 1, but don't stop looking for even better variations.

Not sure of the usefulness of specifying the closest match in such a fine-grained approach.

Is it the rounding attribute you find less useful? My idea of different rounding values are:

• nearest to round up or down to the nearest value.
• thicker or safe to always round towards a thicker gauge value for safety in maximum current cases.
• thinner to always round towards a thinner gauge value to stay within size restrictions of connector terminals or ferrules.

These proposed yaml directives are on a "per-invocation of the program" basis? Or could they be overridden on a per-cable basis? If the latter, that seems like it would take care of any situation where the user wanted to tweak the nearest-match tolerance.

I suggest accepting the gauge_equiv dict attribute in the options section - i.e. "per-invocation of the program", but I also mentioned early that the show_equiv attribute for each cable could optionally (as an alternative to the simple true/false value) accept the same dict entries to override the common options when needed.

Edit: Maybe also consider renaming show_equiv to gauge_equiv for consistency and to enable a potential future length_equiv attribute?

[thestumbler]

Not sure of the usefulness of specifying the closest match in such a fine-grained approach.

Is it the rounding attribute you find less useful? My idea of different rounding values are:

By fine-grained, I meant specifying rounding separately for each kind of wire gauge standard, not the kinds of rounding options. I think those are good.

[kvid]

By fine-grained, I meant specifying rounding separately for each kind of wire gauge standard, not the kinds of rounding options. I think those are good.

I agree - that was also my motivation for variation 2. Originally, I was thinking separate values for each unit to allow a computed value for mm² and rounding to list entries for AWG, but then I realized only one value is really needed separately for each unit - either the number of digits in a computed value, or a list of available values for matching.