Hardware Development Guidelines

Overview

This guide refers to practices that is followed for hardware projects. It contains 3 sections:

  1. design

  2. fabrication

  3. assembly

Each of the sections refer to a different stage of hardware development.

Design

Repository

The repository of a hardware project must include:

  1. License file for example, CERN Open Hardware Licence Version 2 - Strongly Reciprocal

  2. Libre Space Foundation Contribution Guide

  3. Git ignore files for different kind of programms, like KiCad, FreeCAD and QUCS.

  4. In case of CAD files, e.g. FreeCAD, it is recommended to use Git LFS

  5. For project management follow, recommended Mode of Operation for Libre Space Foundation projects

  6. An (under test) method to keep track of issues with epics and/or milestones is followed at SIDLOC project - issue and some notes

KiCad and FreeCAD Workflow

  1. KiCad workflow for multiple boards is under test in SIDLOC project and an example of the method is given below.

  2. FreeCAD workflow uses Git LFS - File Locking

An example KiCAD workflow for multiple boards (from SIDLOC project)

Consider the case where someone wants to make some schematic and PCB changes in one of the SIDLOC sub-projects (e.g. RFFE). Described below is a series of steps to perform these changes according to the “Breadboards Prototyping Workflow” scheme.

Change the common schematic

First thing would be to clone either a branch of SIDLOC Schematic project or a forked repo :

git clone link_to_forked_repo

Then, changes can be made on the specific sheet of the SIDLOC schematic project. In our case, the RFFE sheet (which corresponds to the rffe.kicad_sch file). When the changes are ready, they shall be pushed to the branch or the forked repo.

git status

The git status command may show changes in other files, but one has to add only the file of interest.

git add rffe.kicad_sch (and any other files containing PURPOSEFUL changes)
git status

Use git status again to confirm that the correct files have been changed

git commit -s -m "message"
git push (appropriate remote and branch name  e.g. "origin master" for pushing on the master branch of the remote repo named "origin")

After pushing, a merge request can be submitted, reviewed and merged into the upstream SIDLOC Schematic repo.

Change the specific schematic and project

Now, one needs to clone the specific project they want to work on, again in a branch or fork, including the sidloc-schematic submodule.

git clone --recurse-submodules link_to_forked_repo

In case one had already cloned into the specific repo when the changes on the SIDLOC Schematic were made, they can navigate into the sidloc-schematic folder and use

git pull

A note : this folder is linked to the LSF SIDLOC schematic repository, not any forked repository. This can be seen in the .gitmodules file. So, one has to wait for the changes to be merged into the LSF SIDLOC Schematic repo. One could also change the .gitmodules file to pull changes form the forked SIDLOC Schematic repo, but this is not particularly useful as corrections might occur during the merge request review process. So it is best to wait for the changes to be merged.

After sucessfully pulling the changes in the sidloc-schematic folder, it is time to modify the board-specific components of the project. If not already done, follow the steps above to set-up the project-specific schematic :

  1. Create a hierarchical sheet whose file name points to the corresponding file in the sidloc-schematic project. In our case that would be sidloc-schematic/rffe.kicad_sch. The internals of this sheet should NOT be changed from the specific project. They are changed in the SIDLOC-Schematic with the steps described above and after pulling the changes in the ``sidloc-schematic`` folder, this sheet will be automatically updated.

  2. Check that the hierarchical sheet pins are the same as those in the common SIDLOC-Schematic. These are added manually (they are not updated when pulling changes in the sidloc-schematic).

  3. Add any connectors and parts that are specific to your board implementation of the SIDLOC project. Remember that the common SIDLOC-Schematic has no specific board implementation - one might as well put all subsystems in a big board. So, any connectors like the PQ9 connector are considered project-specific and are placed outside the hierarchical sheets.

When changes to the breadboard project are complete, then they can be committed, pushed on a fork/branch and then merged upon review.

git status

Make sure to add only the project-specific files (not files from the sidloc-schematic folder) that were PURPOSEFULLY changed (for example changes in the PCB)

git add sidloc-rffe.kicad_pcb
git status

Commit and push

git commit -s -m "Message"
git push (appropriate remote and branch name  e.g. "origin master" for pushing on the master branch of the remote repo named "origin")

Finally, submit a merge request.

General checks

  • All ports required by either the common project or the breadboard projects are exposed as hierarchical labels

  • ERC passes on all projects; unused hierarchical ports must be set to “not connected”.

  • There is no net naming conflicts

  • There is no component naming conflicts (annotations)

Integrating lsf-kicad-lib in a KiCAD project

LSF maintains a symbol, footprint and 3d model library for KiCAD under the lsf-kicad-lib repository. For LSF projects, it is good to regularly merge the symbols/footprints created for the project into the lsf-kicad-lib; contribution guidelines are written in the repository’s README. To use the library in a design, the following steps are proposed (also summarized in the README) :

  • Clone lsf-kicad-lib anywhere in your computer (choose a writeable location to allow modifications to the library)

  • Under Preferences -> Configure Paths set a new environment variable named LSF_KICAD_LIB and set the path to the location where lsf-kicad-lib is cloned

  • Under Preferences -> Manage Symbol Libraries add lsf-kicad as a global symbol library using the ${LSF_KICAD_LIB}/lsf-kicad.kicad_sym path

  • Under Preferences -> Manage Footprint Libraries add lsf-kicad-lib as a global footprint library using the ${LSF_KICAD_LIB}/lsf-kicad-lib.pretty path

Electronics Parts

  1. An inventory with electronic parts is kept in LSF lab. For that reason it is recommended to select parts from inventory that the threshold of minimum order is above 20 (more details TBA)

  2. Parts like MCUs, PSUs etc are preferred to re-used for all the projects

  3. Preferred vendors

  4. For Board to wire connectors the Molex - PicoBlade and Hirose - DF11 series are preferred

  5. A Libre Space Foundation KiCad Library exists. It is advised to use parts from it (or KiCAD libs). In case that a part does not exist a merge request in to library is more than welcome

  6. To export a BOM, for e.g. Mouser, use either bom_csv_grouped_by_value and from generated .csv use the second table of follow a guide: The Generation of Bill of Material Files

KiCAD Preferred settings

  1. Schematic grid size: 1.27mm

  2. PCB Logos: project logo, license logo and Libre Space Foundation logo.

  3. CI for KiCad (Under development)

  4. Add Fiducial points that help stencil alignment in stencil printer

FreeCAD Preferred settings

  1. For fabrication drawings use Libre Space Foundation templates

Releases

The release scheme is under development and testing in SatNOGS COMMS project

Fabrication

PCB Ordering

  1. Preferred vendors are to be followed

  2. Tag a release on the hardware repository and write all production details like this .

  3. Ping people with access according to Procurement policy.

  4. Note: Stencil size (maximum) 180x220 mm (due to stencil printer)

Assembly

PCB assembly

Libre Space Foundation uses hackerspace.gr laboratory with:

  1. Reflow oven, TBD

  2. Pick and Place, TBD

  3. Stencil printer, TBD

Mechanichal Parts assembly

TBD

Cables assembly

TBD