X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=googlemail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type;
	bh=7hd5mnFJrXXvB5NMBHltE0hWEt+a+/DW8c0/AUvv6FU=;
	b=cZiIX7hi+Xbyn0P9jr12vuUoN6lOze4NZz/SLWh41ZCkVCi6n7WxN47N8n21crQqzd
	kf01drE0c4eKaJhPXgK+v5PVWBPTIwFFeG4zcDMh9n9RxFeLXXAibntTYMF/3R6rS5tj
	Mu/rBYKYN4M/dZb9aDjBcJLualeKztqTg87C6QYvnACtiwsWuw00BPIHb3C8/uiqccFQ
	JZ+8pfbCFVQEjZAjVEMDEZzWHbJ5nZT4L9TcbKCPXUIN9mCwCIFN+3/oDhAVmLCBkQb0
	27Ujj//sCPU/QgRnDi84k6hZurHGVzt8Lg9qKfBQdMoIxHjtahmf3+MIBl0brgkigrzD
	GG2A==
MIME-Version:	1.0
X-Received:	by 10.182.215.163 with SMTP id oj3mr2696955obc.49.1421247600994;
	Wed, 14 Jan 2015 07:00:00 -0800 (PST)
In-Reply-To:	<CAOuGh89WdJfoVgDsV8Cvxpt3cQ-nkTj3QWn+oZP=mOW-SJAE3A@mail.gmail.com>
References:	<CAGde_xMT+BXsS0iiTD4yz2On_nTpAD1VkyzkKVuGW4=gduOqdg AT mail DOT gmail DOT com>
	<54B57095 DOT 20000 AT sbcglobal DOT net>
	<CAGde_xMHch3jiGc=0TR-6aCnVhQ9GfJ+-ozGN2jMaBKwrdB8jQ AT mail DOT gmail DOT com>
	<20150114114830 DOT GA24995 AT visitor2 DOT iram DOT es>
	<CAOuGh89WdJfoVgDsV8Cvxpt3cQ-nkTj3QWn+oZP=mOW-SJAE3A AT mail DOT gmail DOT com>
Date:	Wed, 14 Jan 2015 16:00:00 +0100
Message-ID:	<CAGde_xMYP=MqDppRVWt4P_xGeBw5D06rgJp3JjPnL07bGKh2ow@mail.gmail.com>
Subject:	Re: [geda-user] Any good repository for datasheets in pdf out there?
From:	Svenn Are Bjerkem <svenn DOT bjerkem AT googlemail DOT com>
To:	geda-user <geda-user AT delorie DOT com>
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

--001a11c2c2ce6532e8050c9dfef4
Content-Type: text/plain; charset=UTF-8

If somebody starts a statement with "Well, honey...." I know something bad
is coming up. Name fits them good in that perspective.

The example with the temperature sensor is a good one. In our BOM system
the "new" datasheet would have a different database key than the "old" to
make sure there is a difference in logistics because there is a difference
in the product (the sensor). In worst case, the vendor of the component
does not change the naming of the component and we would have an "old"
HEL-705-U and a "new" HEL-705-U. If the pdf for both would be named
"datasheet.pdf" after download, the mess would be complete.

We do not use this kind of sensors, but we use RAM and FLASH chips which
happens to be very short lived, but have equal interfaces but different
timings. Upon end-of-life notifications we go out in the market to find a
replacement which match all possible parameters in order to just replace
the component in the pick-and-place machine. Put that component into the
production database and write a new BOM which we send to the manufacturer.
A simple change order. But we need to keep track of all chip variations we
have used and their corresponding datasheets. The internal database number
(or BOM component ID) is not possible to map to a particular component in a
normal human brain. It is coded in a way, but it is not possible to deduct
the vendor from the BOM component ID.

Once, when I worked for a company where we had ASICs made by external
companies, logistics guy came and asked if we would be so kind to put the
SAP number on the chip housing, and each design change should trigger a new
SAP number. The mappping of chips from design through ordering to mounting
is not a new problem.

I could try to suggest we use the git hash for the datasheet checked into
git-annex as BOM-ID in our database, but I guess I would have to look over
my shoulder ever after....

-- 
Svenn

--001a11c2c2ce6532e8050c9dfef4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">If somebody starts a statement =
with &quot;Well, honey....&quot; I know something bad is coming up. Name fi=
ts them good in that perspective.<br><br></div><div class=3D"gmail_extra">T=
he example with the temperature sensor is a good one. In our BOM system the=
 &quot;new&quot; datasheet would have a different database key than the &qu=
ot;old&quot; to make sure there is a difference in logistics because there =
is a difference in the product (the sensor). In worst case, the vendor of t=
he component does not change the naming of the component and we would have =
an &quot;old&quot; HEL-705-U and a &quot;new&quot; HEL-705-U. If the pdf fo=
r both would be named &quot;datasheet.pdf&quot; after download, the mess wo=
uld be complete. <br><br>We do not use this kind of sensors, but we use RAM=
 and FLASH chips which happens to be very short lived, but have equal inter=
faces but different timings. Upon end-of-life notifications we go out in th=
e market to find a replacement which match all possible parameters in order=
 to just replace the component in the pick-and-place machine. Put that comp=
onent into the production database and write a new BOM which we send to the=
 manufacturer. A simple change order. But we need to keep track of all chip=
 variations we have used and their corresponding datasheets. The internal d=
atabase number (or BOM component ID) is not possible to map to a particular=
 component in a normal human brain. It is coded in a way, but it is not pos=
sible to deduct the vendor from the BOM component ID.<br><br></div><div cla=
ss=3D"gmail_extra">Once, when I worked for a company where we had ASICs mad=
e by external companies, logistics guy came and asked if we would be so kin=
d to put the SAP number on the chip housing, and each design change should =
trigger a new SAP number. The mappping of chips from design through orderin=
g to mounting is not a new problem.<br><br></div><div class=3D"gmail_extra"=
>I could try to suggest we use the git hash for the datasheet checked into =
git-annex as BOM-ID in our database, but I guess I would have to look over =
my shoulder ever after....<br></div><div class=3D"gmail_extra"><br>-- <br><=
div class=3D"gmail_signature">Svenn</div>
</div></div>

--001a11c2c2ce6532e8050c9dfef4--

- Raw text -