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: References: <54B57095 DOT 20000 AT sbcglobal DOT net> <20150114114830 DOT GA24995 AT visitor2 DOT iram DOT es> Date: Wed, 14 Jan 2015 16:00:00 +0100 Message-ID: Subject: Re: [geda-user] Any good repository for datasheets in pdf out there? From: Svenn Are Bjerkem To: geda-user Content-Type: multipart/alternative; boundary=001a11c2c2ce6532e8050c9dfef4 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 Precedence: bulk --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
If somebody starts a statement = with "Well, honey...." I know something bad is coming up. Name fi= ts them good in that perspective.

T= he example with the temperature sensor is a good one. In our BOM system the= "new" datasheet would have a different database key than the &qu= ot;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 t= he 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 fo= r both would be named "datasheet.pdf" after download, the mess wo= uld 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 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.

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.

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....

--
<= div class=3D"gmail_signature">Svenn
--001a11c2c2ce6532e8050c9dfef4--