Packages

Packages is a tool to maintain a repository of packages of electronic components. It is developed with the goal that various applications use one and the same repository as a basis for their handling of packages. The repository is in a well-documented JSON format, easy to parse in a variety of programming languages.

Back to page

Downloads, requirements & license

Packages 1.2 Setup for Microsoft Windows (184 MiB)

The Packages application as a self-extracting setup, for Microsoft Windows. This setup includes the Java JDK 17.0 runtime.

Packages 1.2 Setup for Microsoft Windows (no JDK) (35 MiB)

The Packages application as a self-extracting setup, for Microsoft Windows. This setup excludes the Java JDK 17.0 runtime.

Packages 1.2 Setup for Linux (221 MiB)

The Packages application and setup script for Linux. This archive includes the Java JDK 17.0 runtime.
This download includes an “install.sh” script. After unpacking the archive in the temp directory, you can run this script. When run as a normal user, it installs the program in the home directory; when run as root, it installs it in /opt.

Packages 1.2 Setup for Linux (no JDK) (43 MiB)

The Packages application and setup script for Linux. This archive excludes the Java JDK 17.0 runtime.
This download includes an “install.sh” script. After unpacking the archive in the temp directory, you can run this script. When run as a normal user, it installs the program in the home directory; when run as root, it installs it in /opt.

Requirements

Packages requires Java JDK 17.0.

License

Packages is open-source software, distributed under the Apache License version 2.0.
The source code can be found on the GitHub project.

The Packages program comes with an example repository of the standard SMT packages (0805, TSSOP, SOT23, QFP and QFN, etc.), plus documentation. An important goal of this tool is to enable multiple applications to use/exchange a single set of package data. Which is why the file lay-out is documented in detail (and which is why a widely supported file format was chosen to store the repository in).

Rationale

Many packages for electronic components exist, but it is not as straightforward as having a long list. On occasion a package name refers to a group of packages, and package name on its own is not conclusive about all dimensions of the package. Essentially the same package may also be known under multiple names —this is in part the result of various standardization bodies that each on their own standardize packages, without regard to the other organizations doing the same.

EDA suites (Electronic Design Application) focus on a flattened view of the package: the footprint. For mechanical design, the height of the package is important too, and pick-&-place machines often need to know the shape of the terminals (for example, gull-wing versus lug-lead) to recognize and centre the component on the nozzle. That is to say: these various applications all use package data, but they don't all need the same data.

During the development of VisualPlace, and each time we configured our pick-&-place machine for a new project —or even making sure we ordered the right component in the right package shape, we encountered these issues. And while these are easily solved by looking up the details in the components' data-sheets, this does, of course, take a tremendous amount of time. As we wrote on the product page for VisualPlace, these “bottlenecks” in preparating the assembly of a new PCB are well known; sufficiently well known to gain a three-letter acronym: NPI (which stands for “New Product Introducion”). NPI causes machine down-time and increased costs.

The goal of Packages is to create a comprehensive repisotory of data that various applications can use and cross-reference. Packages groups the data in a structured way, and makes it easily searchable (using both keyword search and parametric search).

File format

For interoperability with other aplications, the trick is to be able to extract the needed information with ease. A key feature of Packages is the file format. The first part is that it stores the package data in the JSON format, which is standardized and for which libraries exist for many programming languages. The second part is that, at the semantical level, the various fields and their purpose are described in detail in the manual.