X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user 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:mime-version
	:content-transfer-encoding;
	bh=xcd4WxcksXSK1cQomAYl5zloF7KM4TYhadKLzNa6G/U=;
	b=H+DGBWWB46wfGJPzWJ4yxn8XC9ucR0rYU7EYfZnPByVRERC0KyHknLenn9u6wjshPk
	/jOBay7vpFeLhakZheoBANjhYmaBD5QbDlY4fZtU1FZcLICwYxcWrUJRkd1+6O9AdTZi
	yMvyQXEWq+sPTMUwcKoAfe1X0RV4puLWeFkfdxyE1dWshDOgDQSPXyta9tv7MiTEppYv
	ocIpX0sO4ovyKGINSRNrl3e/y8qFJDSTwwNJG847Z6/aAg1MUCScksf6x8xw/FEALe4N
	9WI75iy0jE26N1lALUgJwkzEZiRkv/03yHyXvgAvq9EdB/s8keg2eXwZ4L+dJUWUHk4U
	gZ+g==
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:mime-version:content-transfer-encoding;
	bh=xcd4WxcksXSK1cQomAYl5zloF7KM4TYhadKLzNa6G/U=;
	b=jPlzJzGASq/2U5mgUWcNqIVKwshWziJ+H5ocZjT5y4/1CZyjxK0ojP5al42cnV0m2c
	WmTcJL93z49+omWlED8bV35b0Z/ba7mlif4fIrxUTOM20oyM2FrAgz86zOPo/vQ1Hkk5
	pVJq3kfgrIwuMfVZmft44SjUei6WDxtMF/xMJzTmfIcafzjcui5I0TV4kQNV4uJ5Ck4W
	AcwrXWUAIQoiFx6rANVDC23CtxDEjRWltIAedmAqy0FFO0ypqT8Q1fP4BV3N47ukhQ2M
	g7vsA4fL2Q40xjeczbQ4kSypc6PjpwwrtTZjt7zHaGldwFBv5z3Pz8vGf9riJcy8gZXg
	lSfA==
X-Gm-Message-State:	AIkVDXKCaiukCpkt6XBRSZoqqJLHXaoXUcwjmfWGcdpj6nNZGHO84WrJoUNEJE6feplxWA==
X-Received:	by 10.46.72.10 with SMTP id v10mr4870999lja.46.1485612377355;
	Sat, 28 Jan 2017 06:06:17 -0800 (PST)
Date:	Sat, 28 Jan 2017 15:06:09 +0100
From:	"Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
Subject:	Re: [geda-user] PCB antenna question
Message-Id:	<20170128150609.8ac62105042db89007e46335@gmail.com>
In-Reply-To:	<1485607260.3072.77.camel@linetec>
References:	<1485607260 DOT 3072 DOT 77 DOT camel AT linetec>
X-Mailer:	Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
Mime-Version:	1.0
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Sat, 28 Jan 2017 13:41:00 +0100
"Richard Rasker (rasker AT linetec DOT nl) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com> wrote:

> Hello,
> 
> Lately, I started on projects involving Bluetooth and UHF RF, and for
> simplicity and cost, I'd like to use PCB antennas.
> 
> While doing this, I ran into a question: how can I 'properly' define PCB
> antenna elements/footprints? When I draw a loop antenna and convert it
> into an element, things get problematic: each line segment is designated
> a separate pad number, which produces error messages as soon as the
> element is entered in a netlist (also see attached example).

This is what I found about the footprint format http://www.ssalewski.de/PcbFootprintRef.txt and there is limitations.

In particular there is no possibility to put drawn objects on a specific layer, I guess position would need to be relative if component are put on up side down opposite side or maybe even on an inner layer. Other limitation is only objects are line, arc, and predefined pins/pads. I would also be good with possibility to refence pin types defined in a library and then used in pcb locally defined with link to library so that local changed could be made or updated only then decided.

I guess Pin and pad may still be useful somwhere as a shortcut for the most common type of pin.


> I tried redefining these lines in several ways using a text editor (by
> changing the pad numbers(*)), but PCB insists on treating the whole
> thing as a collection of shorted nets -- which of course is technically
> correct, but not what is desired.
> Simply said: Is there a way to create a 'shorted' element that isn't
> treated as a short circuit by PCB?

Not what I know about but it have been discussed and might already be implemented.

I have also seen this in other layout software. As I understand pcb internally calculate physical real nets usually made of copper and normally this should agree with the netlist in the schematic. I guess an attribute to ignore this then physical real nets are calculated in pcb or just mark some kind of note about it would be the solution.

The source is out there and I guess this would rather simple to check a flag if object should be not be considered as conductive if we could just agree about a suitable flag or attribute?


> *: A related question: when defining connector footprints, I usually
> define all mechanical metal parts as pin/pad 0. Would it be possible in
> principle to modify PCB's behaviour to treat these zero pins/pads as
> 'floating', so that they don't produce error messages when connected to
> an arbitrary net, or, alternatively, are left unconnected? Or would that
> raise other problems?

What do you mean by mechanical part?


Regards Nicklas Karlsson

- Raw text -