| delorie.com/archives/browse.cgi | search |
| X-Authentication-Warning: | delorie.com: mail set sender to geda-help-bounces using -f |
| X-Recipient: | geda-help AT delorie DOT com |
| X-Original-DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; |
| d=gmail.com; s=20161025; | |
| h=date:from:to:subject:message-id:in-reply-to:references:reply-to | |
| :organization:disposition-notification-to:return-receipt-to | |
| :mime-version:content-transfer-encoding; | |
| bh=zvMfnzJdPnCSh7JoXjOwmdIrtvoWGI1uEUpNWsGn6pY=; | |
| b=OOWxrW15LyEAfVMMFE3ZdkAgtGRa3MPSlGdFYJpLMbtP/fZEQGc88MhzZHV4uHn95C | |
| Qr0xoT7ETD8r3Lsm0zYSr/BvvCQHJIQzWpk5D1RtWNgjZF0VT/HB/0QfA7QbYTo7RYBk | |
| drbzN6pSTB8cOR0iqnRCoy2N4U/F4WuHAtMUbPIrKOq8Rhr0lAM1Ijy05FCW/LIgUz9R | |
| FxMWNE2gAON+00Ps1hit8SmSj/iJhYxnyM37qIhn4ymLGlZHrznnTuKJvJi8EIdqe4bc | |
| aInmy36gWKhbf5b/7lHrF9gkKmiUWP+OvKKcxpV0/L5B1kLgdK5esJubQb1u+R9SZvhU | |
| nJLw== | |
| X-Google-DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; |
| d=1e100.net; s=20161025; | |
| h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to | |
| :references:reply-to:organization:disposition-notification-to | |
| :return-receipt-to:mime-version:content-transfer-encoding; | |
| bh=zvMfnzJdPnCSh7JoXjOwmdIrtvoWGI1uEUpNWsGn6pY=; | |
| b=WdqtHGuQGIexoz+P25zjRWVmk/6xHFsRHydZdM/xqq9t5/cp9C/8qPNdM7HOvi4NoW | |
| jcIv8UhpOCWHbWkixvFRF4a6XoYeZoQUsk+7fL2+p6BkT7rzRGK5Mnt7ZgHyOiUZZCOn | |
| Klzn6jtmUIiXKZTWl0BzvtUrV+kF1sorJYwY54luoPMeJX3J+i/dNFXlj3g8gjjz3Rj5 | |
| t+uEp0QsSHb5cQHCcpt1cOVo/dSnfHLLedxBJsgBWpKXbtpcsaeklT1Ct+GvJAOaq9X4 | |
| qsi1vUoRu8HvVqDGrCcGXp0DszJCp6X8y6GGuEEYPRVoiYPt854+uberWJSl9RO1sRgx | |
| ybFw== | |
| X-Gm-Message-State: | APjAAAVLrWEp7XQIjoXqPBUD1x4Y1bdviIB/cr9LzV6tBcGkBq+ahuWk |
| Mz3+QQXLutLZA1oKXSOmaApDqMc= | |
| X-Google-Smtp-Source: | APXvYqx/59YnrHk+Vth7rC7sFL7pGCKjbkZwzIwUm9wCSwIIcT9tHWdD/lc4I2gJVQKn/LTuebKKGw== |
| X-Received: | by 2002:a37:4c42:: with SMTP id z63mr5810700qka.79.1571797174696; |
| Tue, 22 Oct 2019 19:19:34 -0700 (PDT) | |
| Date: | Wed, 23 Oct 2019 02:19:21 +0000 |
| From: | "John L. Males (jlmales AT gmail DOT com) [via geda-help AT delorie DOT com]" <geda-help AT delorie DOT com> |
| To: | geda-help AT delorie DOT com |
| Subject: | Re: [geda-help] Question: New User - How To Create Very Simple |
| Unique PCB With No Components | |
| Message-Id: | <20191023021921.6a6906ecca7b2ac74f080cb6@gmail.com> |
| In-Reply-To: | <20191022215959.913.qmail@stuge.se> |
| References: | <CAJZxidBbky8CT7mcRa1DX_pZTLnf=x2x0Hh4CiX122F-F_c1Vw AT mail DOT gmail DOT com> |
| <20191020183718 DOT e6fccd7def16f88626a4fa24 AT gmail DOT com> | |
| <CAHUm0tM-w4Y-AazjhGX4wC8R1Pq1Cgr0S6AZ3O+5LFGHUixkAg AT mail DOT gmail DOT com> | |
| <20191021024423 DOT 8d189fc5ca003a8a11384366 AT gmail DOT com> | |
| <CAHUm0tNgLr71gWeMeGKQD9ZEtOo-nPYmcOxT4GZ7TTBV36Z8NQ AT mail DOT gmail DOT com> | |
| <20191021213833 DOT 6bef6a8bfbaf6d69e36c2527 AT gmail DOT com> | |
| <CAJZxidAL_hu6Kjs6G09xBaBS6ibvxP1+tGAHnOqA2A=HRdnkGQ AT mail DOT gmail DOT com> | |
| <20191022024127 DOT bb67cfef6635bc82b8c747a4 AT gmail DOT com> | |
| <20191022170155 DOT 29708 DOT qmail AT stuge DOT se> | |
| <20191022202910 DOT 7a72089873edeea3807e1d93 AT gmail DOT com> | |
| <20191022215959 DOT 913 DOT qmail AT stuge DOT se> | |
| Organization: | Toronto, Ontario |
| X-Mailer: | Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd11.2) |
| Disposition-Notification-To: | jlmales AT gmail DOT com |
| X-Compose-Start-Epoch: | `date +%s` |
| Mime-Version: | 1.0 |
| Reply-To: | geda-help AT delorie DOT com |
| Errors-To: | nobody AT delorie DOT com |
| X-Mailing-List: | geda-help AT delorie DOT com |
| X-Unsubscribes-To: | listserv AT delorie DOT com |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Peter,
Thank you for all your answers.
I am going to read the documentation link you provided for the
"Pin" statement and other (two) statements I have not asked any
questions about. If I have more questions I will post them.
For the moment I think for this sensor PCB I am going to be
fine short term with what I currently know and will know after
reading the link to the documentation you provided.
As FYI the 27pF to - 39pF is the capacitance specified for
about a 2200mm2 surface top and bottom. I believe the range
specified is due to the tolerance differences in the nominal
0.79mm PCB was in reference to and that the PCB was made of FR4.
Chad had suggested an excellent idea of creating segments for
the capacitance area in a reply Chad had sent to me via the
mailing list previously. I am going to see if I can figure out
how I might implement this idea as a part. Then all I need to
do is find out the target capacitance the electronics expects
of the PCB and plates the PCB is placed between. From there I
will see how I can figure out with more expensive PCB the
overall capacitance, base size of the copper for foundation
capacitance, and then the segment size that allows trimming via
cutting small joining traces at a reasonable predictable
reduction of capacitance. The segments in total will be a
reasonable level above to tad below the foundation capacitance.
Thanks again for your answers and those that have replied to my
prior posts.
John L. Males
Toronto, Ontario
Canada
22 October 2019 22:19 -0400 EDT
================================================================
2019-10-23 01:56:13+0000-UTC Time: 1571795773 PC/System time
23 Oct 01:56:13 ntpdate[52389]: ntpdate 4.2.8p12-a (1)
23 Oct 01:56:28 ntpdate[53627]: step time server 132.246.11.238
offset -0.001106 sec
FreeBSD 11.3-STABLE FreeBSD 11.3-STABLE #0 r349903: Thu Jul 11
16:13:47 UTC 2019
root AT releng2 DOT nyi DOT freebsd DOT org:/usr/obj/usr/src/sys/GENERIC
(Work in progress alternative to Linux Kernel of its own right,
Debian, and
other Linux based Kernel distributions determined.)
Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz
Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz (1396.86-MHz K8-class
CPU) Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz (1396.86-MHz
K8-class CPU) Intel(R) Core(TM) i3-2367M CPU @ 1.40GHz
(1396.86-MHz K8-class CPU) Intel(R) Core(TM) i3-2367M CPU @
1.40GHz (1396.86-MHz K8-class CPU) Intel(R) Core(TM) i3-2367M
CPU @ 1.40GHz (1396.86-MHz K8-class CPU)
dev.cpu.0.temperature: 72.0C
dev.cpu.1.temperature: 72.0C
dev.cpu.2.temperature: 67.0C
dev.cpu.3.temperature: 67.0C
hw.acpi.thermal.tz0.temperature: 72.1C
vmstat -s:
170007684 cpu context switches
3540905 device interrupts
991559 software interrupts
19563425 traps
527754563 system calls
27 kernel threads created
3067 fork() calls
1018 vfork() calls
0 rfork() calls
0 swap pager pageins
0 swap pager pages paged in
0 swap pager pageouts
0 swap pager pages paged out
6823 vnode pager pageins
84031 vnode pager pages paged in
190 vnode pager pageouts
3144 vnode pager pages paged out
0 page daemon wakeups
13614200 pages examined by the page daemon
0 clean page reclamation shortfalls
0 pages reactivated by the page daemon
172891 copy-on-write faults
748 copy-on-write optimized faults
15116106 zero fill pages zeroed
0 zero fill pages prezeroed
35 intransit blocking page faults
20394007 total VM faults taken
9387 page faults requiring I/O
0 pages affected by kernel thread creation
149127 pages affected by fork()
35993 pages affected by vfork()
0 pages affected by rfork()
18975092 pages freed
0 pages freed by daemon
5255360 pages freed by exiting processes
161863 pages active
713437 pages inactive
31180 pages in the laundry queue
209623 pages wired down
891628 pages free
4096 bytes per page
3331941 total name lookups
cache hits (93% pos + 3% neg) system 0% per-directory
deletions 0%, falsehits 0%, toolong 0%
Boot time : 1571762712
procs memory page disks
faults cpu0 cpu1 cpu2 cpu3 r b w avm
fre flt re pi po fr sr ad0 pa0 in sy cs us sy
id us sy id us sy id us sy id 2 0 0 28390260 3566452 617 0
0 0 574 412 0 0 107 15955 5140 11 4 86 11 3 86 11
3 86 11 3 86
memory info:
real memory = 8589934592 (8192 MB)
avail memory = 8166465536 (7788 MB)
last pid: 59758; load averages: 0.85, 0.87, 0.68 up
0+09:11:17 01:56:29 60 processes: 1 running, 59 sleeping
Mem: 633M Active, 2787M Inact, 122M Laundry, 819M Wired, 334M
Buf, 3482M Free Swap: 48G Total, 48G Free
hw.physmem: 8463925248
hw.usermem: 7605149696
hw.realmem: 8589934592
total used free shared
buffers cached Mem: 8030732 1610600
6420132 0 0 0 Swap:
50331644 0 50331644
swapinfo:
Device 1K-blocks Used Avail Capacity
/dev/ada0s1b 50331644 0 50331644 0%
vmstat:
procs memory page disks
faults cpu r b w avm fre flt re pi po
fr sr ad0 pa0 in sy cs us sy id 1 0 0 28390244
3566456 617 0 0 0 574 412 0 0 107 15956 5140
11 3 86
Message replied to:
Date: Tue, 22 Oct 2019 21:59:59 +0000
From: "Peter Stuge (peter AT stuge DOT se) [via
geda-help AT delorie DOT com]" <geda-help AT delorie DOT com> To: "John L.
Males \(jlmales AT gmail DOT com\) \[via geda-help AT delorie DOT com\]"
<geda-help AT delorie DOT com> Subject: Re: [geda-help] Question: New
User - How To Create Very Simple Unique PCB With No Components
> John L. Males (jlmales AT gmail DOT com) [via geda-help AT delorie DOT com]
> wrote:
> > The Pin statement in the 3x6 hole part I created as one
> > example was:
> >
> > Pin(300 350 125 90 "101" 0x01)
> >
> > Your great example to make it a pure hole with no connection
> > attribute was:
> >
> > Pin[0 0 3.6mm 0.4mm 3.4mm 3.2mm "" "1" "hole"]
> >
> > If there a difference in context or meaning of the Pin
> > statement when using round brackets vs square brackets?
>
> If I understand your question correctly then the answer is no;
> they both create the same thing on the board.
>
>
> > There is a difference in the number of items I used from the
> > connector part I used as basis of my pin statement. Is this
> > related to the type of brackets used as asked just above?
>
> Yes. Here's the documentation:
>
> http://pcb.geda-project.org/pcb-cvs/pcb.html#Pin-syntax
>
>
> > Am I correct to assume the first two zeros you used are
> > still for the pin location?
>
> Yes.
>
>
> > If one does not use the "mm" units suffix in your example
> > will that mean the default units is mils?
>
> I think so, but I'm not sure.
>
>
> > Can one explicitly state mils a a unit of measure?
>
> Yes.
>
>
> > One aspect I learned was the use of 0x101 in the format of
> > the Pin statement created a square hole and graphic inside
> > that collectively indicate pin 1 of the connector. Is this
> > the same parameter in the round brackets syntax I deduced
> > from a connector part that can indicate hole?
>
> Yes. The square bracket syntax allows using symbolic flags,
> more human readable.
>
> The "square" symbolic flag (combine flags using a comma)
> doesn't make much difference for a Pin with the "hole" flag.
>
> The "square" flag doesn't create a square hole, but results
> in a square copper pad, as often seen for pin 1.
>
>
> > The second and third value in the round bracket Pin syntax I
> > deduced from the connector part were outside and inside
> > diameter.
>
> Yes, Thickness and Drill.
>
>
> > The first 4 values of the round bracket Pin syntax I used
> > are in mils as I discovered.
>
> Yes.
>
>
> > I am assuming the 5th value in the round bracket values I
> > used is some sort of comment or reference point that I do
> > not see in the PCB nor gerbers I created as test.
>
> Yes. It's the name of the pin. Not relevant for your
> ventilation holes, but can be helpful for anything that
> connects somewhere. Names can be displayed in the GUI, and
> are sometimes used in messages.
>
>
> > The current indications I have states the boards have a
> > capacitance between 27pF to 39pF.
>
> Doesn't that depend completely on copper area and dielectric
> constant (meaning thickness, and uniformity)?
>
> I assumed that you have a target capacitance which you need
> to achieve.
>
> Another option could be to create a 4-layer board with a
> quite thin core and no copper on the two outermost layers,
> which probably allows another capacitance range and perhaps
> significantly tighter tolerance.
>
>
> > I believe the wide tolerance is due to using FR4 boards.
>
> I have no idea; I don't know where the number 27-39pF comes
> from. :)
>
>
> > I think it was Chad that mentioned Polyimide board that my
> > sense was would have smaller capacitance tolerances
> > including from temperature delta point of view.
>
> PI is one choice, but will probably be very thin at most fabs
> - this is the core used for all flex PCBs - the
> copper-coloured bendy PCBs that are inside many things with
> moving parts.
>
>
> > Thickness is also a factor because the gap this sensor board
> > sits between is about 0.125". So a board that is also
> > dimensionally stable is important as well. The fixtures the
> > board is attached to are of a warp less design.
>
> A board will never reliably fit snug into that gap, so make
> sure that there is a separate mount for the PCB. Check if
> mounting force warps the board enough to affect capacitance
> in a relevant way.
>
>
> > The board does not move, but maybe the metal it is mounted
> > to might pinch the solder mask that would cause unwanted low
> > voltage short that wold render the sensor board useless as
> > well as the application. I had been considering before
> > your comment about the solder mask if running a trace or
> > making a small gap about a via at edge of the copper planes
> > to transition the lower connection to upper side of board
> > that is not in contact with metal fixture to then run the
> > trace top side to the solder pad.
>
> Yes. Avoid copper on the board underneath the metal mount.
>
>
> > Is it possible to make a copper area a part?
>
> From
> http://pcb.geda-project.org/pcb-cvs/pcb.html#Element-syntax
>
> "Elements may contain pins, pads, element lines, element arcs,
> attributes, and (for older elements) an optional mark."
>
> So no, no polygons. pcb-rnd allows that, but only using its
> own file format.
>
>
> > Why is it important to provide at least a 0.5mm space of
> > copper from side of the board?
>
> The fab will route the outer edge of the PCB, again with some
> tolerance. The 0.5mm space ensures that no copper will extend
> to the edge of the board, which could result in a short
> circuit if that edge touches some surrounding metal.
>
> Also, soldermask doesn't always extend to the very edge.
> Leaving space without copper also ensures that all copper is
> actually masked.
>
> And some fabs do not route the outer edge completely, but
> leave a few bridges or tabs perforated with small drilled
> holes along the outer edge of your design, so that those tabs
> can be broken off easily in the very last fabrication step.
> The holes extend "into" your board, and the break-off process
> can tear the soldermask and crack the core imperfectly or
> unevenly. That shouldn't cause exposed copper.
>
>
> > If not could one edit the text file of the board with
> > the copper sides on it manually to effect the at least 0.5mm
> > clearance of copper from the edge of the board.
>
> Mh, yes sure, but it's not so convenient.
>
>
> > Do this via the GUI is challenge as one would have to zoom
> > the board so much it may make trying to effect the
> > clearance from the edge challenging or not practical from a
> > GUI point of view.
>
> The GUI has a grid which helps a lot for such operations.
>
>
> > I have skipped questions I have of the "Element" statement
> > and "ElementLine" for now until I have the "Pin" statement
> > questions I asked above sorted out that I understand for my
> > needs.
>
> Maybe your questions are already answered in the
> documentation. :)
>
>
> //Peter
>
-----BEGIN PGP SIGNATURE-----
iF0EARECAB0WIQQxRId2q5JPHFiozTr5X9dS0HpoEAUCXa+4qQAKCRD5X9dS0Hpo
EEOOAKDbzqYuSCFbRout49Yq3NIEQzouPQCePM8Wddal8Mtkr3pR6ekGz82skQo=
=set4
-----END PGP SIGNATURE-----
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |